Última revisão: maio de 2026
Construa os serviços da AWS do exame AZ-400 com Terraform puro — um bloco de cada vez, cada um vinculado a um domínio do exame. O mesmo código funciona no OpenTofu.
Ao final deste laboratório, você terá provisionado, com Terraform puro, o lado da infraestrutura AZ-400 de um pipeline de CI/CD — um Azure Container Registry para publicar imagens, um cluster AKS como destino de implantação com identidade gerenciada e integração com o Log Analytics, um Key Vault para segredos do pipeline, e as atribuições de função que conectam tudo à identidade do kubelet do AKS para que possa extrair imagens e ler segredos sem credenciais no YAML do pipeline.
Solte os snippets em um único main.tf, execute terraform init e depois terraform apply passo a passo.
>= 1.5 ou OpenTofu >= 1.6.az login).O AKS é o principal custo aqui:
Total de ~$75/mês enquanto estiver em execução. O antipadrão de custo mais testado do AZ-400 é deixar um cluster AKS não utilizado em execução — destrua ou pare o cluster quando não estiver em uso.
Abertura padrão do Azure.
terraform {
required_version = ">= 1.5"
required_providers {
azurerm = { source = "hashicorp/azurerm", version = "~> 4.0" }
random = { source = "hashicorp/random", version = "~> 3.6" }
}
}
provider "azurerm" {
features {
key_vault {
purge_soft_delete_on_destroy = true
}
}
}
resource "random_id" "suffix" {
byte_length = 3
}
data "azurerm_client_config" "current" {}
locals {
tags = {
Project = "certlabpro-az-400"
ManagedBy = "terraform"
}
}
resource "azurerm_resource_group" "main" {
name = "certlabpro-az-400-rg"
location = "eastus"
tags = local.tags
}O ACR é onde o pipeline de CI envia imagens de contêiner que o pipeline de CD puxa. O AZ-400 testa esse limite de push/pull como um padrão de segurança: o pipeline de build obtém AcrPush, o destino de implantação obtém AcrPull, e os dois nunca se encontram.
Usamos a camada Básica — a mais barata, com um único destino de replicação. A camada Premium adiciona geo-replicação e o recurso Content Trust (assinatura de imagem); ambos são tópicos do exame AZ-400, mas proibitivos em termos de custo para o laboratório.
resource "azurerm_container_registry" "main" {
name = "acrcertlabpro${random_id.suffix.hex}"
resource_group_name = azurerm_resource_group.main.name
location = azurerm_resource_group.main.location
sku = "Basic"
admin_enabled = false # admin user disabled — Entra-only access
tags = local.tags
}O AKS é o destino de implantação preferencial do AZ-400 para cargas de trabalho de contêiner. Usamos uma identidade gerenciada atribuída ao sistema (o padrão moderno; a autenticação de principal de serviço está sendo descontinuada), um único nodepool de sistema pequeno e azure_policy_enabled = true (a resposta do AZ-400 para Implementar conformidade para a aplicação de políticas no nível do cluster por meio do complemento Azure Policy).
A integração do workspace do Log Analytics + agente OMS é a resposta do AZ-400 para Implementar instrumentação para observabilidade no nível do cluster — cada log de pod, cada métrica de nó, cada evento de auditoria do Kubernetes chega ao Log Analytics para consulta KQL.
resource "azurerm_log_analytics_workspace" "main" {
name = "log-az400"
resource_group_name = azurerm_resource_group.main.name
location = azurerm_resource_group.main.location
sku = "PerGB2018"
retention_in_days = 30
tags = local.tags
}
resource "azurerm_kubernetes_cluster" "main" {
name = "aks-az400"
resource_group_name = azurerm_resource_group.main.name
location = azurerm_resource_group.main.location
dns_prefix = "azaks${random_id.suffix.hex}"
default_node_pool {
name = "system"
node_count = 1
vm_size = "Standard_D2s_v3"
}
identity {
type = "SystemAssigned"
}
oms_agent {
log_analytics_workspace_id = azurerm_log_analytics_workspace.main.id
}
azure_policy_enabled = true
tags = local.tags
}
# Grant the AKS kubelet identity AcrPull on the registry from Step 2.
# This is the AZ-400 password-less image-pull pattern.
resource "azurerm_role_assignment" "aks_acr_pull" {
scope = azurerm_container_registry.main.id
role_definition_name = "AcrPull"
principal_id = azurerm_kubernetes_cluster.main.kubelet_identity[0].object_id
}Segredos de pipeline — chaves de API, credenciais de implantação, tokens de terceiros — nunca devem residir no YAML do pipeline. O domínio Implementar segurança e validar bases de código para conformidade do AZ-400 testa este padrão de Referência-de-Key-Vault-em-tarefa-de-pipeline: os pipelines referenciam segredos por nome do Key Vault em tempo de execução.
Concedemos à identidade do kubelet do AKS a função Key Vault Secrets User para que os pods implantados também possam ler segredos por meio do Secrets Store CSI Driver (o mecanismo de montagem no cluster para segredos apoiados pelo Key Vault). Com a função estabelecida, cada pod que precisa de uma senha de banco de dados a lê via driver CSI, e não de uma variável de ambiente incorporada na imagem.
resource "azurerm_key_vault" "main" {
name = "kv-az400-${random_id.suffix.hex}"
resource_group_name = azurerm_resource_group.main.name
location = azurerm_resource_group.main.location
tenant_id = data.azurerm_client_config.current.tenant_id
sku_name = "standard"
enable_rbac_authorization = true
soft_delete_retention_days = 7
tags = local.tags
}
resource "azurerm_role_assignment" "kv_admin_self" {
scope = azurerm_key_vault.main.id
role_definition_name = "Key Vault Administrator"
principal_id = data.azurerm_client_config.current.object_id
}
resource "azurerm_role_assignment" "aks_kv_reader" {
scope = azurerm_key_vault.main.id
role_definition_name = "Key Vault Secrets User"
principal_id = azurerm_kubernetes_cluster.main.kubelet_identity[0].object_id
}O Log Analytics lida com sinais no nível do cluster (métricas de nó, logs de pod); o App Insights lida com o nível do aplicativo (rastreamento de solicitações, telemetria de exceções, rastreamento de dependências, rastreamentos distribuídos). O AZ-400 Implementar instrumentação testa ambas as camadas — o exame espera que você as conecte em par, com o App Insights no modo baseado em workspace usando o workspace do Log Analytics da Etapa 3.
Com esta peça final no lugar, a forma de destino CI/CD do AZ-400 está completa: o ACR recebe imagens de build, o AKS as implanta, o Key Vault fornece segredos, o Log Analytics + App Insights observam o resultado. O YAML do pipeline (Azure DevOps ou GitHub Actions) orquestra tudo — ele reside no repositório de origem, não no Terraform.
resource "azurerm_application_insights" "main" {
name = "appi-az400"
resource_group_name = azurerm_resource_group.main.name
location = azurerm_resource_group.main.location
workspace_id = azurerm_log_analytics_workspace.main.id
application_type = "web"
tags = local.tags
}terraform destroy derruba tudo. O AKS é o item que fatura $70/mês para o nó do sistema — destrua prontamente. O ACR Básico custa $5/mês. O workspace do Log Analytics retém dados pelo período de retenção (30 dias aqui) mesmo após a destruição dos consumidores; o próprio workspace é destruído de forma limpa.
O AZ-400 cobre os serviços Azure DevOps Services e as superfícies GitHub no Azure que não residem no provedor azurerm — organizações, projetos, repositórios, pipelines, pools de agentes, ambientes, grupos de variáveis, conexões de serviço do Azure DevOps (todos no provedor azuredevops separado), GitHub Advanced Security para Azure DevOps e as regras Live Metrics + Smart Detection do Application Insights.
Nós nos concentramos na infraestrutura de destino de implantação porque é o substrato sobre o qual os pipelines AZ-400 realmente são implantados. Uma vez que ACR + AKS + Key Vault + observabilidade estão no lugar, o YAML do pipeline (em seu repositório de origem, não no Terraform) realiza o trabalho de build-push-deploy via tarefas padrão do Azure CLI.
Para cobertura dos padrões do Azure DevOps Services + GitHub Actions, consulte as seções Navegar, Guia e Editorial desta página de certificação.