1.1 O problema: infraestrutura feita à mão

1.2 O que IaC resolve

Infraestrutura como Código é gerir e provisionar infraestrutura através de arquivos de definição versionados, em vez de configuração manual. Benefícios diretos:

• Versionamento e revisão: toda mudança de infra é um commit / PR, com histórico, blame, e revisão por pares.
• Reprodutibilidade: o mesmo código gera o mesmo ambiente — dev, staging, prod, DR, um novo cliente.
• Automação: CI/CD aplica a infra; humanos aprovam, não digitam.
• Documentação viva: o código é a descrição exata do que existe.
• Rollback: reverter para um commit anterior (com cuidado — Módulo 3).
• Detecção de drift: comparar o mundo real com o código e alarmar diferenças.

1.3 Declarativo × imperativo, imutável × mutável

1.4 De IaC a Platform Engineering

IaC dá às equipes de plataforma o poder de codificar infra. Mas se cada time de produto precisa escrever seu próprio Terraform, entender VPCs, IAM, Kubernetes e observabilidade, a carga cognitiva explode e a velocidade cai. Platform Engineering resolve isso empacotando as capacidades de infra num produto interno (o Internal Developer Platform) que o desenvolvedor consome por self-service, por um caminho pré-pavimentado (golden path), sem precisar ser especialista em nuvem. IaC é o motor; a plataforma é o carro que o dev dirige. Módulos 7–9.

2.1 O modelo

# providers.tf — de qual API vamos falar
terraform {
  required_providers {
    aws = { source = "hashicorp/aws", version = "~> 5.0" }
  }
}
provider "aws" { region = var.region }

# main.tf — o estado DESEJADO, declarativo
resource "aws_instance" "web" {
  ami           = data.aws_ami.ubuntu.id
  instance_type = var.instance_type
  subnet_id     = aws_subnet.public.id
  tags = { Name = "web-${var.env}", Team = "payments" }
}

# variables.tf / outputs.tf
variable "env" { type = string }
output "web_ip" { value = aws_instance.web.public_ip }

• Provider: o plugin que fala com uma API (AWS, GCP, Azure, Cloudflare, GitHub, Datadog, Kubernetes… centenas).
• Resource: um objeto de infra que o Terraform cria/atualiza/destrói.
• Data source: lê algo que já existe (uma AMI, uma VPC criada por outro time) sem gerenciá-lo.
• Variables / outputs: entradas e saídas do módulo (Módulo 4).
• HCL (HashiCorp Configuration Language): declarativa, com for_each/count, dynamic blocks, funções, expressões condicionais — mas não é uma linguagem de programação completa (por design).

2.2 O ciclo

terraform init      # baixa providers, configura o backend do state
terraform validate  # sintaxe e consistência
terraform plan      # calcula o DIFF entre o código e o state → mostra o que vai mudar
terraform apply     # executa o plan (com confirmação); atualiza o state
terraform destroy   # remove tudo que este state gerencia

2.3 Terraform × OpenTofu

• Em 2023, a HashiCorp mudou a licença do Terraform de open source (MPL) para BSL (Business Source License — restrições de uso comercial competitivo).
• A comunidade forkou a última versão MPL e criou o OpenTofu, agora um projeto da Linux Foundation, open source, drop-in compatible com a sintaxe HCL do Terraform.
• Na prática: os conceitos e o HCL são os mesmos; o tofu substitui o terraform na linha de comando. OpenTofu tem inovado (state encryption nativa, provider iteration antecipado). Escolha organizacional; para aprender, tanto faz — o conhecimento transfere 100%.

3.1 O que é o state

O state (terraform.tfstate) é o mapeamento entre os recursos que você declarou no código e os objetos reais na nuvem (com seus IDs e atributos). É como o Terraform sabe que aws_instance.web no código corresponde à instância i-0abc123 na AWS — e, portanto, o que precisa mudar no próximo plan.

3.2 Backend remoto + locking

• Backend remoto: guardar o state num storage compartilhado e criptografado (S3, GCS, Azure Blob, Terraform/HCP Cloud, um backend do Spacelift/env0). Nunca no laptop de alguém.
• State locking: um lock (DynamoDB para o backend S3, ou nativo em outros) impede que dois apply rodem ao mesmo tempo.
• Versionamento do bucket de state para conseguir recuperar uma versão anterior.
• Criptografia at-rest (e, no OpenTofu, opcionalmente client-side).
• Acesso restrito — quem lê o state lê os segredos que estão nele.

3.3 Segmentar o state (blast radius)

Um único state gigante para toda a empresa = todo apply arrisca tudo, e o plan fica lento. Segmente por fronteira de mudança e de risco:

