Microsoft AZ-400: Infraestrutura como Código e Gerenciamento de Configuração — Guia de estudos

By Laurynas Brazys · 10 August 2026 · #microsoft #az-400 #certification #exam-prep #study-guide

Faz parte do Microsoft DevOps Engineer Expert AZ-400 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Microsoft, ou faça testes cronometrados no ExamRoll.io.

Visão Geral

Infraestrutura como Código (IaC) e Gerenciamento de Configuração no Azure permitem que você defina, provisione e imponha configurações de infraestrutura e aplicação de forma repetida e segura. O Azure suporta nativamente ARM JSON e Bicep, e se integra bem com Terraform e Ansible. O estado da configuração pode ser declarado com PowerShell Desired State Configuration (DSC), Azure Automation DSC, Chef e Puppet. O lançamento de features de aplicação e o gerenciamento de chaves são centralizados com o Azure App Configuration e o Key Vault. Imagens imutáveis criadas com o Packer reduzem o drift. A governança é imposta como política como código com o Azure Policy e OPA/Gatekeeper para Kubernetes.

IaC Nativo do Azure: Templates ARM e Bicep

Templates ARM são documentos JSON declarativos que o Azure Resource Manager utiliza para criar e atualizar recursos. A estrutura de nível superior inclui $schema, contentVersion, parameters, variables, resources e outputs. Parâmetros permitem a entrada de dados específicos do ambiente; variáveis ajudam a derivar valores calculados; recursos declaram o estado desejado; outputs publicam resultados como IDs de recursos. Os templates suportam expressões e funções de tempo de execução (por exemplo, resourceId, reference, concat, uniqueString) para que você possa compor nomes e recuperar propriedades.

Para dividir grandes implantações em unidades de fácil manutenção, você pode usar templates aninhados (nested) ou vinculados (linked). Um template aninhado insere o JSON diretamente na propriedade template de um recurso Microsoft.Resources/deployments. Um template vinculado referencia um template remoto via templateLink.uri, normalmente armazenado no Azure Storage com uma SAS de tempo limitado para garantir a integridade. Use templates aninhados quando tudo pode residir em um único artefato e você deseja uma implantação transacional entre as partes. Use templates vinculados para topologias muito grandes ou ao reutilizar templates entre repositórios ou equipes. Defina o escopo de suas implantações para um grupo de recursos, assinatura, grupo de gerenciamento ou tenant, conforme necessário, configurando o escopo da implantação no recurso de implantações.

O ARM suporta dois modos de implantação. Incremental (padrão) cria ou atualiza os recursos presentes no template sem excluir nada que não esteja declarado. Completo (Complete) exclui os recursos no escopo de destino que não estão especificados no template, tornando-o útil para garantir um drift mínimo, mas também mais arriscado se o template não for a fonte de autoridade para aquele escopo. As operações Validate e What-If ajudam a visualizar as alterações para reduzir o risco antes da execução.

Bicep é uma linguagem de domínio específico (DSL) que compila para JSON do ARM e oferece uma ergonomia de autoria de primeira classe. As declarações de recursos usam nomes simbólicos, impõem tipos e suportam a palavra-chave existing para referenciar recursos pré-existentes sem reimplantá-los. Parâmetros, variáveis, outputs e declarações de recursos são concisos, e os relacionamentos pai-filho e os escopos são explícitos. Módulos permitem composição e reutilização; cada módulo é um arquivo Bicep referenciado com a palavra-chave module e pode ser publicado e consumido a partir de registros de template spec ou de artefatos OCI. Condições são expressas de forma inline com if em recursos ou módulos, e laços (loops) usam expressões for para declarar múltiplas instâncias com um tratamento claro de dependências. A migração de JSON do ARM é direta: az bicep decompile (ou bicep decompile) converte JSON para Bicep; em seguida, você refatora em módulos e adota nomes simbólicos. O Bicep não tem perdas em relação ao ARM e suporta toda a superfície da plataforma; bicep build emite o JSON do ARM padrão para implantação.

IaC Multiplataforma no Azure com Terraform

