O exame AZ-400 aborda IaC pela perspectiva de 'qual ferramenta usar e quando.' Entender por que ARM Templates e Bicep são semelhantes mas distintos, por que o Terraform domina em ambientes multi-nuvem e onde DSC e Cloud-Init aparecem — tudo via cenários concretos — é o que define essa área. Agrupar as ferramentas por 'o que declaram' é mais eficaz do que memorizar nomes.
Por que precisamos de IaC: cliques não deixam memória
Montar um móvel da IKEA sem as instruções funciona na primeira vez, mas seis meses depois, ao precisar de duas peças idênticas, você não sabe por onde recomeçar. Criar recursos no portal do Azure com cliques tem o mesmo problema: nenhum registro de quem fez o quê, quando ou com quais configurações, e reproduzir o ambiente em staging ou produção exige começar do zero cada vez.
IaC (Infrastructure as Code) declara o 'estado desejado' da infraestrutura como código, versionado no Git. Isso cria histórico de mudanças, permite revisão por pares via pull requests e automatiza o deployment via CI/CD. Dois enfoques principais existem.
: descreve o estado final; a ferramenta compara com o estado atual e decide o que mudar. ARM Templates, Bicep e Terraform funcionam assim. : lista cada passo em ordem. Scripts de Azure CLI e PowerShell funcionam assim.
O exame foca em ferramentas declarativas por conta da — o mesmo template executado dez vezes sempre produz o mesmo resultado.
ARM Templates: o projeto arquitetônico dos recursos Azure
Antes de construir, o arquiteto desenha plantas com posição das colunas, tamanho das janelas e número de andares. ARM Template é essa planta para os recursos do Azure. Escrito em JSON, é lido pelo Azure Resource Manager para criar e configurar os recursos.
Seções principais:
: valores no momento do deployment (nome do ambiente, tamanho da VM, etc.) : valores intermediários reutilizados : lista de recursos a criar (seção central) : valores retornados após o deployment
O principal problema é a verbosidade do JSON: sem suporte a comentários e com loops para recursos repetidos. O Bicep resolveu isso.
Bicep: ARM Templates com sintaxe legível por humanos
Um documento técnico de chef (medidas em gramas) versus uma receita doméstica ('um punhado'). O prato é o mesmo. Essa é a relação entre ARM Template e Bicep.
Bicep é uma DSL construída sobre ARM Templates. O Azure CLI ou o Azure Pipelines a transpila internamente para JSON antes do deployment. Características principais:
: cada linha de Bicep corresponde ao ARM Template equivalente. O inverso também funciona (). Suporta comentários, sintaxe concisa e segurança de tipos. permite compor arquivos Bicep reutilizáveis.
Metade das linhas para o mesmo recurso. Se a equipe é Azure-only e precisa de integração estreita com ARM, Bicep é a resposta.
Terraform: a linguagem comum para multi-nuvem
Viajar por vários países com um idioma compartilhado é muito mais eficiente do que aprender cada língua nativa por separado. Para uma organização que usa Azure, AWS e GCP juntos, o Terraform cumpre exatamente esse papel de língua franca.
Terraform é open-source, criado pela HashiCorp e escrito em HCL (HashiCorp Configuration Language). Conceitos principais:
: plug-in do provedor (azurerm, aws, google, etc.) que abstrai as chamadas de API de cada nuvem. : arquivo () com o estado atual dos recursos gerenciados. O Terraform compara o código declarado com esse arquivo para saber o que mudar. : prévia — 'adicionar 5, modificar 1, destruir 0' — antes de executar qualquer coisa. : executa as alterações reais. : armazena o state no Azure Blob Storage ou no Terraform Cloud para trabalho em equipe.
| Critério | Bicep | Terraform | |----------|-------|-----------| | Nuvem alvo | Apenas Azure | Multi-nuvem | | Linguagem | DSL (ARM) | HCL | | State | Não necessário | Obrigatório () | | APIs Azure recentes | Imediato | Requer update do provider |
No exame, 'multi-nuvem', 'HashiCorp', 'HCL' ou 'tfstate' apontam para Terraform.
!Bicep vs Terraform
DSC, Cloud-Init e Ansible: gerenciando o interior do SO
IaC provisiona VMs. Ferramentas de configuração controlam o que é instalado dentro delas. Essa distinção é cobrada com frequência.
declara, via PowerShell, qual software instalar, quais serviços Windows ativar e quais configurações de sistema de arquivos aplicar. Com Azure Automation State Configuration, corrige automaticamente o configuration drift em frotas de VMs.
inicializa uma VM Linux na primeira inicialização: pacotes, usuários e arquivos em YAML. Azure, AWS e GCP o suportam.
Ansible, Chef e Puppet completam o cenário:
: sem agente, usa SSH. : DSL Ruby, termos Cookbook e Recipe. : DSL declarativa, arquitetura Master-Agent.
Resumo: ARM/Bicep/Terraform = provisionamento de infraestrutura. DSC/Cloud-Init/Ansible = configuração de SO e software.
Varredura de segurança IaC: vulnerabilidades antes do deployment
Vistoriar um edifício pronto custa mais do que revisar as plantas. A varredura IaC aplica o mesmo princípio: ferramentas no pipeline detectam configurações inseguras antes do código chegar ao Azure.
: análise estática Python para Terraform, ARM, Bicep, Kubernetes e mais. varre o diretório inteiro. : foco em Terraform, alinhado com as recomendações do Azure Security Center.
Positionar a varredura antes do impede que código inseguro chegue ao . O próximo artigo aprofunda a integração de segurança em pipelines.
Resumo do Exame
'IaC nativa do Azure, DSL sobre ARM' → Bicep 'Multi-nuvem, HCL, tfstate, HashiCorp' → Terraform 'Converter ARM Template em sintaxe legível' → 'Ver alterações do Terraform antes de aplicar' → 'State do Terraform para equipe' → Remote Backend (Azure Blob Storage ou Terraform Cloud) 'Gerenciar software/serviços dentro da VM' → Azure DSC 'Inicialização de VM Linux no primeiro boot' → Cloud-Init 'Configuração sem agente via SSH' → Ansible 'Declarativo vs imperativo' → ARM/Bicep/Terraform=declarativo; Azure CLI=imperativo 'Varredura estática IaC / Terraform' → Checkov ou tfsec 'Prévia de deployment ARM/Bicep' →
Bicep = declarativo nativo Azure, Terraform = declarativo multi-nuvem, DSC = configuração de SO.