Azure Resource Locks: Practical Guardrails Without Breaking Operations

Azure Resource Locks are one of those Azure features that feel boring right up until they save your production environment from a very enthusiastic click on Delete. They are not a full governance strategy, and they are absolutely not a replacement for backups, RBAC, Azure Policy, or change control. But used well, they add a practical, low-friction guardrail around critical resources.

The trick is knowing where locks help, where they surprise people, and where they make automation grumpy. Let’s build a sane admin pattern that protects important Azure resources without turning every deployment into a support ticket-shaped piñata.

What Azure Resource Locks actually do

Azure management locks can be applied at a subscription, resource group, or individual resource scope. Microsoft documents two lock levels:

The important phrase is authorized users. Locks override normal user permissions for the protected operation. If someone has Owner on the subscription, a lock can still stop the delete action until the lock is removed by someone with permission to manage locks.

Start with CanNotDelete, not ReadOnly

For most admin scenarios, CanNotDelete is the better first move. It prevents accidental deletion while still allowing normal patching, scaling, configuration updates, and deployment changes. ReadOnly sounds stronger, but it often blocks operations that don’t look like “writes” from a human point of view.

Microsoft calls out several real-world surprises with read-only locks. For example, a read-only lock on a storage account can block listing account keys because that operation uses a POST request to the Azure Resource Manager API. A read-only lock on a resource group that contains virtual machines can prevent start or restart operations. A read-only lock on a resource group with an App Service plan can block scale operations.

Understand inheritance before locking a resource group

Locks inherit downward. If you apply a lock at a subscription, resource group, or parent resource scope, child resources inherit the lock. Resources created later inherit the parent lock too. Microsoft also notes that the most restrictive lock in the inheritance chain wins.

That inheritance is usually what admins want from a production resource group lock. If a protected resource exists inside the group and someone tries to delete the whole group, Azure blocks the delete operation. The deletion does not partially succeed just because some resources are unlocked. That is excellent when the delete was accidental. It is slightly less excellent at 5:03 PM on a Friday when your cleanup pipeline is now wearing a tiny clown hat.

Control plane vs data plane: the gotcha that matters

Azure Resource Locks apply to control plane operations through Azure Resource Manager, not data plane operations against the service endpoint. This distinction is easy to miss and very important for security conversations.

For example, a lock on a storage account can help protect the storage account resource from management-plane deletion. It does not magically protect blobs, queues, tables, or files from data-plane modification by identities that already have data access. That job belongs to data-plane permissions, network controls, immutability features, backup/restore strategy, monitoring, and good old-fashioned least privilege.

A practical locking pattern for Azure admins

Here is the pattern I like for production environments:

1. Classify resources by blast radius. Start with shared infrastructure: hub networking, production DNS, key vaults, Log Analytics workspaces, managed identities, API Management instances, production databases, and core resource groups.
2. Use CanNotDelete broadly, ReadOnly sparingly. Delete protection catches the scary mistakes with fewer operational side effects.
3. Document the unlock path. Who can remove a lock? What approval is required? How long can it stay removed?
4. Automate temporary unlocks for planned changes. If a pipeline needs to replace a resource, make lock removal explicit, approved, logged, and reversed.
5. Pair locks with Azure Policy. Locks protect known scopes; policy can enforce broader standards and prevent drift.
6. Test the ugly cases. Try scaling, restarting, backup cleanup, deployment cleanup, role assignment updates, and resource group deletion in a non-production clone.

Azure CLI and PowerShell examples

For a resource group level 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 version:

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

Use naming conventions that explain intent. do-not-delete is fine for a lab. In production, 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 can block requests based on the intended action at scale. Microsoft currently documents delete as the supported action. A matching delete request is blocked with 403 Forbidden.

That makes denyAction useful when you want a rule-based safety net, such as “deny deletion of production Cosmos DB accounts tagged environment=prod.” It is not identical to a lock. Microsoft documents specific behaviors and exemptions, including cases for resource group deletion, cascade deletion, subscription deletion, and certain authorization resources.

Common mistakes to avoid

• Using ReadOnly everywhere. This is the fastest way to make normal operations fail in confusing ways.
• Locking backup-managed resource groups without testing. Microsoft notes that locks can interfere with backup cleanup and restore point management scenarios.
• Assuming locks protect data. They protect management operations, not every data-plane operation.
• Forgetting deployment history cleanup. Microsoft documents that a CanNotDelete lock on a resource group can prevent Resource Manager from automatically deleting old deployments; at 800 deployments, deployments can fail.
• Leaving temporary unlocks open-ended. If a lock is removed for a change, the re-lock should be part of the same runbook or pipeline.
• Not testing inherited locks. Parent locks can affect extension resources and future resources.

Where this fits with your wider Azure guardrails

If you already run Azure Resource Graph checks, locks are a natural next layer. Use queries to find production resources without guardrails, then apply locks or policies where the risk justifies it. I covered drift-hunting patterns in Azure Resource Graph Queries: 7 Admin Guardrails to Find Cloud Drift Fast, and this is exactly the kind of control worth tracking.

Locks also complement troubleshooting runbooks. If your App Service depends on Key Vault references, managed identity, private endpoints, or firewall rules, a delete lock can keep a well-meaning cleanup from removing a critical dependency. For that rabbit hole, see App Service Key Vault References: Troubleshoot 403s, Identity, and Firewalls.

Recommended baseline

For most organizations, I would start here:

• Production resource groups: CanNotDelete, unless deployment tooling regularly replaces the full group.
• Shared networking: CanNotDelete on hub resource groups, DNS zones, firewalls, route tables, and VPN/ExpressRoute components.
• Secrets and identity dependencies: CanNotDelete on production Key Vaults and managed identities.
• Observability: CanNotDelete on Log Analytics workspaces and action groups, with testing for purge and retention workflows.
• ReadOnly: Only for tightly controlled resources where update operations are rare and tested.
• Azure Policy: Use denyAction for tagged production resource types where you need broad delete prevention.

The goal is not to make deletion impossible forever. The goal is to make destructive change intentional. Azure Resource Locks give admins one more speed bump between “I clicked the wrong thing” and “why is production shaped like smoke?”

Sources

• Microsoft Learn: Lock your Azure resources to protect your infrastructure
• Microsoft Learn: Azure Policy definitions denyAction effect
• Microsoft Learn: Use the Azure portal and Azure Resource Manager to manage resource groups
• Microsoft Learn: Azure control plane and data plane