Pular para o conteúdo principal

Laboratório Técnico: Move a virtual machine to another resource group, subscription, or region

Questões​

Questão 1 — Múltipla Escolha​

Uma equipe de operações precisa mover uma máquina virtual do Azure para outra subscription dentro do mesmo tenant. Após a operação, qual das afirmações abaixo descreve corretamente o comportamento esperado?

A. A VM mantém seu Resource ID original, pois apenas o escopo de cobrança muda.

B. Os recursos dependentes, como discos gerenciados e NICs, devem ser movidos separadamente em uma operação posterior.

C. O Resource ID da VM e de todos os recursos movidos junto com ela é atualizado para refletir a nova subscription.

D. A operação falha automaticamente se a VM estiver com status Running; é necessário desalocá-la antes de iniciar o processo.

Questão 2 — Cenário Técnico​

Um administrador executa o seguinte comando para mover uma VM e seus recursos associados para outro resource group:

az resource move \
  --destination-group rg-destino \
  --ids /subscriptions/aaaa/resourceGroups/rg-origem/providers/Microsoft.Compute/virtualMachines/vm-prod \
      /subscriptions/aaaa/resourceGroups/rg-origem/providers/Microsoft.Compute/disks/vm-prod-osdisk \
      /subscriptions/aaaa/resourceGroups/rg-origem/providers/Microsoft.Network/networkInterfaces/vm-prod-nic

A operação retorna um erro indicando que o recurso não pode ser movido. Após investigação, o administrador descobre que há um resource lock do tipo ReadOnly aplicado no resource group de origem. Qual é a ação correta?

A. Alterar o lock de ReadOnly para CanNotDelete no resource group de origem antes de tentar novamente.

B. Remover o resource lock do resource group de origem, executar o move e reaplicar o lock se necessário.

C. Aplicar um lock CanNotDelete no resource group de destino antes de iniciar a operação.

D. Mover os recursos individualmente, um por vez, pois locks impedem apenas operações em lote.

Questão 3 — Verdadeiro ou Falso​

Ao mover uma máquina virtual entre regiões do Azure usando o Azure Resource Mover, a VM de origem é automaticamente excluída após a conclusão bem-sucedida da movimentação, sem necessidade de ação manual adicional.

Questão 4 — Cenário Técnico​

Uma VM de produção está sendo movida para uma nova subscription. A equipe percebe que a VM utiliza um Key Vault na subscription de origem para armazenar segredos usados por uma extensão instalada na VM. Após a conclusão do move, a extensão para de funcionar corretamente.

Qual é a causa mais provável do problema?

A. O Key Vault foi movido junto com a VM, mas seu URI foi alterado, invalidando as referências existentes.

B. A VM perdeu sua managed identity durante o processo de movimentação entre subscriptions.

C. O Key Vault permaneceu na subscription de origem e as políticas de acesso ou RBAC da managed identity da VM não foram atualizadas para a nova subscription.

D. Extensões de VM não são compatíveis com Key Vaults em subscriptions diferentes e precisam ser reinstaladas manualmente.

Questão 5 — Múltipla Escolha​

Qual das opções abaixo representa uma limitação real ao mover uma máquina virtual para outro resource group dentro da mesma subscription?

A. A VM não pode ser movida se estiver associada a uma Virtual Network que contém um Gateway de VPN ativo.

B. A VM é automaticamente reiniciada ao ser registrada no novo resource group de destino.

C. Tags aplicadas diretamente na VM são removidas durante o processo de movimentação.

D. O Availability Set ao qual a VM pertence deve ser excluído antes que a VM possa ser movida.

Gabarito e Explicações​

Gabarito — Questão 1​

Resposta: C

Quando um recurso é movido entre subscriptions (ou entre resource groups), o Azure reatribui um novo Resource ID a cada recurso movido, pois o Resource ID é composto pelo caminho completo que inclui a subscription e o resource group. Qualquer referência externa que use o ID antigo, como políticas, RBAC assignments ou scripts de automação, deixa de ser válida e precisa ser atualizada.

O principal equívoco dos distratores é assumir que o move é uma operação "leve" que preserva metadados ou que os recursos dependentes podem ser movidos separadamente. Na prática, o Azure exige que recursos interdependentes, como VM, disco gerenciado e NIC, sejam movidos na mesma operação para garantir consistência. A alternativa D confunde o comportamento de movimentação com o de algumas operações de resize, que de fato exigem desalocação.

Gabarito — Questão 2​

Resposta: B

Um lock do tipo ReadOnly impede qualquer operação de escrita ou exclusão no resource group, incluindo a operação de move, que internamente realiza alterações de metadados nos recursos. A única forma de desbloquear o processo é remover o lock antes da operação. Após concluir o move, o lock pode ser reaplicado no destino, se necessário.

A alternativa A está errada porque trocar ReadOnly por CanNotDelete ainda aplica restrições que podem interferir dependendo do escopo. A alternativa C é irrelevante para o problema, pois o impedimento está na origem. A alternativa D é incorreta: locks operam no nível do resource group ou do recurso e bloqueiam operações independentemente de serem individuais ou em lote.

Gabarito — Questão 3​

Falso

O Azure Resource Mover executa o processo de movimentação em etapas. Após a etapa de "commit" (confirmação da movimentação), os recursos de origem entram em um estado onde precisam ser explicitamente excluídos pelo administrador. A exclusão automática não ocorre. Essa separação é intencional: ela permite validar que a VM está funcionando corretamente na região de destino antes de descomissionar o recurso de origem. Assumir que a exclusão é automática pode resultar em custos duplicados por manter ambas as instâncias ativas.

Gabarito — Questão 4​

Resposta: C

Ao mover uma VM entre subscriptions, o Key Vault não é movido junto por padrão e permanece na subscription de origem. A managed identity da VM, embora tecnicamente preservada, agora opera no contexto de uma subscription diferente. As políticas de acesso (ou os RBAC assignments) que concediam à managed identity permissão para acessar o Key Vault estavam vinculadas ao principal da identidade dentro do escopo original e precisam ser recriadas ou atualizadas para refletir o novo contexto.

A alternativa A está errada porque o URI do Key Vault não muda ao mover a VM. A alternativa B é parcialmente plausível como distrator, mas managed identities do tipo system-assigned são preservadas durante o move. A alternativa D é tecnicamente incorreta: extensões podem acessar Key Vaults em subscriptions distintas, desde que as permissões estejam corretas.

Gabarito — Questão 5​

Resposta: A

Uma das limitações documentadas para movimentação de VMs é que recursos dentro de uma Virtual Network que contém um Virtual Network Gateway (Gateway de VPN ou ExpressRoute) não podem ser movidos. O gateway cria dependências que impedem a reconfiguração do recurso de rede durante o processo. Mover a VM exigiria primeiro remover o gateway ou usar uma abordagem alternativa de arquitetura.

A alternativa B é falsa: a VM não é reiniciada pelo simples ato de ser registrada em outro resource group. A alternativa C é falsa: tags são preservadas durante o move. A alternativa D é falsa: Availability Sets podem ser movidos junto com as VMs que pertencem a eles, desde que todos os membros do conjunto sejam incluídos na operação.