Azure Resource Locks Explained: CanNotDelete vs. ReadOnly, Inheritance, and Who Can Remove One

A resource lock is a management setting an administrator applies to a subscription, resource group, or individual resource to stop accidental deletion or modification, and it overrides normal role assignments for every user who touches that scope, including subscription Owners. Azure only ships two lock types: CanNotDelete, which blocks deletion while leaving everyday configuration changes alone, and ReadOnly, which blocks both. As an administrator you’ll run into locks less as an abstract governance concept and more as the reason a routine change suddenly fails with a permissions-shaped error that RBAC didn’t cause. Knowing exactly what each lock type blocks, how it inherits, and who’s allowed to remove it is what AZ-104 expects.

Locks live on the control plane, not the data plane

The detail that trips up administrators in production before it ever trips them up on the exam is that resource locks only govern Azure Resource Manager (ARM) control-plane requests, the calls that go to management.azure.com to create, update, or delete a resource. They have no authority over data-plane requests, the calls that go directly to a service’s own endpoint (https://mystorage.blob.core.windows.net, for example) to actually read or write data inside that resource.

According to Microsoft’s official documentation on locking resources, locks apply only to control-plane operations, not data-plane ones. That split matters most on storage accounts. A ReadOnly or CanNotDelete lock on a storage account protects the account resource itself, but it does nothing to protect the blobs, queues, tables, or files stored inside it. Someone with data-plane access can still delete every blob in a locked container, because that delete request never touches the control plane the lock is watching. If the goal is protecting data rather than protecting the account object, the lock is the wrong tool; look at soft delete, versioning, or one of the redundancy options instead.

CanNotDelete vs ReadOnly

	CanNotDelete	ReadOnly
Portal label	Delete	Read-only
Deletion	Blocked	Blocked
Configuration changes	Allowed	Blocked
Write-classified data-plane-adjacent actions (e.g., listing storage keys)	Allowed	Blocked
Effective permission level	Unchanged	Reduced to Reader for everyone

CanNotDelete leaves a resource fully usable. Authorized users keep resizing, reconfiguring, and tagging it; they just can’t remove it. It’s the lock to reach for when the goal is preventing one specific catastrophic action without freezing day-to-day administration.

ReadOnly is far more aggressive. It restricts every user, regardless of their assigned role, to Reader-level behavior against that resource: no deletes, no updates. Because Azure implements several operations as writes under the hood even though they look like harmless reads, a ReadOnly lock has a habit of breaking things nobody expected it to touch. That’s covered in detail below, and it’s the single most exam-relevant fact about this lock type.

Scope, inheritance, and what happens on group deletion

Locks apply at the subscription, resource group, or individual resource scope, and a lock at any parent scope is inherited automatically by everything beneath it, including resources added after the lock was created. Extension resources such as diagnostic settings inherit the lock from the resource they’re attached to as well, since their resource ID is nested under the parent’s.

When locks from different scopes stack on the same resource, they combine rather than one overriding the other, and the most restrictive combination always wins. A CanNotDelete lock on a resource group plus a ReadOnly lock on one resource inside it leaves that resource fully frozen, even though sibling resources in the same group are only protected from deletion.

This inheritance has a direct operational consequence: if a resource group contains even one resource carrying a Delete-type lock, an attempt to delete the entire resource group fails outright. Azure checks every resource in the group before allowing a group-level delete, and there’s no partial deletion, so the one locked resource blocks removal of everything else alongside it too.

Who can create or remove a lock

Creating or deleting a lock requires the Microsoft.Authorization/locks/* action (or the broader Microsoft.Authorization/*). The Owner and User Access Administrator built-in roles include that action by default; Contributor, despite its otherwise broad ability to create, modify, and delete resources, does not. A custom role can be built to grant just that permission if a team needs lock management without full Owner rights.

This is a genuinely separate axis from ordinary resource permissions. Someone can hold Contributor on a resource group, be able to delete every resource in it, and still be completely unable to remove a lock standing in their way, because lock management lives under the authorization namespace, not the resource provider namespace of whatever they’re trying to change.

The ReadOnly gotchas that catch administrators off guard

Because a ReadOnly lock blocks anything Azure Resource Manager classifies as a write, and that classification doesn’t always match intuition, a handful of operations break in ways that look like they should be reads:

• Listing or regenerating storage account keys. The List Keys and Regenerate Keys operations are implemented as POST requests, so a ReadOnly lock on a storage account blocks both. Applications or scripts using the account key stop authenticating, and a compromised key can’t be rotated until the lock comes off.
• Resizing, starting, or restarting a virtual machine. Resizing a VM is a control-plane update to its hardware profile, and starting or restarting it requires a POST-based action. A ReadOnly lock placed directly on the VM, or on the resource group containing it, blocks all three, so a routine scale-up can fail with no obvious explanation until someone checks for a lock.
• Scaling an App Service plan up or out. A ReadOnly lock on the resource group containing the plan blocks that change the same way it blocks VM resizing.
• Creating a blob container through the control plane, or assigning RBAC roles scoped to the storage account. Both are treated as writes against the account resource.
• Creating an NSG flow log for a locked network security group, since enabling flow logging modifies the NSG’s diagnostic configuration.

None of these operations touch the data plane, and none of them look like configuration changes on the surface. That’s exactly why the exam likes to frame a scenario as “we only wanted to prevent changes, and now this unrelated thing is broken.”

How the AZ-104 exam tests this

• A scenario needs a resource protected from deletion by everyone, including Owners, while normal administration continues. That’s CanNotDelete. ReadOnly is too aggressive, and an RBAC change doesn’t stop an Owner from acting.
• A scenario needs a finished configuration frozen so nothing changes, while the resource keeps running for connected systems. That’s ReadOnly, distinct from Azure Policy, which governs what gets deployed, not whether an existing resource can change.
• A scenario has a Contributor unable to remove a lock. The explanation is always the Microsoft.Authorization/locks/* action, which Contributor lacks and Owner or User Access Administrator hold.
• A scenario describes a storage key rotation, VM resize, or App Service scaling operation failing unexpectedly after “just” a ReadOnly lock was applied. This tests whether you know ReadOnly blocks write-classified operations well beyond obvious settings changes.
• A scenario asks whether a lock on a storage account stops someone from deleting the blobs inside it. It doesn’t. Locks are control-plane only; data-plane operations against the resource’s own service endpoint are untouched.
• A scenario tries to delete a resource group that contains one locked resource. The whole operation fails until that specific lock is removed, regardless of how many other resources in the group are unlocked.

Locks are a narrow tool with a wide blast radius when misapplied. Pairing them correctly with Azure RBAC roles and understanding where they sit relative to subscriptions, resource groups, and management groups makes the rest of the governance domain click into place. For the full breadth of AZ-104 governance topics, see the AZ-104 study guide.