Resource group locks

The procedure for creating a resource group lock is the same as the subscription lock – the only change is the place where the lock is applied. To add a lock from the Azure portal, follow these steps:

1. Go to your resource group and find the Locks blade:

1. The rest is the same as in the Subscription lock section. When browsing a resource group lock, you will be able to also see the locks that have been applied at the subscription level:

Performing the same operation from the CLI is even easier – you only need a single command where you pass the name of a lock (the -n parameter), its type (-t), and the resource group (-g) that it will be applied to:

$ az lock create -n "Read-only_RG" -t "ReadOnly" --resource-group "azureadministrator-euw-rg"

The result of creating such a lock is a JSON representation of a created Azure resource (remember that locks are also resources in terms of Azure Resource Manager):

{
  "id": "/subscriptions/.../resourceGroups/azureadministrator-euw-rg/providers/Microsoft.Authorization/locks/Read-only_RG",
  "level": "ReadOnly",
  "name": "Read-only_RG",
  "notes": null,
  "owners": null,
  "resourceGroup": "azureadministrator-euw-rg",
  "type": "Microsoft.Authorization/locks"
}

As you can see, the result of such a command is a little bit different than when performing it on the subscription – its identifier now contains the subscription name and the name of the resource group where the lock was applied.

Now, let's assume that we want to delete a resource group that is secured by a delete lock. To do so, we will try to delete a resource group:

$ az group delete -n "azureadministrator-euw-rg"
Are you sure you want to perform this operation? (y/n): y

As you can see, before the command runs, the CLI asks you whether you are sure about deleting the resource group. The result of running such a command will be as follows:

The scope '/subscriptions/.../resourcegroups/azureadministrator-euw-rg' cannot perform delete operation because following scope(s) are locked: '/subscriptions/.../resourceGroups/azureadministrator-euw-rg,/subscriptions/...'. Please remove the lock and try again.

The result of deleting a resource group that has two delete locks (one from the subscription and one applied directly to the group) tells us that both the resource group and the subscription scopes are blocked. There is no way to remove such resources if locks are not removed beforehand.

Let's check what happens if we try to remove other resources provisioned inside a resource group:

When you try to remove such a resource from the portal, you will be notified that such an operation is currently unavailable:

Additionally, if I add the read-only lock to the resource, the following message will be displayed when I try to change something:

Failed to update storage account 'azureadministratorarm'. Error: The scope 'azureadministrator-euw-rg/providers/Microsoft.Storage/storageAccounts/azureadministratorarm'>azureadministratorarm' cannot perform write operation because following scope(s) are locked: '/subscriptions/...,/subscriptions/.../resourceGroups/azureadministrator-euw-rg'. Please remove the lock and try again.

If you add a lock at the subscription/resource group level, it will be applied to all the resources provisioned there. However, there may be situations where you want to have better control over this functionality.

Fortunately, when using the Azure CLI, you can use additional switches that allow you to apply the lock to a specific resource type or even a particular resource only. To add a lock to the subscription for all storage accounts, you can use the following command:

az lock create --resource-type "Microsoft.Storage/storageAccounts"

Since the preceding command is run without additional parameters, it creates a lock at the highest level available (subscription). If you need a lock for a specific resource in a resource group, you may want to try the following snippet:

$ az lock create --resource "/subscriptions/.../resourceGroups/azureadministrator-euw-rg/providers/Microsoft.Storage/storageAccounts/azureadministratorarm" -g "azureadministrator-euw-rg"

By using the whole identifier of a resource and applying the resource group's name, you can create a specific lock that is applied only at the resource level. You can also script locks using the ARM template:

{
  "name": "string",
  "type": "Microsoft.Authorization/locks",
  "apiVersion": "2016-09-01",
  "properties": {
    "level": "string",
    "notes": "string"
  }
}

Thanks to this feature, you can automatically apply it when a production environment is deployed to Azure.

For more information, you can refer to the az lock documentation: https://docs.microsoft.com/en-us/cli/azure/lock?view=azure-cli-latest.

Becoming a master in proper resource locking is especially important when managing Azure resources. With this simple feature, you can greatly enhance resource immutability and be confident that no one has changed resources without proper automation. The next section will help you understand how to audit changes and management actions on a resource group using a service called Azure Event Grid.