Microsoft AZ-104: Máquinas Virtuais do Azure e Computação — Guia de estudos

By Laurynas Brazys · 6 August 2026 · #microsoft #az-104 #certification #exam-prep #study-guide

Faz parte do Microsoft Azure Administrator Associate AZ-104 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Microsoft, ou faça testes cronometrados no ExamRoll.io.

Visão Geral

As Azure Virtual Machines (VMs) fornecem computação elástica para cargas de trabalho Windows e Linux com controle granular sobre tamanho, armazenamento, disponibilidade, rede, segurança e gerenciamento do ciclo de vida. Os administradores devem entender as famílias de dimensionamento, as construções de disponibilidade, a automação de escala, a capacidade spot, as extensões, os modelos de armazenamento, os hosts dedicados, o backup e os padrões de acesso seguro para atender a metas de confiabilidade, desempenho e custo.

Opções de Computação e Dimensionamento

As famílias de tamanho de VM visam perfis de carga de trabalho distintos. As de uso geral (séries Dv, Ev, B burstable) equilibram as proporções de vCPU para memória para servidores web, bancos de dados pequenos e servidores de aplicação. As otimizadas para computação (Fsv2, HB/HBv2 para HPC com uso intensivo de CPU) maximizam a vCPU por GB e são ajustadas para alta velocidade de clock, beneficiando camadas de API sem estado (stateless), workers de lote e servidores de jogos. As otimizadas para memória (Ev5, Mv2/Mv3) oferecem mais memória por vCPU e suportam caches em memória, motores de análise e grandes bancos de dados. As VMs com GPU (NV, NVv4 para visualização; NC/ND para treinamento e inferência de CUDA/AI) incluem GPUs NVIDIA com particionamento de vGPU em alguns SKUs para densidade e eficiência de custo; a compatibilidade de drivers e frameworks deve ser validada e fixada por meio de extensões.

Operações de upgrade e redimensionamento são restringidas pela disponibilidade de hardware no cluster de destino; redimensionar uma VM em um conjunto de disponibilidade (availability set) pode falhar com erros de alocação se a capacidade for limitada. Desalocar todas as VMs no conjunto e depois redimensioná-las geralmente funciona, pois permite o posicionamento em diferentes hardwares. Quando IPs internos estáticos são necessários, você os atribui na configuração da NIC no Azure, não dentro do sistema operacional convidado.

Os Azure Dedicated Hosts posicionam suas VMs em servidores físicos de locatário único para isolamento em nível de host, conformidade e previsibilidade. Grupos de hosts definem uma coleção de hosts em uma região e podem abranger zonas de disponibilidade e domínios de falha de host para distribuir o risco de falha e manutenção do host. Domínios de falha de host dentro de um grupo de hosts garantem que as VMs sejam distribuídas entre racks físicos. Os benefícios de licenciamento incluem trazer licenças do Windows Server/SQL Server com Software Assurance ou Azure Hybrid Benefit e a opção de licenciar por host (útil para SQL Enterprise/Windows Datacenter) em vez de por VM, potencialmente reduzindo custos para consolidação densa.

Disponibilidade, Escala e Otimização de Custos

Conjuntos de disponibilidade (Availability sets) protegem contra falhas de hardware e manutenção planejada dentro de um datacenter. As VMs são distribuídas entre domínios de falha (energia/rack distintos) e domínios de atualização (ondas de manutenção). Os limites típicos são de até 3 domínios de falha e 20 domínios de atualização; implante pelo menos duas instâncias para obter o SLA de 99,95%. Zonas de disponibilidade (Availability zones) fornecem maior resiliência ao posicionar recursos em edifícios de datacenter fisicamente separados dentro de uma região; implantar duas ou mais VMs entre zonas resulta em um SLA de VM de 99,99%. As zonas exigem recursos cientes da zona, e o tráfego entre zonas usa um load balancer ou application gateway do SKU Standard; planeje o tráfego de saída de dados (egress) dentro de uma região.

