Skip to main content

Technical Lab: Move a virtual machine to another resource group, subscription, or region

Questions​

Question 1 — Multiple Choice​

An operations team needs to move an Azure virtual machine to another subscription within the same tenant. After the operation, which statement below correctly describes the expected behavior?

A. The VM maintains its original Resource ID, as only the billing scope changes.

B. Dependent resources, such as managed disks and NICs, must be moved separately in a subsequent operation.

C. The Resource ID of the VM and all resources moved with it is updated to reflect the new subscription.

D. The operation automatically fails if the VM has Running status; it must be deallocated before starting the process.

Question 2 — Technical Scenario​

An administrator executes the following command to move a VM and its associated resources to another 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

The operation returns an error indicating that the resource cannot be moved. After investigation, the administrator discovers there is a resource lock of type ReadOnly applied to the source resource group. What is the correct action?

A. Change the lock from ReadOnly to CanNotDelete on the source resource group before trying again.

B. Remove the resource lock from the source resource group, execute the move, and reapply the lock if necessary.

C. Apply a CanNotDelete lock to the destination resource group before starting the operation.

D. Move the resources individually, one at a time, as locks prevent only batch operations.

Question 3 — True or False​

When moving a virtual machine between Azure regions using Azure Resource Mover, the source VM is automatically deleted after successful completion of the move, without requiring additional manual action.

Question 4 — Technical Scenario​

A production VM is being moved to a new subscription. The team notices that the VM uses a Key Vault in the source subscription to store secrets used by an extension installed on the VM. After completing the move, the extension stops working correctly.

What is the most likely cause of the problem?

A. The Key Vault was moved along with the VM, but its URI was changed, invalidating existing references.

B. The VM lost its managed identity during the cross-subscription move process.

C. The Key Vault remained in the source subscription and the access policies or RBAC of the VM's managed identity were not updated for the new subscription.

D. VM extensions are not compatible with Key Vaults in different subscriptions and need to be manually reinstalled.

Question 5 — Multiple Choice​

Which option below represents a real limitation when moving a virtual machine to another resource group within the same subscription?

A. The VM cannot be moved if it is associated with a Virtual Network that contains an active VPN Gateway.

B. The VM is automatically restarted when registered in the new destination resource group.

C. Tags applied directly to the VM are removed during the move process.

D. The Availability Set to which the VM belongs must be deleted before the VM can be moved.

Answer Key and Explanations​

Answer Key — Question 1​

Answer: C

When a resource is moved between subscriptions (or between resource groups), Azure reassigns a new Resource ID to each moved resource, as the Resource ID is composed of the full path that includes the subscription and resource group. Any external reference that uses the old ID, such as policies, RBAC assignments, or automation scripts, becomes invalid and needs to be updated.

The main misconception of the distractors is assuming that the move is a "lightweight" operation that preserves metadata or that dependent resources can be moved separately. In practice, Azure requires that interdependent resources, such as VM, managed disk, and NIC, be moved in the same operation to ensure consistency. Alternative D confuses move behavior with some resize operations, which indeed require deallocation.

Answer Key — Question 2​

Answer: B

A ReadOnly type lock prevents any write or delete operations on the resource group, including the move operation, which internally makes metadata changes to resources. The only way to unblock the process is to remove the lock before the operation. After completing the move, the lock can be reapplied to the destination if necessary.

Alternative A is wrong because changing ReadOnly to CanNotDelete still applies restrictions that may interfere depending on scope. Alternative C is irrelevant to the problem, as the impediment is at the source. Alternative D is incorrect: locks operate at the resource group or resource level and block operations regardless of whether they are individual or batch.

Answer Key — Question 3​

False

Azure Resource Mover executes the move process in stages. After the "commit" stage (confirmation of the move), the source resources enter a state where they need to be explicitly deleted by the administrator. Automatic deletion does not occur. This separation is intentional: it allows validation that the VM is working correctly in the destination region before decommissioning the source resource. Assuming that deletion is automatic can result in duplicate costs by maintaining both instances active.

Answer Key — Question 4​

Answer: C

When moving a VM between subscriptions, the Key Vault is not moved along by default and remains in the source subscription. The VM's managed identity, although technically preserved, now operates in the context of a different subscription. The access policies (or RBAC assignments) that granted the managed identity permission to access the Key Vault were linked to the identity's principal within the original scope and need to be recreated or updated to reflect the new context.

Alternative A is wrong because the Key Vault URI doesn't change when moving the VM. Alternative B is partially plausible as a distractor, but system-assigned managed identities are preserved during the move. Alternative D is technically incorrect: extensions can access Key Vaults in different subscriptions, provided the permissions are correct.

Answer Key — Question 5​

Answer: A

One of the documented limitations for VM moves is that resources within a Virtual Network that contains a Virtual Network Gateway (VPN Gateway or ExpressRoute) cannot be moved. The gateway creates dependencies that prevent network resource reconfiguration during the process. Moving the VM would require first removing the gateway or using an alternative architecture approach.

Alternative B is false: the VM is not restarted by the simple act of being registered in another resource group. Alternative C is false: tags are preserved during the move. Alternative D is false: Availability Sets can be moved along with the VMs that belong to them, provided all members of the set are included in the operation.