Troubleshooting Lab: Move a virtual machine to another resource group, subscription, or region
Diagnostic Scenarios
Scenario 1 — Root Cause
An administrator attempts to move a production VM and its associated resources to a new resource group within the same subscription. The environment has the following characteristics:
- The VM is deallocated
- The subscription has an active Azure Policy that requires the
CostCentertag on all resources - The destination resource group already exists and contains other resources
- The VM has a managed disk and an associated NIC
- A Key Vault in the same subscription is referenced by an application environment variable, but is not a dependent resource of the VM in Azure Resource Manager
The command executed was:
az resource move \
--destination-group rg-financeiro \
--ids /subscriptions/bbbb/resourceGroups/rg-ti/providers/Microsoft.Compute/virtualMachines/vm-app01 \
/subscriptions/bbbb/resourceGroups/rg-ti/providers/Microsoft.Compute/disks/vm-app01-osdisk \
/subscriptions/bbbb/resourceGroups/rg-ti/providers/Microsoft.Network/networkInterfaces/vm-app01-nic
The returned output was:
(ResourceMoveProviderValidationFailed) The resource move operation was not
successful. The following resources failed validation:
Microsoft.Compute/virtualMachines/vm-app01: The request did not include
all required tags.
What is the root cause of the failure?
A. The managed disk and NIC need to be listed before the VM in the --ids parameter so that validation occurs in the correct order.
B. The destination resource group does not have the CostCenter tag, and the Azure Policy blocks creation or movement of resources without this tag at the destination.
C. The VM is deallocated and Azure requires it to be in Running state for dependency validation to occur correctly during the move.
D. The Key Vault referenced by the application needs to be included in the same move command, as Azure Resource Manager detects it as an implicit dependency.
Scenario 2 — Action Decision
The cause of the problem has been identified: the VM vm-migrada was successfully moved to a new subscription, but its system-assigned managed identity needs Key Vault Secrets User permission on the Key Vault that remained in the source subscription. The team has already validated that the VM is operational at the destination and that the managed identity was preserved.
The constraint context is:
- The environment is production and the application is down waiting for the fix
- The team does not have permission to move the Key Vault to the new subscription
- A colleague suggests recreating the managed identity as user-assigned and redoing the entire configuration
- The security team requires approval for any access policy changes on the Key Vault, but the approval process takes less than 15 minutes
What is the correct action to take at this moment?
A. Recreate the VM with a user-assigned managed identity and assign Key Vault Secrets User permission to the new identity, replacing the system-assigned one.
B. Wait for security team approval and then add a new RBAC assignment granting the VM's managed identity the Key Vault Secrets User role on the Key Vault in the source subscription.
C. Move the Key Vault to the new subscription immediately to put all resources in the same scope and eliminate the cross-subscription dependency.
D. Add the RBAC assignment without waiting for approval, documenting the action as a production emergency and notifying the security team afterwards.
Scenario 3 — Root Cause
A VM called vm-relatorios was moved to a new region using Azure Resource Mover. The commit operation completed without errors. Two days later, the finance team reports that the Azure bill is showing double billing: both the resources in the source region and those in the destination region appear active.
Information collected by the team:
- Azure Resource Mover displayed
Commit pendingstatus the previous week - The team executed the commit and received success confirmation
- The VM in the destination region is operational and passed validation tests
- The VM in the source region shows status
Stopped (deallocated) - The subscription is within quota limits for both regions
What is the root cause of the double billing?
A. Azure Resource Mover silently failed the commit and kept the source resources in active state without notifying the team.
B. VMs in Stopped (deallocated) state still generate managed disk billing, and the source VM's disk was not deleted after the commit.
C. The subscription duplicated resources during the Resource Mover replication process, creating untracked copies that need to be removed via support.
D. The Stopped (deallocated) status indicates that the source VM is still allocated and generating compute billing, as the shutdown was not initiated by Resource Mover.
Scenario 4 — Diagnostic Sequence
An administrator receives the following error when trying to move a VM to another resource group:
(MoveNotSupported) The move is not supported for the resources of type
'Microsoft.Compute/virtualMachines' that have the following resources
attached or dependent: ['Microsoft.Compute/virtualMachines/vm-db01/extensions/DependencyAgentWindows']
The VM vm-db01 is part of an environment monitored by Azure Monitor and has extensions installed. The team has the following investigation steps, presented out of order:
- Check the official documentation for which resource types and extensions block move operations
- Confirm if the move is successful after removal
- Try to execute the move command and observe the complete error message
- Identify all extensions installed on the VM and check which ones are incompatible with move
- Remove the incompatible extension or wait for move support for that resource type
What is the correct investigation sequence?
A. 3 → 1 → 4 → 5 → 2
B. 1 → 4 → 3 → 5 → 2
C. 4 → 3 → 1 → 2 → 5
D. 3 → 4 → 1 → 5 → 2
Answer Key and Explanations
Answer Key — Scenario 1
Answer: B
The error message is explicit: The request did not include all required tags. The Azure Policy configured in the subscription requires the CostCenter tag on all resources. During a move operation, Azure validates if the resources at the destination would be in compliance with applicable policies. If the destination resource group does not have the CostCenter tag, the resources moved to it will fail policy validation.
The information about the Key Vault was intentionally irrelevant: Azure Resource Manager does not detect it as a move dependency, as the relationship is only application configuration, not an ARM link.
Alternative A represents a classic superficial diagnosis error: the order of --ids has no impact on validation. Alternative C reverses the logic: deallocated VMs are eligible for move. Alternative D would be the most dangerous distractor in a real environment, as it could lead the administrator to unnecessarily try to move the Key Vault, causing additional disruption.
Answer Key — Scenario 2
Answer: B
The cause is identified and the solution is known: add an RBAC assignment on the Key Vault for the VM's managed identity. The critical constraint is that the security team requires approval, but the process takes less than 15 minutes. Given that the environment is in production and down, the correct action is to wait for approval (short and acceptable timeframe) and then apply the precise fix.
Alternative A represents a technically valid action in other contexts, but in this scenario would be over-engineering: recreating the identity, reassigning permissions, and reconfiguring the application would cause much more downtime than waiting 15 minutes. Alternative C ignores the explicit constraint that the team does not have permission to move the Key Vault. Alternative D is the most dangerous distractor: acting without approval violates the established security process and can generate compliance incidents, even if the intention is to resolve an emergency.
Answer Key — Scenario 3
Answer: B
Azure Resource Mover creates a copy of resources in the destination region during the replication process. After commit, the source resources are not automatically deleted: they remain existing and need to be manually removed. In the case of VMs with managed disks, even if the VM is in Stopped (deallocated) state, the managed disk continues to be billed for existing as a provisioned resource, regardless of the VM's execution state.
The information about Commit pending and validation tests was relevant to confirm that the commit was executed successfully, but irrelevant to explain the double billing. Alternative A is false because the commit was confirmed successful. Alternative D represents the most common mistake: confusing the VM state with disk billing. Alternative C would be the most dangerous distractor, as it would lead the team to open an unnecessary support ticket, delaying the simple resolution of manually deleting the source resources.
Answer Key — Scenario 4
Answer: A
The correct sequence is: observe the error (3), consult documentation to understand which extension types block move (1), identify all VM extensions and cross-reference with the incompatibility list (4), take corrective action to remove or wait for support (5), and confirm success (2).
Progressive diagnosis always starts from the observed symptom to hypothesis validation, never from a generic sweep. Alternative B starts with documentation before observing the error, which would be inefficient without knowing the exact symptom. Alternative C starts with extension identification before observing the error or consulting documentation, wasting effort. Alternative D separates error observation from documentation consultation so that extension identification occurs before knowing which ones are incompatible, which reverses the elimination logic.
Troubleshooting Tree: Move a virtual machine to another resource group, subscription, or region
Color Legend:
| Color | Node Type |
|---|---|
| Dark blue | Initial symptom (root node) |
| Blue | Diagnostic question |
| Red | Identified cause |
| Green | Resolution or successful operation |
| Orange | Intermediate validation or verification |
To use this tree when facing a real problem, start with the root node describing the observed symptom after the move operation. Follow the diagnostic questions answering based on what you can directly observe: error message, resource state, destination scope. Each branch eliminates hypotheses until reaching an identified cause in red or an intermediate verification in orange that guides the next investigation step. Never skip steps to reach a cause faster; the tree was built so that each question depends on the previous answer.