Laboratório Hands-on Guiado: AZ-104 Microsoft Azure Administrator

Cenário

A Contoso Seguros é uma seguradora de médio porte em processo de migração de cargas de trabalho críticas para o Azure. Atualmente, a empresa possui uma única subscription Azure com um Resource Group contendo uma VNet de hub e recursos básicos de rede. A equipe de infraestrutura recebeu a demanda de provisionar um ambiente de máquinas virtuais que atenda a requisitos rigorosos de alta disponibilidade, criptografia de dados em repouso e em trânsito, e elasticidade para suportar picos sazonais de processamento de apólices.

O objetivo global deste laboratório é construir, proteger, reorganizar e escalar a infraestrutura de VMs da Contoso Seguros, cobrindo desde a criação inicial de uma VM até a implantação de um Virtual Machine Scale Set com autoescalonamento, passando por criptografia no host, movimentação de recursos, gerenciamento de discos e dimensionamento, e distribuição em zonas de disponibilidade e conjuntos de disponibilidade.

Pré-requisitos

Antes de iniciar a Fase 1, confirme ou crie os recursos listados abaixo. Todos os comandos CLI assumem que você já executou az login e selecionou a subscription correta.

Subscription Azure com permissões de Owner ou Contributor. Verifique com:

az account show --query "{name:name, id:id, state:state}" -o table

Segunda subscription (necessária para a Fase 3, movimentação entre subscriptions). Se você não possui uma segunda subscription, poderá executar apenas a movimentação entre Resource Groups. Registre o ID da segunda subscription para uso posterior.
Registro do recurso EncryptionAtHost na subscription. Esse registro pode levar alguns minutos:

Via Portal

Navegue até Subscriptions > selecione sua subscription > Resource providers > pesquise por Microsoft.Compute > confirme que o status é Registered. Em seguida, navegue até Subscriptions > sua subscription > Preview features > pesquise por EncryptionAtHost > clique em Register se o status não for Registered.

Via CLI

# Registrar o feature EncryptionAtHost
az feature register --namespace Microsoft.Compute --name EncryptionAtHost

# Verificar o status (aguarde até "Registered")
az feature show --namespace Microsoft.Compute --name EncryptionAtHost --query "properties.state" -o tsv

# Propagar o registro
az provider register --namespace Microsoft.Compute

Resource Group principal:

az group create --name rg-contoso-lab --location brazilsouth

VNet e Subnet:

az network vnet create \
  --resource-group rg-contoso-lab \
  --name vnet-contoso-hub \
  --address-prefix 10.0.0.0/16 \
  --subnet-name snet-workloads \
  --subnet-prefix 10.0.1.0/24 \
  --location brazilsouth

Network Security Group associado à subnet:

az network nsg create \
  --resource-group rg-contoso-lab \
  --name nsg-workloads \
  --location brazilsouth

az network vnet subnet update \
  --resource-group rg-contoso-lab \
  --vnet-name vnet-contoso-hub \
  --name snet-workloads \
  --network-security-group nsg-workloads

Resource Group secundário (para movimentação de recursos):

az group create --name rg-contoso-destino --location brazilsouth

Tabela de referência de recursos

Recurso	Nome no lab	Região
Resource Group principal	rg-contoso-lab	Brazil South
Resource Group de destino	rg-contoso-destino	Brazil South
VNet	vnet-contoso-hub	Brazil South
Subnet	snet-workloads	Brazil South
NSG	nsg-workloads	Brazil South
VM principal	vm-apolices-01	Brazil South
VM em Availability Set	vm-backend-01	Brazil South
VM em Availability Zone	vm-frontend-01	Brazil South
Availability Set	avset-backend	Brazil South
Disk Encryption Set	des-contoso	Brazil South
Key Vault	kv-contoso-lab-XXX	Brazil South
VMSS	vmss-processamento	Brazil South

Substitua XXX no nome do Key Vault por um sufixo único (ex: suas iniciais + data), pois o nome deve ser globalmente exclusivo.

Fases do Laboratório

O laboratório está organizado em cinco fases progressivas. Cada fase constrói sobre os recursos criados anteriormente, simulando a evolução real de um ambiente de produção.

Fase 1 — Criação e Configuração Inicial de VM

Nesta fase você criará a primeira máquina virtual do ambiente da Contoso Seguros e configurará a criptografia no host. Essa VM servirá de base para todas as operações das fases seguintes. Os objetivos cobertos são: Create a virtual machine e Configure encryption at host for Azure virtual machines.

Tarefa 1.1 — Criar a máquina virtual principal

A Contoso Seguros precisa de uma VM Windows Server para o sistema de processamento de apólices. Você criará a VM com configurações específicas e validará que ela está operacional antes de prosseguir.

Via Portal

Navegue até Virtual machines > + Create > Azure virtual machine
Na aba Basics, preencha:
- Subscription: sua subscription ativa
- Resource group: rg-contoso-lab
- Virtual machine name: vm-apolices-01
- Region: Brazil South
- Availability options: No infrastructure redundancy required (será alterado em fases posteriores)
- Security type: Standard (importante para compatibilidade com encryption at host)
- Image: Windows Server 2022 Datacenter: Azure Edition - x64 Gen2
- Size: Standard_D2s_v5 (2 vCPUs, 8 GiB RAM)
- Administrator account: defina username admincontoso e uma senha forte
Na aba Disks:
- OS disk type: Premium SSD
- Encryption at host: marque a caixa para habilitar (se a opção não estiver disponível, retorne aos pré-requisitos e verifique o registro do feature EncryptionAtHost)
Na aba Networking:
- Virtual network: vnet-contoso-hub
- Subnet: snet-workloads
- Public IP: selecione None (a VM não precisa de IP público neste momento)
- NIC network security group: None (o NSG está na subnet)
Na aba Management: mantenha os padrões
Clique em Review + create > Create

