# Azure Resource Locks and Tags > Chapter 39 of the Courseiva AZ-900 curriculum — https://courseiva.com/learn/az-900/azure-resource-locks **Official objective:** 3.2 — Azure Management Governance ## Introduction 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. ## A Padlock on a Storage Unit's Door 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). ## Core explanation ### 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. ## Real-world context 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. ## Exam focus 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. ## Step by step 1. **Apply tags for organization** — Tags are applied to resources to identify ownership, project, environment, or other organizational categories, supporting search, reporting, and cost analysis. 2. **Identify critical resources needing protection** — Resources that would be especially disruptive if accidentally deleted or modified are identified as candidates for a resource lock. 3. **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. 4. **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. ## Comparisons ### Tags vs Resource Locks **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 ## Common misconceptions - **Misconception:** Tags prevent a resource from being accidentally deleted. **Reality:** 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. - **Misconception:** CanNotDelete and ReadOnly locks work the same way. **Reality:** CanNotDelete still allows a resource to be modified, just not deleted. ReadOnly prevents both modification and deletion — they offer different levels of protection. - **Misconception:** A user with permission to delete a resource can always do so, regardless of locks. **Reality:** 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. ## Key takeaways - 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. ## FAQ **What's the difference between a tag and a resource lock?** 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. **What's the difference between CanNotDelete and ReadOnly locks?** 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. **Can someone with full permissions still delete a locked 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. --- Interactive version with quiz and diagrams: https://courseiva.com/learn/az-900/azure-resource-locks