Os Virtual Machine Scale Sets (VMSS) orquestram frotas de VMs idênticas ou heterogêneas com autoescalonamento e gerenciamento de integridade integrados. A orquestração uniforme usa um modelo de scale set com um único perfil de VM e se integra nativamente com o Azure Load Balancer ou Application Gateway. A orquestração flexível suporta diversos SKUs de VM e individualidade de instância, combina-se com conjuntos/zonas de disponibilidade e é adequada para funções com estado (stateful) ou mistas. Os modos de upgrade determinam o comportamento da implantação (rollout): Manual (o administrador aciona os upgrades), Automático (a plataforma atualiza todas as instâncias quando o modelo muda) e Contínuo (em lotes com sondas de integridade, pausa entre lotes e limites de falha). As políticas de autoescalonamento (autoscale) reagem a métricas (CPU, memória via AMA, tamanho da fila, métricas personalizadas), agendamentos ou ambos; defina a capacidade mínima/máxima/desejada, cooldowns e políticas de redução (scale-in) (por exemplo, a VM mais nova primeiro) para controlar a rotatividade (churn). Para gerenciamento de entrada em escala, use pools de NAT de entrada do load balancer no Standard Load Balancer público ou interno. As sondas de integridade (health probes) devem visar a porta e o protocolo reais do serviço; para o SQL Always On com um internal load balancer, use uma sonda TCP na porta do listener em vez de HTTP.

As Azure Spot VMs exploram a capacidade não utilizada do Azure com grandes descontos, sem garantias de disponibilidade. A remoção (eviction) ocorre quando a capacidade é reivindicada ou o preço de mercado excede seu preço máximo; você pode definir a política de remoção como Deallocate (preservar o disco para uma reinicialização posterior, quando disponível) ou Delete (destruir na remoção). Elas se integram com VMSS e Standard Load Balancer para escalonamento sem estado (stateless). Casos de uso adequados incluem processamento em lote, executores de CI/CD, renderização, fuzzing e grandes farms da web sem estado que podem tolerar interrupções. Evite Spot para produção de instância única ou camadas com estado (stateful) sem checkpointing. Limites de preço (price caps) impedem que você pague mais do que seu limite; se a demanda aumentar, espere taxas de remoção mais altas.

Armazenamento, Backup e Gerenciamento de Imagens

Cada VM possui um disco de SO (managed disk, com cache otimizado para boot) e discos de dados opcionais para armazenamento de aplicativos. O disco temporário (D: no Windows, frequentemente /dev/sdb no Linux) reside no host e não é persistente; use-o apenas para caches efêmeros ou arquivo de paginação/swap. Os managed disks abstraem as contas de armazenamento, oferecem opções de redundância zonal/regional, simplificam a escala e melhoram a distribuição em conjuntos de disponibilidade. Discos não gerenciados (unmanaged disks) alocados em contas de armazenamento do cliente são legados e devem ser evitados devido a limites de escala e throttling. Selecione os SKUs de disco de acordo com o desempenho e o custo: Premium SSD e Premium SSD v2 para cargas de trabalho transacionais de baixa latência, Ultra Disk para throughput/IOPS extremos com desempenho ajustável, Standard SSD para uso geral e Standard HDD para cargas de trabalho frias (cold workloads).

Desanexar um disco de dados de uma VM antes de anexá-lo a outra minimiza o tempo de inatividade e preserva a consistência dos dados. Operações de redimensionamento em discos geralmente exigem a expansão da partição/sistema de arquivos (FS) dentro do sistema operacional convidado (in-guest); grandes alterações no tamanho da VM podem exigir sua desalocação.

O Azure Backup protege VMs usando um Recovery Services vault. Habilite o backup na VM ou em escala por meio da atribuição de políticas. As políticas de backup definem agendamentos (diário/semanal), retenção (curto e longo prazo) e parâmetros de Restauração Instantânea (Instant Restore), que retêm snapshots localmente para recuperação rápida de arquivos. Backups consistentes com a aplicação estão disponíveis via VSS para Windows ou scripts de pré/pós-execução no Linux. As restaurações podem ter como alvo uma VM inteira (geralmente para uma nova VM), discos (para reanexação/recuperação rápida) ou arquivos (restauração em nível de arquivo para qualquer VM na assinatura com montagem segura). Os backups funcionam para VMs em execução e paradas (incluindo as desalocadas). Garanta a compatibilidade da criptografia: chaves gerenciadas pela plataforma (platform-managed keys) são suportadas por padrão, e o Azure Disk Encryption exige etapas adicionais para o backup. Considere a restauração entre regiões (cross-region restore) se o seu vault tiver armazenamento com redundância geográfica habilitado e sua postura de conformidade permitir.

