Resource Tags and Resource Locks

Resource tags are name-value pairs of metadata that you attach to Azure resources, resource groups, and subscriptions. Unlike folder structures, tags allow a single resource to be categorised in multiple dimensions simultaneously. For example, a VM can have tags Environment=Production, Team=Backend, CostCentre=CC-042, and Project=Phoenix all at once, enabling filtering by any of those dimensions independently.

Organisations typically define a standard tagging taxonomy covering several dimensions. Financial tags (CostCentre, BudgetOwner) enable cost allocation. Operational tags (Environment, Criticality, Owner) support filtering and alerting. Lifecycle tags (AutoShutdown, ExpiryDate) enable automation. Security tags (DataClassification, Compliance) support security tooling. Defining the taxonomy before deploying resources prevents an inconsistent, un-queryable tag landscape.

Tags can be applied through the Azure portal, CLI, ARM templates, Bicep, and Terraform. The az tag command manages tags on resources, while az group update tags resource groups. Using Azure Policy with the Modify or Append effect, you can automatically add or require tags at resource creation time — ensuring every new resource has a CostCentre tag without relying on developers to remember to add it manually.

A common misconception is that tags on a resource group automatically propagate to the resources inside it. They do not — Azure resource tags do not inherit from parent scopes. If you tag a resource group with Environment=Production, the VMs and databases inside that group do not automatically receive that tag. To enforce consistent tagging, use an Azure Policy with the Inherit a tag from the resource group built-in definition, which automatically copies the resource group tag to all resources within it.

Tags are most powerful when combined with Azure Cost Management. In the Cost Analysis view, you can group spending by any tag key — for example, view total monthly spend by CostCentre to see which department is the largest cloud consumer. You can also filter by Environment=Production to exclude development spending from production budgets. Azure Cost Management requires that the tag was applied before the billing period to appear in cost data.

Resource locks protect Azure resources from accidental deletion or modification, regardless of what RBAC permissions a user holds. A user with Owner or Contributor rights can still be blocked from deleting or modifying a locked resource. Locks are applied at the resource, resource group, or subscription level and cascade downward — a lock on a resource group protects every resource inside it.

Azure supports two lock types. CanNotDelete (Delete lock) allows users to read and modify the resource but prevents deletion. This is the most common lock — applied to production databases, storage accounts, and VNets to prevent accidental teardown. ReadOnly prevents all write and delete operations, making the resource behave as if only the Reader role was assigned to everyone. ReadOnly is more restrictive and can disrupt automated processes that update resource properties.

To delete or modify a locked resource, a user must first remove the lock — which requires the Microsoft.Authorization/locks/delete permission (available to Owner and User Access Administrator roles by default). The lock removal, resource modification, and optional lock re-application can be scripted into a change management workflow, ensuring protected resources can still be modified through a controlled process with an audit trail.

A lock applied at a parent scope (subscription or resource group) is inherited by all child resources. You cannot override a lock at a lower scope — if a resource group has a CanNotDelete lock, individual resources inside cannot be deleted even if they have no lock applied directly to them. Adding a CanNotDelete lock at the resource level in addition to a parent lock does not change behaviour; the parent lock already provides the protection.

ReadOnly locks can cause unexpected failures in automated processes. Some Azure operations that appear read-only at the surface actually require write access to resource properties behind the scenes. For example, listing a storage account's access keys is blocked by a ReadOnly lock because the key-listing action modifies the account's audit trail. Scaling a VM, restarting an App Service, and attaching a disk to a running VM are also blocked. Test ReadOnly locks in non-production environments before applying them to critical resources.

Combining tags and locks creates a powerful governance pattern. You can use a tag like Protected=true to mark resources that should have CanNotDelete locks, then run an Azure Automation Runbook that queries for resources with this tag and creates the lock if it is missing. This self-healing governance pattern ensures that even if an administrator accidentally removes a lock, it gets reapplied automatically within the runbook's schedule.

Test your understanding of Microsoft Azure Fundamentals (AZ-900) concepts from this lesson.

In this lesson you learned: resource tags are name-value metadata pairs that enable cost allocation, filtering, and automation across any dimension, tags do not inherit from parent resource groups and must be enforced via Azure Policy, and resource locks (CanNotDelete and ReadOnly) protect resources from accidental change regardless of RBAC permissions. Next up we explore Azure Blueprints for packaging governance artefacts together.