Via CLI

az vm create \
  --resource-group rg-contoso-lab \
  --name vm-apolices-01 \
  --image Win2022AzureEditionCore \
  --size Standard_D2s_v5 \
  --admin-username admincontoso \
  --admin-password "SuaSenhaForte@2026!" \
  --vnet-name vnet-contoso-hub \
  --subnet snet-workloads \
  --public-ip-address "" \
  --nsg "" \
  --security-type Standard \
  --encryption-at-host true \
  --os-disk-name osdisk-apolices-01 \
  --location brazilsouth

A VM será provisionada com disco de SO Premium SSD, conectada à subnet de workloads e com criptografia no host habilitada desde o início. A criptografia no host garante que os dados nos discos temporários e nos caches dos discos de dados e de SO sejam criptografados em repouso, fluindo criptografados até o serviço de Storage.

Tarefa 1.2 — Verificar o estado da criptografia no host

Antes de considerar a VM protegida, você deve validar que a criptografia no host está de fato ativa. Essa verificação é essencial porque a habilitação pode falhar silenciosamente se o feature provider não estiver registrado ou se o tamanho da VM não suportar o recurso.

Via Portal

Navegue até Virtual machines > vm-apolices-01 > Disks
Na seção Additional settings, verifique se o campo Encryption at host exibe Enabled
Navegue até Virtual machines > vm-apolices-01 > Overview > verifique que o Status é Running

Via CLI

# Verificar encryption at host
az vm show \
  --resource-group rg-contoso-lab \
  --name vm-apolices-01 \
  --query "securityProfile.encryptionAtHost" -o tsv
# Output esperado: true

# Verificar status da VM
az vm get-instance-view \
  --resource-group rg-contoso-lab \
  --name vm-apolices-01 \
  --query "instanceView.statuses[?starts_with(code,'PowerState')].displayStatus" -o tsv
# Output esperado: VM running

Essa validação confirma que a criptografia no host está operacional. Se o output retornar false ou a propriedade não existir, investigue se o feature EncryptionAtHost está registrado e se o tamanho da VM pertence a uma família que suporta o recurso (séries Dsv3, Dsv5, Esv3, entre outras).

Tarefa 1.3 — Simular falha de habilitação de encryption at host com VM incompatível

Para entender o comportamento de erro, você tentará habilitar encryption at host em uma VM com tamanho incompatível. Esse cenário adverso é comum quando equipes escolhem tamanhos de VM sem verificar compatibilidade com criptografia.

Via CLI

# Tentar criar uma VM com tamanho que NÃO suporta encryption at host
az vm create \
  --resource-group rg-contoso-lab \
  --name vm-teste-falha \
  --image Ubuntu2204 \
  --size Standard_B1s \
  --admin-username admincontoso \
  --admin-password "SuaSenhaForte@2026!" \
  --vnet-name vnet-contoso-hub \
  --subnet snet-workloads \
  --public-ip-address "" \
  --nsg "" \
  --security-type Standard \
  --encryption-at-host true \
  --location brazilsouth

Via Portal

Navegue até Virtual machines > + Create > Azure virtual machine
Preencha os campos obrigatórios com Resource Group rg-contoso-lab, nome vm-teste-falha, imagem Ubuntu Server 22.04 LTS
Selecione o tamanho Standard_B1s
Na aba Disks, tente marcar Encryption at host
Observe a mensagem de erro indicando que o tamanho selecionado não suporta o recurso

O Azure retornará um erro informando que o tamanho de VM selecionado não suporta criptografia no host. Registre a mensagem de erro para referência. Se a VM vm-teste-falha tiver sido criada parcialmente, remova-a:

az vm delete --resource-group rg-contoso-lab --name vm-teste-falha --yes --no-wait

Fase 2 — Gerenciamento de Discos e Dimensionamento da VM

Nesta fase, você trabalhará com a VM vm-apolices-01 criada na Fase 1 para gerenciar discos (adicionar, redimensionar, alterar tipo) e alterar o tamanho da VM. Os objetivos cobertos são: Manage virtual machine disks e Manage virtual machine sizes.

Tarefa 2.1 — Adicionar e configurar discos de dados

O sistema de apólices da Contoso precisa de um disco de dados dedicado para armazenamento de documentos e outro para logs de auditoria. Você adicionará dois discos managed à VM.

Via Portal

Navegue até Virtual machines > vm-apolices-01 > Disks
Na seção Data disks, clique em Create and attach a new disk
Para o primeiro disco:
- Name: disk-apolices-data
- Storage type: Premium SSD
- Size (GiB): 64
- LUN: 0
Clique novamente em Create and attach a new disk para o segundo disco:
- Name: disk-apolices-logs
- Storage type: Standard SSD
- Size (GiB): 32
- LUN: 1
Clique em Apply

Via CLI

# Criar e anexar disco de dados para documentos
az vm disk attach \
  --resource-group rg-contoso-lab \
  --vm-name vm-apolices-01 \
  --name disk-apolices-data \
  --size-gb 64 \
  --sku Premium_LRS \
  --lun 0 \
  --new

# Criar e anexar disco de logs
az vm disk attach \
  --resource-group rg-contoso-lab \
  --vm-name vm-apolices-01 \
  --name disk-apolices-logs \
  --size-gb 32 \
  --sku StandardSSD_LRS \
  --lun 1 \
  --new

Os discos managed são criados e associados à VM. Como a VM já possui encryption at host habilitada, os dados gravados nesses discos também serão criptografados automaticamente no host, incluindo os dados no cache.

