Ansible vs Terraform em 2026: Infrastructure as Code e Perguntas de Entrevista DevOps

Ansible vs Terraform representa uma das questões de comparação mais comuns em entrevistas DevOps, mas a própria formulação revela uma incompreensão: essas ferramentas resolvem problemas diferentes. Ansible 2.20 lida com gerenciamento de configuração e deploy de aplicações, enquanto Terraform 1.15 provisiona recursos de infraestrutura. Compreender quando cada ferramenta se destaca, onde elas se sobrepõem e como se complementam separa engenheiros DevOps seniores daqueles que ainda estão aprendendo os fundamentos.

Declarativo vs Procedural: A Diferença Fundamental

Terraform utiliza uma abordagem declarativa. Um arquivo de configuração descreve o estado final desejado, e o Terraform calcula as mudanças necessárias para alcançá-lo. Essa abordagem funciona bem para infraestrutura que precisa ser criada, modificada ou destruída como uma unidade.

# main.tf
resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.medium"
  
  tags = {
    Name        = "web-server"
    Environment = "production"
  }
}

resource "aws_security_group" "web" {
  name        = "web-sg"
  description = "Allow HTTP and HTTPS"
  
  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

Executar terraform apply cria ambos os recursos se eles não existirem, ou os atualiza para corresponder à configuração. Executá-lo novamente sem mudanças não produz nenhuma operação: o Terraform compara a configuração com seu arquivo de estado e não encontra nada a fazer.

Ansible utiliza uma abordagem procedural com tarefas executadas em ordem. Embora os módulos Ansible sejam frequentemente idempotentes (executá-los duas vezes produz o mesmo resultado), o playbook em si descreve uma sequência de ações em vez de um estado final.

# webserver.yml
- name: Configure web server
  hosts: webservers
  become: true
  
  tasks:
    - name: Install nginx
      ansible.builtin.apt:
        name: nginx
        state: present
        update_cache: true
    
    - name: Copy nginx configuration
      ansible.builtin.template:
        src: nginx.conf.j2
        dest: /etc/nginx/nginx.conf
      notify: Restart nginx
    
    - name: Ensure nginx is running
      ansible.builtin.service:
        name: nginx
        state: started
        enabled: true
  
  handlers:
    - name: Restart nginx
      ansible.builtin.service:
        name: nginx
        state: restarted

Cada tarefa executa em sequência. O padrão notify/handler fornece algum comportamento declarativo: o handler executa apenas uma vez no final, independentemente de quantas tarefas o acionem.

Gerenciamento de Estado: Um Tópico Crítico em Entrevistas

Terraform mantém um arquivo de estado que mapeia a configuração para recursos reais. Esse estado rastreia IDs de recursos, dependências e metadados. Sem ele, o Terraform não consegue determinar o que existe ou o que precisa mudar.

Ansible não tem arquivo de estado equivalente. Ele se conecta aos sistemas alvo e executa tarefas, dependendo do estado atual do sistema e da idempotência dos módulos. Isso torna o Ansible mais simples para começar, mas mais difícil de rastrear mudanças ao longo do tempo.

Uma pergunta de entrevista comum aborda a segurança do arquivo de estado. O estado do Terraform pode conter dados sensíveis: senhas de bancos de dados, chaves de API, identificadores de recursos. Deploys em produção armazenam o estado remotamente (S3, Azure Blob, Terraform Cloud) com criptografia e controles de acesso.

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

A tabela DynamoDB fornece locking, prevenindo que dois engenheiros modifiquem o estado simultaneamente.

Quando Usar Cada Ferramenta

Terraform se destaca no provisionamento de infraestrutura cloud: máquinas virtuais, bancos de dados gerenciados, load balancers, roles IAM, VPCs. Ele lida com dependências entre recursos automaticamente e suporta todos os principais provedores cloud através de uma sintaxe HCL consistente.

Ansible se destaca na configuração de sistemas existentes: instalação de pacotes, gerenciamento de usuários, deploy de código de aplicação, orquestração de deploys multi-etapas. Ele se conecta via SSH (ou WinRM para Windows) sem requerer agentes nas máquinas alvo.

A zona de sobreposição causa confusão. Ambos podem instalar software em uma VM. Terraform pode usar provisioners para executar scripts após a criação de recursos. Ansible pode criar recursos cloud através de módulos como amazon.aws.ec2_instance. Mas usar cada ferramenta fora de sua força leva a problemas de manutenibilidade.

O Workflow Combinado em Produção

A maioria das organizações usa ambas as ferramentas juntas. Terraform provisiona a infraestrutura e expõe os detalhes de conexão. Ansible consome esses outputs para configurar os sistemas.

# outputs.tf
output "web_server_ips" {
  value       = aws_instance.web[*].private_ip
  description = "Private IPs of web servers"
}

output "db_endpoint" {
  value       = aws_rds_instance.main.endpoint
  description = "RDS endpoint for application config"
}

Um pipeline CI/CD executa Terraform primeiro, captura os outputs, gera um inventário Ansible dinamicamente, depois executa playbooks contra a nova infraestrutura.

# ansible/inventory/aws_ec2.yml
plugin: amazon.aws.aws_ec2
regions:
  - us-east-1
filters:
  tag:Environment: production
  instance-state-name: running
hostnames:
  - private-ip-address
groups:
  webservers: "'web' in tags.Role"
  databases: "'db' in tags.Role"

Esse inventário dinâmico consulta a AWS diretamente, agrupando instâncias por suas tags. Nenhum gerenciamento manual de IPs necessário.

OpenTofu: O Fork Que Mudou o Cenário

HashiCorp relicenciou o Terraform sob a Business Source License (BSL) em agosto de 2023. A comunidade respondeu fazendo fork do Terraform 1.5 em OpenTofu, agora hospedado sob a Linux Foundation.

Em agosto de 2026, OpenTofu 1.11.6 permanece como uma substituição direta para a maioria dos workflows Terraform. A mesma sintaxe HCL, o mesmo ecossistema de providers, o mesmo formato de estado. OpenTofu adicionou funcionalidades não presentes no binário open-source do Terraform: criptografia de estado, for_each para providers, e avaliação antecipada de variáveis.

Para preparação de entrevistas, entender a distinção de licenciamento é importante. BSL permite uso interno mas restringe a construção de produtos concorrentes. Organizações preocupadas com vendor lock-in ou com requisitos de compliance específicos podem preferir a licença MPL 2.0 do OpenTofu. A aquisição da HashiCorp pela IBM em dezembro de 2024 adicionou outra variável às discussões sobre relações com fornecedores.

Perguntas Comuns de Entrevista DevOps

P: Ansible pode substituir Terraform?

Não efetivamente. Ansible pode criar recursos cloud, mas não possui gerenciamento de estado. Executar o mesmo playbook duas vezes pode criar recursos duplicados. O arquivo de estado do Terraform rastreia o que existe e calcula mudanças mínimas. Usar Ansible para o que ele faz melhor: gerenciamento de configuração.

P: Como lidar com secrets no Terraform?

Nunca commitar secrets no controle de versão. Usar variáveis de ambiente, integração com Vault, ou gerenciadores de secrets de provedores cloud. Marcar variáveis como sensíveis para evitar que apareçam em logs:

# variables.tf
variable "db_password" {
  type        = string
  sensitive   = true
  description = "Database password from Vault or environment"
}

P: O que é idempotência do Ansible?

Uma operação idempotente produz o mesmo resultado seja executada uma ou múltiplas vezes. O módulo apt com state: present instala um pacote se estiver faltando e não faz nada se já estiver instalado. Escrever playbooks idempotentes previne mudanças não intencionais em execuções subsequentes.

P: Como testar código de infraestrutura?

Terraform: terraform validate verifica a sintaxe, terraform plan visualiza mudanças, e ferramentas como Terratest executam testes de integração. Ansible: ansible-lint detecta problemas, modo --check realiza dry runs, e Molecule testa roles contra containers.

Para preparação mais profunda de entrevistas Terraform, consultar Terraform Interview Questions: Infrastructure as Code Complete Guide. Praticar hands-on com os módulos Terraform Basics e Ansible Configuration Management.

Compatibilidade de Versões e Ecossistema

Versões estáveis atuais em agosto de 2026:

A arquitetura de collections do Ansible separa funcionalidade core de módulos específicos de provedores. A collection amazon.aws recebe atualizações independentemente do core Ansible. Isso importa para pinning de versões em pipelines CI/CD.

O versionamento de providers do Terraform segue princípios similares. Arquivos de lock (terraform.lock.hcl) garantem versões consistentes de providers entre membros da equipe e sistemas CI.

# versions.tf
terraform {
  required_version = ">= 1.15.0"
  
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.60"
    }
  }
}

