Resource group locks

By default nothing stops a developer from deleting a resource group or a single resource in Azure Portal. This short post will show what you can do to prevent such situations and save your time and nerves.

Locks in Azure Portal

Each resource group and a resource it contains has a Locks tab in the Settings section. What is lock in this particular case? Well, it's a specific property attached to your resource, which either forbids updates(by marking it as read-only) or prevents from unintentional deletion.


Now if you try to delete a resource, you will get a message telling you, that it's protected by a lock. To actually delete or update a resource secured by a lock, you have to delete it.

Locks in ARM templates

ARM template allow you to create a resource with a lock attached. If we take a look at the documentation:

    "type": enum,
    "apiVersion": "2015-01-01",
    "name": string,
    "dependsOn": [ array values ],
        "level": enum,
        "notes": string

we'll see that we have two possible levels of a lock:

  • CannotDelete
  • ReadOnly

once this applied, no one will be able to perform forbidden action. Note that to create a lock, user have to have access to Microsoft.Authorization/* or Microsoft.Authorization/locks/* actions.

Azure Key Vault - making it right

Recently I spent a couple of hours struggling with one of our Azure Key Vaults - its access policies to be more specific. Short story - I was unable to create a new one from the portal, nor access secrets or keys. After exchanging several emails with Microsoft and few calls with their technician, we managed to find both a quick solution and the root of all evil - invalid ARM template.

Key Vaults are somehow fragile resources when it comes to determining who can access them. You can be a "superadmin hero", still if a Key Vault was created in the other tenant or for an object not related with you, you can see it, you can manage it but if it comes to retrieving keys or secrets, you won't be able to do so. It's perfectly fine - it should be as secure as possible - but the way it informs you, that something is wrong, can be described as... well, lacking.

Consider following example:

	"type": "Microsoft.KeyVault/vaults",
	"name": "[parameters('keyVaultName')]",
	"location": "[resourceGroup().location]",
	"apiVersion": "2015-06-01",
	"tags": {
		"displayName": "my-keyvault"
	"properties": {
		"enabledForDeployment": true,
		"enabledForDiskEncryption": true,
		"enabledForTemplateDeployment": true,
		"tenantId": "[parameters('tenantId')]",
		"accessPolicies": [
				"tenantId": "[parameters('tenantId')]",
				"objectId": "[parameters('objectId')]",
				"permissions": {
					"keys": "[parameters('keysPermissions')]",
					"secrets": "[parameters('secretsPermissions')]"
		"sku": {
			"name": "[parameters('vaultSkuName')]",
			"family": "A"

It is possible with ARM to create a key vault, which can be accessed e.g. by a group of admins(by passing correct tenantId and objectId). However, let's say you have made a mistake in those fields. Key vault will still be created with an access policy, but following things will happen also:

  • you won't be able to create a new access policy
  • you won't be able to browse keys
  • you won't be able to browse secrets
  • ARM will still be able to retrieve keys and secrets

Trying to add a new policy will result in "Invalid parameter name 'accessPolicy'" error while managing it with Azure Powershell CLI will give "401 Unauthorized" response. I've seen more descriptive messages in my life TBH.

Microsoft guided me to the solution with their article Change a key vault tenant ID after a subscription move, which describes a solution suitable also if a subscription hasn't been moved and a key vault has just been created(for a invalid tenant or an object). Performing steps from the article helped me in restoring proper access to the key vault and finally led to the proper solution of our issue.