Tarefa 2.2 — Expandir e alterar o tipo de disco

A equipe de armazenamento identificou que o disco de logs precisa de maior capacidade e melhor desempenho. Você redimensionará o disco e alterará seu SKU. Essa operação requer que a VM esteja desalocada.

Via Portal

Navegue até Virtual machines > vm-apolices-01 > Overview > clique em Stop > confirme a desalocação
Aguarde até que o status mude para Stopped (deallocated)
Navegue até Virtual machines > vm-apolices-01 > Disks
Clique no disco disk-apolices-logs
No blade do disco, clique em Size + performance
Altere o Storage type para Premium SSD
Altere o Size para 64 GiB
Clique em Save
Retorne à VM e clique em Start

Via CLI

# Desalocar a VM (obrigatório para alterar tipo/tamanho de disco)
az vm deallocate \
  --resource-group rg-contoso-lab \
  --name vm-apolices-01

# Redimensionar e alterar o SKU do disco de logs
az disk update \
  --resource-group rg-contoso-lab \
  --name disk-apolices-logs \
  --size-gb 64 \
  --sku Premium_LRS

# Reiniciar a VM
az vm start \
  --resource-group rg-contoso-lab \
  --name vm-apolices-01

O disco de logs agora possui 64 GiB e utiliza Premium SSD. Note que a redução de tamanho de disco managed não é suportada pelo Azure; apenas expansões são permitidas. A alteração de SKU para Premium SSD melhora a latência de escrita, o que é crítico para logs de auditoria.

Tarefa 2.3 — Alterar o tamanho da VM

A carga de processamento de apólices aumentou, e a VM precisa de mais recursos. Você primeiro verificará quais tamanhos estão disponíveis na região e então fará o redimensionamento.

Via Portal

Navegue até Virtual machines > vm-apolices-01 > Availability + scaling > Size
Observe a lista de tamanhos disponíveis. Note que alguns tamanhos exigem desalocação (indicados com ícone de alerta)
Selecione Standard_D4s_v5 (4 vCPUs, 16 GiB RAM)
Clique em Resize
Se a VM estiver em execução e o novo tamanho exigir desalocação, o portal solicitará confirmação. Confirme

Via CLI

# Listar tamanhos disponíveis para a VM na região
az vm list-vm-resize-options \
  --resource-group rg-contoso-lab \
  --name vm-apolices-01 \
  --query "[].{Name:name, vCPUs:numberOfCores, MemoryGB:memoryInMb}" -o table

# Redimensionar a VM (pode exigir desalocação automática)
az vm resize \
  --resource-group rg-contoso-lab \
  --name vm-apolices-01 \
  --size Standard_D4s_v5

O redimensionamento altera a quantidade de vCPUs e memória disponíveis para a VM. Se o novo tamanho não estiver no mesmo cluster de hardware, o Azure precisará desalocar e realocar a VM, causando um breve período de indisponibilidade. Verifique que a encryption at host continua ativa após o redimensionamento, pois o novo tamanho (D4s_v5) também suporta o recurso.

Tarefa 2.4 — Desanexar disco e verificar persistência dos dados

Para validar que os discos managed são independentes da VM, você desanexará o disco de dados, verificará que ele persiste como recurso, e o reanexará.

Via Portal

Navegue até Virtual machines > vm-apolices-01 > Disks
Na linha do disco disk-apolices-data, clique no ícone X (Detach) à direita
Clique em Apply
Navegue até Disks (no menu principal do portal) > pesquise disk-apolices-data
Confirme que o disco existe com status Unattached e que seus dados (tamanho, SKU) estão preservados
Retorne a Virtual machines > vm-apolices-01 > Disks > Attach existing disks
Selecione disk-apolices-data e defina LUN como 0
Clique em Apply

Via CLI

# Desanexar o disco de dados
az vm disk detach \
  --resource-group rg-contoso-lab \
  --vm-name vm-apolices-01 \
  --name disk-apolices-data

# Verificar que o disco persiste como recurso independente
az disk show \
  --resource-group rg-contoso-lab \
  --name disk-apolices-data \
  --query "{name:name, diskState:diskState, sizeGb:diskSizeGb, sku:sku.name}" -o table
# Output esperado: diskState = Unattached

# Reanexar o disco
az vm disk attach \
  --resource-group rg-contoso-lab \
  --vm-name vm-apolices-01 \
  --name disk-apolices-data \
  --lun 0

Essa operação demonstra que discos managed no Azure são recursos de primeira classe, independentes do ciclo de vida da VM. O disco mantém seus dados e configurações mesmo quando desanexado, podendo ser movido entre VMs conforme necessário.

Fase 3 — Movimentação de VM entre Resource Groups e Subscriptions

Nesta fase, você moverá recursos da VM vm-apolices-01 (criada na Fase 1 e configurada na Fase 2) para outro Resource Group e, opcionalmente, para outra subscription. O objetivo coberto é: Move a virtual machine to another resource group, subscription, or region.

Tarefa 3.1 — Validar pré-requisitos de movimentação e mover VM para outro Resource Group

A equipe de governança da Contoso Seguros decidiu reorganizar os recursos por departamento. A VM de apólices deve ser movida para o Resource Group rg-contoso-destino. Antes de executar a movimentação, é necessário validar que ela é possível.

Via Portal

Navegue até Resource groups > rg-contoso-lab
Marque a caixa de seleção ao lado de vm-apolices-01
Clique em Move > Move to another resource group
Na tela de validação, observe que o Azure listará todos os recursos dependentes que precisam ser movidos junto (disco de SO, discos de dados, interface de rede)
Selecione rg-contoso-destino como Resource Group de destino
Marque a caixa de seleção de todos os recursos dependentes listados (NIC, discos, etc.)
Marque o checkbox de confirmação indicando que ferramentas e scripts precisarão ser atualizados com os novos IDs de recursos
Clique em Validate e aguarde a validação ser concluída com sucesso
Clique em Move (o processo pode levar vários minutos)

