3.4 Resource Locks and Tags
Key Takeaways
- Resource Locks prevent accidental deletion or modification of Azure resources — even by Owner-level users.
- There are two lock types: CanNotDelete (prevents deletion but allows modification) and ReadOnly (prevents all changes).
- Locks are inherited from parent scopes: a lock on a resource group applies to all resources within it.
- Tags are key-value pairs that organize Azure resources for cost tracking, ownership, environment identification, and automation.
- Tags are NOT inherited — they must be applied at each level (use Azure Policy to enforce tagging).
Resource Locks and Tags
Quick Answer: Resource Locks prevent accidental deletion (CanNotDelete) or modification (ReadOnly) of Azure resources. Tags are key-value pairs for organizing resources. Locks are inherited; tags are NOT inherited.
Resource Locks
Resource Locks prevent accidental deletion or modification of critical Azure resources. Even users with Owner permissions cannot delete a locked resource without first removing the lock.
Lock Types
| Lock Type | Prevents | Allows |
|---|---|---|
| CanNotDelete (Delete) | Deleting the resource | Reading and modifying the resource |
| ReadOnly | Any modification or deletion | Reading the resource only |
Lock Behavior
- Locks can be applied at the subscription, resource group, or resource level
- Locks are inherited — a lock on a resource group applies to ALL resources within it
- A lock on a subscription applies to all resource groups and resources in the subscription
- To delete a locked resource, you must first remove the lock, then delete the resource
- Multiple locks can exist on a resource — the most restrictive lock wins
On the Exam: Even the Owner role cannot delete a resource with a CanNotDelete lock without first removing the lock. Locks are designed to prevent accidental changes, not to replace RBAC security.
When to Use Resource Locks
| Scenario | Lock Type |
|---|---|
| Production database that must never be deleted | CanNotDelete |
| Production network configuration that must not change | ReadOnly |
| Shared resource group used by multiple teams | CanNotDelete |
| Compliance-critical resources with audit requirements | ReadOnly |
Resource Tags
Tags are key-value pairs that you attach to Azure resources, resource groups, and subscriptions to logically organize them.
Tag Structure
Tags consist of a name (key) and a value:
| Tag Name | Tag Value | Purpose |
|---|---|---|
| Environment | Production, Staging, Development | Identify resource environment |
| CostCenter | CC-1234, CC-5678 | Track costs by department |
| Owner | jane.doe@company.com | Identify resource owner |
| Project | Project-Alpha, Project-Beta | Group resources by project |
| ManagedBy | IT-Ops, DevOps-Team | Identify managing team |
Important Tag Rules
| Rule | Detail |
|---|---|
| NOT inherited | Tags on a resource group do NOT automatically apply to resources within it |
| Max tags per resource | 50 tag name/value pairs |
| Tag name max length | 512 characters (128 for storage accounts) |
| Tag value max length | 256 characters |
| Case-sensitive | "Environment" and "environment" are different tag names |
| Can be enforced | Use Azure Policy to require specific tags on resources |
Tag Use Cases
| Use Case | How Tags Help |
|---|---|
| Cost management | Filter Azure Cost Management reports by tag to see spending per project, department, or team |
| Operations | Identify resource owner for incident response |
| Automation | Auto-shutdown VMs tagged with "Environment: Development" after business hours |
| Compliance | Tag resources with data classification (e.g., "DataClass: Confidential") |
| Governance | Use Azure Policy to require tags at creation time |
Enforcing Tags with Azure Policy
Since tags are not inherited, use Azure Policy to ensure consistent tagging:
- Require a tag on resources — Deny creation of resources without a specific tag
- Require a tag on resource groups — Deny creation of resource groups without a tag
- Inherit a tag from the resource group — Automatically copy a tag from the resource group to new resources
On the Exam: Tags are NOT inherited from resource groups to resources. This is a frequently tested fact. Use Azure Policy with the "Inherit a tag from the resource group" policy to enforce tag inheritance.
Which resource lock type prevents deletion but allows modifications?
Are Azure resource tags inherited from a resource group to the resources inside it?
A user with the Owner role tries to delete a resource that has a CanNotDelete lock. What happens?