Azure Resource Locks: Prevent Accidental Deletion and Changes

Azure resource locks stop people and automation from deleting or changing a subscription, resource group or resource, regardless of their RBAC permissions. A CanNotDelete lock blocks deletion only; a ReadOnly lock blocks both updates and deletion. You add them in the portal under Locks, with az lock create, with New-AzResourceLock, or as a Microsoft.Authorization/locks resource in Bicep or ARM templates.

Who this is for and what you will have

This guide is for Azure administrators and engineers who want a guard rail against accidental deletion of important resources such as production databases, key vaults, networks and storage accounts. By the end you will know which lock type to choose, where to apply it, how to create and remove it with each tool, which operations a ReadOnly lock unexpectedly breaks, and how locks differ from RBAC and Azure Policy.

How locks work

Microsoft describes two lock levels. The names differ by tool:

A lock overrides any user permissions. Unlike RBAC, which grants or denies access to particular users and roles, a management lock applies a restriction across all users and roles.

Inheritance

When you apply a lock at a parent scope, every resource within that scope inherits it, including resources you add later. The most restrictive lock in the inheritance chain takes precedence. Extension resources inherit locks from the resource they attach to; for example, if you lock a storage account, you cannot delete a diagnostic setting applied to a blob service under it.

If a resource inside a resource group has a Delete lock and you try to delete the resource group, the whole operation is blocked. Partial deletion is not possible, even when the group and the other resources are unlocked.

Control plane only

Locks apply to control plane operations, which go to https://management.azure.com, and not to data plane operations, which go to the service instance such as https://myaccount.blob.core.windows.net/. The documentation's example: a ReadOnly lock on a SQL Database logical server prevents changes to the server resource but still lets you create, update or delete data in its databases.

This has a direct consequence for storage. A lock on a storage account does not protect its data from being deleted or modified. If a request uses the control plane operation File Shares - Delete, the lock makes it fail; if it uses the data plane operation Delete Share, it succeeds. Do not treat locks as a data backup or data protection feature. For data safety, see Azure Storage account redundancy: LRS, ZRS and GRS and Azure Backup for VMs with Recovery Services vaults.

Prerequisites