Via CLI

# Obter o ID completo da VM e recursos associados
VM_ID=$(az vm show --resource-group rg-contoso-lab --name vm-apolices-01 --query "id" -o tsv)
NIC_ID=$(az vm show --resource-group rg-contoso-lab --name vm-apolices-01 --query "networkProfile.networkInterfaces[0].id" -o tsv)
OSDISK_ID=$(az vm show --resource-group rg-contoso-lab --name vm-apolices-01 --query "storageProfile.osDisk.managedDisk.id" -o tsv)
DATADISK1_ID=$(az disk show --resource-group rg-contoso-lab --name disk-apolices-data --query "id" -o tsv)
DATADISK2_ID=$(az disk show --resource-group rg-contoso-lab --name disk-apolices-logs --query "id" -o tsv)

# Validar a movimentação antes de executar
az resource invoke-action \
  --action validateMoveResources \
  --ids $VM_ID \
  --request-body "{\"resources\": [\"$VM_ID\",\"$NIC_ID\",\"$OSDISK_ID\",\"$DATADISK1_ID\",\"$DATADISK2_ID\"], \"targetResourceGroup\": \"/subscriptions/$(az account show --query id -o tsv)/resourceGroups/rg-contoso-destino\"}"

# Executar a movimentação
az resource move \
  --destination-group rg-contoso-destino \
  --ids $VM_ID $NIC_ID $OSDISK_ID $DATADISK1_ID $DATADISK2_ID

A movimentação de uma VM entre Resource Groups é uma operação de metadados que não causa downtime. Porém, todos os recursos dependentes (NIC, discos, IP público se existir) devem ser movidos juntos. Os IDs de recurso mudam após a movimentação, o que pode impactar scripts e políticas existentes.

Tarefa 3.2 — Verificar a integridade pós-movimentação

Após a movimentação, é essencial confirmar que a VM e todos os recursos dependentes estão no novo Resource Group e funcionando corretamente.

Via Portal

Navegue até Resource groups > rg-contoso-destino
Verifique que os seguintes recursos estão presentes: vm-apolices-01, discos, NIC
Navegue até Virtual machines > vm-apolices-01 > Overview
Confirme que o Status é Running (ou inicie a VM se estava parada)
Navegue até Virtual machines > vm-apolices-01 > Disks
Confirme que ambos os discos de dados estão anexados e que Encryption at host ainda está Enabled

Via CLI

# Listar recursos no RG de destino
az resource list \
  --resource-group rg-contoso-destino \
  --query "[].{Name:name, Type:type}" -o table

# Verificar status da VM
az vm get-instance-view \
  --resource-group rg-contoso-destino \
  --name vm-apolices-01 \
  --query "instanceView.statuses[?starts_with(code,'PowerState')].displayStatus" -o tsv

# Confirmar encryption at host após movimentação
az vm show \
  --resource-group rg-contoso-destino \
  --name vm-apolices-01 \
  --query "securityProfile.encryptionAtHost" -o tsv

Tarefa 3.3 — Mover VM para outra subscription (opcional) e planejar movimentação entre regiões

Se você possui uma segunda subscription, execute a movimentação da VM para ela. Caso contrário, planeje e documente os passos que seriam necessários.

Movimentação entre subscriptions (Via CLI)

# Obter IDs atualizados (agora no rg-contoso-destino)
VM_ID=$(az vm show --resource-group rg-contoso-destino --name vm-apolices-01 --query "id" -o tsv)
NIC_ID=$(az vm show --resource-group rg-contoso-destino --name vm-apolices-01 --query "networkProfile.networkInterfaces[0].id" -o tsv)
OSDISK_ID=$(az vm show --resource-group rg-contoso-destino --name vm-apolices-01 --query "storageProfile.osDisk.managedDisk.id" -o tsv)
DATADISK1_ID=$(az disk show --resource-group rg-contoso-destino --name disk-apolices-data --query "id" -o tsv)
DATADISK2_ID=$(az disk show --resource-group rg-contoso-destino --name disk-apolices-logs --query "id" -o tsv)

# Definir a subscription de destino
DEST_SUB_ID="<ID-da-segunda-subscription>"

# Criar um RG de destino na subscription alvo
az group create \
  --name rg-contoso-migrado \
  --location brazilsouth \
  --subscription $DEST_SUB_ID

# Mover recursos para outra subscription
az resource move \
  --destination-group rg-contoso-migrado \
  --destination-subscription-id $DEST_SUB_ID \
  --ids $VM_ID $NIC_ID $OSDISK_ID $DATADISK1_ID $DATADISK2_ID

Movimentação entre regiões

A movimentação direta de VM entre regiões não é suportada como operação de move. Para mover uma VM para outra região, é necessário utilizar o Azure Resource Mover ou recriar a VM na região de destino. Os passos conceituais são:

Navegue até Azure Resource Mover no portal
Selecione a região de origem (Brazil South) e a região de destino (ex: East US 2)
Adicione os recursos da VM (VM, discos, NIC, VNet de destino)
Resolva dependências apontadas pelo Resource Mover
Inicie a preparação e, após validação, execute a movimentação
Confirme o commit e remova os recursos da região de origem

Se você executou a movimentação entre subscriptions, retorne a VM para rg-contoso-destino na subscription original antes de prosseguir para a Fase 4. Caso contrário, continue usando rg-contoso-destino.

