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.

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 — this 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.

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. "A CanNotDelete lock on the production resource group so a stray click can't take it down, with backups covering the data" is the answer of someone who has watched a real outage start with a confident delete.