Azure Resource Locks and Tags

Azure Resource Locks are a governance feature that prevents accidental deletion or modification of Azure resources. They act as an override for any permissions — even if a user has Contributor or Owner role, a lock can block their ability to delete or modify a resource. Locks are applied at the subscription, resource group, or individual resource level and are inherited by child resources. Tags, on the other hand, are metadata key-value pairs that you attach to resources to logically organize them. Tags are used for cost reporting, resource grouping, automation, and policy enforcement. They do not affect access control.

When you apply a lock to a resource, Azure's Resource Manager checks the lock before executing any operation. The lock is evaluated after Azure RBAC (Role-Based Access Control) but before the operation is performed. The process works as follows:

Locks are inherited. For example, if you apply a CanNotDelete lock to a resource group, all resources within that group inherit that lock. You cannot delete any resource in that group unless you remove the lock first. However, you can still modify the resources (e.g., change configuration) unless a ReadOnly lock is applied.

Azure provides two types of locks:

There is no 'Delete' lock that only prevents deletion but allows modification; that's exactly what CanNotDelete does. ReadOnly is stricter.

Tags are simple key-value pairs. For example: Environment: Production, CostCenter: 12345, Owner: Alice. You can apply tags to most Azure resources, resource groups, and subscriptions. Tags are not inherited by default, but you can use Azure Policy to enforce inheritance. Tags are stored as metadata and are visible in the Azure Portal, CLI, and via API. They are used for:

Tags have limits: each resource can have up to 50 tag name-value pairs. Tag names are case-insensitive but case-preserving. Tag values are case-sensitive.

In an on-premises data center, there is no built-in equivalent to resource locks. You might use physical security (locked server racks) or administrative procedures (change management) to prevent accidental deletion. But these are not automated or enforced by the infrastructure. Tags are similar to labeling systems in ITIL or CMDBs, where you assign metadata to assets. However, in Azure, tags are native and can drive automated cost allocation and policy, which is much harder to achieve on-premises.

To manage locks in the Azure Portal:

To manage tags in the Azure Portal:

Using Azure CLI:

# Apply a CanNotDelete lock to a resource group
az lock create --name LockRG --lock-type CanNotDelete --resource-group MyResourceGroup

# Apply a ReadOnly lock to a storage account
az lock create --name LockStorage --lock-type ReadOnly --resource-group MyResourceGroup --resource-name mystorageaccount --resource-type Microsoft.Storage/storageAccounts

# List all locks
az lock list

# Add a tag to a resource group
az tag create --resource-id /subscriptions/.../resourceGroups/MyResourceGroup --tags Environment=Production CostCenter=12345

Using PowerShell:

# Apply a CanNotDelete lock
New-AzResourceLock -LockName LockRG -LockLevel CanNotDelete -ResourceGroupName MyResourceGroup

# Apply a ReadOnly lock
New-AzResourceLock -LockName LockStorage -LockLevel ReadOnly -ResourceGroupName MyResourceGroup -ResourceName mystorageaccount -ResourceType Microsoft.Storage/storageAccounts

# Add tags
Set-AzResourceGroup -Name MyResourceGroup -Tag @{Environment='Production'; CostCenter='12345'}

A mid-sized e-commerce company runs its customer database on Azure SQL Database. One night, a junior DBA accidentally tries to delete the database while cleaning up test resources. Without a lock, the database would be gone, causing hours of downtime and potential data loss. The company applies a CanNotDelete lock on the resource group containing the database. Now, any delete attempt fails with an error. Additionally, they tag the resource group with Environment: Production and CostCenter: ECommerce. This helps the finance team track costs. If the lock were not applied, the accidental deletion could have cost the company thousands in lost revenue. The lock also prevents automated scripts from deleting the resource. The team also applies a ReadOnly lock on a configuration file stored in Azure Blob Storage to prevent accidental modification. A common mistake is applying the lock at the wrong level — if they applied it only to the database resource, new resources added to the group would be unprotected. So they apply it at the resource group level for inheritance.

A multinational corporation has hundreds of Azure subscriptions. The finance team needs to allocate costs to different departments and projects. They mandate that all resources must have tags: Department, Project, and CostCenter. Using Azure Policy, they enforce that any new resource without these tags is denied creation or flagged as non-compliant. They also use Azure Cost Management to generate reports grouped by these tags. Without tags, the finance team would have to manually track costs, leading to inaccuracies and disputes. A common issue is that tags are not applied consistently. For example, some teams use 'Dept' while others use 'Department'. To solve this, they create a policy that requires specific tag names. They also use a remediation task to add missing tags. The scale of this operation requires automation; they use Azure CLI scripts to apply tags to existing resources. The cost of not tagging is poor visibility and potential budget overruns.

A financial services company is undergoing a security audit. To ensure no changes are made to the production environment during the audit, they apply a ReadOnly lock at the subscription level. This prevents any modifications or deletions across all resources. After the audit, they remove the lock. However, during the audit, they realize that Azure Backup jobs fail because they need to write to the Recovery Services vault. They had to temporarily remove the lock for backups. This is a real-world challenge: ReadOnly locks can break dependent services. Best practice is to test locks in a non-production environment first. They also tag resources with AuditStatus: InProgress to track which resources are under audit. This scenario highlights that locks are powerful but must be used carefully.