Azure resource locks: the seatbelt against an accidental delete
Someone with legitimate delete rights fat-fingers the wrong resource group at 5pm on a Friday, and the production database goes with it. Resource locks are the safety catch that makes that specific disaster impossible — even for people who are allowed to delete.
New to cloud? CAMPUX is a free, build-first course. Start here →
RBAC decides who can do things. But some resources are so important you want a second barrier even against the people who legitimately can, a "are you really sure?" that a role assignment does not give you. Resource locks are that barrier. Microsoft's framing is the key: you can lock a subscription, resource group, or resource to protect it from accidental deletions and modifications, and here is the important part, "the lock overrides any user permissions." An Owner can delete anything; an Owner facing a lock cannot, until they remove the lock first.
Two levels of lock
There are exactly two, and the names say what they do:
- CanNotDelete (shown as Delete in the portal) — authorized users can read and modify the resource, but cannot delete it. The everyday choice: keep working on it, just do not let it vanish.
- ReadOnly (shown as Read-only) — authorized users can read the resource but cannot modify or delete it. Effectively the same as restricting everyone to the Reader role on that resource. Use it to freeze something entirely.
Unlike RBAC, a lock is not per-user — it applies across all users and roles. It is not "you can't delete this"; it is "nobody can delete this while the lock is on."
Locks inherit downward
Locks follow the same scope hierarchy as everything else in Azure. Apply a lock at a parent — a subscription or resource group — and every resource inside inherits it, including ones you add later. When more than one lock applies, the most restrictive wins. And the protection is thorough: a Delete lock on even one resource in a group will block an attempt to delete the whole group — Azure will not do a partial deletion. So a single lock on your production database can save the entire resource group from a careless bulk delete.
RBAC says who is allowed. A lock says "not even them, not right now" — the pause that stops a permitted click from becoming an outage.
A lock protects the resource, not the data inside it. Microsoft is explicit that locks apply only to control-plane operations (management.azure.com), not data-plane ones. So a ReadOnly or CanNotDelete lock on a storage account stops the account from being deleted or reconfigured — but it does not stop someone from deleting the blobs inside it, because that is a data-plane action. Locks are a guard on the resource's existence and shape, not a substitute for data protection like soft delete and backups.
Who can set them, and where you can't
Because a lock overrides permissions, the ability to create and remove locks is itself restricted: only the Owner and User Access Administrator roles (or a custom role with the lock actions) can manage them. Two practical notes worth carrying: you cannot apply a lock to a management group (locks live at subscription, resource group, and resource scope), and some innocent-looking operations quietly fail under a ReadOnly lock — for example, listing a storage account's keys is a write-style operation, so a ReadOnly lock blocks it. Locks can surprise you, which is why you apply them deliberately, to the few things that truly must not change or vanish.
The takeaway
Resource locks are a small, blunt, effective safety layer that sits above permissions: put a CanNotDelete lock on the resources whose accidental deletion would ruin your week — the production database, the shared network, the state storage account — and a ReadOnly lock on anything that should be frozen. Remember they inherit down a scope, they override even Owner, only Owner/User Access Administrator can toggle them, and they guard the resource, not its data. Set the lock and the backups together, then measure the payoff in the outage that never happens: the Friday a confident, permitted click lands on the wrong resource group and simply bounces off.
Questions people also ask
What is the difference between CanNotDelete and ReadOnly locks in Azure?
A CanNotDelete lock lets authorized users read and modify a resource but blocks deletion. A ReadOnly lock blocks both modification and deletion, so the resource behaves as if every user only holds the Reader role. Use CanNotDelete on resources you still edit, and ReadOnly on anything that should stay frozen entirely.
Can an Owner delete a resource that has a lock?
No. A lock overrides user permissions, including Owner. An Owner who normally has full delete rights cannot remove a locked resource until they first remove the lock itself. Only Owner and User Access Administrator (or a custom role with lock permissions) can take that step, so the lock is a deliberate extra barrier above RBAC.
Do Azure resource locks apply to management groups?
No. Resource locks can only be applied at the subscription, resource group, or individual resource scope. Management groups sit above subscriptions in the hierarchy, and Azure does not let you place a CanNotDelete or ReadOnly lock there, so protection has to start at the subscription level.
Does a resource lock protect the data inside a resource?
No. Locks apply only to control-plane operations against management.azure.com, not data-plane operations. A ReadOnly or CanNotDelete lock on a storage account stops the account from being deleted or reconfigured, but it does not stop someone from deleting the blobs inside it. Use soft delete and backups for data protection.
Do resources inherit a lock applied to a resource group?
Yes. Locks follow Azure's scope hierarchy, so a lock placed on a subscription or resource group is inherited by every resource inside it, including ones added later. When locks conflict, the most restrictive one wins, and a single Delete lock on one resource blocks deletion of the entire group.