Última revisão: maio de 2026
Construa os serviços da AWS do exame AZ-104 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, a carga de trabalho de referência AZ-104 — um Grupo de Recursos, uma VNet com uma sub-rede privada protegida por NSG, uma VM Linux com uma identidade gerenciada atribuída ao sistema, uma Conta de Armazenamento que a VM pode ler através dessa identidade e um espaço de trabalho do Log Analytics que recebe diagnósticos da VM. Cada bloco se vincula a um dos cinco domínios do exame AZ-104.
Adicione os trechos a um único main.tf, execute terraform init e depois terraform apply passo a passo.
>= 1.5 ou OpenTofu >= 1.6.az login).~/.ssh/id_rsa.pub (ou altere o caminho na Etapa 4) para o login de administrador da VM.A VM é o principal custo:
Pare a VM (az vm deallocate) quando não a estiver usando ativamente para reduzir pela metade o custo de computação. Destrua todo o RG para interromper completamente a cobrança.
Início padrão do Azure: fixe azurerm ~> 4.0, crie o Grupo de Recursos, leia a chave pública SSH local como uma fonte de dados para que a VM na Etapa 4 possa usá-la. O domínio Identity and Governance do AZ-104 testa Grupos de Recursos como o menor escopo de RBAC; as tags aqui são propagadas para o rastreamento de custos em Monitor Azure resources.
terraform {
required_version = ">= 1.5"
required_providers {
azurerm = {
source = "hashicorp/azurerm"
version = "~> 4.0"
}
random = {
source = "hashicorp/random"
version = "~> 3.6"
}
}
}
provider "azurerm" {
features {}
}
resource "random_id" "suffix" {
byte_length = 2
}
locals {
tags = {
Project = "certlabpro-az-104"
ManagedBy = "terraform"
}
}
resource "azurerm_resource_group" "main" {
name = "certlabpro-az-104-rg"
location = "eastus"
tags = local.tags
}Toda carga de trabalho AZ-104 é executada dentro de uma Rede Virtual. Criamos uma VNet /16 e reservamos uma sub-rede /24 para a VM. O NSG anexado à sub-rede permite SSH (porta 22) de entrada — em produção, o CIDR de origem seria restrito; o laboratório o abre para * para que você possa se conectar de qualquer IP.
O domínio Deploy and Manage Networking do AZ-104 testa repetidamente este padrão de segurança em camadas: NSGs são stateful, eles se aplicam a sub-redes ou NICs (nós aplicamos à sub-rede aqui — a resposta de melhor prática do AZ-104), e a estrutura de regra de negação-padrão + permissão-explícita é como os NSGs do Azure diferem dos grupos de segurança da AWS (os NSGs do Azure têm números de regra explícitos; os SGs da AWS não).
resource "azurerm_virtual_network" "main" {
name = "certlabpro-az-104-vnet"
resource_group_name = azurerm_resource_group.main.name
location = azurerm_resource_group.main.location
address_space = ["10.0.0.0/16"]
tags = local.tags
}
resource "azurerm_subnet" "app" {
name = "app"
resource_group_name = azurerm_resource_group.main.name
virtual_network_name = azurerm_virtual_network.main.name
address_prefixes = ["10.0.1.0/24"]
}
resource "azurerm_network_security_group" "app" {
name = "certlabpro-az-104-nsg"
resource_group_name = azurerm_resource_group.main.name
location = azurerm_resource_group.main.location
security_rule {
name = "AllowSSH"
priority = 100
direction = "Inbound"
access = "Allow"
protocol = "Tcp"
source_port_range = "*"
destination_port_range = "22"
source_address_prefix = "*"
destination_address_prefix = "*"
}
tags = local.tags
}
resource "azurerm_subnet_network_security_group_association" "app" {
subnet_id = azurerm_subnet.app.id
network_security_group_id = azurerm_network_security_group.app.id
}Padrões de armazenamento AZ-104: Camada Standard, LRS, apenas HTTPS, TLS 1.2 mínimo, acesso público bloqueado. Concederemos à identidade gerenciada da VM acesso de leitura a esta conta na Etapa 4. O domínio Manage Azure Identities and Governance testa este padrão de identidade gerenciada → recurso como a alternativa sem senha para armazenar chaves de conta de armazenamento na configuração do aplicativo.
resource "azurerm_storage_account" "data" {
name = "az104data${random_id.suffix.hex}"
resource_group_name = azurerm_resource_group.main.name
location = azurerm_resource_group.main.location
account_tier = "Standard"
account_replication_type = "LRS"
account_kind = "StorageV2"
https_traffic_only_enabled = true
min_tls_version = "TLS1_2"
allow_nested_items_to_be_public = false
tags = local.tags
}A VM é o artefato de computação canônico do AZ-104. Usamos Standard_B1s (a menor SKU Linux elegível para o nível gratuito), Ubuntu 22.04 LTS, autenticação por chave SSH (a resposta anti-padrão de senha do AZ-104) e uma identidade gerenciada atribuída ao sistema.
A atribuição de função concede a essa identidade gerenciada o papel de Storage Blob Data Reader na conta de armazenamento da Etapa 3 — o que significa que a VM pode chamar as APIs REST de armazenamento usando seu token de identidade, sem chaves armazenadas em disco. Esta é a questão de cruzamento Implement and Manage Storage + Identity do AZ-104: como uma VM acessa o armazenamento sem credenciais? Identidade gerenciada + atribuição de função RBAC.
resource "azurerm_public_ip" "vm" {
name = "certlabpro-az-104-vm-pip"
resource_group_name = azurerm_resource_group.main.name
location = azurerm_resource_group.main.location
allocation_method = "Static"
sku = "Standard"
tags = local.tags
}
resource "azurerm_network_interface" "vm" {
name = "certlabpro-az-104-vm-nic"
resource_group_name = azurerm_resource_group.main.name
location = azurerm_resource_group.main.location
ip_configuration {
name = "ipconfig1"
subnet_id = azurerm_subnet.app.id
private_ip_address_allocation = "Dynamic"
public_ip_address_id = azurerm_public_ip.vm.id
}
tags = local.tags
}
resource "azurerm_linux_virtual_machine" "main" {
name = "certlabpro-az-104-vm"
resource_group_name = azurerm_resource_group.main.name
location = azurerm_resource_group.main.location
size = "Standard_B1s"
admin_username = "azureuser"
disable_password_authentication = true
network_interface_ids = [azurerm_network_interface.vm.id]
admin_ssh_key {
username = "azureuser"
public_key = file("~/.ssh/id_rsa.pub")
}
os_disk {
caching = "ReadWrite"
storage_account_type = "Standard_LRS"
}
source_image_reference {
publisher = "Canonical"
offer = "0001-com-ubuntu-server-jammy"
sku = "22_04-lts-gen2"
version = "latest"
}
identity {
type = "SystemAssigned"
}
tags = local.tags
}
resource "azurerm_role_assignment" "vm_storage_reader" {
scope = azurerm_storage_account.data.id
role_definition_name = "Storage Blob Data Reader"
principal_id = azurerm_linux_virtual_machine.main.identity[0].principal_id
}O domínio Monitor and Maintain Azure Resources do AZ-104 (~10–15% do exame) depende do Log Analytics como destino para tudo o que é observável. Criamos o espaço de trabalho e uma Configuração de Diagnóstico na conta de armazenamento da Etapa 3 — cada transação de armazenamento agora chega em formato KQL consultável.
Para a VM, normalmente instalaríamos o Azure Monitor Agent (AMA) via uma extensão de VM — esse é o caminho moderno pós-Log-Analytics-Agent. Para o laboratório, configuramos o espaço de trabalho; a instalação do próprio agente é uma etapa de tempo de execução separada (azurerm_virtual_machine_extension) que é abordada nas seções Navegar / Editorial. A forma arquitetônica — espaço de trabalho existe, recursos fluem para ele — é o que as questões do AZ-104 testam.
resource "azurerm_log_analytics_workspace" "main" {
name = "certlabpro-az-104-logs"
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_monitor_diagnostic_setting" "storage" {
name = "diag"
target_resource_id = "${azurerm_storage_account.data.id}/blobServices/default/"
log_analytics_workspace_id = azurerm_log_analytics_workspace.main.id
enabled_log {
category = "StorageRead"
}
enabled_log {
category = "StorageWrite"
}
metric {
category = "AllMetrics"
enabled = true
}
}terraform destroy derruba tudo. Duas observações:
az vm deallocate interrompe a cobrança de computação (o armazenamento ainda é cobrado). terraform destroy remove tudo.Static — ele sobrevive à desalocação da VM e mantém a reserva de endereço IP. Destrua ou converta para Dynamic se você não quiser pagar por um IP público não utilizado (~$0.005/hora).O AZ-104 abrange uma ampla superfície de operações — Azure Backup, Recovery Services Vault, Site Recovery, Azure Files / Azure File Sync, Azure Migrate, Application Gateway, Load Balancer, Azure Bastion, VPN Gateway, ExpressRoute, Azure Firewall, Azure Policy, Azure Blueprints (depreciando), Acesso Condicional no Entra ID, B2B/B2C, funções personalizadas de RBAC e modelos ARM/Bicep.
Nós nos limitamos à linha de base VNet + VM + Storage + Monitor porque é o substrato que toda outra questão do AZ-104 presume. Adicione um Application Gateway para roteamento de camada 7; adicione um VPN Gateway para conectividade híbrida; adicione um Recovery Services Vault para backup — cada um é um complemento focado nesta base.
Para cobertura serviço a serviço, consulte as seções Navegar, Guia e Editorial desta página de certificação.