Perguntas de entrevista sobre Terraform: guia completo de Infrastructure as Code 2026

Perguntas sobre Terraform dominam processos seletivos para vagas de DevOps, SRE e engenharia de plataforma em 2026. Com o Terraform 1.14 consolidando recursos como variables in module source e o HCP Terraform amadurecendo como plataforma gerenciada, recrutadores esperam que candidatos demonstrem conhecimento pratico e atualizado sobre Infrastructure as Code.

Conceitos fundamentais do Terraform

O que e o Terraform e como ele difere de outras ferramentas IaC?

O Terraform e uma ferramenta de Infrastructure as Code declarativa, desenvolvida originalmente pela HashiCorp. Diferente de ferramentas imperativas como scripts Bash ou Ansible playbooks, o Terraform utiliza a linguagem HCL (HashiCorp Configuration Language) para descrever o estado desejado da infraestrutura. O motor do Terraform compara esse estado desejado com o estado atual registrado no arquivo de state e gera um plano de diferencas (diff) que mostra exatamente quais recursos serao criados, modificados ou destruidos.

Uma das principais vantagens do Terraform e sua natureza cloud-agnostic. Atraves do sistema de providers, a mesma ferramenta provisiona recursos na AWS, Azure, GCP, Cloudflare e centenas de outros servicos. Esse modelo unificado reduz a curva de aprendizado para equipes que operam em ambientes multi-cloud.

Desde 2023, a mudanca de licenca para BSL (Business Source License) gerou o fork OpenTofu, mantido pela Linux Foundation. Em 2026, Terraform 1.14 e OpenTofu 1.9 apresentam divergencias significativas em funcionalidades. Candidatos devem conhecer essa dinamica e saber articular as diferencas praticas entre as duas ferramentas, especialmente no que se refere a compatibilidade de providers e novos recursos exclusivos de cada uma.

O fluxo de trabalho do Terraform: init, plan, apply, destroy

O ciclo de vida de uma operacao Terraform se resume a quatro comandos principais. Compreender profundamente o que cada um executa internamente e requisito basico em qualquer entrevista.

# 1. Initialize - downloads providers and modules
terraform init

# 2. Plan - shows what will change without modifying anything
terraform plan -out=tfplan

# 3. Apply - executes the planned changes
terraform apply tfplan

# 4. Destroy - tears down all managed resources
terraform destroy

O comando terraform init inicializa o diretorio de trabalho, faz download dos providers declarados e configura o backend de state. Esse comando deve ser executado sempre que um novo provider e adicionado ou quando o backend muda.

O terraform plan e o comando mais importante para ambientes de producao. Ele gera um plano de execucao detalhado sem modificar nenhum recurso real. A flag -out=tfplan salva o plano em arquivo binario, garantindo que o apply subsequente execute exatamente o que foi revisado. Em pipelines CI/CD, salvar o plano e considerado pratica obrigatoria para evitar diferencas entre o momento da revisao e o momento da aplicacao.

O terraform apply executa as mudancas planejadas. Quando utilizado com um arquivo de plano salvo, nao solicita confirmacao interativa, tornando-o seguro para automacao. O terraform destroy remove todos os recursos gerenciados e deve ser utilizado com extrema cautela em ambientes produtivos.

Gerenciamento de state: o tema mais frequente em entrevistas

O que e o state do Terraform e por que ele e essencial?

O state do Terraform e um arquivo JSON (por padrao terraform.tfstate) que mapeia cada recurso declarado no codigo HCL ao recurso real existente no provedor de cloud. Esse mapeamento e fundamental: sem ele, o Terraform nao consegue determinar quais recursos ja existem, quais precisam ser atualizados e quais devem ser destruidos.

As consequencias da perda do arquivo de state sao severas. O Terraform perde a referencia de todos os recursos provisionados, tornando impossivel gerencia-los sem reconstruir o state manualmente com terraform import. Em infraestruturas grandes, essa reconstrucao pode levar dias e introduzir erros. Por isso, o gerenciamento adequado do state e o topico que mais aparece em entrevistas tecnicas.

Como gerenciar o state em producao?

Em ambientes produtivos, o state jamais deve ser armazenado localmente. A pratica padrao e utilizar um backend remoto com suporte a locking para evitar que duas execucoes simultaneas corrompam o arquivo.