Para as fases seguintes, o laboratório assume que a VM vm-apolices-01 está no Resource Group rg-contoso-destino.

Fase 4 — Alta Disponibilidade com Availability Zones e Availability Sets

Nesta fase, você criará novas VMs distribuídas em Availability Zones e um Availability Set, utilizando a VNet vnet-contoso-hub criada nos pré-requisitos e ainda presente em rg-contoso-lab. O objetivo coberto é: Deploy virtual machines to availability zones and availability sets.

Tarefa 4.1 — Criar VMs em Availability Zones distintas

A Contoso Seguros precisa de VMs de frontend distribuídas em zonas de disponibilidade para garantir resiliência contra falhas de datacenter. Você criará duas VMs, cada uma em uma zona diferente.

Via Portal

Navegue até Virtual machines > + Create > Azure virtual machine
Na aba Basics:
- Resource group: rg-contoso-lab
- Virtual machine name: vm-frontend-01
- Region: Brazil South
- Availability options: Availability zone
- Availability zone: Zone 1
- Security type: Standard
- Image: Ubuntu Server 22.04 LTS - x64 Gen2
- Size: Standard_D2s_v5
- Authentication type: Password
- Username: admincontoso
Na aba Disks: mantenha padrões (Premium SSD)
Na aba Networking: selecione vnet-contoso-hub / snet-workloads, sem IP público
Clique em Review + create > Create
Repita o processo para vm-frontend-02 com Availability zone: Zone 2

Via CLI

# VM na Zona 1
az vm create \
  --resource-group rg-contoso-lab \
  --name vm-frontend-01 \
  --image Ubuntu2204 \
  --size Standard_D2s_v5 \
  --admin-username admincontoso \
  --admin-password "SuaSenhaForte@2026!" \
  --vnet-name vnet-contoso-hub \
  --subnet snet-workloads \
  --public-ip-address "" \
  --nsg "" \
  --zone 1 \
  --security-type Standard \
  --location brazilsouth

# VM na Zona 2
az vm create \
  --resource-group rg-contoso-lab \
  --name vm-frontend-02 \
  --image Ubuntu2204 \
  --size Standard_D2s_v5 \
  --admin-username admincontoso \
  --admin-password "SuaSenhaForte@2026!" \
  --vnet-name vnet-contoso-hub \
  --subnet snet-workloads \
  --public-ip-address "" \
  --nsg "" \
  --zone 2 \
  --security-type Standard \
  --location brazilsouth

As duas VMs estão agora em zonas de disponibilidade distintas. Isso garante que, se uma zona inteira sofrer uma falha (energia, rede ou resfriamento), a outra VM permanecerá operacional. O SLA para VMs em zonas de disponibilidade é de 99,99%.

Tarefa 4.2 — Criar um Availability Set e implantar VMs de backend

Os servidores de backend da Contoso não requerem proteção contra falha de datacenter inteiro, mas precisam de proteção contra falhas de hardware e atualizações de plataforma. Você criará um Availability Set e duas VMs dentro dele.

Via Portal

Navegue até a barra de pesquisa do portal > digite Availability Sets > + Create
Preencha:
- Resource group: rg-contoso-lab
- Name: avset-backend
- Region: Brazil South
- Fault domains: 2
- Update domains: 5
Clique em Review + create > Create
Navegue até Virtual machines > + Create > Azure virtual machine
Na aba Basics:
- Resource group: rg-contoso-lab
- Virtual machine name: vm-backend-01
- Availability options: Availability set
- Availability set: avset-backend
- Security type: Standard
- Image: Ubuntu Server 22.04 LTS - x64 Gen2
- Size: Standard_D2s_v5
Complete as abas restantes conforme padrões anteriores (mesma VNet/Subnet, sem IP público)
Repita para vm-backend-02, selecionando o mesmo Availability Set avset-backend

Via CLI

# Criar o Availability Set
az vm availability-set create \
  --resource-group rg-contoso-lab \
  --name avset-backend \
  --platform-fault-domain-count 2 \
  --platform-update-domain-count 5 \
  --location brazilsouth

# VM de backend 01
az vm create \
  --resource-group rg-contoso-lab \
  --name vm-backend-01 \
  --image Ubuntu2204 \
  --size Standard_D2s_v5 \
  --admin-username admincontoso \
  --admin-password "SuaSenhaForte@2026!" \
  --vnet-name vnet-contoso-hub \
  --subnet snet-workloads \
  --public-ip-address "" \
  --nsg "" \
  --availability-set avset-backend \
  --security-type Standard \
  --location brazilsouth

# VM de backend 02
az vm create \
  --resource-group rg-contoso-lab \
  --name vm-backend-02 \
  --image Ubuntu2204 \
  --size Standard_D2s_v5 \
  --admin-username admincontoso \
  --admin-password "SuaSenhaForte@2026!" \
  --vnet-name vnet-contoso-hub \
  --subnet snet-workloads \
  --public-ip-address "" \
  --nsg "" \
  --availability-set avset-backend \
  --security-type Standard \
  --location brazilsouth

As VMs de backend estão distribuídas em fault domains e update domains distintos dentro do Availability Set. Isso garante que o Azure não executará manutenção planejada em ambas simultaneamente e que falhas de rack físico não afetem ambas ao mesmo tempo.

Tarefa 4.3 — Verificar distribuição de fault domains e tentar adicionar VM zonal ao Availability Set

Nesta tarefa, você verificará a distribuição das VMs nos fault domains e tentará combinar Availability Zone com Availability Set para observar a incompatibilidade.

Via Portal

Navegue até Availability Sets > avset-backend
Observe a lista de VMs e confirme que vm-backend-01 e vm-backend-02 estão em fault domains diferentes
Anote o Update domain de cada VM

