azureblog.co.uk
← cd ~/posts

Resource locks: a cheap insurance policy against the wrong click

A delete lock takes seconds to add and can save a production outage. Here's how locks work, and the ReadOnly gotchas to avoid.

2 min read⚠ checked 18 Feb 2026Azure · Governance
Part 2 of 5 in Azure landing zone guardrails
On this page
  1. The two lock types
  2. Where to use them
  3. Locks protect the control plane, not your data
  4. Be careful with ReadOnly
  5. Managing locks at scale

decides who can change a resource. Locks add a second check that applies to everyone, including Owners: the resource can't be deleted, or can't be changed at all, until the lock is removed.

The two lock types

  • CanNotDelete (shown as Delete in the portal): the resource can be read and modified, but not deleted.
  • ReadOnly: the resource can be read, but not modified or deleted.

Locks inherit downwards. A lock on a resource group protects everything in it, including resources added later.

shell
az lock create --name do-not-delete \
  --lock-type CanNotDelete \
  --resource-group rg-core-networking \
  --notes "Hub networking. Raise a change before removing."

CanNotDelete

Shown as Delete in the portal

  • Read: yes
  • Modify settings: yes
  • Delete: no
  • Right choice for most production resources

ReadOnly

Shown as Read-only in the portal

  • Read: yes (mostly)
  • Modify settings: no
  • Delete: no
  • Blocks some POST operations that look like reads
What each lock allows on the control plane.

Where to use them

  • Hub virtual networks, ExpressRoute and VPN gateways
  • DNS zones, including private DNS zones
  • Key Vaults and workspaces
  • Recovery Services vaults holding your backups

Locks protect the control plane, not your data

Locks apply to operations through Azure Resource Manager (management.azure.com). They don't apply to data plane operations. That surprises people:

  • A CanNotDelete lock on a storage account stops the account being deleted, but anyone with data access can still delete blobs in it. Use soft delete, versioning and immutability policies for the data itself.
  • A lock on a SQL server doesn't stop someone with database permissions dropping a table.
  • A lock on a stops the vault being deleted, but secrets can still be deleted by those with data-plane roles. Soft delete and purge protection cover that.
SubscriptionRarely locked as a whole
Resource group: rg-core-networkingCanNotDelete
Hub VNet, gateways, DNS zonesAll protected, including resources added later

↓ Deleting the resource group fails while any lock applies inside it.

Locks inherit downwards, and the most restrictive lock wins.

Be careful with ReadOnly

ReadOnly blocks more than you'd expect, because some read-like operations are actually management actions:

  • Listing storage account keys is a POST operation, so it's blocked, which can break apps and portal views.
  • Scaling, restarting or reconfiguring services is blocked.
  • Some backup and update operations fail.

In most cases CanNotDelete is the right choice. Keep ReadOnly for resources that truly shouldn't change.

Governance tip: only Owners and User Access Administrators can remove locks by default. That makes lock removal a natural point for change control.

Managing locks at scale

shell
# Every lock in the current subscription
az lock list --output table

# Remove one (needs Microsoft.Authorization/locks/delete)
az lock delete --name do-not-delete --resource-group rg-core-networking

For many subscriptions, deploy locks as code alongside the resources, in Bicep or Terraform, so a rebuilt environment gets them back automatically. can also audit for resource groups that should be locked but aren't.

Do locks stop Azure Backup or updates?

CanNotDelete rarely gets in the way. ReadOnly can block backup restore points, VM updates and scaling. Test any ReadOnly lock against your operational tasks before relying on it.

Can an Owner still delete a locked resource?

Only by removing the lock first. That's the point: it turns an accidental delete into two deliberate steps, and lock deletion shows up in the activity log.

Should I lock everything?

No. Locks on resources that change often just train people to remove them. Lock the shared foundations that everything depends on.

This post was last checked against Microsoft's documentation over six months ago. The approach should still hold, but check the linked sources for anything that has changed before you act on it.

Next in Azure landing zone guardrails · part 3 of 5Stop surprise Azure bills with budgets and anomaly alerts →

Related posts