Azure Resource Locks: Practical Admin Guardrails

Azure Resource Locks seem boring right up until they save production from an enthusiastic click on Delete. They aren’t a governance strategy on their own, and they don’t replace backups, RBAC, Azure Policy or change control. Used well, though, they add a cheap, low-friction guardrail around critical resources. The trick is knowing where locks help, where they surprise people, and where they break automation.

What Azure Resource Locks do

Management locks apply at subscription, resource group or resource scope. There are two levels:

Locks override normal permissions for the protected operation. Even a subscription Owner can’t delete a locked resource until someone with permission to manage locks removes the lock. RBAC decides who may act; the lock makes destructive actions deliberate.

Start with CanNotDelete, not ReadOnly

For most scenarios, CanNotDelete is the right first move. It prevents accidental deletion while allowing patching, scaling, configuration changes and deployments. ReadOnly sounds stronger but blocks operations that don’t look like writes to a human.

Microsoft lists real surprises. A read-only lock on a storage account can block listing account keys, because that’s a POST to Azure Resource Manager. A read-only lock on a resource group with VMs can prevent starts and restarts, and on a group with an App Service plan it can block scaling.

Understand inheritance before locking a resource group

Locks inherit downward. Child resources inherit a parent lock, including resources created later, and the most restrictive lock in the chain wins. If a locked resource sits inside a group and someone deletes the group, Azure blocks the whole delete rather than partially succeeding. That’s exactly what you want for an accidental delete, and exactly what breaks an unprepared cleanup pipeline.

Control plane vs. data plane

Azure Resource Locks apply to control-plane operations through Azure Resource Manager, not data-plane operations against the service endpoint.

A lock on a storage account protects the account from deletion, not its blobs, queues, tables or files from identities with data access. That’s the job of data-plane permissions, network controls, immutability, backups and least privilege.

A practical locking pattern

1. Classify resources by blast radius. Start with hub networking, production DNS, key vaults, Log Analytics workspaces, managed identities, API Management, production databases and core resource groups.
2. Use CanNotDelete broadly and ReadOnly sparingly.
3. Document the unlock path: who can remove a lock, what approval is needed and how long it may stay off.
4. Automate temporary unlocks for planned changes, with approval, logging and automatic re-lock.
5. Pair locks with Azure Policy for broader standards and drift prevention.
6. Test the awkward cases in non-production: scaling, restarts, backup cleanup, deployment cleanup, role assignments and group deletion.

Azure CLI and PowerShell examples

Create a resource group delete lock with Azure CLI:

az lock create \
  --name rg-prod-cannot-delete \
  --lock-type CanNotDelete \
  --resource-group rg-prod-shared \
  --notes "Production guardrail: remove only through approved change."

List locks on a resource group:

az lock list --resource-group rg-prod-shared --output table

PowerShell:

New-AzResourceLock `
  -LockName "rg-prod-cannot-delete" `
  -LockLevel CanNotDelete `
  -ResourceGroupName "rg-prod-shared" `
  -LockNotes "Production guardrail: remove only through approved change."

Use names that encode scope and ownership, such as rg-prod-platform-cannot-delete or kv-payments-prod-cannot-delete.

When to use Azure Policy denyAction instead

Azure Policy’s denyAction effect blocks requests by intended action at scale; delete is the documented supported action, and matching requests get 403 Forbidden. It suits rules such as “deny deletion of production Cosmos DB accounts tagged environment=prod.” It isn’t identical to a lock; Microsoft documents specific behaviors for resource group deletion, cascade deletion, subscription deletion and some authorization resources.

Common mistakes

• ReadOnly everywhere, which makes normal operations fail in confusing ways.
• Locking backup-managed resource groups without testing; locks can interfere with backup cleanup and restore point management.
• Assuming locks protect data. They protect management operations only.
• Forgetting deployment history. A CanNotDelete lock on a resource group can stop Resource Manager deleting old deployments; at 800, deployments can fail.
• Open-ended temporary unlocks. Re-locking belongs in the same runbook or pipeline.
• Not testing inherited locks, which affect extension resources and future resources.

Recommended Azure Resource Locks baseline

• Production resource groups: CanNotDelete, unless tooling regularly replaces the whole group.
• Shared networking: CanNotDelete on hub groups, DNS zones, firewalls, route tables and VPN/ExpressRoute.
• Secrets and identity: CanNotDelete on production key vaults and managed identities.
• Observability: CanNotDelete on Log Analytics workspaces and action groups, after testing purge and retention workflows.
• ReadOnly: only for tightly controlled resources with rare, tested updates.
• Azure Policy: denyAction for tagged production resource types needing broad delete prevention.

Use Azure Resource Graph queries to find production resources without guardrails, and see App Service Key Vault references for a dependency a delete lock can protect. The goal isn’t to make deletion impossible; it’s to make destructive change intentional.

Last reviewed: October 2026

Sources

• Lock your Azure resources (Microsoft Learn)
• Azure Policy denyAction effect (Microsoft Learn)
• Manage resource groups in the Azure portal (Microsoft Learn)
• Azure control plane and data plane (Microsoft Learn)