Via CLI

# Verificar distribuição no Availability Set
az vm availability-set show \
  --resource-group rg-contoso-lab \
  --name avset-backend \
  --query "virtualMachines[].id" -o tsv

az vm show --resource-group rg-contoso-lab --name vm-backend-01 \
  --query "instanceView.platformFaultDomain" -o tsv 2>/dev/null

az vm get-instance-view --resource-group rg-contoso-lab --name vm-backend-01 \
  --query "instanceView.platformFaultDomain" -o tsv

az vm get-instance-view --resource-group rg-contoso-lab --name vm-backend-02 \
  --query "instanceView.platformFaultDomain" -o tsv

Cenário adverso: tentar combinar zona e Availability Set

# Esta operação FALHARÁ - zona e availability set são mutuamente exclusivos
az vm create \
  --resource-group rg-contoso-lab \
  --name vm-teste-conflito \
  --image Ubuntu2204 \
  --size Standard_D2s_v5 \
  --admin-username admincontoso \
  --admin-password "SuaSenhaForte@2026!" \
  --vnet-name vnet-contoso-hub \
  --subnet snet-workloads \
  --public-ip-address "" \
  --nsg "" \
  --availability-set avset-backend \
  --zone 1 \
  --security-type Standard \
  --location brazilsouth

O Azure retornará erro informando que não é possível especificar Availability Zone e Availability Set simultaneamente. Esses dois mecanismos de alta disponibilidade são mutuamente exclusivos, e a escolha entre eles deve ser feita no momento do design da arquitetura, conforme os requisitos de SLA e resiliência.

Fase 5 — Virtual Machine Scale Sets com Autoescalonamento

Nesta fase, você criará e configurará um Virtual Machine Scale Set para lidar com o processamento sazonal de apólices da Contoso Seguros, utilizando a VNet vnet-contoso-hub de rg-contoso-lab. O objetivo coberto é: Deploy and configure an Azure Virtual Machine Scale Sets.

Tarefa 5.1 — Criar o Virtual Machine Scale Set

O departamento de processamento de apólices da Contoso precisa de escalabilidade elástica para lidar com picos de final de mês. Você criará um VMSS com orquestração Flexible e configuração inicial.

Via Portal

Navegue até Virtual Machine Scale Sets > + Create
Na aba Basics:
- Resource group: rg-contoso-lab
- Virtual machine scale set name: vmss-processamento
- Region: Brazil South
- Availability zone: selecione Zone 1 e Zone 2
- Orchestration mode: Flexible
- Security type: Standard
- Image: Ubuntu Server 22.04 LTS - x64 Gen2
- Size: Standard_D2s_v5
- Authentication type: Password
- Username: admincontoso
Na aba Disks: mantenha Premium SSD como tipo de disco de SO
Na aba Networking:
- Virtual network: vnet-contoso-hub
- Subnet: snet-workloads
- Network interface: edite para remover o IP público das instâncias
Na aba Scaling:
- Initial instance count: 2
- Scaling policy: Custom
- Minimum number of instances: 2
- Maximum number of instances: 6
- Scale out: CPU threshold > 75%, increase count by 1, cooldown 5 minutes
- Scale in: CPU threshold < 25%, decrease count by 1, cooldown 5 minutes
Na aba Health:
- Enable application health monitoring: marque
- Health probe protocol: TCP
- Port number: 80
Clique em Review + create > Create

Via CLI

# Criar o VMSS com autoescalonamento
az vmss create \
  --resource-group rg-contoso-lab \
  --name vmss-processamento \
  --image Ubuntu2204 \
  --vm-sku Standard_D2s_v5 \
  --admin-username admincontoso \
  --admin-password "SuaSenhaForte@2026!" \
  --vnet-name vnet-contoso-hub \
  --subnet snet-workloads \
  --instance-count 2 \
  --zones 1 2 \
  --orchestration-mode Flexible \
  --public-ip-address "" \
  --security-type Standard \
  --location brazilsouth

# Configurar regras de autoescalonamento
az monitor autoscale create \
  --resource-group rg-contoso-lab \
  --resource vmss-processamento \
  --resource-type Microsoft.Compute/virtualMachineScaleSets \
  --name autoscale-processamento \
  --min-count 2 \
  --max-count 6 \
  --count 2

# Regra de scale-out (CPU > 75%)
az monitor autoscale rule create \
  --resource-group rg-contoso-lab \
  --autoscale-name autoscale-processamento \
  --condition "Percentage CPU > 75 avg 5m" \
  --scale out 1

# Regra de scale-in (CPU < 25%)
az monitor autoscale rule create \
  --resource-group rg-contoso-lab \
  --autoscale-name autoscale-processamento \
  --condition "Percentage CPU < 25 avg 5m" \
  --scale in 1

O VMSS está configurado para distribuir instâncias entre as zonas 1 e 2, com escalonamento automático baseado em utilização de CPU. A contagem inicial de 2 instâncias garante disponibilidade mínima, enquanto o limite de 6 permite absorver picos sem provisionamento manual.

Tarefa 5.2 — Testar o autoescalonamento com carga simulada

Para validar que o autoescalonamento funciona corretamente, você simulará carga de CPU nas instâncias do VMSS e observará a criação automática de novas instâncias.

Via CLI

# Listar instâncias atuais do VMSS
az vmss list-instances \
  --resource-group rg-contoso-lab \
  --name vmss-processamento \
  --query "[].{Name:name, Zone:zones[0], State:instanceView.statuses[?starts_with(code,'PowerState')].displayStatus | [0]}" -o table

