10.4 Migration, Move, Backup, and Recovery Cases

Case 1: Move a VM to another resource group

A team wants to move a production VM and its related resources from rg-old to rg-prod. The VM has managed disks, a NIC, a public IP, an NSG, and a Recovery Services vault backup policy. A CanNotDelete lock exists on rg-old.

A resource move is not a file copy. Azure validates whether each resource type supports the move, whether dependent resources are included, whether locks or policies block the operation, and whether subscription or region constraints apply. For a VM, include dependent resources such as NICs, disks, public IPs, and NSGs when required. Validate before the move.

Portal path: Resource group > Move > Move to another resource group. CLI checks can include listing resource IDs and using Azure move validation where available for the resource type. Before moving, review locks at resource, resource group, and subscription scope.

az lock list --resource-group rg-old -o table
az resource list -g rg-old --query "[?contains(name, 'vm-prod-01')].[name,type,id]" -o table

The CanNotDelete lock can block move operations because moving involves operations that are treated as delete and create in metadata terms. Remove or adjust the lock only with approval, perform the move, and restore the protection if required. Do not delete the lock permanently if it represents a production control.

Case 2: Subscription move and RBAC impact

A resource group is moved to another subscription in the same tenant. After the move, operators complain they lost access. This can happen because RBAC assignments are scoped to management groups, subscriptions, resource groups, or resources. Moving changes the scope path. Assignments inherited from the old subscription do not automatically follow if they are not present at the new scope.

Before a move, capture required role assignments, policy assignments, locks, tags, budgets, diagnostic settings, and dependencies. After the move, reapply or validate access at the new scope. If managed identities are involved, understand whether resource IDs, role assignments, or references must be updated. For exam purposes, the key is that moves are governance operations, not only resource operations.

Case 3: Backup versus Site Recovery

Azure Backup protects data and supports restore from recovery points. Azure Site Recovery, or ASR, replicates workloads for disaster recovery and failover. The exam may describe both backup and regional outage language, so read carefully.

If the requirement is to restore a deleted file, recover a VM to a previous point, or retain backups for compliance, think Azure Backup and a Recovery Services vault or Backup vault depending on workload. If the requirement is to fail over a VM workload to another region during an outage, think Azure Site Recovery. Backup is not an instant regional failover mechanism. Site Recovery is not a substitute for granular file recovery retention in every case.

Case 4: Backup failure after policy change

A VM backup job starts failing after a backup policy retention change. The operations team also enabled a resource lock on the vault. Start with backup jobs and alerts. Then inspect the vault, policy, protected item, VM agent health, permissions, and lock behavior.

Portal path: Recovery Services vault > Backup jobs, Backup alerts, Backup policies, and Backup items. For monitoring, configure alerts and action groups for backup failures. Backup reports can help identify trends such as repeated failures or storage growth.

A common remediation is not to create a second vault immediately. First identify the failed operation. If policy modification was blocked by a lock, adjust the lock with approval. If the VM agent cannot communicate, troubleshoot the VM extension or network. If the backup window conflicts with workload behavior, adjust schedule. If retention does not meet compliance, update the policy after validating cost and restore requirements.

Case 5: Restore under pressure

A developer deletes application data at 9:10 AM. The business asks for the fastest restore to the latest point before deletion. The administrator must identify available recovery points and the restore target. Restoring over production may be risky if users are still writing data. Restoring to an alternate location can allow comparison and selective recovery.

For VMs, restore options can include creating a new VM, restoring disks, or file-level recovery depending on the scenario. For Azure Files and Blob Storage, snapshots, soft delete, versioning, and point-in-time restore features may be relevant depending on what was enabled before the deletion. You cannot use a feature retroactively if it was not enabled and no backup exists.

Move and recovery exam traps

Do not assume every resource can move across resource groups, subscriptions, or regions. Always validate supported move operations and dependencies. Do not ignore locks and policy. They are common reasons that an otherwise correct move or delete fails.

Do not choose ASR for a simple file restore. Do not choose Backup alone for a requirement to orchestrate regional failover. Do not claim labs are guaranteed on the exam; Microsoft says labs may be present and can be removed. Study the operations because interactive components may require real portal sequence knowledge, but do not build your time plan around a guaranteed lab.

A strong administrator prepares before change: export or document dependencies, check role assignments, verify backups, run test failovers where appropriate, and configure alerts. In AZ-104 wording, minimize downtime and avoid data loss are not decorations. They are constraints that rule out risky shortcuts.