resource-locks

Azure resource locks

What it is

A resource lock is a setting attached to a resource (or a resource group / subscription, and therefore its children) that prevents the resource from being deleted or modified by anyone — even an Owner — until the lock is removed. It is an Azure Resource Manager (ARM) management feature that enforces protection at the management plane. There are two lock levels:

1. CanNotDelete — authorized users can still read and modify the resource, but they cannot delete it (you may still be able to add/remove resources under it and modify settings).
2. ReadOnly — acts like a Reader role: users can read the resource but cannot delete or modify it in any way.

Why it exists

To protect critical resources from accidental (or hostile) deletion/modification. RBAC tells you who may do what; locks override that when you need an absolute safety net — e.g. a production VM, a billing-level resource group, or an audit log that must never vanish.

Key ideas

• Inheritance: A lock set on a parent scope (resource group or subscription) applies to that scope and all child resources under it.
• Precedence: A lock always takes precedence over RBAC role assignments — even a user with Owner cannot delete a locked resource. The only way to make the change is to remove the lock first.
• Where they live: Locks are managed via the CLI/portal/ARM under the resource’s Locks (exclusions) or as Microsoft.Authorization/locks, affecting the management plane only — they do not block data-plane traffic.
• Data-plane caveat: Some resources have a separate data plane. For example, a CanNotDelete lock on a storage account prevents deleting the account, but does not by itself prevent deleting a blob container inside it (container/blob deletion is a resource-level operation in the containers plane). You must also lock the container explicitly to fully protect it. Similarly, locks don’t stop operations that always run (e.g. some static VM operations) — evaluate the specific resource type.
• General tip: Apply locks to resource groups (or subscriptions) rather than individual resources so new children are covered automatically. Remember the protection is temporary-by-design: to delete protected resources you must remove the lock first — do this deliberately in a maintenance window, because a removed lock leaves the resource exposed again (removing the lock is itself the only “override”).
• Difference from Azure Policy: Locks enforce deletion/modification protection on resources you already have. azure-policy remediates what resources may be deployed/created at all.

Exam notes

• Memorize the two levels: CanNotDelete (✗ delete, ✓ modify) vs ReadOnly (✗ delete, ✗ modify).
• Locks apply below their scope (children), and override RBAC — Owner can’t delete a locked resource.
• You can lock a subscription → resource group → resource, in that hierarchy, and inheritance flows down.
• Locks are not a substitute for RBAC or Azure Policy — they’re a separate guardrail layer.

Related

rbac · resource-group · subscription · azure-policy · role-assignment

📘 Source: Microsoft Learn — Resource locks