No domínio de computação do AZ-104 (20–25%), o item "criar e configurar máquinas virtuais" vai muito além de criar uma VM. Ele inclui "gerenciar tamanhos de máquinas virtuais", "gerenciar discos de máquinas virtuais" e "mover uma máquina virtual para outro grupo de recursos, assinatura ou região", e a revisão de abril de 2026 trocou o antigo "configurar o Azure Disk Encryption" por "configurar a criptografia no host para máquinas virtuais do Azure". Nosso banco de questões volta sempre a perguntas operacionais como "o tamanho que você quer não aparece na lista" e "o que muda quando uma VM vai para outra assinatura?".
Este artigo se concentra nas operações feitas depois que a VM já existe: a diferença entre os dois tipos de "parada" e como são cobrados, quando redimensionar causa reinicialização ou exige desalocar, os tipos de discos gerenciados e as regras de expansão, a criptografia de disco agora centrada na criptografia no host e as regras para mover entre grupos de recursos, assinaturas e regiões. O básico de conjuntos de disponibilidade, zonas de disponibilidade e conjuntos de dimensionamento está em Máquinas Virtuais e Automação de Implantação.
---
Estados de Energia e Cobrança: Existem Dois Tipos de "Parada"
Se você só estaciona um carro alugado, o aluguel continua correndo; só devolver o carro para a cobrança. Mas depois de devolvido, ninguém garante que você vai receber o mesmo carro da próxima vez. "Parar" uma VM do Azure funciona do mesmo jeito.
!Parar e desalocar uma VM diferem na cobrança e no que permanece
| Estado | Como acontece | Cobrança de computação | O que lembrar | |------|------|------|------| | Em execução | A VM está funcionando | Cobrada | Estado normal | | Parada (alocada) | Desligada de dentro do SO ou chamada à API PowerOff | Continua cobrada | A VM mantém o hardware, então o custo continua | | Parada (desalocada) | Parar no portal ou operação deallocate | Não cobrada | Cobranças de disco e rede continuam |
Desalocar devolve a reserva do hardware, então algumas coisas vão junto. Os endereços IP dinâmicos são liberados, e os dados do disco temporário (como a unidade D: no Windows) podem ser perdidos na desalocação, na reimplantação ou durante a manutenção. Já o disco do SO e os discos de dados são discos gerenciados e permanecem intactos.
Dica para o exame: "Eliminar os custos de computação da VM fora do horário comercial" significa desalocar a VM (Parar no portal), não desligá-la de dentro do SO. Se "o IP público muda depois de parar e iniciar a VM", o IP usa alocação dinâmica e deve ser alterado para estático.
---
Redimensionar uma VM: Reinicialização Sempre, Desalocação às Vezes
Você pode alterar o tamanho de uma VM em execução ou desalocada, mas redimensionar uma VM em execução sempre a reinicia. Por isso, o redimensionamento deve ser tratado como uma operação disruptiva em cargas de trabalho com estado.
| Situação | O que fazer | |------|------| | O novo tamanho está disponível no cluster de hardware atual | Alterar com a VM em execução (ela reinicia automaticamente) | | O novo tamanho não aparece na lista (o cluster atual não suporta) | Desalocar a VM e depois alterar (ela pode ir para outro cluster) | | A VM está em um conjunto de disponibilidade e o novo tamanho não está no cluster | Desalocar todas as VMs do conjunto de disponibilidade e depois alterar | | Uma mudança que faz uma VM Windows passar a ter ou deixar de ter disco temporário | Não suportada (só com disco ↔ com disco, ou sem disco ↔ sem disco) |
Dica para o exame: Se "o tamanho desejado não aparece na lista de tamanhos do portal", desaloque a VM e olhe de novo: aparecem mais tamanhos. Se a questão envolve um conjunto de disponibilidade, a resposta certa é "parar (desalocar) todas as VMs do conjunto".
---
Trabalhando com Discos Gerenciados
Os discos de uma VM têm três funções: disco do SO, discos de dados e disco temporário. O disco temporário não é um disco gerenciado e serve para dados de curta duração, como arquivos de paginação ou tempdb. Os discos de SO e de dados usam um dos cinco tipos de discos gerenciados.
| Tipo de disco | Indicado para | Pode ser disco do SO | |------|------|------| | Ultra Disk | Cargas de E/S de altíssimo nível (SAP HANA, bancos de dados grandes) | Não | | SSD Premium v2 | Produção que exige baixa latência e desempenho ajustado em detalhe | Não | | SSD Premium | Produção e cargas sensíveis a desempenho | Sim | | SSD Standard | Servidores web, aplicativos leves, desenvolvimento e teste | Sim | | HDD Standard | Backups e cargas de E/S sequencial não críticas | Sim, mas será desativado em 8 de setembro de 2028 |
Os discos só podem crescer; não podem ser reduzidos Às vezes os discos de dados podem ser expandidos sem desalocar a VM com "expandir sem tempo de inatividade"; caso contrário, desaloque e depois expanda A troca entre SSD Premium, SSD Standard e HDD Standard é permitida duas vezes por dia e, para um disco anexado, normalmente se desaloca a VM antes A maioria das conversões de ou para Ultra Disk não pode ser feita diretamente, então você cria um disco novo e move os dados Um instantâneo é uma cópia de um disco em um ponto no tempo; crie um disco novo a partir dele para restaurar ou anexe-o a outra VM
Dica para o exame: "Trocar o disco do SO para Ultra Disk para melhorar o desempenho" é uma opção impossível. Para acelerar um disco do SO, mude-o para SSD Premium. "Reduzir um disco de dados de 128 GiB para 64 GiB" também não é suportado.
---
Criptografia de Disco: a Criptografia no Host É o Novo Padrão
O Azure Disk Encryption (ADE) saiu do guia de abril de 2026 e a criptografia no host entrou por causa do cronograma de desativação do ADE. A Microsoft planeja desativar o ADE em 15 de setembro de 2028; depois dessa data, discos criptografados com ADE não serão desbloqueados quando a VM reiniciar. A Microsoft recomenda a criptografia no host para VMs novas.
| Método | Como funciona | O que lembrar | |------|------|------| | Criptografia do lado do servidor (SSE) | Sempre criptografa os dados dos discos gerenciados ao armazená-los | Chaves gerenciadas pela plataforma por padrão, chaves do cliente por um conjunto de criptografia de disco; não cobre discos temporários nem caches | | Criptografia no host | Criptografa discos temporários e caches de disco no host da VM e envia os dados já criptografados ao armazenamento | Registrar o recurso EncryptionAtHost na assinatura; desalocar as VMs existentes antes de habilitar | | Azure Disk Encryption (ADE) | Criptografa dentro da VM com BitLocker ou DM-Crypt, chaves no Key Vault | Será desativado em 15 de setembro de 2028; migrar para a criptografia no host | | Criptografia de disco confidencial | Vincula as chaves do disco ao TPM da VM para que só essa VM tenha acesso | Só para tamanhos de VM confidenciais |
A criptografia no host e o ADE não podem ser usados juntos Uma VM que já usou ADE não pode simplesmente ativar a criptografia no host; ela precisa seguir um procedimento de migração A ordem para habilitar a criptografia no host é: registrar o recurso → desalocar (se for uma VM existente) → habilitar a criptografia no host nas configurações de disco da VM → iniciar
Dica para o exame: "Discos temporários e caches de disco também precisam ser criptografados em repouso" significa criptografia no host. Só a SSE não criptografa o disco temporário. "Criptografar no nível do SO com BitLocker dentro da VM" descreve o ADE, mas dificilmente será a resposta certa para um design novo.
---
Movendo uma VM: Grupo de Recursos, Assinatura ou Região
Mudar para outra sala no mesmo prédio é bem diferente de se mudar para outra cidade. Da mesma forma, mover uma VM para outro grupo de recursos ou assinatura é um processo diferente de movê-la para outra região.
| Item | Movimentação entre grupos de recursos ou assinaturas | Movimentação entre regiões | |------|------|------| | O que muda | A ID do recurso (a parte da ID da assinatura ou do nome do grupo de recursos) | A localização física; novos recursos são criados | | O que não muda | A região física e o host; a VM continua em execução | A origem permanece até você excluí-la depois de confirmar | | Ferramenta | Mover no portal, Move-AzResource, az resource move | Azure Resource Mover | | Restrições durante a movimentação | Os grupos de recursos de origem e destino ficam bloqueados; não é possível criar, excluir ou atualizar | Avança por etapas com estados que mudam |
Condições que aparecem com frequência em movimentações entre grupos de recursos e assinaturas:
Mover entre assinaturas exige que as duas estejam no mesmo locatário do Microsoft Entra A assinatura de destino precisa estar registrada para o provedor de recursos Para mover para outra assinatura uma VM que está em uma VNet existente, a VNet e seus recursos dependentes também precisam ser movidos VMs criadas de imagens do Marketplace com planos não podem ser movidas entre assinaturas Uma VM configurada com o Azure Backup só pode ser movida depois de excluir do cofre as coleções de pontos de restauração (instantâneos) A ID do recurso muda depois da movimentação, então atualize as referências em scripts, modelos e painéis
As movimentações entre regiões ficam com o Azure Resource Mover, que analisa dependências e trabalha em etapas: selecionar recursos → validar dependências → preparar → iniciar a movimentação → confirmar (ou descartar) → excluir a origem. Você pode descartar a movimentação a qualquer momento antes de confirmar.
Dica para o exame: "Mover uma VM para outro grupo de recursos a transfere para outro host em outra região" é falso. Uma movimentação de grupo de recursos só muda o agrupamento administrativo; a localização física continua a mesma. Quando o requisito é mudar de região, escolha o Resource Mover.
---
Referência Rápida do Exame
Pontos-chave para revisar uma última vez antes do exame.
| Tema | O que lembrar | |------|------| | Parada (alocada) vs desaloca