# Instalar extensão de script personalizado para gerar carga de CPU
az vmss extension set \
  --resource-group rg-contoso-lab \
  --vmss-name vmss-processamento \
  --name CustomScript \
  --publisher Microsoft.Azure.Extensions \
  --version 2.1 \
  --settings '{"commandToExecute":"apt-get update && apt-get install -y stress && stress --cpu 4 --timeout 600"}'

# Monitorar a contagem de instâncias ao longo do tempo (execute várias vezes)
az vmss list-instances \
  --resource-group rg-contoso-lab \
  --name vmss-processamento \
  --query "length(@)" -o tsv

# Verificar métricas de CPU do VMSS
az monitor metrics list \
  --resource $(az vmss show --resource-group rg-contoso-lab --name vmss-processamento --query "id" -o tsv) \
  --metric "Percentage CPU" \
  --interval PT1M \
  --query "value[0].timeseries[0].data[-5:]" -o table

Via Portal

Navegue até Virtual Machine Scale Sets > vmss-processamento > Instances
Observe a contagem inicial de instâncias (deve ser 2)
Aguarde de 5 a 10 minutos após a extensão gerar carga
Atualize a página de Instances e observe se novas instâncias estão sendo criadas
Navegue até Virtual Machine Scale Sets > vmss-processamento > Metrics
Selecione a métrica Percentage CPU e observe o gráfico subir acima de 75%

Após o período de carga (10 minutos), a ferramenta stress será encerrada automaticamente. Com a redução da CPU abaixo de 25%, o autoscaler iniciará o processo de scale-in após o cooldown de 5 minutos, removendo instâncias excedentes até atingir o mínimo de 2.

Tarefa 5.3 — Atualizar configuração do VMSS e aplicar upgrade de imagem

A equipe de segurança solicitou que todas as instâncias do VMSS incluam um pacote adicional de monitoramento. Você atualizará o modelo do VMSS e aplicará a atualização às instâncias existentes.

Via Portal

Navegue até Virtual Machine Scale Sets > vmss-processamento > Extensions + applications
Observe a extensão CustomScript já instalada
Navegue até Virtual Machine Scale Sets > vmss-processamento > Scaling
Verifique que as regras de autoescalonamento estão configuradas conforme definido na Tarefa 5.1
Ajuste o Maximum number of instances para 8 (simulando aumento de capacidade aprovada)
Clique em Save

Via CLI

# Atualizar o limite máximo de instâncias
az monitor autoscale update \
  --resource-group rg-contoso-lab \
  --name autoscale-processamento \
  --max-count 8

# Verificar a configuração atualizada
az monitor autoscale show \
  --resource-group rg-contoso-lab \
  --name autoscale-processamento \
  --query "{minCount:profiles[0].capacity.minimum, maxCount:profiles[0].capacity.maximum, defaultCount:profiles[0].capacity.default}" -o table

A atualização do limite máximo é aplicada imediatamente ao perfil de autoescalonamento. Instâncias existentes não são afetadas por essa mudança; ela apenas permite que o autoscaler crie mais instâncias durante picos futuros. Para mudanças no modelo da VM (como nova imagem ou extensões), seria necessário executar um upgrade das instâncias.

Validação Final

Verifique os seguintes critérios para confirmar que o laboratório foi executado com sucesso:

Encryption at host ativa na VM principal: Execute az vm show --resource-group rg-contoso-destino --name vm-apolices-01 --query "securityProfile.encryptionAtHost" e confirme que o output é true. Alternativamente, no portal, navegue até a VM > Disks e verifique o campo Encryption at host.
VM movida para o Resource Group de destino: Navegue até Resource groups > rg-contoso-destino e confirme que vm-apolices-01 está presente com todos os recursos dependentes (discos e NIC). Via CLI: az vm show --resource-group rg-contoso-destino --name vm-apolices-01 --query "name" -o tsv.
VMs de frontend em zonas de disponibilidade distintas: Execute az vm show --resource-group rg-contoso-lab --name vm-frontend-01 --query "zones[0]" e az vm show --resource-group rg-contoso-lab --name vm-frontend-02 --query "zones[0]". Os outputs devem retornar zonas diferentes (ex: "1" e "2").
VMSS respondendo a carga com scale-out: Navegue até Virtual Machine Scale Sets > vmss-processamento > Activity log e procure por eventos do tipo "Autoscale scale up completed". Isso confirma que o autoescalonamento não apenas está configurado, mas efetivamente respondeu a uma condição de carga real, criando novas instâncias automaticamente.
VMs de backend em fault domains distintos no Availability Set: Navegue até Availability Sets > avset-backend e confirme que as duas VMs estão listadas em fault domains diferentes. Via CLI: execute az vm get-instance-view para cada VM de backend e compare os valores de platformFaultDomain.

Cleanup do Ambiente

Remova todos os recursos criados durante o laboratório para evitar cobranças. Execute na ordem inversa à criação:

Via Portal

Navegue até Virtual Machine Scale Sets > vmss-processamento > Delete > confirme digitando o nome
Navegue até Availability Sets > avset-backend (será removido junto com o Resource Group)
Navegue até Resource groups > rg-contoso-destino > Delete resource group > digite o nome do RG para confirmar
Navegue até Resource groups > rg-contoso-lab > Delete resource group > digite o nome do RG para confirmar
Aguarde a conclusão de ambas as exclusões (pode levar vários minutos)
Navegue até Resource groups e confirme que nem rg-contoso-lab nem rg-contoso-destino aparecem na lista

Via CLI

# Remover o Resource Group de destino (inclui vm-apolices-01 e dependências)
az group delete --name rg-contoso-destino --yes --no-wait

# Remover o Resource Group principal (inclui VNet, NSG, VMs de frontend/backend, VMSS, Availability Set)
az group delete --name rg-contoso-lab --yes --no-wait