# backend.tf
terraform {
  backend "s3" {
    bucket         = "company-terraform-state"
    key            = "prod/networking/terraform.tfstate"
    region         = "eu-west-1"
    dynamodb_table = "terraform-locks"
    encrypt        = true
  }
}

Nessa configuracao, o bucket S3 armazena o state com criptografia habilitada, enquanto a tabela DynamoDB implementa o mecanismo de locking. Quando um operador executa terraform apply, o Terraform adquire um lock na tabela DynamoDB, impedindo que outro processo modifique o state simultaneamente. Ao terminar, o lock e liberado automaticamente.

O HCP Terraform (anteriormente Terraform Cloud) oferece uma alternativa gerenciada que inclui versionamento de state, controle de acesso granular e execucao remota de plans. Para equipes que preferem nao gerenciar a infraestrutura do proprio state, essa opcao elimina a complexidade operacional do backend S3 + DynamoDB.

Boas praticas para o arquivo state

• Nunca fazer commit do arquivo terraform.tfstate em repositorios de controle de versao. Ele pode conter dados sensiveis como senhas e chaves de API.
• Habilitar criptografia em repouso no backend remoto (flag encrypt = true no S3, ou criptografia nativa no Azure Blob Storage e GCS).
• Separar o state por ambiente e por dominio de infraestrutura. Um state unico para toda a organizacao cria acoplamento excessivo e aumenta o raio de impacto de erros.
• Sempre utilizar locking. Sem locking, execucoes paralelas podem sobrescrever mudancas e corromper o state permanentemente.
• Utilizar terraform state list e terraform state show para inspecionar recursos gerenciados sem precisar consultar o provedor de cloud diretamente.

Modulos: componentes de infraestrutura reutilizaveis

Como funcionam os modulos no Terraform?

No Terraform, um modulo e simplesmente um diretorio contendo arquivos .tf. Todo projeto Terraform possui um modulo raiz (root module), que e o diretorio onde terraform plan e executado. Modulos filhos (child modules) sao invocados a partir do modulo raiz atraves do bloco module, permitindo encapsular e reutilizar logica de infraestrutura.

# main.tf - calling a module
module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "5.16.0"

  name = "production-vpc"
  cidr = "10.0.0.0/16"

  azs             = ["eu-west-1a", "eu-west-1b", "eu-west-1c"]
  private_subnets = ["10.0.1.0/24", "10.0.2.0/24", "10.0.3.0/24"]
  public_subnets  = ["10.0.101.0/24", "10.0.102.0/24", "10.0.103.0/24"]

  enable_nat_gateway = true
  single_nat_gateway = true
}

Esse exemplo utiliza o modulo oficial de VPC da AWS, fixado na versao 5.16.0. O atributo version e fundamental para garantir reproducibilidade. O Terraform 1.14 introduziu suporte a variaveis dentro do atributo source de modulos, permitindo construir caminhos de source dinamicamente, uma funcionalidade que simplifica cenarios de multi-conta e multi-regiao.

O que caracteriza um modulo bem projetado?

Entrevistadores frequentemente pedem para o candidato descrever as caracteristicas de um modulo de qualidade. Os criterios mais relevantes sao:

• Inputs e outputs claros: todas as variaveis devem ter description, type e default quando aplicavel. Outputs devem expor apenas os valores necessarios para integracao com outros modulos.
• Escopo minimo: cada modulo deve resolver um unico problema de infraestrutura. Um modulo que provisiona VPC, banco de dados e aplicacao ao mesmo tempo viola o principio de responsabilidade unica.
• Sem valores hardcoded: regioes, nomes de conta e identificadores especificos de ambiente devem ser passados como variaveis, nunca escritos diretamente no codigo do modulo.
• Versionamento com releases: modulos internos devem seguir versionamento semantico e ser publicados em registry privado ou referenciados por tags Git.

Workspaces, ambientes e estrutura do projeto

Como gerenciar multiplos ambientes?

O gerenciamento de ambientes multiplos (dev, staging, producao) e um desafio recorrente em projetos Terraform. Existem tres abordagens consolidadas, cada uma com vantagens e riscos especificos.

| Padrao | Mecanismo | Ideal para | Risco | |--------|-----------|------------|-------| | Workspaces | terraform workspace select prod | Projetos simples, mesma config por ambiente | Backend compartilhado, risco de apply no workspace errado | | Diretorio por ambiente | Diretorios separados dev/, staging/, prod/ | Isolamento total entre ambientes | Duplicacao de codigo | | Terragrunt | Wrapper DRY que gera configs de backend | Grandes implantacoes multi-conta | Dependencia de ferramenta adicional |

