HashiCorp Terraform Associate
Última revisão: maio de 2026
Uma referência rápida dos padrões arquiteturais que o exame 004 avalia. Leia de cima a baixo ou pule para uma seção.
Uma equipa clica manualmente em consolas cloud; ninguém sabe como a produção deveria ser.
Adotar IaC. As configurações residem em ficheiros versionados — os ficheiros são a fonte autoritativa da verdade, não a consola cloud.
Por quê: Registo de auditoria, revisão por pares, rollback e replicação fluem todos do controlo de versão. O provisionamento manual não tem nenhum destes.
Escolher entre descrever o estado final desejado versus scriptar os passos para alcançá-lo.
Terraform é declarativo. Você descreve o alvo; Terraform descobre as chamadas API. Ansible, scripts Bash, SDKs personalizados são imperativos.
Por quê: Configurações declarativas são idempotentes e convergem independentemente do estado inicial. Scripts imperativos devem raciocinar sobre cada transição.
O engenheiro quer que o mesmo `terraform apply` possa ser executado novamente com segurança sem duplicar recursos.
Idempotente por design. Aplicar a mesma configuração repetidamente converge para o mesmo estado — sem duplicatas, sem drift.
Detetar quando a realidade divergiu do que a configuração diz (alguém clicou na consola).
`terraform plan -refresh-only` lê o estado atual da cloud e reporta diferenças em relação ao estado sem propor alterações.
Distinguir o provisionamento inicial das operações contínuas.
Dia 0 = design e planeamento. Dia 1 = provisionamento inicial (primeiro apply). Dia 2 = operações contínuas: patching, escalonamento, rotação de certificados, remediação de drift.
Por quê: A maioria do trabalho de produção é do Dia 2. As ferramentas IaC devem suportar iteração, não apenas a primeira implantação.
Reduzir o risco de drift da consola; exigir que todas as alterações de infraestrutura passem por revisão.
GitOps com IaC: git é a fonte da verdade, PRs desencadeiam plans, merges desencadeiam applies. Bloquear acesso direto à consola via SCP/IAM.
Carga de trabalho abrange AWS e GCP; a equipa quer uma única ferramenta, um único fluxo de trabalho.
Terraform com múltiplos providers numa única configuração: `hashicorp/aws` + `hashicorp/google`. Saídas de um provider alimentam entradas de outro.
Por quê: Core agnóstico ao provider; SDKs por cloud residem em providers plugáveis. CloudFormation/ARM são single-cloud.
Etapas padrão do ciclo de vida do Terraform.
`init` (download de providers + backend) → `plan` (pré-visualização) → `apply` (executar) → `destroy` (desmantelar). `plan` é apenas de leitura e seguro.
Por que o Terraform precisa de um ficheiro de estado em vez de consultar a cloud a cada execução?
O estado mapeia endereços de configuração (`aws_instance.web`) para IDs de recursos reais, rastreia dependências e armazena metadados em cache. Sem ele, o Terraform não consegue saber quais recursos da cloud ele gere versus quais foram criados noutro local.
Escolher entre CLI de código aberto e HCP Terraform.
Solo / pequena equipa / sem imposição de política → CLI OSS com backend remoto. Múltiplas equipas / políticas Sentinel/OPA / execuções impulsionadas por VCS / credenciais dinâmicas → HCP Terraform.
Por quê: Ambos executam o mesmo binário Terraform; o HCP adiciona colaboração, governança e infraestrutura de remote-runner.
Provisionar VMs versus configurar software dentro delas.
Terraform provisiona recursos cloud (VMs, redes, IAM). Ansible/Chef/Puppet configuram software dentro das VMs. São complementares, não concorrentes.
Uma empresa apenas AWS a debater CloudFormation vs Terraform.
CloudFormation tem integração AWS mais estreita, rollback nativo e zero gestão de ficheiros de estado. Terraform ganha em multi-cloud, ecossistema de módulos maior e ergonomia HCL. Escolha CFN se for apenas AWS e o rollback for o mais importante; Terraform caso contrário.
Fixar a origem e a versão do provider para instalações reproduzíveis.
Declarar em `terraform { required_providers { aws = { source = "hashicorp/aws", version = "~> 5.0" } } }`.
Por quê: Sem `required_providers` explícitos, o Terraform assume namespaces de registo legados e pode escolher versões incompatíveis.
A configuração tem `required_providers` para AWS mas nenhum bloco `provider "aws"`.
O Terraform cria uma configuração de provider vazia por defeito. O provider AWS lê então `AWS_ACCESS_KEY_ID`/`AWS_PROFILE`/IMDS na sua precedência padrão.
Por quê: Um bloco `provider` explícito é opcional; é necessário apenas para substituir valores predefinidos ou para criar aliases de várias instâncias.
Decidir qual operador de restrição de versão usar.
`~> 5.0` permite `>= 5.0, < 6.0` (qualquer 5.x). `~> 5.0.1` permite `>= 5.0.1, < 5.1.0` (apenas atualizações de patch). `>= 5.0` sem limite superior. `= 5.2.0` exato. `!= 5.3.0` exclusão.
Por quê: O operador pessimista `~>` permite apenas que o componente de versão mais à direita cresça.
O que faz `terraform init` na verdade?
Faz o download de providers por `required_providers`, inicializa o backend, faz o download das fontes dos módulos e escreve `.terraform/` mais `.terraform.lock.hcl`. Requerido antes de `plan` ou `apply`.
Um ficheiro `.terraform.lock.hcl` apareceu depois de `init`. Fazer commit ou gitignore?
Faça commit. O ficheiro de lock regista as versões exatas do provider + checksums criptográficos. Garante que todos os colaboradores e CI runners instalem providers idênticos.
Por quê: Sem ele, `terraform init` pode escolher uma versão compatível mais recente numa máquina diferente, introduzindo diffs inesperados.
Padronizar espaços em branco, alinhamento e indentação em ficheiros `.tf`.
`terraform fmt` reescreve os ficheiros `.tf` no local para um estilo canónico. Executar em pre-commit hooks e CI.
Detetar erros de sintaxe e incompatibilidades de tipo sem aceder a APIs cloud.
`terraform validate` verifica a sintaxe HCL, consistência de tipos, argumentos obrigatórios e referências internas. Apenas local, sem necessidade de autenticação do provider.
Por quê: Não deteta problemas do lado do provider (autenticação, recursos em falta) — estes só surgem em `plan`.
CI executa `terraform init` repetidamente em muitos projetos, cada um a descarregar os mesmos providers do zero.
Defina `TF_PLUGIN_CACHE_DIR` (ou `plugin_cache_dir` na configuração do CLI). Os providers são descarregados uma vez e linkados simbolicamente para diretórios `.terraform/` por projeto.
Os endereços de origem do provider seguem que formato?
`<hostname>/<namespace>/<type>` — por exemplo, `registry.terraform.io/hashicorp/aws`. O hostname omitido assume o Terraform Registry público. Namespace = fornecedor. Type = nome do provider.
Impedir que colaboradores executem uma versão incompatível do CLI Terraform.
`terraform { required_version = ">= 1.5, < 2.0" }`. O CLI recusa-se a operar se a versão em execução não corresponder.
Escolher autenticação do provider para um CI/CD runner.
Melhor: credenciais dinâmicas de curta duração (confiança OIDC para AWS/Azure/GCP, credenciais de provider dinâmicas do HCP Terraform). Aceitável: variáveis de ambiente (`AWS_ACCESS_KEY_ID`). Evitar: credenciais hardcoded no bloco `provider`.
Por quê: Segredos estáticos de longa duração na configuração são a principal causa de incidentes de credenciais vazadas.
Onde vivem as configurações de alto nível?
Um bloco `terraform { ... }` contém `required_version`, `required_providers`, `backend`, `cloud` e experimentos. Múltiplos blocos `terraform` em diferentes ficheiros são mesclados.
O recurso existe no estado mas não deve mais ser gerido pelo Terraform; o recurso cloud deve continuar a funcionar.
`terraform state rm <addr>`. Remove do estado sem destruir o recurso cloud.
Refatorou o nome de um recurso ou moveu-o para um módulo; quer evitar destroy/recreate.
`terraform state mv <old> <new>`. Atualiza o mapeamento de estado sem tocar nos recursos da cloud.
Por quê: No Terraform 1.1+, prefira o bloco `moved` em HCL — é revisável, controlado por versão e funciona em planos de PR.
URL do registo de provider interno mudou; o estado existente ainda referencia o endereço de origem antigo.
`terraform state replace-provider <old-source> <new-source>`. Reescreve as referências de provider no estado.
O apply falhou a meio da execução; o lock do DynamoDB está preso e outros engenheiros estão bloqueados.
`terraform force-unlock <LOCK_ID>` (o ID do lock está na mensagem de erro). Verifique se mais ninguém está a executar antes de desbloquear.
Por quê: Locks não são liberados automaticamente em caso de falha porque a fase de limpeza nunca foi executada.
Um bucket S3 existente criado manualmente precisa ser gerido pelo Terraform sem recriação.
Escreva o bloco de recurso, depois `terraform import aws_s3_bucket.legacy legacy-bucket-name`. O estado agora regista o bucket existente; planos subsequentes mostram apenas drift.
Precisa importar muitos recursos de forma reproduzível através de CI em vez de comandos CLI ad-hoc.
Use o bloco `import` (Terraform 1.5+): `import { to = aws_s3_bucket.legacy, id = "legacy-bucket-name" }`. As importações acontecem durante `apply`, são controladas por versão e funcionam na saída do plan.
Depurar um erro de provider críptico; precisa de rastreamentos HTTP completos.
`TF_LOG=TRACE` (o mais verboso). `TF_LOG_PATH=./tf.log` escreve para um ficheiro. Outros níveis: DEBUG, INFO, WARN, ERROR.
Testar uma expressão como `merge()` ou `cidrsubnet()` contra o estado atual sem aplicar.
`terraform console` abre um REPL interativo com a configuração atual + estado no âmbito. Útil para prototipar locals e outputs.
Visualizar o DAG de dependência de uma configuração complexa.
`terraform graph | dot -Tsvg > graph.svg` produz uma visualização Graphviz das dependências de recursos.
Ler uma saída Terraform de um script CI.
`terraform output -json <name>` emite JSON seguro para parsing com `jq`. `terraform output` normal é formatado para humanos e não é seguro para scripts.
Forçar um único recurso a ser recriado no próximo apply.
`terraform apply -replace=aws_instance.web` (Terraform 1.x). O legado `terraform taint` está deprecado.
Por quê: `-replace` é revisável na saída do plan; `taint` mutava o estado silenciosamente antes do próximo plan.
Inspecionar o que está atualmente rastreado no estado.
`terraform state list` mostra todos os endereços de recurso. `terraform state show <addr>` mostra atributos para um recurso. Para recursos indexados use aspas: `terraform state show 'aws_instance.web[0]'`.
Escolher uma origem de módulo.
Caminho local → `./modules/vpc`. Registo público → `terraform-aws-modules/vpc/aws`. Git → `git::https://github.com/org/repo.git//path?ref=v1.0`. S3/HTTP/Mercurial também são suportados.
Fixar um módulo de registo para permitir apenas atualizações de patch.
`version = "~> 3.5.2"` permite `>= 3.5.2, < 3.6.0`. Para tolerância a atualizações menores, use `~> 3.0` (qualquer 3.x). Módulos de caminho local não suportam `version`.
Módulos apenas internos com visibilidade em toda a organização.
HCP Terraform Private Module Registry. Endereço: `app.terraform.io/<org>/<name>/<provider>`. Versões detetadas a partir de tags Git seguindo semver (`v1.2.0`).
Tanto o registo público quanto o registo privado do HCP Terraform detetam as versões dos módulos através de que mecanismo?
Git tags seguindo o versionamento semântico (`v1.2.0` ou `1.2.0`). Fazer push de uma nova tag → nova versão disponível.
Expor o ARN de um bucket criado à configuração que o invoca.
Dentro do módulo: `output "bucket_arn" { value = aws_s3_bucket.this.arn }`. O chamador lê como `module.<name>.bucket_arn`.
Parametrizar um módulo para que os chamadores possam fornecer CIDR, nome, tags.
Blocos `variable` na raiz do módulo definem entradas. Os chamadores passam-nas inline: `module "vpc" { source = "...", cidr = "10.0.0.0/16" }`.
O módulo recebe uma palavra-passe de base de dados como input; o valor nunca deve aparecer na saída do CLI.
Marque a variável `sensitive = true`. A saída de apply/plan mostra `(sensitive value)`. Nota: ainda armazenado em plaintext no estado.
Construir um módulo de "plataforma" que internamente invoca módulos VPC + EKS + RDS.
Um módulo pode chamar outros módulos. Conecte as saídas de um como entradas para o próximo: `eks_subnet_ids = module.vpc.private_subnet_ids`.
Instanciar o mesmo módulo N vezes com inputs diferentes (ex: um por região).
`module "regional" { for_each = toset(["us-east-1", "eu-west-1"]), source = "...", region = each.key }`. Referência via `module.regional["us-east-1"].output_name`.
O módulo precisa de um provider com alias (por exemplo, para uma região não padrão).
O chamador passa o bloco `providers = { aws = aws.us_west }` na invocação do `module`. O módulo declara `configuration_aliases = [aws.us_west]` em `required_providers`.
Endereçar um módulo de registo público.
`<NAMESPACE>/<NAME>/<PROVIDER>` — por exemplo, `terraform-aws-modules/vpc/aws`. Tags Git impulsionam as versões.
Reutilizar o mesmo módulo em dev/staging/prod.
Dois padrões: (1) Workspaces com uma configuração raiz + `*.tfvars` por workspace. (2) Configurações raiz por ambiente (`envs/dev/main.tf`, `envs/prod/main.tf`), cada uma chamando módulos partilhados. O padrão 2 é mais comum para isolamento entre múltiplas equipas.
Garantir que o CI aplique exatamente o que foi revisado no plan, sem drift entre as etapas.
`terraform plan -out=tfplan` guarda o plan. Depois `terraform apply tfplan` aplica esse plan exato. Recusar-se a replanear elimina o risco de time-of-check/time-of-use.
Decodificar os símbolos de saída do plan: `+`, `-`, `~`, `-/+`, `<=`.
`+` criar. `-` destruir. `~` atualizar no local. `-/+` destruir e depois criar (substituir). `<=` ler (data source). O símbolo de substituição significa que um atributo `forces replacement` mudou.
Corrigir rapidamente um recurso quebrado sem tocar no resto da configuração.
`terraform apply -target=aws_instance.web`. Use com moderação — ignora o rastreamento de dependências e pode deixar o estado inconsistente. Documente por que cada `-target` foi usado.
Por quê: A HashiCorp diz explicitamente que `-target` é para resolução de problemas excecional, não para o fluxo de trabalho normal.
Forçar um recurso específico a ser recriado.
`terraform apply -replace=aws_instance.web`. Substitui o fluxo de trabalho deprecado `terraform taint`.
Desmantelar tudo na configuração atual.
`terraform destroy` (ou `terraform apply -destroy`). Planeia o inverso da configuração. Requer confirmação a menos que `-auto-approve`.
Destruir um recurso sem afetar outros.
`terraform destroy -target=aws_instance.web`. As mesmas ressalvas de `-target` que no apply — use com moderação.
Detetar drift sem propor alterações.
`terraform plan -refresh-only`. Atualiza o estado a partir dos recursos reais e reporta diferenças, mas não gera um plano de modificação de recursos.
Por quê: Substitui o comando `terraform refresh` autônomo e deprecado.
O Recurso A deve existir antes do Recurso B, mas B não referencia os atributos de A.
Adicione `depends_on = [resource_a.name]` a B. Use apenas quando referências implícitas de atributos não conseguem expressar a dependência (ex: a política IAM deve propagar antes que o EC2 a utilize).
Substituir um recurso sem tempo de inatividade.
`lifecycle { create_before_destroy = true }`. O Terraform cria o novo recurso primeiro, redireciona as referências e depois destrói o antigo.
Por quê: O padrão é destruir-depois-criar, o que causa tempo de inatividade. Nota: os recursos dependentes também devem suportar a alteração.
Prevenir a destruição acidental da base de dados de produção por `terraform destroy`.
`lifecycle { prevent_destroy = true }`. Faz com que `terraform plan` falhe se uma destruição for proposta para esse recurso.
Por quê: Barreira de última linha — não protege contra `terraform state rm` seguido de destroy.
A aplicação define uma tag em tempo de execução que o Terraform continua a reverter.
`lifecycle { ignore_changes = [tags["LastDeployed"]] }`. O Terraform ignora o drift nesses atributos.
Substituir uma instância EC2 sempre que um launch template relacionado muda (sem modificar o EC2 diretamente).
`lifecycle { replace_triggered_by = [aws_launch_template.web.latest_version] }` (Terraform 1.2+). A instância é substituída quando qualquer valor listado muda.
Pipeline CI/CD aplica após um trabalho de planificação bem-sucedido; sem humano ao teclado.
`terraform apply -auto-approve` ignora a confirmação interativa. Combine com um ficheiro de plan guardado (`terraform apply tfplan`) para tornar o CI determinístico.
O provider de cloud aplica limites de taxa ao Terraform; muitas criações de recursos estão a falhar intermitentemente.
`terraform apply -parallelism=5` (padrão 10) limita as operações de recursos concorrentes.
Dois recursos não têm dependências um no outro.
O Terraform cria-os em paralelo. O DAG impõe a sequenciação apenas ao longo das arestas de referência.
Por quê: Recursos com a mesma profundidade DAG são executados concorrentemente até `-parallelism`.
Variável definida em `terraform.tfvars`, variável de ambiente `TF_VAR_region` E flag CLI `-var=region=...`.
O mais alto vence: CLI `-var` / `-var-file` > `*.auto.tfvars` (ordem lexical) > `terraform.tfvars` > `TF_VAR_*` env > valor padrão da variável.
Passar valores de variáveis específicos do ambiente sem verificar segredos no git.
`terraform apply -var-file=prod.tfvars`. Os ficheiros `*.auto.tfvars` carregam automaticamente. `terraform.tfvars` também carrega automaticamente.
Refatorar o nome/caminho de um recurso em HCL sem destroy/recreate.
`moved { from = aws_instance.old_web; to = aws_instance.new_web }` (Terraform 1.1+). Revisável no plan de PR; substitui o `terraform state mv` ad-hoc.
Por quê: Reside em HCL, controlado por versão, idempotente entre colaboradores. `state mv` é um efeito colateral de CLI único.
Remover um recurso da configuração sem o destruir.
`removed { from = aws_instance.legacy; lifecycle { destroy = false } }` (Terraform 1.7+). Substitui o `terraform state rm` ad-hoc. Defina `destroy = true` para também destruir.
O CI precisa saber se um plan tem alterações sem analisar o texto.
`terraform plan -detailed-exitcode`. 0 = sem alterações, 1 = erro, 2 = alterações presentes. Impulsiona trabalhos de PR "apenas plan".
O que o estado realmente contém?
Mapeamento de endereço de recurso → ID de recurso cloud, snapshots de atributos, metadados do gráfico de dependências e referências de módulo/provider. Usado para planear diffs e detetar drift.
Engenheiro individual a prototipar localmente — o estado local é OK?
Sim para trabalho solo descartável. Terraform escreve `terraform.tfstate` ao lado da configuração. Mude para um backend remoto no momento em que uma segunda pessoa, um CI runner, ou um ambiente de produção esteja envolvido.
A equipa precisa de estado partilhado entre engenheiros, com locking + versioning, alojado na AWS.
Backend S3. Configure `bucket`, `key`, `region`. Adicione `dynamodb_table` para bloqueio de estado. Ative o versionamento de bucket + encriptação SSE-KMS server-side.
Por quê: S3 + DynamoDB é o backend remoto canónico alojado na AWS. O versionamento recupera de estados corrompidos ou acidentalmente sobrescritos.
Estado partilhado alojado no Azure sem credenciais estáticas no CI.
Tipo de backend `azurerm`. Defina `use_msi = true` (Managed Identity) ou `use_oidc = true` para que o runner se autentique via sua identidade. Blob lease nativo lida com o locking.
Estado partilhado alojado no GCP com versionamento de objetos.
Tipo de backend `gcs`. Configure `bucket` + `prefix`. GCS tem gerações de objetos incorporadas (versionamento); locking via GCS object lock.
Dois engenheiros executam apply simultaneamente contra o mesmo estado suportado por S3.
A tabela de lock do DynamoDB impede escritas concorrentes. O primeiro adquire o lock, o segundo vê um erro `state lock failed` e deve esperar ou `force-unlock` se o lock estiver obsoleto.
Por quê: Sem DynamoDB, applies concorrentes podem corromper o ficheiro de estado S3.
HCP Terraform — devo configurar o DynamoDB?
Não. O HCP Terraform lida com o estado, locking e encriptação nativamente. Basta declarar `cloud { ... }` em vez de um backend.
Migrar do estado local para o backend S3.
Adicione o bloco `backend "s3"`. Execute `terraform init -migrate-state`. O Terraform copia o estado local para S3 e pede confirmação.
A configuração do backend mudou (ex: novo bucket) mas não quer migrar o estado existente.
`terraform init -reconfigure`. Reinicializa o backend e ignora a cache local existente. Use quando intencionalmente começa do zero.
Gerir dev / staging / prod com uma única configuração raiz.
Workspaces — `terraform workspace new staging`, `terraform workspace select prod`. Cada um tem o seu próprio ficheiro de estado. Referência via `terraform.workspace` em HCL.
Por quê: Opção leve. Para isolamento real (IAM diferente, contas separadas), prefira configurações raiz por ambiente.
Onde o backend local armazena o estado do workspace?
Workspace `default` → `terraform.tfstate` na raiz do projeto. Outros workspaces → `terraform.tfstate.d/<NAME>/terraform.tfstate`.
Executar `terraform workspace select prod` enquanto os recursos de staging existem.
Os recursos de staging não são afetados. Mudar de workspace apenas altera qual ficheiro de estado o Terraform lê a seguir — é uma mudança de ponteiro local.
Ver workspaces disponíveis e o ativo.
`terraform workspace list` (asterisco marca o atual). `terraform workspace show` imprime apenas o nome atual.
A equipa de segurança pergunta como o Terraform lida com senhas RDS no estado.
Valores sensíveis são armazenados em **texto simples** no estado. Mitigações: encriptar o backend em repouso (S3 SSE-KMS, HCP nativo), restringir o acesso IAM ao bucket de estado e evitar colocar segredos no Terraform quando possível.
Por quê: A flag `sensitive = true` apenas oculta valores da saída do CLI, não do estado.
A conformidade exige encriptação em repouso no estado.
S3: ativar SSE-KMS no bucket. Azure: encriptação de conta de armazenamento (padrão LIGADO). GCS: chaves de encriptação geridas pelo cliente. HCP Terraform: encriptado nativamente em repouso.
Engenheiro executou `terraform destroy` contra prod por engano. Estado agora vazio.
Restaurar a versão anterior do ficheiro de estado do versionamento do S3, depois executar `terraform plan` para ver o que o Terraform agora pensa que precisa ser criado/importado. Combine com a restauração do lado da cloud (snapshots, `aws backup`) para os recursos destruídos.
O ficheiro de estado parece errado; tentado a editá-lo diretamente.
Não. Use os subcomandos `terraform state` (`mv`, `rm`, `replace-provider`, `pull`, `push`). Edições manuais de JSON ignoram verificações de integridade e corrompem a linhagem.
Inspecionar o JSON de estado remoto bruto, ou fazer push de um ficheiro de estado recuperado.
`terraform state pull` escreve o estado remoto atual para stdout. `terraform state push <file>` sobrescreve o remoto com o ficheiro dado. Push é destrutivo — faça backup primeiro.
Passar um token de API temporário através do Terraform sem que ele vá parar ao estado.
Marque a variável `ephemeral = true` (Terraform 1.10+). Valores efémeros nunca são persistidos em ficheiros de estado ou plan. Para exportar através de uma saída de módulo, marque também a saída `ephemeral = true`.
Por quê: `sensitive` está oculto no CLI mas armazenado em plaintext no estado. `ephemeral` nunca é realmente armazenado.
Diferença entre um argumento `sensitive` e um argumento write-only (ex: `password_wo`).
`sensitive` é armazenado em estado plaintext, apenas redigido no CLI. Write-only **nunca** é armazenado no estado. Para detetar alterações em atributos write-only, o Terraform usa um campo de versão companheiro (ex: `password_wo_version`).
Mostrar um elemento de um recurso `count` no estado.
Cite o endereço: `terraform state show 'aws_instance.web[0]'`. Sem aspas, a shell pode interpretar os parênteses.
Equipas diferentes precisam operar independentemente sem interferir no estado umas das outras.
Um ficheiro de estado por equipa (ou por ambiente por equipa). Backends/buckets separados. Use `terraform_remote_state` data source para ler outro estado apenas para leitura.
Equipa de rede gere a VPC; equipa de aplicação precisa do ID da VPC.
`data "terraform_remote_state" "network" { backend = "s3"; config = { bucket = "...", key = "network/terraform.tfstate" } }`. Referencie as saídas como `data.terraform_remote_state.network.outputs.vpc_id`.
Por quê: Apenas leitura — o estado da equipa de rede não é bloqueado ou modificado.
Configuração escrita para Terraform 0.13; quer usar 1.x.
Os ficheiros de estado são compatíveis com versões futuras: 1.x lê o estado 0.13. A HashiCorp recomenda atualizações incrementais (0.13 → 0.14 → … → 1.x) executando cada versão contra o estado.
Alguém modificou um grupo de segurança via consola; quer que o Terraform reafirne ou aceite o novo estado.
Reafirmar: `terraform apply` — Terraform reverte para a configuração. Aceitar: atualizar HCL para corresponder à realidade, depois aplicar (sem diff). Detetar primeiro via `terraform plan -refresh-only`.
Tipar fortemente uma variável.
Primitivos: `string`, `number`, `bool`. Coleções: `list(<type>)`, `set(<type>)`, `map(<type>)`. Estruturais: `object({...})`, `tuple([...])`. Use `any` apenas quando for verdadeiramente polimórfico.
Restringir `environment` a dev/staging/prod.
`variable "environment" { validation { condition = contains(["dev","staging","prod"], var.environment); error_message = "..." } }`. Múltiplos blocos `validation` permitidos; todos devem passar.
Gerar uma palavra-passe de base de dados sem que ela apareça em `terraform output`.
`output "db_password" { value = ...; sensitive = true }`. O CLI mostra `(sensitive value)`. Ainda legível via `terraform output db_password` ou `-json` (intencionalmente — para scripts).
Calcular um valor uma vez e reutilizá-lo em vários recursos.
`locals { common_tags = merge(var.tags, { Project = var.project }) }`. Referencie como `local.common_tags`. Não substituível de fora do módulo.
Procurar uma AMI existente sem a gerir.
`data "aws_ami" "ubuntu" { most_recent = true; filter { ... } }`. Apenas leitura. Referencie atributos como `data.aws_ami.ubuntu.id`.
Criar N recursos semelhantes — escolher `count` ou `for_each`.
`for_each` (com map ou set) quando os itens têm identidade estável (nomes de região, chaves de ambiente). `count` para "preciso de N cópias, a ordem não importa, a identidade é apenas um índice". Adicionar/remover no meio de `count` causa destroy/recreate; `for_each` preserva a identidade.
Criar um recurso por item numa lista de strings.
`for_each = toset(["a", "b", "c"])`. `each.key` e `each.value` dão ambos a string. Para mapas: `for_each = var.users` — `each.key` = chave do map, `each.value` = valor do map.
Gerar um número variável de blocos aninhados (ex: regras de ingresso).
`dynamic "ingress" { for_each = var.rules; content { from_port = ingress.value.from; ... } }`. O argumento `iterator` pode renomear o iterador se necessário.
Obter uma lista de atributos em todas as instâncias de um recurso `count`.
`aws_instance.web[*].id` retorna uma lista de IDs. Funciona com `count` e `for_each` (mas `for_each` produz um map não ordenado, então `values(aws_instance.web)[*].id`).
Definir um valor com base numa condição.
Ternário: `var.is_prod ? 5 : 1`. Ambas as ramificações devem produzir o mesmo tipo.
Combinar dois mapas; os valores do segundo vencem em caso de colisão de chaves.
`merge(local.defaults, local.overrides)`. O mapa mais à direita vence. Útil para composição de tags.
Ler um valor de mapa com um padrão se a chave estiver em falta.
`lookup(var.config, "region", "us-east-1")`. Retorna o valor padrão quando a chave não está presente. Para estruturas profundamente opcionais, prefira o `try()` opcional.
Colapsar listas aninhadas numa lista plana.
`flatten([["a","b"], ["c"], [["d","e"]]])` → `["a","b","c","d","e"]`. Achata listas recursivamente; preserva a ordem.
Incorporar um mapa Terraform num documento de política IAM.
`jsonencode({Version = "2012-10-17", Statement = [...]})`. Produz uma string JSON. Inverso: `jsondecode()`.
Renderizar um script user-data com template com valores de variáveis.
`templatefile("init.sh.tpl", { region = var.region, env = var.env })`. O template usa a sintaxe `${region}`. Alternativa mais recente para renderização estática: `file()` + `format()`.
Esculpir CIDRs de subnet a partir de um range de VPC.
`cidrsubnet("10.0.0.0/16", 8, 0)` → `10.0.0.0/24`. Primeiro arg = pai, segundo = bits a estender, terceiro = número da subnet.
Ler um valor que pode não existir; recorrer a um padrão.
`try(yamldecode(file("config.yaml")), { defaults = true })`. Avalia da esquerda para a direita; retorna a primeira expressão sem erro.
Iterar sobre ficheiros que correspondem a um glob.
`fileset(path.module, "configs/*.json")` retorna um conjunto de caminhos. Combine com `for_each` para gerir um recurso por ficheiro.
Mesmo provider em duas regiões (ex: AWS us-east-1 + us-west-2).
Dois blocos `provider "aws" { alias = "..." }`. Recursos optam via `provider = aws.us_west`. Módulos aceitam aliases via `configuration_aliases`.
Executar um comando shell numa VM recém-criada.
Provisioner `remote-exec` dentro de um recurso. Ferramenta de último recurso — prefira cloud-init, user data ou gestão de configuração. Os provisioners não são rastreados no estado e não são executados novamente em caso de drift.
Executar um comando que não corresponde a um recurso cloud (ex: invocação CLI).
`resource "null_resource" "trigger" { triggers = { sha = sha1(file(".")) }; provisioner "local-exec" { command = "..." } }`. Re-executa quando `triggers` mudam.
Verificar continuamente um invariante de tempo de execução (ex: endpoint de saúde retorna 200) sem bloquear o apply.
`check "endpoint" { data "http" "h" { url = "..." }; assert { condition = data.http.h.status_code == 200; error_message = "..." } }`. Executa em plan/apply; falha é um aviso, não um erro grave.
Por quê: `check` permite data sources com escopo utilizáveis apenas dentro da verificação. `precondition`/`postcondition` são erros graves em plan/apply.
Falhar o plano se uma AMI for muito antiga.
`lifecycle { precondition { condition = data.aws_ami.x.creation_date > "2024-01-01"; error_message = "..." } }`. Falha grave, avaliada antes/depois, conforme apropriado.
Variável com um valor posicional de forma fixa.
`type = tuple([string, number, bool])` exige exatamente três elementos nessa ordem. Diferente de uma lista (homogénea, comprimento variável).
Tipar fortemente uma entrada estruturada (ex: `database = { instance_class = string, allocated_storage = number }`).
`type = object({ instance_class = string, allocated_storage = number, multi_az = optional(bool, false) })`. `optional(<type>, <default>)` torna os atributos opcionais.
Como são carregados os ficheiros `*.tfvars`?
`terraform.tfvars` e `*.auto.tfvars` carregam automaticamente (ordem lexical para `auto`). Outros nomes exigem `-var-file=path.tfvars`.
Escrever testes automatizados para um módulo Terraform.
Ficheiros `.tftest.hcl` com `run "name" { command = plan|apply, assert { condition = ..., error_message = ... } }`. `command = plan` não tem efeitos secundários; `command = apply` cria realmente recursos.
Passar variáveis para execuções de teste.
O bloco `variables { ... }` ao nível do ficheiro aplica-se a todas as execuções. `variables { ... }` por execução substitui apenas para essa execução.
Escolher um modo de execução de workspace no HCP Terraform.
Impulsionado por VCS (auto-plan no git push, mais comum). Impulsionado por CLI (o desenvolvedor executa `terraform plan/apply` localmente, o HCP mantém o estado). Impulsionado por API (execuções Terraform acionadas por API, usadas por sistemas de automação/CD).
Ordem das fases numa execução do HCP Terraform.
plan → estimativa de custo (se ativada) → verificação de política (Sentinel/OPA) → apply manual ou automático. Falhas de política obrigatórias ou falhas de run-task interrompem a pipeline.
Garantir que todos os buckets S3 são encriptados, bloqueando o apply se violado.
Política Sentinel com imposição obrigatória rígida. Inspeciona o plan; a falha bloqueia o apply. Soft-mandatory permite a substituição pelo administrador. Advisory regista logs mas nunca bloqueia.
Integrar um scanner de segurança de terceiros na pipeline de execução do HCP Terraform.
Executar tarefa na fase pós-plan. O HCP POSTa o plan para o seu endpoint; o endpoint responde passa/falha. A imposição obrigatória bloqueia o apply em caso de falha; o advisory apenas avisa.
Mostrar o impacto de um pull request antes de fazer merge.
Os planos especulativos são executados em PRs (ou branches), comentam os resultados de volta para o PR e nunca aplicam. Acionados automaticamente quando a integração VCS está ativada.
Evitar armazenar chaves de acesso AWS como segredos estáticos em variáveis do HCP Terraform.
Credenciais de provider dinâmicas. O HCP Terraform solicita credenciais de curta duração via confiança OIDC para AWS/Azure/GCP. Sem chaves estáticas; identidades por execução; auditável.
Por quê: Chaves estáticas vazam. A confiança OIDC vincula credenciais ao workspace + execução, expira dentro de uma hora.
Partilhar as mesmas credenciais de provider entre vários workspaces.
Conjuntos de variáveis. Definir uma vez ao nível da organização/projeto, anexar a vários workspaces. As atualizações propagam sem edições por workspace.
O que é o Projeto Padrão no HCP Terraform?
Um projeto incorporado que existe em todas as organizações e não pode ser excluído (a renomeação é permitida). Todos os workspaces pertencem a ele, a menos que sejam explicitamente atribuídos a outro projeto.
Aplicar um workspace downstream sempre que um workspace upstream concluir um apply bem-sucedido.
Run triggers. Configure o(s) workspace(s) de origem no workspace dependente; o HCP enfileira uma execução no dependente após cada apply upstream bem-sucedido.