Para imagens douradas (golden images), use o Azure Compute Gallery para versionar e replicar imagens entre regiões; uploads de VHDs generalizados do ambiente local (on-premises) podem ser realizados com ferramentas como o

undefined

e, em seguida, capturados na galeria para um provisionamento consistente.

Rede, Acesso e Observabilidade

Cada VM requer pelo menos uma interface de rede (NIC), que contém uma ou mais configurações de IP. Uma única NIC pode ter um IP privado primário e IPs privados secundários adicionais; associe um IP público a uma configuração de IP para expor serviços. A maioria das cargas de trabalho precisa de apenas uma NIC por VM; os tamanhos das VMs determinam os limites de NICs. Ao implantar cinco VMs que precisam de IPs públicos e privados com uma postura de segurança idêntica, crie uma NIC por VM e um único Network Security Group aplicado na sub-rede (ou na NIC) para impor regras de entrada/saída uniformes. A atribuição de IP privado deve ser estática na NIC no Azure para manter a continuidade do endereço; não configure IPs estáticos dentro do sistema operacional convidado. IPs públicos devem usar o SKU Standard para suporte a zonas e conjuntos de escala; combine-os com um Standard Load Balancer para produção.

O Accelerated Networking usa SR-IOV para contornar o datapath do host e reduzir a latência, o jitter e a sobrecarga da CPU. É suportado em tamanhos de VM e imagens de SO selecionados e requer uma vNIC compatível no momento da criação (ou uma parada/desalocação para habilitá-lo). Use-o para serviços de alta taxa de transferência (high-throughput) e baixa latência, e para camadas de gateway com muito tráfego.

O Azure Bastion fornece RDP/SSH seguro sobre TLS diretamente do portal do Azure ou de um cliente nativo, sem expor IPs públicos nas VMs. Implante um host Bastion na rede virtual de destino em uma sub-rede dedicada chamada AzureBastionSubnet com um prefixo /26 ou maior e associe um IP público Standard ao recurso Bastion. Os SKUs incluem Basic e Standard; o Standard adiciona recursos como escalonamento manual (instâncias), conexões baseadas em IP (para qualquer IP privado alcançável, inclusive através de VNets emparelhadas), suporte a cliente nativo, integração com gravação de sessão e links compartilháveis. Use o Bastion para atender aos requisitos de acesso administrativo de confiança zero (zero-trust), evitando endpoints públicos por VM e regras de NAT de entrada.

As extensões de VM (VM extensions) automatizam a configuração e a telemetria. A Custom Script Extension executa PowerShell ou Bash durante ou após o provisionamento para inicializar software ou injetar arquivos de configuração; projete scripts idempotentes e armazene artefatos em um armazenamento seguro com tokens SAS. A extensão PowerShell DSC aplica a Desired State Configuration para convergir nós Windows para o estado declarado; use pull servers ou o Azure Automation State Configuration para gerenciamento em escala. O Azure Monitor Agent (instalado via extensão) transmite métricas e logs do sistema operacional convidado para workspaces do Log Analytics sob Regras de Coleta de Dados (Data Collection Rules); prefira o AMA em vez do agente legado Log Analytics/MMA para roteamento de dados granular, multihoming e escala.

Construções de Disponibilidade na Prática e SLAs

Escolha os availability sets quando precisar de redundância intra-datacenter com backends de armazenamento compartilhado e não exigir posicionamento zonal. Escolha as availability zones para serviços de missão crítica que demandam isolamento de falhas no nível de prédio e um SLA mais alto. Para serviços de scale-out, combine o VMSS com zonas para distribuição uniforme e recuperação automática; fixe as health probes nas portas da carga de trabalho e utilize rolling upgrades para mitigar riscos. Entenda que VMs únicas, mesmo com Premium SSD, oferecem um SLA menor do que implantações com múltiplas instâncias. Para camadas stateless sensíveis a custo, incorpore um pool de Spot VMs atrás de um Standard Load Balancer e defina políticas conservadoras de remoção (eviction) e scale-in para proteger a capacidade de linha de base.

Cenário de Problema Prático

A Contoso Ltd. opera uma aplicação web de múltiplas camadas com uma API stateless, um cache Redis stateful e um grupo de disponibilidade SQL Server Always On. Eles precisam melhorar a resiliência a falhas zonais, reduzir os custos de computação para a camada de API, proteger o acesso administrativo sem IPs públicos e padronizar o monitoramento e os backups.