O Terraform complementa o IaC nativo do Azure quando são necessários fluxos de trabalho multinuvem ou agnósticos de provedor. O provedor azurerm gerencia os recursos do Azure Resource Manager e deve ter sua versão fixada (version-pinned); inclua features {} mesmo que vazio para habilitar os recursos do provedor. Outros provedores comuns incluem azuread para objetos do AAD e random para valores utilitários. Autentique-se por meio de um service principal, Managed Identity em agentes hospedados ou pela Azure CLI. Adote uma estratégia clara de configuração de provedor para cada ambiente e centralize módulos reutilizáveis com variáveis de entrada e outputs.

O gerenciamento de estado (state) é crítico. Use o backend azurerm para armazenar o estado remoto no Azure Storage: configure resource_group_name, storage_account_name, container_name e key; autentique-se com managed identity ou SAS; e habilite a exclusão reversível (soft delete) e o versionamento no contêiner de blob. O backend usa leases de blob para bloquear o estado e evitar mutações concorrentes. O acesso à conta de armazenamento deve ser controlado por RBAC e, opcionalmente, restrito com Private Endpoints. Mantenha os arquivos de estado isolados por ambiente e, por design, nunca armazene segredos no estado — use o Key Vault e data sources para recuperar segredos quando necessário.

Workspaces fornecem isolamento lógico do estado dentro da mesma configuração para ramificação de ambientes como dev, test e prod. Use terraform workspace select e garanta que a chave do backend codifique o workspace para evitar colisões (por exemplo, myapp-${terraform.workspace}.tfstate). Workspaces são excelentes para paridade de ambiente com pequenas diferenças; quando as topologias divergem significativamente, use configurações ou módulos separados para evitar drift e complexidade condicional. Integre com o Azure Pipelines usando service connections e as tarefas da CLI do Terraform para padronizar init/plan/apply entre os estágios e para condicionar os applies a aprovações e verificações de política.

Gerenciamento de Configuração em Escala: DSC, Azure Automation DSC, Ansible, Chef e Puppet

O PowerShell Desired State Configuration (DSC) declara o estado de sistemas Windows e multiplataforma por meio de recursos. Existem dois modos de entrega: push, que envia MOFs diretamente para os nós; e pull, no qual os nós buscam seus MOFs de um pull service em um cronograma definido. O Local Configuration Manager (LCM) impõe a política. As configurações principais do LCM incluem:

ConfigurationMode: ApplyOnly (configura uma vez, sem correção de desvio), ApplyAndMonitor (detecta o desvio, sem correção), ApplyAndAutoCorrect (detecta e corrige o desvio).
ConfigurationModeFrequencyMins e RefreshFrequencyMins para ajustar a cadência de imposição e de pull.
RebootNodeIfNeeded e ActionAfterReboot para lidar com reinicializações.
Configurações parciais para compor o estado de um nó a partir de múltiplos MOFs que visam recursos de forma independente (por exemplo, hardening do SO base e função da aplicação).

O Azure Automation State Configuration (Azure Automation DSC) é um pull service gerenciado. Você cria as configurações em PowerShell, importa-as para uma Automation Account e inicia trabalhos de compilação que produzem as configurações de nó (MOF). Os nós se registram com Register-AzAutomationDscNode usando uma chave/endpoint de registro e podem ser agrupados e ter configurações atribuídas com valores de parâmetros por nó. Os relatórios de conformidade mostram a última configuração aplicada e o status de desvio; nós em ApplyAndAutoCorrect farão a remediação automaticamente no próximo check-in. Os trabalhos de compilação são artefatos de build auditáveis, e o controle de acesso baseado em função restringe a autoria de configurações e a atribuição de nós.

O Ansible não utiliza agentes (agentless) e é adequado para a configuração de frotas Linux e orquestração ad-hoc. No Azure, use a azure.azcollection, que fornece módulos para computação, rede, Key Vault e muito mais. O inventário dinâmico com o plugin azure_rm descobre hosts de suas assinaturas ou de resource groups e tags específicos; a aquisição de credenciais pode usar um service principal, o Azure CLI ou uma identidade gerenciada. Integre com o Azure Pipelines instalando o Ansible em um agente Linux, fazendo login via AzureCLI@2 ou uma conexão de serviço do Azure Resource Manager, e executando playbooks que referenciam o inventário dinâmico, grupos de variáveis e arquivos seguros. O Ansible se destaca em tarefas idempotentes e legíveis e pode complementar o DSC em ambientes com predominância de Windows, lidando com fluxos de trabalho e orquestração multiplataforma.