Escolhendo Entre Eles: Um Framework de Decisão

A pergunta raramente é Ansible ou Terraform. A pergunta é qual ferramenta lida com qual responsabilidade.

Para uma visão completa de como essas ferramentas se encaixam nos workflows de deploy modernos, consultar CI/CD Pipeline Interview Questions.

O Que Engenheiros Seniores Devem Saber Sobre Ansible e Terraform

• Terraform gerencia o estado da infraestrutura declarativamente; Ansible configura sistemas proceduralmente. Usar ambos juntos produz infraestrutura manutenível.
• A segurança do arquivo de estado importa. Armazenar estado do Terraform remotamente com criptografia e locking habilitados.
• OpenTofu fornece uma alternativa licenciada sob MPL ao Terraform com funcionalidades adicionais. A migração é direta para a maioria dos workflows.
• Idempotência não é automática. Escrever playbooks que produzam resultados consistentes em execuções repetidas.
• Inventário dinâmico elimina gerenciamento manual de hosts. Consultar provedores cloud diretamente para infraestrutura atual.
• Pinning de versão previne surpresas. Bloquear versões de providers no Terraform; fixar versões de collections no Ansible.
• Testar código de infraestrutura requer abordagens diferentes: terraform plan para visualizar mudanças, modo --check para dry runs Ansible, frameworks de testes de integração para ambos.