• Por ambiente (dev / staging / prod — states separados, credenciais separadas).
• Por camada / ciclo de vida (rede e IAM mudam raramente; workloads mudam sempre — states diferentes).
• Por time / domínio (cada time dono do seu state).
• Passar valores entre states via terraform_remote_state (data source) ou, melhor, via outputs publicados / parâmetros (SSM, etc.) para reduzir acoplamento.

3.4 Operações de manutenção

4.1 Módulos

Um módulo é um conjunto de recursos empacotado com uma interface (variáveis de entrada, outputs) — a unidade de reuso do Terraform. Um bom módulo:

• Tem uma responsabilidade clara (um módulo "rede VPC", um módulo "serviço ECS", um módulo "bucket com política padrão").
• Expõe poucas variáveis essenciais + defaults sensatos; não vira um "passa-tudo" que só reembrulha o provider.
• Aplica os padrões da organização por dentro (tags obrigatórias, criptografia ligada, logging, políticas de acesso) — é onde a governança mora.
• É versionado (git tag / registry) e consumido por versão fixa (?ref=v1.4.2).
• Tem README, exemplos, e testes (Módulo 6).

module "api_service" {
  source  = "git::https://github.com/acme/tf-modules.git//ecs-service?ref=v2.3.1"
  name    = "payments-api"
  env     = var.env
  cpu     = 512
  memory  = 1024
  image   = var.image_tag
  # tags, log group, IAM role, alarms, autoscaling: aplicados DENTRO do módulo
}

4.2 Estrutura do repositório

4.3 O registry e a governança de módulos

