Azure Resource Locks: CanNotDelete vs ReadOnly

A resource lock is a setting you apply to an Azure resource, resource group, or subscription that prevents accidental deletion or modification, and it overrides normal role-based permissions for every user — including subscription Owners — until someone with the right authorization removes it. Azure gives you exactly two lock types: CanNotDelete, which blocks deletion while still allowing configuration changes, and ReadOnly, which blocks both. Getting those two behaviors straight, along with how locks inherit and who’s actually permitted to remove one, is a small but reliably tested corner of the AZ-900 governance domain.

Why locks exist, and what they’re not

A resource lock solves one narrow problem: someone with legitimate permission accidentally deletes or breaks a resource nobody meant to touch that day. It isn’t a substitute for Azure Policy, which evaluates configuration rules at the time a resource is created, and it isn’t a substitute for RBAC, which decides which actions a role is normally permitted to perform. A lock sits on top of both — it doesn’t care what role you hold or what policy already allowed your deployment; it simply refuses the specific delete or write operation the lock is configured to block, enforced at the Azure Resource Manager layer before role permissions are even evaluated.

That independence from RBAC is the detail most worth remembering. Being a subscription Owner gives you essentially unlimited permissions everywhere else in Azure, but it grants no special exemption from a lock. If a CanNotDelete lock sits on a resource, an Owner’s delete attempt fails exactly the same way a Reader’s would, because the lock check happens before Azure even looks at what role is asking.

CanNotDelete vs ReadOnly

CanNotDelete allows authorized users to keep reading and modifying a resource normally — resizing a VM, updating firewall rules, changing tags — but blocks anyone from deleting it. It’s the lighter-touch option: protection against the one destructive action, with day-to-day administration left untouched.

ReadOnly is stricter. It restricts every user to Reader-level behavior, blocking both updates and deletion, effectively freezing the resource’s current configuration in place. This is where the exam likes to set a trap: ReadOnly doesn’t just block obvious configuration changes, it blocks any operation Azure classifies internally as a write — and some operations that look like simple reads are actually implemented as writes. Listing or regenerating a storage account’s access keys is the classic example. An application or automation script that calls that operation will start failing the moment a ReadOnly lock lands on the storage account, even though nobody touched its configuration, because Azure Resource Manager treats key retrieval as a write-type action under the hood.

	CanNotDelete	ReadOnly
Deletion	Blocked	Blocked
Modification	Allowed	Blocked
Data-plane “write” actions (e.g., listing storage keys)	Allowed	Blocked
Typical use case	Protect a critical resource while keeping it maintainable	Freeze a finished configuration entirely

Scope and inheritance

Locks can be applied at the subscription, resource group, or individual resource scope, and a lock at a higher scope is automatically inherited by everything beneath it — apply a ReadOnly lock at the subscription level and every resource group and resource inside it picks up that restriction without any further configuration. The reverse isn’t true: a lock applied directly to one specific resource affects only that resource and its own children, not sibling resources elsewhere in the same resource group.

When locks from different scopes both apply to the same resource — say, a subscription-level ReadOnly lock and a resource-level CanNotDelete lock on one storage account within it — they combine rather than one overriding the other, and the most restrictive combination wins. That storage account ends up both non-deletable and fully read-only, governed by both locks at once.

This inheritance has a practical consequence for cleanup: if you try to delete a resource group that contains a resource with a lock directly on it, the whole resource group deletion fails until that specific lock is removed first. Azure checks every contained resource for locks as part of a group-level delete, and no administrative role bypasses that check automatically.

Who can remove a lock

Managing a lock — creating or removing one — requires the Microsoft.Authorization/locks/* permission, which the Owner and User Access Administrator roles include but Contributor does not, despite Contributor’s otherwise broad access to modify and delete resources. That split runs on a different axis than Azure RBAC vs. Conditional Access — a role can grant every ordinary action on a resource while still lacking the specific permission needed to touch a lock on it. A team member with only Contributor on a locked resource group can’t remove the lock themselves, even to delete something they created; someone with Owner or User Access Administrator has to do it. This permission requirement is the same regardless of which lock type is applied, and it has nothing to do with whether the requesting user originally created the lock — any user holding the right role can remove it.

Locks are implemented under the Microsoft.Authorization resource provider namespace — the same namespace used for RBAC role assignments and definitions, which reflects that a lock is fundamentally an authorization-layer control, not a resource-provider setting. They’re enforced identically no matter which interface you use to make the request: the Azure portal, CLI, PowerShell, and the REST API all respect the same lock. There’s also no built-in expiration — a lock stays in force until someone with sufficient permission explicitly removes it.

How the AZ-900 exam tests this

• A scenario wants a resource protected from deletion by everyone, including Owners or Global Administrators, while ongoing configuration changes still need to happen. The answer is CanNotDelete, not ReadOnly (too restrictive) and not an RBAC change (bypassable by anyone with role-assignment permission).
• A scenario wants a finished configuration frozen so nothing can change, and explicitly says the resource still needs to remain usable by connected resources. That’s ReadOnly — the exam distinguishes this from Deny-effect Azure Policy, which blocks new deployments but doesn’t freeze an existing resource in place.
• A scenario describes an operation that looks like a harmless read — listing keys, retrieving a connection string — failing unexpectedly after a ReadOnly lock was applied “just to prevent configuration changes.” This tests whether you know ReadOnly also blocks write-classified data-plane actions, not just obvious settings changes.
• A scenario has a user with Contributor trying and failing to remove a lock. The answer hinges on the Microsoft.Authorization/locks/* permission living in Owner or User Access Administrator, not Contributor.
• A scenario layers a lock at one scope on top of a different lock at a child scope and asks what the net effect is. The pattern to remember: locks combine, and the most restrictive one wins — nothing is overridden or ignored.

Seeing “cannot be deleted by anyone, but configuration must keep working” should point you straight to CanNotDelete, while “must stay frozen exactly as-is” points to ReadOnly. To sharpen that recognition against exam-style scenarios, work through AZ-900 practice questions covering locks alongside the other governance controls they get mixed up with.

Locks answer a narrower question than Azure Policy does — Policy governs what a resource is allowed to look like at creation, while a lock governs whether an existing resource can be changed or removed at all. For how locks fit into the broader subscription and management group hierarchy they inherit through, see Azure Subscriptions vs. Management Groups.

Quick reference

• Two lock types only: CanNotDelete (blocks delete, allows modify) and ReadOnly (blocks both).
• Locks override RBAC for every role, including Owner — enforced at the Resource Manager layer, independent of permissions.
• Locks apply at subscription, resource group, or resource scope, and inherit downward automatically.
• Multiple applicable locks combine; the most restrictive one governs.
• Removing a lock needs Microsoft.Authorization/locks/* — granted by Owner or User Access Administrator, not Contributor.
• ReadOnly can unexpectedly block data-plane actions Azure treats as writes, like listing storage account keys.
• Deleting a resource group fails if any contained resource still has a lock on it.
• Locks are free and have no expiration — someone has to remove them manually.