A abordagem de diretorio por ambiente e a mais adotada em organizacoes de medio e grande porte. Cada ambiente possui seu proprio diretorio com arquivos backend.tf, terraform.tfvars e main.tf. Essa separacao fisica garante que um terraform apply em desenvolvimento jamais afete producao, eliminando o risco de erros por troca de workspace.

Qual a diferenca entre workspaces e isolamento por diretorio?

Workspaces compartilham o mesmo backend e a mesma configuracao, diferenciando ambientes apenas pelo namespace do state. Isso significa que uma variavel esquecida ou um provider mal configurado afeta todos os workspaces igualmente. Alem disso, o risco de executar terraform apply no workspace errado e real e documentado em post-mortems publicos.

O isolamento por diretorio, em contraste, trata cada ambiente como um projeto Terraform independente. O backend, as variaveis e ate as versoes de providers podem diferir entre ambientes. Essa abordagem introduz duplicacao de codigo, que pode ser mitigada com modulos compartilhados e ferramentas como Terragrunt para gerar configuracoes DRY.

Providers, data sources e ciclo de vida dos recursos

O que sao providers e como configura-los?

Providers sao plugins que permitem ao Terraform interagir com APIs de provedores de cloud, servicos SaaS e outras plataformas. Cada provider deve ser declarado com source e restricao de versao.

# providers.tf
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.80"
    }
  }
}

provider "aws" {
  region = var.aws_region

  default_tags {
    tags = {
      Environment = var.environment
      ManagedBy   = "terraform"
      Team        = var.team_name
    }
  }
}

A restricao ~> 5.80 permite atualizacoes automaticas de patch (5.80.x, 5.81.x, etc.) mas bloqueia atualizacoes de major version. Essa estrategia equilibra seguranca com estabilidade. O bloco default_tags aplica tags padrao a todos os recursos AWS criados por esse provider, eliminando a necessidade de repeti-las em cada recurso individual. Essa pratica e considerada obrigatoria em ambientes corporativos para rastreamento de custos e governanca.

Data sources versus recursos

A distincao entre data sources e resources e uma pergunta classica em entrevistas. Ambos sao declarados em HCL, mas possuem propositos fundamentalmente diferentes.

# Data source - reads an existing AMI, does not create anything
data "aws_ami" "ubuntu" {
  most_recent = true
  owners      = ["099720109477"] # Canonical

  filter {
    name   = "name"
    values = ["ubuntu/images/hvm-ssd-gp3/ubuntu-noble-24.04-amd64-server-*"]
  }
}

# Resource - creates an EC2 instance using the data source
resource "aws_instance" "web" {
  ami           = data.aws_ami.ubuntu.id
  instance_type = "t3.micro"
}

Um data source consulta informacoes de recursos ja existentes na infraestrutura sem criar ou modificar nada. No exemplo acima, o data source aws_ami busca a AMI Ubuntu mais recente publicada pela Canonical. O resource aws_instance cria efetivamente uma instancia EC2 utilizando o ID da AMI obtido pelo data source.

Data sources sao essenciais para integrar infraestrutura gerenciada pelo Terraform com recursos provisionados manualmente ou por outras ferramentas. Permitem referenciar VPCs existentes, certificados ACM, zonas Route 53 e qualquer outro recurso sem necessidade de importa-lo para o state.

Topicos avancados: import, moved blocks e testes

Como funciona o terraform import?

O terraform import permite incorporar recursos existentes ao gerenciamento do Terraform. A partir do Terraform 1.5, o bloco import declarativo substituiu o comando CLI, tornando a operacao reproduzivel e auditavel.

# import.tf
import {
  to = aws_s3_bucket.legacy_data
  id = "my-legacy-bucket-name"
}

resource "aws_s3_bucket" "legacy_data" {
  bucket = "my-legacy-bucket-name"
}

Apos declarar o bloco import e o resource correspondente, basta executar terraform plan para gerar a configuracao necessaria. O Terraform compara o recurso real com a declaracao HCL e indica quais atributos precisam ser ajustados. Esse fluxo e fundamental para migrar infraestrutura legada para gerenciamento via IaC sem necessidade de recriar recursos.