• Registry (Terraform Registry público, ou privado no TFC/Spacelift/Artifactory) para descoberta e versionamento de módulos.
• Módulos da comunidade (ex.: terraform-aws-modules/*) são bons pontos de partida — mas fixe a versão e revise o que fazem.
• Módulos internos são o "golden path" de infra: se todo serviço é criado pelo módulo ecs-service, então criptografia, tags, alarmes e IAM mínimo vêm por padrão, sem cada time reinventar (ponte para Platform Engineering — Módulo 7).

5.1 Provisioning: as ferramentas

5.2 Config management (complementar, não substituto)

• Ansible (Chef, Puppet, Salt): configuram o interior de servidores — instalar pacotes, gerir arquivos, serviços, usuários. Provisioning (Terraform) cria a VM; config management a configura.
• Ansible é agentless (SSH), procedural-ish (playbooks com tasks idempotentes), ótimo para bootstrap, VMs legadas, tarefas de OS, e orquestração de operações.
• No mundo imutável/contêiner, config management perde peso: a "config" vira a imagem (Dockerfile) e o manifesto K8s. Ainda relevante para o que não é contêiner.

5.3 Imagens: Packer

Packer (HashiCorp) constrói imagens de máquina (AMI, imagem GCP, imagem Docker) de forma automatizada e versionada — parte-se de uma base, aplica-se provisioners (shell, Ansible), e sela-se a imagem. É o que viabiliza infra imutável: o Terraform lança instâncias a partir de uma AMI que o Packer produziu e testou, em vez de configurar cada instância no boot.

5.4 Como escolher

6.1 CI/CD para infraestrutura

Pull Request abre
   ▼
CI: fmt + validate + tflint + plan + policy check + security scan + custo estimado
   ▼
Revisão humana do PLAN (não só do código — o diff de infra é o que importa)
   ▼
Merge → CD: apply automático no ambiente-alvo (com aprovação manual para prod)
   ▼
Notificação + drift detection agendada

• O plan no PR é o coração: o revisor vê exatamente o que vai mudar na nuvem, comentado no PR.
• Ferramentas de orquestração: Atlantis (open source, comenta o plan no PR), Terraform/HCP Cloud, Spacelift, env0, Scalr — cuidam de state, locking, RBAC, política, sequência de stacks e histórico.
• Infracost no PR: estimativa de impacto de custo da mudança.
• Apply: automático para dev/staging; para prod, aprovação manual e janela.

6.2 Policy as Code

Exemplos de política: "nenhum security group com 0.0.0.0/0 na porta 22"; "todo recurso tem as tags team e cost-center"; "storage sempre criptografado"; "instâncias só de famílias aprovadas"; "nada de IAM *:*". Roda no CI e bloqueia o merge se violar (com exceções auditadas).

6.3 Testes de IaC

• terraform test (nativo, 1.6+): testes em HCL que fazem plan/apply em recursos de teste e checam asserções.
• Terratest (Go): sobe infra real efêmera, valida (faz uma request HTTP, checa um output), destrói. Mais lento, mais realista.
• Testes de contrato dos módulos: cada exemplo do módulo tem que dar plan limpo.
• Preview / ephemeral environments (Módulo 9) como teste de integração de verdade.

6.4 Segredos

• Nunca em variáveis de texto no código nem no state commitado.
• Buscar em runtime de um cofre: HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager (via data source), ou SOPS (criptografia de arquivos com KMS) para o que precisa ficar no repo.
• Lembrar que o state ainda guarda o valor resolvido → backend criptografado e acesso restrito (Módulo 3); OpenTofu tem state encryption client-side.
• Credenciais do próprio pipeline: OIDC federation (o CI assume um role sem chave estática) > chaves de longa duração.

7.1 O problema que resolve

O movimento "you build it, you run it" deu autonomia aos times de produto — mas também jogou neles a complexidade inteira da nuvem: Kubernetes, IAM, redes, Terraform, CI/CD, observabilidade, secrets, políticas de segurança. A carga cognitiva passou a competir com o tempo de construir features. Sintomas: cada time reinventa o mesmo pipeline, configura observabilidade do zero, copia Terraform de outro time (com os bugs), e leva semanas para pôr um serviço novo no ar.

7.2 Conceitos-chave

• Internal Developer Platform (IDP): o conjunto integrado de ferramentas e serviços de autoatendimento. Não é uma ferramenta só — é a montagem coerente de várias (Módulo 8).
• Internal Developer Portal: a interface / catálogo (ex.: Backstage) onde o dev descobre serviços, cria novos a partir de templates, e vê docs, donos, saúde. É a "vitrine" do IDP, não o IDP inteiro.
• Golden Path / Paved Road: a forma recomendada e suportada de fazer algo (ex.: "um serviço Go em produção" = este template + este pipeline + este runtime + observabilidade de fábrica). Quem segue o golden path anda rápido e com suporte; quem sai dele pode, mas assume a complexidade.
• Platform as a Product: a plataforma tem usuários (os desenvolvedores), um product owner, um roadmap, e sua adoção é voluntária (ela precisa ser boa o suficiente para as pessoas quererem usá-la, não ser imposta).
• Thinnest Viable Platform (TVP): começar com o mínimo que resolve a dor mais aguda (às vezes é só uma página de wiki bem feita + um template), não um mega-projeto.

7.3 Team Topologies

O modelo de Team Topologies (Skelton & Pais) dá o vocabulário organizacional:

• Stream-aligned team: o time de produto que entrega valor ao usuário final — o "cliente" da plataforma.
• Platform team: constrói e opera o IDP como produto, para reduzir a carga cognitiva dos stream-aligned.
• Enabling team: ajuda os stream-aligned a adotar novas capacidades (coaching temporário).
• Complicated-subsystem team: dono de uma parte que exige especialização profunda.
• Modo de interação preferido entre platform e stream-aligned: X-as-a-Service (consome sem precisar conversar), com colaboração pontual quando algo novo é construído.

8.1 As capacidades de um IDP

8.2 Abstrações: o "workload spec"

A ideia de ponta: o dev descreve o que a aplicação precisa em termos abstratos ("um serviço web, um banco Postgres, uma fila"), e a plataforma traduz isso para a infra concreta (RDS ou Cloud SQL, SQS ou PubSub) conforme o ambiente e as políticas. Ferramentas/padrões:

• Score (open source, CNCF sandbox): um spec de workload agnóstico de plataforma.
• Crossplane Compositions: definir "Database" como um XRD que compõe recursos reais.
• Kratix: "promises" — a plataforma publica um contrato ("peça um Postgres") e um pipeline o materializa.
• Humanitec, Kubevela, Radius: platform orchestrators comerciais/open source que fazem essa tradução.

8.3 Construir × comprar

8.4 Medir o sucesso da plataforma

• Métricas DORA (DevOps Research): frequência de deploy, lead time para mudança, taxa de falha de mudança, tempo de restauração — a plataforma deve melhorá-las.
• DevEx / carga cognitiva: pesquisas ("SPACE framework"), tempo para o primeiro deploy de um novo contratado, NPS da plataforma.
• Adoção: % de serviços no golden path; % de times usando o self-service vs abrindo chamado.
• "Time to hello world": quanto tempo da ideia ao serviço em produção — a métrica-síntese.
• Custo por serviço/ambiente (cruza com FinOps).

9.1 GitOps

GitOps aplica o modelo de reconciliação do Kubernetes ao deploy: o estado desejado vive num repositório git, e um agente no cluster (pull) compara continuamente o cluster com o git e converge — em vez de um pipeline "empurrar" (push) mudanças de fora.

• Ferramentas: Argo CD, Flux (ambos CNCF graduados).
• Estrutura comum: um repo de "config" por ambiente; promoção entre ambientes = PR que atualiza a tag da imagem / os valores.
• GitOps é sobretudo para o runtime (K8s manifests, Helm) — para infra de nuvem, combina-se com Crossplane (infra como CRDs reconciliados por GitOps) ou com o Terraform rodando via Flux/Atlantis.

9.2 Ambientes efêmeros

Um ambiente completo criado por PR (preview environment) e destruído no merge/close — a infra e o app juntos, isolados. Dá teste de integração de verdade, revisão de UX pelo time de produto, e "nada esquecido ligado". Habilitado por IaC parametrizado + namespaces/clusters efêmeros + GitOps. Ferramentas: vCluster, Crossplane, Qovery, Uffizzi, ou pipelines próprios.

9.3 Multi-cluster e multi-cloud

• Multi-cluster (vários clusters K8s por região/tenant/blast radius): gerido por GitOps (Argo CD "app of apps" / ApplicationSets), Cluster API para provisionar clusters como código, fleet management (Rancher, GKE Fleet).
• Multi-cloud é caro em complexidade — faça só com motivo real (soberania, resiliência regulatória, evitar lock-in crítico). O denominador comum costuma ser Kubernetes + Terraform/OpenTofu + Crossplane; evitar depender de serviços proprietários únicos de um provedor no caminho crítico.

9.4 Segurança da supply chain de IaC

• Módulos e providers de terceiros: fixar versões e hashes (.terraform.lock.hcl), revisar antes de adotar, mirror interno.
• Policy as code obrigatória no pipeline (Módulo 6) — o gate que impede o recurso inseguro.
• Least privilege do pipeline: o role que aplica infra deve poder mudar só o que aquele stack gerencia; OIDC em vez de chaves.
• Proteção do state: criptografia, acesso mínimo, versionamento (é onde os segredos moram).
• Assinatura e proveniência das imagens (Packer/contêiner) — cosign, SLSA.
• Compliance as code: mapear controles (CIS Benchmarks, SOC2, ISO 27001) para políticas automatizadas e evidências geradas pelo pipeline.

9.5 O que vem por aí

• IA gerando e revisando IaC: copilots que escrevem módulos, explicam o plan, sugerem correções de política — útil como acelerador, com revisão humana (o plan continua sendo a autoridade).
• Platform orchestrators amadurecendo (Score, Radius, Kratix) — a abstração de workload virando padrão.
• Convergência infra + runtime via Crossplane/GitOps — um só modelo de reconciliação para tudo.
• Plataformas para IA/ML (golden path para treinar/servir modelos — ver apostilas de MLOps e LLMOps).
• FinOps embutido na plataforma (custo por serviço visível no portal, guardrails de custo no provisioning — ver apostila de FinOps).

10.1 Os perfis que contratam

10.2 Certificações e leituras

• HashiCorp Certified: Terraform Associate — a mais citada; cobre bem os Módulos 2–4.
• CKA / CKAD (Kubernetes) — quase pré-requisito para plataforma moderna.
• Certificações de nuvem a nível de arquitetura/associate (AWS/GCP/Azure).
• Leitura: Terraform: Up & Running (Yevgeniy Brikman); Infrastructure as Code (Kief Morris); Team Topologies (Skelton & Pais); Platform Engineering on Kubernetes (Mauricio Salatino); o site platformengineering.org e o Internal Developer Platform reference architecture; os DORA reports.

10.3 Roadmap de estudo (8–10 semanas)

10.4 Banco de perguntas de entrevista (com a resposta que aprova)

10.5 Projetos de portfólio que geram entrevista

1. Stack multi-ambiente (âncora): uma aplicação real provisionada com Terraform/OpenTofu em dev/staging/prod, via um módulo de serviço versionado com governança embutida (tags, criptografia, IAM mínimo, alarmes), state remoto segmentado, e CI com plan no PR + Checkov + política OPA custom + Infracost. README com as decisões.
2. Golden path de serviço: um template (Backstage scaffolder ou cookiecutter) que cria repo + pipeline + infra + observabilidade OTel de fábrica — "do zero a produção em minutos", demonstrado.
3. GitOps end-to-end: Argo CD/Flux com self-heal e prune, promoção entre ambientes por PR, e a demonstração de drift sendo revertido.
4. Crossplane ou Pulumi: refazer uma parte da stack com uma segunda ferramenta, comparando os trade-offs por escrito.
5. Migração para IaC: pegar recursos criados à mão e trazê-los para o Terraform via blocos import, chegando a "no changes", documentando o processo.