This chapter covers Azure Resource Locks and Tags — two related but distinct tools for managing resources. AZ-900 tests this under objective 3.2, alongside the broader governance concepts covered in nearby chapters.
Jump to a section
A simple way to picture Azure Resource Locks and Tags
Tags on storage boxes help you identify what's inside and organize them, but they don't physically stop someone from removing or damaging a box. A padlock on a storage unit's door does something different — it actively prevents the door from being opened at all, regardless of who's trying. Azure Resource Locks and Tags work similarly but serve different purposes: tags help organize and identify resources (like labeling boxes), while resource locks actively prevent accidental deletion or modification (like a padlock preventing the door from opening at all).
What Resource Locks do
A resource lock prevents a resource (or a broader scope, like a resource group) from being accidentally deleted or modified, regardless of a user's normal permissions to do so. Locks come in two types: CanNotDelete, which allows viewing and modifying a resource but prevents deleting it, and ReadOnly, which prevents both deleting and modifying it.
What Tags do
Tags are name-value pairs attached to resources for organizational purposes — such as identifying which department owns a resource, which project it belongs to, or its environment (development, production, and so on). Tags don't restrict what can be done to a resource; they simply help organize, search, and report on resources, including supporting cost analysis broken down by tag.
Why both matter together
Tags help an organization understand and organize a large number of resources; locks help protect specific critical resources from accidental changes. They solve different problems and are often used together — for example, tagging a resource as "production" and also applying a lock to prevent it from being accidentally deleted.
An important distinction from RBAC
Resource locks are different from RBAC (covered in an earlier chapter) — RBAC controls who has permission to perform an action; a lock overrides even an authorized user's ability to perform a specific action (like deletion) on a locked resource, adding an extra layer of protection beyond normal permissions.
Apply tags for organization
Tags are applied to resources to identify ownership, project, environment, or other organizational categories, supporting search, reporting, and cost analysis.
Identify critical resources needing protection
Resources that would be especially disruptive if accidentally deleted or modified are identified as candidates for a resource lock.
Apply the appropriate lock type
A CanNotDelete lock is applied if modification should still be allowed but deletion should be prevented; a ReadOnly lock is applied if neither deletion nor modification should be allowed.
Understand locks override normal permissions
Even a user with sufficient RBAC permissions to delete or modify a resource will be blocked by an applied lock, until the lock itself is removed by someone with appropriate access to do so.
An organization tags all of its resources with a department and environment label, making it easy to generate a cost report broken down by department, or to quickly identify which resources belong to the production environment specifically.
Separately, that same organization applies a CanNotDelete lock to its production database, so even an engineer with full permissions to manage that resource can't accidentally delete it — preventing a costly mistake, since deleting the lock itself would require a deliberate, additional step before the resource could be deleted.
Objective 3.2 expects candidates to distinguish tags (organizational metadata) from resource locks (protection against accidental deletion or modification), and to understand the two lock types.
A common wrong answer is assuming tags provide any protective function — they don't; tags are purely for organization and identification, not preventing changes. Another common trap is confusing the two lock types — CanNotDelete still allows modification, while ReadOnly prevents both modification and deletion.
Stable terms: Resource Lock, Tag, CanNotDelete, ReadOnly. Understanding that locks override even authorized users' normal permissions is a frequently tested nuance.
Memory trick: tags organize and identify (no protection). Locks protect against accidental change — CanNotDelete allows edits but blocks deletion; ReadOnly blocks both.
Tags are name-value pairs used to organize, identify, and report on resources — they don't provide any protective function.
Resource locks prevent accidental deletion (CanNotDelete) or both deletion and modification (ReadOnly) of a resource.
Resource locks override even an authorized user's normal RBAC permissions, adding an extra layer of protection.
Tags and locks solve different problems and are often used together on the same resource.
These come up on the exam all the time. Here's how to tell them apart.
Tags
Name-value pairs for organization
No protective effect on the resource
Supports search, reporting, and cost analysis
Resource Locks
Prevents accidental deletion or modification
Overrides normal RBAC permissions
Two types: CanNotDelete and ReadOnly
Mistake
Tags prevent a resource from being accidentally deleted.
Correct
Tags are purely for organization and identification — they don't provide any protective function. Resource locks are the tool specifically designed to prevent accidental deletion or modification.
Mistake
CanNotDelete and ReadOnly locks work the same way.
Correct
CanNotDelete still allows a resource to be modified, just not deleted. ReadOnly prevents both modification and deletion — they offer different levels of protection.
Mistake
A user with permission to delete a resource can always do so, regardless of locks.
Correct
A resource lock overrides even an authorized user's normal RBAC permissions — if a CanNotDelete or ReadOnly lock is applied, the relevant action is blocked until the lock itself is removed.
A tag is a name-value pair used to organize and identify resources — it doesn't restrict what can be done to the resource. A resource lock actively prevents accidental deletion or modification, overriding even an authorized user's normal permissions.
A CanNotDelete lock allows a resource to still be viewed and modified, but prevents it from being deleted. A ReadOnly lock is stricter, preventing both modification and deletion of the resource.
No — a resource lock overrides normal RBAC permissions. Even a user who would otherwise have permission to delete the resource is blocked until the lock itself is removed by someone with appropriate access to do so.
You've just covered Azure Resource Locks and Tags — now see how well it sticks with free AZ-900 practice questions. Full explanations included, no account needed.
Done with this chapter?