3.2 Resource Groups, Lifecycle, and Move Operations

What a resource group really controls

A resource group is a container for Azure resources that share a lifecycle, administrative boundary, or deployment purpose. It is not a network boundary and it is not a region boundary. The resource group itself has a location, but that location stores resource group metadata. A resource group located in East US can contain a virtual machine in West US, a storage account in Central US, and a Log Analytics workspace in East US. The resource locations control where the services run.

For AZ-104, the strongest resource group design signal is lifecycle. Put resources together when they are deployed, managed, monitored, and retired together. Put them apart when they are shared by several workloads, owned by different teams, controlled by different policies, or deleted on different schedules. A hub virtual network, a shared Log Analytics workspace, or a Recovery Services vault may not belong in the same resource group as one disposable application environment.

Subscription
|-- rg-app-payments-prod
|   |-- vm-payments-01
|   |-- nic-payments-01
|   |-- pip-payments-01
|   `-- disk-payments-01
|-- rg-network-hub-prod
|   |-- vnet-hub-prod
|   `-- azure-firewall-prod
`-- rg-monitoring-prod
    |-- log-analytics-prod
    `-- action-group-ops

This layout shows an important exam pattern. The VM and its direct dependencies may be application lifecycle resources. The hub network and monitoring workspace are shared platform resources. Deleting the application resource group should not delete the hub or central monitoring assets.

Lifecycle operations

Resource groups are commonly created by portal, CLI, PowerShell, ARM templates, or Bicep. The portal path is Resource groups > Create, then select subscription, name, region, tags, and review. CLI creation is direct:

az group create --name rg-app-payments-prod --location eastus --tags Environment=Prod CostCenter=FIN App=Payments
az group show --name rg-app-payments-prod --query "{name:name, location:location, tags:tags}"

Deleting a resource group is a high-impact operation because Azure attempts to delete all contained resources. Before deletion, check whether the group contains shared resources, protected resources, backup vault dependencies, private endpoints, disks, public IPs, managed identities, role assignments, or diagnostic settings. A delete lock can prevent deletion. A dependent resource in another group can also create cleanup surprises.

Move operations and provider support

Azure supports moving many resources between resource groups or subscriptions, but not all resources can move, and not all move together cleanly. The safe workflow is inventory, dependency mapping, validation, maintenance window, move, and post-check. The portal includes a move experience from the resource group or resource blade. CLI uses commands such as az resource move, but you still need resource IDs and provider support.

az resource list --resource-group rg-old --query "[].{name:name,type:type,id:id}" --output table
az resource move --destination-group rg-new --ids /subscriptions/<subId>/resourceGroups/rg-old/providers/Microsoft.Network/publicIPAddresses/pip1

Move validation matters. Azure Resource Manager validates whether the selected resources can move and whether dependencies are included. For example, moving a VM usually requires planning for its NICs, disks, public IP addresses, availability set, load balancer references, backup configuration, and extensions. Some resources can move across resource groups in the same subscription but not across subscriptions. Some resources cannot move at all. Some moves temporarily lock resources for management operations while the move completes.

A classic exam trap is assuming a move changes region. Moving a resource to another resource group or subscription does not relocate the underlying service to another Azure region. To change a VM region, you typically redeploy, replicate, restore, or use a service-specific migration approach. To change a storage account region, you use replication, failover, copy, or create a new account depending on the goal and redundancy configuration.

Scenario workflow

Suppose a team created all development resources in rg-temp, but the network team now wants shared network resources moved to rg-network-dev. Start by listing resource types and dependencies. Move only resources whose lifecycle is truly network-owned. A subnet cannot exist outside its virtual network, and many child resources are bound to parents. If a network interface belongs to a VM lifecycle, moving only the virtual network may be valid, but moving the NIC without the VM may not meet the ownership goal.

Then check locks and policies. A CanNotDelete lock may not block a move, but locks and policy can still affect related operations. A policy at the destination requiring a tag may deny the moved resource if tags are missing. If remediation is needed, tag before moving or use an approved exemption.

Finally, update runbooks, dashboards, budgets, and access reviews. If operations scripts point to a resource group name, they may fail after the move. If RBAC was assigned at the old resource group scope, users may lose access after resources move to the new scope. That is a tested AZ-104 behavior: scope-based access follows the scope, not the user's intention.

Exam traps

Do not put every resource for a subscription into one large resource group. It makes deletion risky and access messy. Do not create one resource group per resource by default. It makes policy, RBAC, and cost operations noisy. Use lifecycle as the main rule and then adjust for ownership, compliance, and shared services.

Do not rely on tags alone for deletion safety. Tags classify resources, but they do not prevent deletion. Use locks for delete protection, RBAC to restrict who can delete, Azure Policy to enforce creation standards, and backups or replication for recovery. Resource group design is one layer of governance, not the whole system.