# Se você criou o RG na segunda subscription
# az group delete --name rg-contoso-migrado --yes --no-wait --subscription $DEST_SUB_ID

# Verificar que a exclusão foi concluída (execute após alguns minutos)
az group list --query "[?name=='rg-contoso-lab' || name=='rg-contoso-destino'].{Name:name, State:properties.provisioningState}" -o table
# Output esperado: tabela vazia (sem resultados)

A exclusão do Resource Group remove automaticamente todos os recursos filhos (VMs, discos, NICs, NSGs, VNets, Availability Sets, VMSS). Aguarde até que o comando de verificação retorne uma tabela vazia para confirmar que todos os recursos foram eliminados e que nenhuma cobrança adicional será gerada.

Cenário​

Pré-requisitos​

Via Portal​

Via CLI​

Tabela de referência de recursos​

Fases do Laboratório​

Fase 1 — Criação e Configuração Inicial de VM​

Tarefa 1.1 — Criar a máquina virtual principal​

Via Portal​

Via CLI​

Tarefa 1.2 — Verificar o estado da criptografia no host​

Via Portal​

Via CLI​

Tarefa 1.3 — Simular falha de habilitação de encryption at host com VM incompatível​

Via CLI​

Via Portal​

Fase 2 — Gerenciamento de Discos e Dimensionamento da VM​

Tarefa 2.1 — Adicionar e configurar discos de dados​

Via Portal​

Via CLI​

Tarefa 2.2 — Expandir e alterar o tipo de disco​

Via Portal​

Via CLI​

Tarefa 2.3 — Alterar o tamanho da VM​

Via Portal​

Via CLI​

Tarefa 2.4 — Desanexar disco e verificar persistência dos dados​

Via Portal​

Via CLI​

Fase 3 — Movimentação de VM entre Resource Groups e Subscriptions​

Tarefa 3.1 — Validar pré-requisitos de movimentação e mover VM para outro Resource Group​

Via Portal​

Via CLI​

Tarefa 3.2 — Verificar a integridade pós-movimentação​

Via Portal​

Via CLI​

Tarefa 3.3 — Mover VM para outra subscription (opcional) e planejar movimentação entre regiões​

Movimentação entre subscriptions (Via CLI)​

Movimentação entre regiões​

Fase 4 — Alta Disponibilidade com Availability Zones e Availability Sets​

Tarefa 4.1 — Criar VMs em Availability Zones distintas​

Via Portal​

Via CLI​

Tarefa 4.2 — Criar um Availability Set e implantar VMs de backend​

Via Portal​

Via CLI​

Tarefa 4.3 — Verificar distribuição de fault domains e tentar adicionar VM zonal ao Availability Set​

Via Portal​

Via CLI​

Cenário adverso: tentar combinar zona e Availability Set​

Fase 5 — Virtual Machine Scale Sets com Autoescalonamento​

Tarefa 5.1 — Criar o Virtual Machine Scale Set​

Via Portal​

Via CLI​

Tarefa 5.2 — Testar o autoescalonamento com carga simulada​

Via CLI​

Via Portal​

Tarefa 5.3 — Atualizar configuração do VMSS e aplicar upgrade de imagem​

Via Portal​

Via CLI​

Validação Final​

Cleanup do Ambiente​

Via Portal​

Via CLI​

Cenário

Pré-requisitos

Via Portal

Via CLI

Tabela de referência de recursos

Fases do Laboratório

Fase 1 — Criação e Configuração Inicial de VM

Tarefa 1.1 — Criar a máquina virtual principal

Via Portal

Via CLI

Tarefa 1.2 — Verificar o estado da criptografia no host

Via Portal

Via CLI

Tarefa 1.3 — Simular falha de habilitação de encryption at host com VM incompatível

Via CLI

Via Portal

Fase 2 — Gerenciamento de Discos e Dimensionamento da VM

Tarefa 2.1 — Adicionar e configurar discos de dados

Via Portal

Via CLI

Tarefa 2.2 — Expandir e alterar o tipo de disco

Via Portal

Via CLI

Tarefa 2.3 — Alterar o tamanho da VM

Via Portal

Via CLI

Tarefa 2.4 — Desanexar disco e verificar persistência dos dados

Via Portal

Via CLI

Fase 3 — Movimentação de VM entre Resource Groups e Subscriptions

Tarefa 3.1 — Validar pré-requisitos de movimentação e mover VM para outro Resource Group

Via Portal

Via CLI

Tarefa 3.2 — Verificar a integridade pós-movimentação

Via Portal

Via CLI

Tarefa 3.3 — Mover VM para outra subscription (opcional) e planejar movimentação entre regiões

Movimentação entre subscriptions (Via CLI)

Movimentação entre regiões

Fase 4 — Alta Disponibilidade com Availability Zones e Availability Sets

Tarefa 4.1 — Criar VMs em Availability Zones distintas

Via Portal

Via CLI

Tarefa 4.2 — Criar um Availability Set e implantar VMs de backend

Via Portal

Via CLI

Tarefa 4.3 — Verificar distribuição de fault domains e tentar adicionar VM zonal ao Availability Set

Via Portal

Via CLI

Cenário adverso: tentar combinar zona e Availability Set

Fase 5 — Virtual Machine Scale Sets com Autoescalonamento

Tarefa 5.1 — Criar o Virtual Machine Scale Set

Via Portal

Via CLI

Tarefa 5.2 — Testar o autoescalonamento com carga simulada

Via CLI

Via Portal

Tarefa 5.3 — Atualizar configuração do VMSS e aplicar upgrade de imagem

Via Portal

Via CLI

Validação Final

Cleanup do Ambiente

Via Portal

Via CLI