O que sao os blocos moved?

Blocos moved permitem renomear ou reorganizar recursos no codigo sem destrui-los e recria-los. Quando um recurso e renomeado diretamente no HCL, o Terraform interpreta como destruicao do antigo e criacao de um novo. O bloco moved instrui o Terraform a atualizar apenas a referencia no state.

# Renamed a resource from "web" to "app"
moved {
  from = aws_instance.web
  to   = aws_instance.app
}

Essa funcionalidade e especialmente valiosa durante refatoracoes de modulos, onde recursos sao reorganizados entre arquivos ou movidos para sub-modulos. Sem blocos moved, cada reorganizacao exigiria destruicao e recriacao de recursos, causando downtime e perda de dados em recursos com estado.

Como funcionam os testes no Terraform?

O framework de testes nativo do Terraform, introduzido na versao 1.6, permite validar configuracoes sem provisionar infraestrutura real. Arquivos de teste utilizam a extensao .tftest.hcl e suportam execucao em modo plan (sem criar recursos) ou apply (criando e destruindo recursos em ambiente efemero).

# tests/vpc.tftest.hcl
run "creates_vpc_with_correct_cidr" {
  command = plan

  assert {
    condition     = aws_vpc.main.cidr_block == "10.0.0.0/16"
    error_message = "VPC CIDR block does not match expected value"
  }
}

run "creates_three_private_subnets" {
  command = plan

  assert {
    condition     = length(aws_subnet.private) == 3
    error_message = "Expected 3 private subnets"
  }
}

O modo plan e suficiente para validar logica de configuracao, como CIDR blocks, contagem de recursos e valores de variaveis. O modo apply e necessario para testar comportamentos que dependem da interacao real com a API do provedor, como validacao de policies IAM ou conectividade de rede.

Terraform em pipelines CI/CD

Como e um pipeline de Terraform em producao?

A integracao do Terraform em pipelines CI/CD segue um fluxo padronizado em organizacoes maduras:

1. Commit e pull request: o desenvolvedor cria uma branch com as mudancas de infraestrutura e abre um pull request.
2. Validacao automatica: o pipeline executa terraform fmt -check, terraform validate e ferramentas de linting como tflint ou checkov para analise de seguranca.
3. Plan automatico: terraform plan -out=tfplan e executado automaticamente. O resultado do plan e publicado como comentario no pull request para revisao pela equipe.
4. Revisao e aprovacao: um ou mais revisores analisam o plan e aprovam o pull request. Em ambientes regulados, essa etapa pode exigir aprovacao de multiplas equipes.
5. Apply controlado: apos o merge, o pipeline executa terraform apply tfplan utilizando o plano gerado e aprovado anteriormente.
6. Verificacao pos-apply: testes de integracao e smoke tests validam que a infraestrutura provisionada esta funcional.

A regra de ouro: o plan revisado por humanos deve ser identico ao plan aplicado pela automacao. Salvar o plano com -out e reaproveita-lo no apply garante essa consistencia e elimina o risco de mudancas inesperadas entre os dois momentos.

Conclusao

O dominio do Terraform em entrevistas tecnicas exige mais do que conhecimento superficial de sintaxe. Os pontos fundamentais que separam candidatos preparados dos demais:

• O gerenciamento de state e o topico mais critico. Saber configurar backends remotos com locking, explicar consequencias de corrupcao e demonstrar estrategias de recuperacao de desastres diferencia candidatos imediatamente.
• O design de modulos separa profissionais junior de senior. Modulos com escopo minimo, inputs/outputs bem documentados e versionamento semantico refletem maturidade em IaC.
• Conhecer profundamente o ciclo plan/apply, incluindo a importancia de salvar planos para pipelines CI/CD, demonstra experiencia em ambientes produtivos reais.
• As funcionalidades do Terraform 1.14, como variaveis em module source e melhorias no framework de testes, sao diferenciais em processos seletivos atuais.
• A capacidade de articular diferencas entre Terraform e OpenTofu, incluindo implicacoes de licenca e divergencia de funcionalidades, demonstra conhecimento do ecossistema completo.
• Para aprofundar a preparacao, consultar os fundamentos de entrevistas DevOps e os conceitos de implantacao no Kubernetes complementa o dominio de Terraform com contexto operacional mais amplo.