Resource Manager, Resource Groups and Locks

Azure Resource Manager (ARM) is the unified management layer: the Portal, CLI, PowerShell, SDKs and templates all go through it, so they share authentication, RBAC, Policy, tags and audit logs. ARM deploys, updates and deletes a whole group of resources in one operation.

A resource group (RG) is a logical container for resources that share a lifecycle (everything of a lab environment, say). Each resource belongs to exactly one RG; the RG has its own region (where metadata is stored) but can hold resources in other regions. Deleting an RG deletes every resource inside.

flowchart TB
  S["Subscription"] --> RG["rg-devops-lab<br/>lock: CanNotDelete"]
  RG --> V["vnet-lab"]
  RG --> VM["vm-web-01"]
  RG --> ST["stdevopslab01"]
  RG -. "lock inherited" .-> VM

Locks

• Set at subscription, RG or resource level; children inherit the parent's lock.
• Creating/removing locks needs Microsoft.Authorization/locks/* (Owner, User Access Administrator) — locks block even Owners.
• Trap: ReadOnly also blocks operations that "look like reads" but are POSTs, such as listing a storage account's keys.

Moving, deleting, quotas

• az resource move moves resources to another RG/subscription; both source and target RGs are write-locked during the move; some services cannot be moved.
• Delete unused resources to avoid costs; with a CanNotDelete lock on the RG, az group delete fails.
• Each resource type has quotas (vCPUs per region, say): see them with az vm list-usage -l southeastasia -o table, raise them with a support request.

Resource IDs

Every resource has a full ID that encodes where it lives:

/subscriptions/<sub-id>/resourceGroups/rg-devops-lab/providers/Microsoft.Compute/virtualMachines/vm-web-01

The segment after providers is the resource provider namespace and type. Role assignments, policies, locks, and --ids arguments all use this format. az resource show --ids <id> works for any type.

Resource providers

Each service is delivered by a provider such as Microsoft.Compute or Microsoft.ContainerService. A subscription must have a provider registered before you create its resources; most common ones register automatically, but a new service may fail with "subscription is not registered". Fix it with az provider register --namespace Microsoft.ContainerService and check with az provider show -n Microsoft.ContainerService --query registrationState.

Deployment history and request flow

Every request goes through ARM, which checks authentication, RBAC, Policy, and locks before passing it to the provider. That is why a deny policy or a lock produces an ARM error before anything is created. Template deployments are listed with az deployment group list -g rg-devops-lab -o table, and individual operations appear in the Activity log.

Using locks well

• Put CanNotDelete on production resource groups and shared networking.
• Expect side effects from ReadOnly: it can block scaling, restarting through some APIs, or adding a disk, because those are write operations.
• Automation that must change locked resources needs a step that removes and restores the lock, and the identity running it needs rights on Microsoft.Authorization/locks.
• Locks protect the management plane only; they do not stop someone with data access from deleting blobs inside a storage account.

Use az lock delete --name no-delete -g rg-devops-lab when a lab really must be removed.