• To create or delete locks you need access to Microsoft.Authorization/* or Microsoft.Authorization/locks/*. The Owner and User Access Administrator roles have this access, as do some specialized built-in roles. You can also create a custom role with those permissions.
• Azure CLI, Azure PowerShell or Bicep tooling if you do not use the portal.

Choose where to lock and which level

Start with CanNotDelete. ReadOnly is far more likely to break normal operations, as the next section shows.

Step 1: Create a lock

Azure portal

1. Open the resource, resource group or subscription you want to lock.
2. In its left navigation, select Locks. For a subscription the menu item is named Resource locks, and for a resource group it is Locks.
3. Select Add. To lock at a parent level, select the parent.
4. Enter a lock name and choose the lock type, Delete or Read-only. Optionally add notes, such as why the lock exists and who to contact.
5. Save.

You cannot add a lock to a management group.

Azure CLI

Lock a resource group:

az lock create --name LockGroup --lock-type CanNotDelete --resource-group exampleresourcegroup

Lock a single resource, here a web app:

az lock create --name LockSite --lock-type CanNotDelete --resource-group exampleresourcegroup --resource-name examplesite --resource-type Microsoft.Web/sites

List locks in the subscription or in one resource group:

az lock list
az lock list --resource-group exampleresourcegroup

Azure PowerShell

New-AzResourceLock -LockName LockGroup -LockLevel CanNotDelete -ResourceGroupName exampleresourcegroup
 
New-AzResourceLock -LockLevel CanNotDelete -LockName LockSite -ResourceName examplesite -ResourceType Microsoft.Web/sites -ResourceGroupName exampleresourcegroup
 
Get-AzResourceLock

Bicep

When the lock's scope matches the deployment scope, such as locking the resource group you deploy to, do not set the scope property. Deploy this file at resource group level:

resource createRgLock 'Microsoft.Authorization/locks@2016-09-01' = {
  name: 'rgLock'
  properties: {
    level: 'CanNotDelete'
    notes: 'Resource group should not be deleted.'
  }
}

To lock a resource inside the deployment scope, set scope to that resource. Here webSite is a Microsoft.Web/sites resource declared in the same Bicep file:

resource siteLock 'Microsoft.Authorization/locks@2016-09-01' = {
  name: 'siteLock'
  scope: webSite
  properties: {
    level: 'CanNotDelete'
    notes: 'Site should not be deleted.'
  }
}

REST API

PUT https://management.azure.com/{scope}/providers/Microsoft.Authorization/locks/{lock-name}?api-version=2016-09-01

with a body such as:

{
  "properties": {
    "level": "CanNotDelete",
    "notes": "Optional text notes."
  }
}

Step 2: Know what a ReadOnly lock breaks

A ReadOnly lock blocks the POST method to Azure Resource Manager. Some operations that look like reads use POST, so they fail. Examples documented by Microsoft:

• A read-only lock on a storage account prevents listing account keys, because List Keys is a POST request. Users without the keys must use Microsoft Entra credentials for blob or queue data. It also prevents creating a blob container through the control plane and blocks RBAC role assignments scoped to the account.
• A read-only lock on a resource group that contains a virtual machine prevents all users from starting or restarting the VM.
• A read-only lock on a resource group with an App Service plan prevents scaling the plan up or out.
• A read-only lock on a resource group that contains an Automation account prevents runbooks from starting.
• A read-only lock on a resource group prevents moving resources in or out of the group.
• A read-only lock on a subscription prevents Azure Advisor from working correctly, since it cannot store query results.
• A read-only lock on an Application Gateway prevents getting backend health, because that call uses POST.
• A read-only lock on an AKS cluster limits use of the Kubernetes resources section in the portal.
• A read-only lock on a Log Analytics workspace prevents enabling User and Entity Behavior Analytics.

If something stops working after you add a ReadOnly lock, remove the lock or switch to CanNotDelete before debugging anything else.

Step 3: Know what a CanNotDelete lock affects

CanNotDelete is safer but has side effects too:

• It prevents deletion of Azure RBAC assignments on the locked resource or resource group.
• On a resource group it stops Resource Manager from automatically deleting old deployments in the history; if you reach 800 deployments, deployments fail.
• On the resource group created by Azure Backup, backups can fail because the service supports a maximum of 18 restore points and cannot clean up old ones.
• On a resource group with Azure Machine Learning workspaces, compute cluster autoscaling cannot remove unused nodes.
• On a VM protected by Site Recovery, it prevents removing certain resource links when you disable replication. Remove the lock before disabling protection if you plan to protect the VM again.
• It does not stop data purge operations on a Log Analytics workspace. Remove the Data Purger role from users instead.
• For PostgreSQL servers in a virtual network, remove delete or read-only locks from the virtual network and subnets before creating the server, and reapply them after.

For the backup case, see Azure Backup for VMs with Recovery Services vaults, and for the Site Recovery case, see Azure Site Recovery cross-region failover.

Step 4: Remove a lock

You cannot delete a locked resource until you remove the lock, and removal needs the same Microsoft.Authorization/locks permissions. That is intentional friction: it forces a deliberate, auditable step.

In the portal, open Locks at the scope where the lock was set, and select Delete next to the lock. Locks inherited from a parent must be removed at the parent.

With CLI:

lockid=$(az lock show --name LockGroup --resource-group exampleresourcegroup --output tsv --query id)
az lock delete --ids $lockid

With PowerShell:

$lockId = (Get-AzResourceLock -ResourceGroupName exampleresourcegroup).LockId
Remove-AzResourceLock -LockId $lockId

Locks, RBAC and Azure Policy compared

They complement each other. RBAC decides who may do what, Policy decides what configurations are allowed, and locks protect specific resources from deletion regardless of role. For an example of policy enforcement, see Azure Policy tag enforcement and remediation, and for role design see Entra admin roles and least privilege.

Managed resource groups and special cases

Some services, such as Azure Databricks, create a locked managed resource group to hold infrastructure. You cannot delete that group or its lock directly; the error says a system application owns the lock. Delete the service itself, which also deletes the infrastructure resource group.

Cancelling an Azure subscription is not blocked by a resource lock. Azure deactivates resources and only deletes them permanently after a waiting period.

Verifying

1. Run az lock list or Get-AzResourceLock and confirm the lock name, level and scope.
2. Try to delete a non-critical test resource in the locked scope. The attempt should fail with a message that the scope is locked. The exact wording varies by client, so look for the lock name in the error rather than relying on a fixed string.
3. For ReadOnly locks, test the operations you depend on, such as starting a VM, listing storage keys or scaling a plan.
4. Record each lock's purpose in its notes field.

Troubleshooting

I cannot delete a resource group and do not know why

A lock on the group, on a resource inside it, or inherited from the subscription is likely. List all locks with az lock list and look at children as well as the parent. One Delete lock on any resource inside blocks the whole group deletion.

The portal says a lock cannot be deleted because a system application owns it

This is a managed resource group, such as the one Azure Databricks creates. Delete the parent service instead.

VM will not start after adding a ReadOnly lock

Starting a VM uses a POST request, which a ReadOnly lock on the resource group blocks. Remove the lock or change it to CanNotDelete.

Storage keys cannot be listed

A ReadOnly lock on the storage account blocks List Keys. Use Microsoft Entra authentication for data access, or remove the lock.

Backups or old deployments start failing

A CanNotDelete lock on the resource group may be stopping the service from cleaning up restore points or deployment history. Lock the individual critical resources rather than the resource group Azure Backup manages, and avoid locking the history-bearing group if you cannot clean deployments another way.

Terraform or Bicep deployments fail on locked resources

Deployments that update a ReadOnly-locked resource fail. Either remove the lock during the deployment, using the same pipeline identity with Microsoft.Authorization/locks permissions, or keep the lock as CanNotDelete.

Checklist

• Choose CanNotDelete by default and use ReadOnly only after testing.
• Lock at the narrowest scope that gives protection, and remember inheritance applies to future resources.
• Document the reason in the notes field.
• Remember locks do not protect data plane operations or replace backups.
• Make sure only a small set of people hold Microsoft.Authorization/locks permissions.
• Define locks in Bicep or templates so they are recreated with the environment.
• Review locks when you decommission an environment, because they will block clean-up.

References

• Lock your Azure resources to protect your infrastructure: https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/lock-resources
• Azure control plane and data plane: https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/control-plane-and-data-plane
• Azure RBAC role assignments in the portal: https://learn.microsoft.com/en-us/azure/role-based-access-control/role-assignments-portal