Azure Resource Locks: Prevent Accidental Deletes & Changes Now

Locks overrides administrator permissions. Here’s an example: 

• Let’s say you deploy an application using automation like a DevOps pipeline (although we don’t recommend the use of ClickOps, Locks would be equally effective here). 
• Imagine the app is partly a database with customer records. 
• Something happens, and now you need to redeploy it. The automation process might remove and recreate all resource - including the database. 
• Or an admin mistypes a resource group name and accidentally deletes production resources instead of the intended lab resources. 

In both cases, hopefully there are backups. But with locks, you can prevent these mistakes. The automation or administrator action would fail because of the lock. 

Types of Resource Locks 

There are two types of resource locks you can apply: CanNotDelete and ReadOnly.

1. CanNotDelete:  

• An authorised user can read and modify a resource 
• They cannot delete it until the lock is removed 
• Often used for production environments 

Example: You can change the storage capacity of a resource, but you can’t remove the storage account. 

2. ReadOnly 

• An authorised user can only view and read a resource. 
• They cannot delete or update it, turning it into a “look but don’t touch” object. 
• Restricts all authorised users to the permissions that the Reader role provides. 
• Limits or prevents POST methods to the ARM API. 

*All protections described in this table apply to management actions at the control plane. Locks do not restrict data operations within the resource (data plane).

How do Azure Resource Locks work? 

Azure Resource Locks only apply to the management of resources through the control plane - the interface for creating, updating, or deleting resources - not to the data plane, where actual data operations occur within the resource. 

In Azure terms: 

• The control plane (sometimes called the management layer) is responsible for managing resources - such as deploying, configuring, or deleting them - using tools like the Azure Portal, ARM templates, Bicep, CLI, or PowerShell. 
• The data plane is where you interact with the actual data or service provided by a resource (e.g., reading/writing blobs in a storage account, querying a database). 

Examples: 

• ReadOnly lock: With this lock applied to an Azure SQL database, applications can still read and write data within the database (data plane). The ReadOnly lock only prevents modification to the database resource at the control plane (such as deleting or reconfiguring the database). 
• CanNotDelete lock: Similarly, this lock on a file share stops deletion of the file share through Azure management (control plane), but it doesn’t prevent someone from deleting files inside the share (data plane). 

Key point: Locks protect resource management at the control plane, not the resource’s internal functionality at the data plane. 

Scope and inheritance 

• Locks can be applied to a subscription, a resource group, or an individual resource.  
• When applied to a subscription or resource group, all resources within that scope inherit the lock, including new resources created after the lock. 
• If multiple locks exist on a resource (e.g., a Delete lock on a subscription and a ReadOnly lock on a resource group), the most restrictive lock applies. 
• You cannot delete a resource group if any resource inside has a lock. All locks must be removed first. Partial deletes aren’t allowed. 

Use cases of Azure Resource Locks 

The table below shows some examples of which locks are recommended for specific resource types: 

Additional considerations for Azure Resource Locks 

Azure Resource Locks are highly recommended for protecting live environments, but it’s important to understand their potential side effects. Applying locks can sometimes have unintended consequences, especially if you’re not aware of how they interact with Azure management operations. 

Key points to consider: 

• Locks operate at the control plane: They limit or prevent certain management actions via the Azure API. For example:  
  • A ReadOnly lock on a virtual machine prevents you from powering it on or off through the Azure portal or API (control plane), but does not affect the running state or data within the VM (data plane). 
  • A ReadOnly lock on a Network Security Group blocks the creation of NSG flow logs (control plane). 
• CanNotDelete locks allow modifications, so some operations remain possible. 
• ReadOnly locks can interfere with normal Azure management operations, and some actions may fail if such a lock is applied. 

Always review Microsoft’s official guidance before applying resource locks to ensure you understand the implications for your specific workloads. 

Example: You can apply a CanNotDelete lock to all resources in resource groups tagged with Environment = Production.

Policy definitions can audit or enforce lock usage, and when combined with Management Groups, they enable consistent protection across multiple subscriptions. 

How to apply Resource Locks in Azure 

There are multiple ways to deploy Azure Resource locks. You can use Azure PowerShell, Azure CLI, Python and more. The “easiest” way may be to deploy Azure resource locks by using the Azure Portal. 

However, at Intercept, we recommend that you avoid doing ClickOps in the Azure portal and use IaC (Infrastructure as Code) instead.  

Let's show you how to deploy resource locks in Azure using templates with Azure Bicep. 

Deploy Resource Locks Azure Bicep 

When deploying a lock using a Bicep file, it’s important to understand how the deployment scope and the lock scope interact. 

• To apply a lock at the deployment scope (for example, on a resource group or subscription), do not set the scope property. 
• To lock a resource within the deployment scope, set the scope property on the lock. 

The example below applies a lock to a resource group: 

Bicep

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

To create a resource group and apply a lock, deploy the template above at the subscription level. In this setup, the main Bicep file creates the resource group and then calls a module to apply the lock. 

Bicep 

targetScope = 'subscription' 

param rgName string 
param rgLocation string 

resource createRg 'Microsoft.Resources/resourceGroups@2025-04-01 = { 
  name: rgName 
  location: rgLocation 
} 

module deployRgLock './lockRg.bicep' = { 
  name: 'lockDeployment' 
  scope: resourceGroup(createRg.name) 
}

The module uses a separate Bicep file called lockRg.bicep to create the resource group lock. 

resource createRgLock 'Microsoft.Authorization/locks@2020-05-01' = { 
  name: 'rgLock' 
  properties: { 
    level: 'CanNotDelete' 
    notes: 'Resource group and its resources should not be deleted.' 
  }
}

When locking a resource within the resource group, include the scope property in the lock definition. Set scope to the name of the resource you want to lock.

param hostingPlanName string 
param location string = resourceGroup().location 

var siteName = 'ExampleSite${uniqueString(resourceGroup().id)}'

The example below shows a template that creates an App Service Plan, a website, and a lock on the website. The lock includes the scope property, which is set to the website to ensure it protects that specific resource.

resource serverFarm 'Microsoft.Web/serverfarms@2024-11-01' = { 
  name: hostingPlanName 
  location: location 
  sku: {
    tier: 'Free' 
    name: 'f1' 
    capacity: 0 
  } 
  properties: { 
    targetWorkerCount: 1 
  }
}

resource webSite 'Microsoft.Web/sites@2024-11-01' = { 
  name: siteName 
  location: location 
  properties: { 
    serverFarmId: serverFarm.name 
  }
} 

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

Closing thoughts

We discussed Azure Resource Locks as an excellent way to prevent accidental deletion or modification of resources.

Remember, locks aren’t foolproof; they prevent accidents but won’t stop intentional actions by authorised (or unauthorised) users. Always consider potential side effects on normal operations before applying them.