3.4 Resource Locks and Tags

Quick Answer: Resource Locks prevent accidental deletion (CanNotDelete) or any change (ReadOnly), and override RBAC — even an Owner must remove the lock first. Tags are key-value labels for organizing and tracking resources; tags are NOT inherited.

Resource Locks

Resource Locks protect critical resources from accidental deletion or modification, regardless of the caller's RBAC role. A lock is a safety control, not a security control: it guards against human error, while RBAC and Policy handle authorization and configuration rules.

The Two Lock Types

Be careful with ReadOnly: it can have surprising side effects. A ReadOnly lock on a storage account, for instance, blocks listing the account keys because that operation is implemented as a POST (a write), which can break apps that retrieve keys at runtime.

Lock Scope and Inheritance

• Locks apply at the subscription, resource group, or individual resource level.
• Locks inherit downward: a lock on a resource group protects every resource inside it; a subscription lock protects everything below.
• When multiple locks apply, the most restrictive one wins — a ReadOnly lock anywhere in the chain overrides a CanNotDelete lock.
• To delete a locked resource you must first remove the lock, then delete. There is no force-delete that bypasses the lock.
• Managing locks requires the Microsoft.Authorization/locks/* action — held by Owner and User Access Administrator, not by Contributor.

On the Exam: A CanNotDelete lock stops even an Owner from deleting the resource until the lock is removed. Pick the lock type by intent: protect from deletion only → CanNotDelete; freeze configuration entirely → ReadOnly.

When to Use Each Lock

Resource Tags

Tags are key-value pairs attached to resources, resource groups, and subscriptions to logically organize them for billing, operations, and automation. Each tag has a name (key) and a value.

Exact Tag Limits (memorize these)

Why Tags Matter — Cost Tracking and Automation

The biggest payoff is in Microsoft Cost Management: you can filter and group the cost analysis view by a tag to see exactly how much CostCenter: CC-1001 or Environment: Dev is spending, and scope budgets to those tags. Automation runbooks commonly target tags too — for example, shut down every VM tagged Environment: Development after business hours to cut spend.

Enforcing Tags with Azure Policy

Because tags do not inherit, you enforce them with Policy:

• Require a tag on resources — Deny creation of any resource missing the required tag.
• Inherit a tag from the resource group — uses the Modify effect to copy the resource group's tag onto child resources.
• Add or replace a tag on resources — standardize values across the estate.

On the Exam: "Are tags inherited from a resource group to its resources?" The answer is No. To simulate inheritance, assign the built-in 'Inherit a tag from the resource group' policy.

A Worked Tagging and Locking Scenario

Fabrikam wants its production database protected and its Marketing spend tracked. The administrator places a CanNotDelete lock directly on the prod-sql resource and a second CanNotDelete lock on the parent resource group as a belt-and-suspenders measure. Because locks inherit and the most restrictive wins, even a junior engineer who is accidentally granted Owner cannot delete the database — the deletion request fails until someone with Microsoft.Authorization/locks/delete removes the lock.

For cost tracking, every Marketing resource gets Department: Marketing and CostCenter: CC-2200. Finance then opens Microsoft Cost Management, groups the cost analysis view by the Department tag, and instantly sees Marketing's monthly run rate. They scope a budget to that tag so an alert fires at eighty percent. A common mistake here: someone tags only the resource group and assumes the VMs inside inherit it — they do not, so the cost report shows the group's spend as untagged. The fix is to assign the Inherit a tag from the resource group policy, which uses the Modify effect to push the tag onto each child resource.

Common Traps

• ReadOnly can break apps, for example by blocking storage account key listing (a write operation).
• Locks override RBAC for the locked operation — even Owner is stopped until the lock is removed.
• Tags do not inherit and have a hard cap of 50 per resource.
• Storage account tag names are limited to 128 characters, not the usual 512.