Chef e Puppet fornecem modelos maduros de política como código (policy-as-code) e relatórios de conformidade. Em VMs do Azure, as extensões de VM do Chef e do Puppet fazem o bootstrap dos agentes no momento do provisionamento, garantindo a convergência antecipada. O Chef Infra usa cookbooks e Policyfiles para fixar dependências e garantir execuções reproduzíveis; o Chef InSpec expressa a conformidade como código (compliance-as-code) e envia relatórios para o Chef Automate sobre desvios e postura de controle. Os manifestos e módulos do Puppet codificam o estado desejado, com o Code Manager e ambientes fornecendo fluxos de promoção; o Puppet Enterprise oferece relatórios centralizados, classificação baseada em função e remediação. Ambas as ferramentas se integram com o Azure por meio de módulos e provedores de recursos e podem coexistir com o DSC nativo do Azure quando a migração ou ambientes mistos o exigirem.

Configuração de Aplicações, Imagens Imutáveis e Política como Código

O Azure App Configuration centraliza as configurações de aplicação e os feature flags. Os feature flags permitem a implantação progressiva (progressive rollout): você define os flags e, se necessário, anexa filtros como implantação baseada em porcentagem ou direcionamento de usuários por meio das bibliotecas do Feature Manager. Os labels (rótulos) permitem separar valores por ambiente ou anel (ring). Os snapshots de configuração capturam uma visão imutável e de um ponto no tempo (point-in-time) para um conjunto de chaves e labels, permitindo implantações consistentes e reproduzíveis em vários serviços sem race conditions (condições de corrida) de alterações simultâneas de chaves. As referências ao Key Vault permitem que você mantenha os secrets (segredos) no Key Vault, armazenando apenas as referências no App Configuration; a identidade gerenciada (managed identity) da aplicação deve ter a permissão get no secret, e as bibliotecas de cliente resolvem e armazenam os secrets em cache com atualização dinâmica opcional. Use o RBAC e o isolamento de rede em ambos os serviços para proteger o acesso.

A infraestrutura imutável elimina o configuration drift (desvio de configuração) reconstruindo a partir de uma imagem conhecida em vez de alterar os hosts. O builder azure-arm (agora azure) do Packer cria imagens a partir de um SO base, executa provisioners (shell, PowerShell, Ansible) e publica em uma Shared Image Gallery com regiões replicadas e versionamento semântico. Um pipeline de golden image (imagem dourada) normalmente faz a verificação de lint dos templates do Packer, constrói a imagem, executa varreduras de vulnerabilidade e conformidade (ex: InSpec), realiza testes de integração, promove-a para a galeria e, em seguida, atualiza os VM Scale Sets ou host pools. Com os VM Scale Sets, atualizações contínuas (rolling upgrades) ou baseadas em saúde (health-based), e atualizações automáticas de imagem do SO, você obtém implantações seguras e consistentes e um rollback fácil, selecionando uma versão de imagem anterior.

A política como código (policy as code) impõe guardrails (barreiras de proteção). As definições do Azure Policy são objetos JSON com uma policyRule que avalia as propriedades dos recursos e aplica efeitos como deny, audit, append, modify ou deployIfNotExists para autorremediação. Parametrize as definições para reutilização; agrupe-as com iniciativas (initiatives, ou seja, definições de conjunto de políticas) para atribuições consistentes e acompanhamento centralizado da conformidade. Atribua políticas no escopo de management group, assinatura ou grupo de recursos; habilite tarefas de remediação (remediation tasks) para políticas de modify e deployIfNotExists para adequar os recursos existentes à conformidade. Armazene os artefatos de política no controle de versão, revise via pull requests e implante via Bicep, ARM ou Terraform para uma promoção consistente entre os ambientes.

Para Kubernetes, o OPA/Gatekeeper impõe restrições no momento da admissão (admission-time). Os ConstraintTemplates definem as políticas em Rego e seus esquemas; os Constraints instanciam essas políticas para um cluster. Controles comuns incluem restringir imagens a registros confiáveis (trusted registries), exigir labels/annotations ou impedir pods privilegiados. O Gatekeeper se integra com ferramentas de GitOps (Flux/Argo CD) e testes de CI via conftest. O Azure Policy for Kubernetes se baseia no Gatekeeper para fornecer atribuição nativa do Azure e visões de conformidade entre clusters AKS, unificando a governança da nuvem e do cluster em um único painel de postura (posture dashboard).