Crie três sub-redes em uma topologia hub-spoke: uma sub-rede de gerenciamento compartilhada (hub), uma sub-rede web/API (spoke) e uma sub-rede de dados (spoke). Implante o Azure Bastion Standard na AzureBastionSubnet (/26) do hub com um IP público Standard. Motivo: O Bastion permite RDP/SSH sobre TLS sem expor IPs públicos em nenhuma VM, e o SKU Standard suporta conexões baseadas em IP entre VNets em peering, centralizando o acesso administrativo.
Implante a camada de API como um VM Scale Set (Uniform) distribuído entre as Availability Zones 1, 2 e 3 com um Standard Load Balancer. Habilite o accelerated networking e defina regras de autoscale para adicionar instâncias quando a CPU média for > 65% por 10 minutos e remover quando for < 35%, com um período de cooldown. Adicione um pool secundário de Spot VMs dentro do mesmo scale set usando orquestração Flexible ou um scale set complementar, configurando o preço máximo e a política de remoção (eviction) como Deallocate. Motivo: VMSS com zonas entrega um SLA de 99,99% e recuperação automática; a capacidade Spot reduz custos para picos de carga, enquanto a política Deallocate preserva os discos para reutilização rápida.
Implante as VMs de cache Redis em um availability set com 2+ instâncias e Premium SSD. Fixe os fault domains em 2 e confie nos 20 update domains da plataforma. Motivo: O cache é stateful, mas pode ser replicado; os availability sets fornecem isolamento de rack e manutenção sem as penalidades de latência entre zonas.
Implante duas VMs do SQL Server por zona (Zonas 1 e 2) participando de um grupo de disponibilidade Always On. Posicione-as em Azure Dedicated Hosts dentro de um grupo de hosts que abrange duas zonas e dois fault domains de host. Configure um Standard Load Balancer interno com uma sonda TCP na porta do listener (ex: 1433) para o listener do AG. Motivo: Os Dedicated Hosts fornecem isolamento no nível de host e eficiência de licenciamento (licenciamento SQL por host), enquanto o posicionamento zonal e as sondas de saúde TCP se alinham aos requisitos do listener do SQL.
Padronize as imagens via Azure Compute Gallery contendo imagens de SO reforçadas (hardened). Use a Custom Script Extension para instalar pré-requisitos da aplicação e a extensão DSC para impor o estado de features do Windows e baselines de registro. Motivo: Imagens da Gallery garantem um provisionamento consistente; as extensões permitem configuração repetível e controle de desvio (drift).
Configure o Azure Monitor Agent via Data Collection Rules para enviar métricas e logs do sistema operacional convidado para um workspace do Log Analytics. Habilite o monitoramento de conexão e os mapas de dependência conforme necessário. Motivo: O AMA é o agente atual, suporta roteamento granular e é necessário para recursos de monitoramento modernos e para o autoscale do VMSS orientado por métricas além da CPU.
Proteja todas as VMs com o Azure Backup em um Recovery Services vault usando duas políticas: política Tier-1 com backups diários e retenção de 30 dias para API/cache, e política Tier-0 com retenção diária mais semanal/mensal para SQL com snapshots consistentes com a aplicação. Teste as restaurações realizando uma recuperação em nível de arquivo para uma jump VM e uma restauração completa da VM para uma rede de preparação (staging). Motivo: Políticas separadas correspondem à criticidade dos dados e ao RPO/RTO; a recuperação de arquivos e a restauração de VMs cobrem cenários de ransomware e desastres.
Atribua IPs privados estáticos às NICs do SQL e do Redis no nível da NIC do Azure; mantenha as instâncias da API dinâmicas atrás do load balancer. Aplique um único NSG em cada sub-rede para impor regras uniformes. Habilite o accelerated networking nas camadas de maior tráfego. Motivo: A atribuição estática no nível da NIC preserva o endereçamento para camadas stateful; NSGs no nível da sub-rede minimizam a proliferação de regras; o accelerated networking reduz a latência e a sobrecarga de CPU.

Este design atende aos objetivos de disponibilidade, custo, segurança e operações combinando zonas e availability sets de forma apropriada, aproveitando a capacidade Spot para escala stateless, impondo acesso administrativo de confiança zero (zero-trust) com o Bastion e padronizando a configuração, o monitoramento e o backup entre as camadas.

← Assinaturas do Azure · Todos os domínios · Rede Virtual do Azure →

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