What are Azure resource locks?

Azure resource locks are management-layer controls that prevent accidental deletion or modification of Azure resources, regardless of what RBAC permissions a user holds. They apply at the subscription, resource group, or individual resource level, and inherited locks flow down to child resources automatically.

What are the two lock types?

Azure provides two lock types: CanNotDelete and ReadOnly.

CanNotDelete allows authorized users to read and modify a resource but prevents deletion. It is the more commonly applied lock for production resources because it does not interfere with routine operational work — teams can update configurations, scale instances, and modify settings without removing the lock. ReadOnly prevents both modification and deletion, leaving the resource accessible for reads only. ReadOnly is appropriate for resources whose configuration should be frozen completely, but it tends to cause operational friction because many management operations that users expect to work silently — such as listing storage account keys — require write access internally and will fail under a ReadOnly lock.

How do you apply a resource lock?

Locks can be applied through the Azure Portal, the Azure CLI, or an ARM template.

Via the CLI:

az lock create \
  --name DoNotDelete \
  --lock-type CanNotDelete \
  --resource-group my-production-rg

In an ARM template, locks appear as a child resource of type Microsoft.Authorization/locks. Applying a lock at the resource group level protects all resources in the group without requiring individual locks on each one.

Locks persist through resource moves and are not affected by role assignments created after the lock was placed.

What do resource locks protect against?

Resource locks protect against accidental deletion and, in the ReadOnly case, accidental modification. They are most effective in environments where a mix of permission levels exists: junior operators or automated scripts might hold Contributor access that would ordinarily permit deletion, and a lock ensures that even legitimate holders of those permissions cannot destroy resources by accident.

Common candidates for CanNotDelete locks include production resource groups, virtual networks, key vaults, and storage accounts backing critical workloads. These are resources whose loss would require significant recovery time and where the cost of an accidental deletion outweighs the minor overhead of maintaining a lock.

What do resource locks not cover?

Resource locks do not protect against someone who holds Owner or User Access Administrator role at the lock’s scope. Those roles include the permission to delete locks (Microsoft.Authorization/locks/delete), so a user with Owner access can remove the lock and then delete the resource. This is by design — Azure’s intent is that locks stop accidents, not that they create a security boundary against privileged users.

This means resource locks are not a substitute for access control. If too many users hold Owner role, locks provide limited protection. They also do nothing to protect resources inside a resource group from deletion through direct resource-level operations — a locked resource group does not inherit lock protection for sub-resources unless those sub-resources are locked individually or the lock is applied at the right scope.

The deeper gap is that locks cannot evaluate context. Removing a lock might be completely routine maintenance, or it might be the first step in a destructive operation that should require approval. Distinguishing between those cases — and intercepting high-risk sequences like lock-removal followed by deletion — requires intent-aware controls operating at the management plane level. That is the layer where Korvalis operates.