Cenário de Problema Prático

O Spotify precisa padronizar a infraestrutura do Azure, reduzir o configuration drift e acelerar implantações seguras de features em microsserviços que abrangem Windows e Linux, AKS e cargas de trabalho baseadas em VMs.

Modele os recursos de nuvem com módulos Bicep por domínio (rede, dados, computação) e implante-os por meio de assinaturas com escopo em management groups. Isso resulta em declarações tipadas e de fácil manutenção, escopo claro e reutilização sem a verbosidade do JSON do ARM.
Use um pequeno número de template specs do ARM vinculados para serviços de plataforma compartilhados consumidos por várias equipes. Templates vinculados hospedados como template specs fornecem artefatos versionados e imutáveis e desassociam a cadência da plataforma das equipes de aplicação.
Selecione o Terraform para dependências de edge e CDN entre nuvens (cross-cloud), com o backend azurerm armazenando o estado remoto (remote state) no Azure Storage por workspace (dev/test/prod) e usando leases de blob para bloqueio (locking). Isso preserva um padrão de pipeline único, ao mesmo tempo que isola o estado com segurança e permite uma promoção consistente.
Centralize a configuração de aplicações e os feature flags no Azure App Configuration. Feature flags com filtros de porcentagem e labels permitem implantações baseadas em anéis (ring-based rollouts); os snapshots de configuração garantem que cada estágio de implantação consuma um conjunto de chaves imutável e auditado.
Armazene os secrets no Azure Key Vault e referencie-os a partir do App Configuration. A resolução das referências em tempo de execução com managed identity permite a rotação de chaves sem novas implantações e remove os secrets da configuração da aplicação e dos pipelines.
Adote imagens imutáveis para cargas de trabalho de VM usando o Packer para construir golden images publicadas na Shared Image Gallery. Um pipeline executa scripts de hardening e varreduras com InSpec, adiciona tags às imagens e promove apenas as versões aprovadas. Os VM Scale Sets consomem imagens da galeria para atualizações blue/green e rolling upgrades, eliminando o drift.
Imponha guardrails com iniciativas do Azure Policy que negam a exposição de IP público em sub-redes privadas, exigem configurações de diagnóstico para o Log Analytics e implantam automaticamente políticas de backup. Atribua no nível do management group para uma cobertura ampla e crie tarefas de remediação para que os recursos existentes convirjam rapidamente para a postura desejada.
Proteja o AKS com OPA/Gatekeeper aplicando constraints que bloqueiam imagens não conformes e pods privilegiados. As políticas são armazenadas e versionadas no Git, validadas com conftest em CI e aplicadas via GitOps para garantir que o estado do cluster corresponda à política em todos os momentos.
Gerencie a configuração de servidores Windows com o Azure Automation DSC. Os nós se registram com

undefined

e usam

undefined

para detectar e remediar o drift; os compilation jobs emitem MOFs por função, e os painéis de conformidade expõem o drift para investigação. 10. Gerencie a configuração e orquestração do Linux com o Ansible usando o inventário dinâmico

undefined

e os módulos

undefined

. O Azure Pipelines se autentica com managed identity, executa playbooks de forma idempotente e coordena atualizações entre serviços, complementando o DSC no Windows. 11. Utilize perfis do Chef InSpec para compliance-as-code multiplataforma tanto em imagens quanto em hosts em execução, alimentando o Chef Automate para geração de relatórios. Isso traz controles auditáveis e testáveis para o pipeline e para a produção, garantindo que os requisitos regulatórios sejam continuamente validados.

Essa combinação fornece IaC tipado e modular (Bicep/Terraform), hosts imutáveis (Packer), configuração de aplicação centralizada (App Configuration/Key Vault), aplicação contínua de configuração (Azure Automation DSC, Ansible) e governança forte (Azure Policy, Gatekeeper). Ela reduz o drift, encurta os tempos de recuperação e implantação e torna a conformidade demonstrável.

← Pipelines de CI · Todos os domínios · Conteinerização e Kubernetes →

Pratique estas questões → · Prática cronometrada no ExamRoll.io →