Azure resource locks
What it is
A resource lock is an Azure Resource Manager guardrail at a subscription, resource-group, or resource scope. It restricts management-plane changes at that scope and below, even when an assigned role would otherwise allow the operation. A user with permission to manage locks can remove the lock first, so a lock is a deliberate safety barrier—not immutable protection.
- 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).
- 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 deletion or modification. RBAC says who is normally allowed to act; a lock adds a restriction across roles. It is especially useful for shared production foundations that should change only through a deliberate process.
Key ideas
- Inheritance: a parent lock applies to existing and future children. The most restrictive inherited lock wins.
- Control plane only: locks apply to Resource Manager operations. They do not generally stop data-plane actions sent directly to a service endpoint.
- Storage example: a ReadOnly or CanNotDelete lock on a storage account does not protect blob, queue, table, or file data when the operation uses the storage data plane. Use the service’s data-protection and authorization controls for that job.
- Unexpected side effects: a ReadOnly lock can block actions that use a management-plane
POST, such as listing a storage account’s access keys or assigning roles at the locked storage scope. Test a lock before applying it broadly. - Difference from Azure Policy: locks protect existing management operations; Azure Policy evaluates and can enforce organizational rules for resource configuration and deployment.
Northwind example
Maya puts a CanNotDelete lock on Northwind’s shared production resource group. Luis can still modify a permitted resource, but cannot delete it through Resource Manager. For an approved retirement, a privileged operator removes the lock, performs the change, and records the decision. The lock would not stop someone with valid storage data-plane permission from deleting a blob, so the team separately uses appropriate data protection and least-privilege access.
Exam notes
- Memorize the two levels: CanNotDelete (✗ delete, ✓ modify) vs ReadOnly (✗ delete, ✗ modify).
- Locks apply below their scope and override ordinary resource-management permissions until an authorized person removes the lock.
- 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