This chapter covers resource locks and tag governance, two critical tools for enforcing governance and preventing accidental modifications in Azure. Resource locks allow you to protect subscriptions, resource groups, or individual resources from deletion or modification, while tags enable resource organization, cost tracking, and policy enforcement. Approximately 10-15% of AZ-104 exam questions touch on these topics, often in scenarios involving RBAC integration, inheritance, and policy evaluation. Mastering these concepts is essential for the 'Governance and Compliance' domain and for designing resilient Azure solutions.
Jump to a section
Imagine you are the facilities manager for a large office building. The building has many rooms (resources) that different teams use. To prevent accidental or malicious changes to critical rooms, you install tamper-proof seals on the doors. There are two types of seals: a red seal that prevents anyone from opening the door at all (CanNotDelete), and a blue seal that prevents anyone from moving furniture inside or changing the room's purpose (CanNotModify). These seals are applied to the door frame (the resource) and can be inherited by all doors inside a wing (subscription or resource group). If someone tries to open a door with a red seal, the seal breaks and an alarm sounds (403 Forbidden error). To make changes, you must first remove the seal, which requires special permission (Owner or User Access Administrator). The seals themselves are not the rooms; they are just restrictions applied on top. If a seal is removed, the room is unchanged but now modifiable. This mirrors how Azure Resource Locks work: they are applied at a scope, inherited by child resources, and only prevent actions at the control plane (management operations), not data plane operations. Just as a seal doesn't prevent someone from using the room's existing contents, a ReadOnly lock doesn't prevent reading data from a storage account — it only prevents modifying the storage account's configuration or deleting it.
What Are Resource Locks?
Resource locks are settings that prevent accidental deletion or modification of Azure resources. They are applied at a scope—subscription, resource group, or individual resource—and are inherited by all child resources within that scope. There are two types of locks: CanNotDelete and ReadOnly.
CanNotDelete: Authorized users can still read and modify a resource, but they cannot delete it. This lock does not prevent modification or deletion of child resources unless the lock is applied at their scope or inherited.
ReadOnly: Authorized users can only read a resource, but cannot delete or modify it. This lock is similar to restricting all users to the Reader role, but it is applied directly to the resource rather than through RBAC.
How Resource Locks Work Internally
Resource locks operate at the Azure Resource Manager (ARM) control plane. When a request to create, update, or delete a resource is sent to ARM, the system checks for any locks at the target scope and all parent scopes. If a lock prohibits the action, ARM returns a 403 Forbidden error. Locks are not applied to the data plane; for example, a ReadOnly lock on a storage account does not prevent reading or writing data in the account's blobs or tables—it only prevents management operations such as changing the account's SKU or deleting the account.
Locks are inherited from parent scopes. If you apply a CanNotDelete lock at the subscription level, no resource in that subscription can be deleted (unless the lock is removed). However, locks are not transitive across management groups—they only apply to the scope and its child scopes within the same hierarchy.
Key Components, Values, and Defaults
Lock types: CanNotDelete and ReadOnly are the only two lock types. There is no CanNotModify lock separate from ReadOnly—ReadOnly effectively prevents all modifications.
Scope: Locks can be applied at the subscription, resource group, or resource level. They cannot be applied to management groups directly (though management group policies can enforce locks).
Inheritance: Locks are inherited by all child resources. A lock at the resource group level applies to all resources in that group.
Permissions: To add or remove locks, you need Microsoft.Authorization/locks/* permissions. Built-in roles that include this are Owner and User Access Administrator. The Contributor role does not have permission to manage locks.
Effect on RBAC: Locks override RBAC permissions. Even if a user has Owner role, they cannot delete a resource with a CanNotDelete lock unless they first remove the lock.
Data plane vs. Control plane: Locks only affect control plane operations (management via ARM). Data plane operations (e.g., reading/writing data in a storage account, querying a SQL database) are unaffected.
Configuration and Verification
You can manage locks via the Azure portal, Azure CLI, Azure PowerShell, or ARM templates.
Azure CLI example:
# Create a CanNotDelete lock at the resource group level
az lock create --name LockRG --lock-type CanNotDelete --resource-group MyResourceGroup
# List all locks
az lock list
# Delete a lock
az lock delete --name LockRG --resource-group MyResourceGroupAzure PowerShell example:
# Create a ReadOnly lock at the subscription level
New-AzResourceLock -LockName LockSub -LockLevel ReadOnly -Scope /subscriptions/00000000-0000-0000-0000-000000000000
# Get locks
Get-AzResourceLock
# Remove a lock
Remove-AzResourceLock -LockName LockSub -Scope /subscriptions/00000000-0000-0000-0000-000000000000Verification: To verify a lock is in effect, try to delete the resource via the portal or CLI. You should receive an error message indicating the resource is locked.
Interaction with Azure Policy and RBAC
Resource locks complement Azure Policy and RBAC but are distinct: - RBAC controls who can perform actions based on roles. - Azure Policy enforces rules on resource configurations during creation or update. - Resource locks prevent actions on existing resources regardless of RBAC permissions.
For example, a user with Contributor role can delete a resource unless a CanNotDelete lock is present. Policy can enforce that certain tags exist, but locks prevent deletion even if the policy is not violated.
Tag Governance
Tags are key-value pairs that can be applied to Azure resources, resource groups, and subscriptions. They are used for organizing resources, managing costs, enforcing policies, and automating operations. Tags are not inherited from parent scopes by default, but you can use Azure Policy to enforce tag inheritance.
Tag characteristics: - Each resource can have up to 50 tags. - Tag names are case-insensitive but case-preserving. - Tag values are case-sensitive. - Tags can be applied during creation or after. - Tags are not automatically inherited from resource groups to resources.
Common use cases:
- Cost tracking: Tag resources with cost center, project, or environment (e.g., CostCenter: IT, Environment: Production).
- Resource organization: Use tags like Department: Marketing to filter resources.
- Automation: Use tags to trigger runbooks or logic apps (e.g., ShutdownTime: 19:00).
- Policy enforcement: Azure Policy can require specific tags or enforce inheritance.
Enforcing Tag Governance with Azure Policy
Azure Policy can enforce tagging rules. Common built-in policies include: - "Require a tag and its value on resources" - "Inherit a tag from the resource group if missing" - "Add or replace a tag on resources"
Example policy assignment (CLI):
# Assign built-in policy to require tag 'Environment' with value 'Production'
az policy assignment create --name RequireEnvironmentTag --policy "2a0e14a6-b0a6-4fab-991a-5b7cda3d9a0e" --params "{'tagName':{'value':'Environment'},'tagValue':{'value':'Production'}}" --scope /subscriptions/00000000-0000-0000-0000-000000000000Tag Inheritance
By default, tags are not inherited. To inherit tags from a resource group, use the built-in policy "Inherit a tag from the resource group if missing" (policy definition ID: /providers/Microsoft.Authorization/policyDefinitions/...). This policy adds the tag from the resource group to any resource that does not have that tag.
Locking Tagged Resources
You can combine locks and tags. For example, apply a CanNotDelete lock to all resources tagged with Environment: Production using Azure Policy with a DeployIfNotExists effect that creates a lock. However, this requires a managed identity and custom policy.
Exam-Relevant Details
Locks are ARM-level, not data plane.
ReadOnly lock prevents all write operations (including PUT, PATCH, DELETE) but allows GET.
CanNotDelete lock allows PUT and PATCH but not DELETE.
Locks are inherited, but tags are not (unless policy enforces inheritance).
To manage locks, you need Microsoft.Authorization/locks/write and delete permissions.
The Contributor role cannot manage locks.
Locks can be applied to resource groups, subscriptions, and individual resources, but not to management groups directly.
When a lock is applied at a parent scope, it affects all child resources. For example, a ReadOnly lock on a resource group prevents any modifications to resources within that group.
Common Mistakes
Confusing locks with RBAC: Locks are not roles; they are restrictions that apply to everyone regardless of role.
Applying a ReadOnly lock to a storage account expecting it to prevent data access: It only prevents management operations, not data read/write.
Forgetting that locks are inherited: A lock at subscription level prevents deletion of all resources, which might be too restrictive.
Thinking tags are inherited: Tags are not inherited; you must use policy to enforce inheritance.
Identify Resource to Protect
Determine which Azure resources require protection from accidental deletion or modification. Typically, these are critical resources such as production databases, virtual networks, or key vaults. Also identify the scope: subscription, resource group, or individual resource. For example, you might want to protect all resources in a 'Production' resource group with a CanNotDelete lock to prevent accidental deletion of any production resource.
Choose Lock Type
Select either CanNotDelete or ReadOnly based on the required level of protection. CanNotDelete allows modifications but prevents deletion; ReadOnly prevents both. For most production resources, CanNotDelete is sufficient to prevent accidental deletion while allowing updates. Use ReadOnly for resources that should not be changed, such as a read-only replica or a configuration resource that must remain static.
Apply Lock via Portal or CLI
In the Azure portal, navigate to the resource, resource group, or subscription, select 'Locks' under 'Settings', and add a lock with a name and type. Alternatively, use Azure CLI or PowerShell. For example, to apply a CanNotDelete lock on a resource group: `az lock create --name LockRG --lock-type CanNotDelete --resource-group MyResourceGroup`. The lock is immediately effective. Verify by attempting to delete a resource in that group; you should receive a 403 error.
Verify Lock Inheritance
Check that child resources inherit the lock as expected. For a lock at the resource group level, all resources within that group should show the lock in their 'Locks' blade (inherited locks are displayed but cannot be modified at the child scope). If you need to exclude a specific resource from the lock, you must remove the lock at the parent scope or apply a separate lock at the child scope (but note that a more restrictive lock at child scope overrides the parent lock? Actually, locks are additive: a ReadOnly lock at parent and no lock at child means child is ReadOnly. You cannot override a parent lock with a less restrictive child lock. The child lock can only add restrictions, not remove them.
Implement Tag Governance
Define a tagging strategy for your organization. Common tags include Environment, CostCenter, Owner, and Project. Apply tags manually or enforce them via Azure Policy. For example, assign the built-in policy 'Require a tag and its value on resources' to ensure all resources have the 'Environment' tag. Use the 'Inherit a tag from the resource group if missing' policy to automatically propagate resource group tags to resources. Monitor compliance via Azure Policy compliance dashboard.
Monitor and Audit Locks and Tags
Regularly review locks and tags using Azure Resource Graph or Azure Monitor. Use Activity Log to track lock creation, modification, and deletion. For tags, use Azure Policy compliance reports to identify non-compliant resources. Create alerts for critical lock changes. For example, set up an alert when a lock is deleted from a production resource group to quickly investigate and reapply the lock.
Enterprise Scenario 1: Protecting Production Environment
A large e-commerce company runs its production workload in Azure. They have a resource group named 'prod-rg' containing virtual machines, a SQL database, and a load balancer. To prevent accidental deletion, the cloud admin applies a CanNotDelete lock at the resource group level. This ensures that even if an engineer accidentally tries to delete the entire resource group or any resource within it, the operation fails. They also apply a ReadOnly lock to the production database server to prevent configuration changes during business hours. The lock is removed temporarily during maintenance windows by a senior admin with Owner permissions. The company uses Azure Policy to enforce that all resources in production have an 'Environment: Production' tag for cost tracking. They use the 'Inherit a tag from the resource group' policy to automatically tag new resources.
Enterprise Scenario 2: Multi-Tenant Tagging Strategy
A managed service provider (MSP) manages multiple customer subscriptions. They use tags to associate resources with specific customers and projects. For example, each resource is tagged with CustomerID and ProjectCode. They enforce tag requirements using Azure Policy at the management group level, so all subscriptions under that management group must comply. They also use tag inheritance policies to automatically apply the customer tag from the subscription to all resources. This enables accurate cost allocation and reporting. The MSP uses Azure Cost Management to filter costs by tags and invoice customers accordingly. A common pitfall is that tags are not inherited by default, so they rely on policy to enforce inheritance.
Scenario 3: Compliance and Audit
A financial institution must comply with regulatory requirements that prevent deletion of audit logs. They apply a CanNotDelete lock on the Log Analytics workspace that stores audit logs. Additionally, they use a ReadOnly lock on the storage account containing archived logs. They have a process where lock removal requires approval and is logged. They use Azure Policy to audit that locks are present on critical resources. For example, a custom policy checks that all storage accounts have a CanNotDelete lock; if not, it marks the resource as non-compliant. This ensures that the locks are not accidentally removed. The institution also uses tags to classify resources by sensitivity level (e.g., 'Confidential', 'Public') and restricts who can modify tags using RBAC.
What AZ-104 Tests on Resource Locks and Tag Governance
The AZ-104 exam covers resource locks under objective 'Manage Azure identities and governance' (15-20%). Specifically, subtopics include:
Configuring and managing resource locks (CanNotDelete, ReadOnly)
Understanding lock inheritance and scope
Differentiating locks from RBAC and Azure Policy
Implementing tag governance using Azure Policy
Enforcing tag inheritance
Common Wrong Answers and Why Candidates Choose Them
Choosing Contributor role to manage locks: Candidates often assume that because Contributor can manage resources, it can also manage locks. However, lock management requires Microsoft.Authorization/locks/* permissions, which Contributor does not have. The correct roles are Owner and User Access Administrator.
Believing ReadOnly lock prevents data access: Many candidates think a ReadOnly lock on a storage account prevents users from reading blobs. Actually, it only prevents management operations (e.g., changing SKU, deleting account). Data plane operations are unaffected.
Thinking locks are inherited across management groups: Locks are inherited only within the scope they are applied (subscription, resource group, resource). They do not apply to other subscriptions under the same management group unless the lock is applied at the management group? Actually, locks cannot be applied to management groups directly. Azure Policy can enforce locks across management groups, but locks themselves are not inherited across management groups.
Confusing CanNotDelete with ReadOnly: Some candidates think CanNotDelete also prevents modifications. It does not; it only prevents deletion. ReadOnly prevents both deletion and modification.
Specific Numbers, Values, and Terms
Lock types: CanNotDelete, ReadOnly
Maximum tags per resource: 50
Tag name length: up to 512 characters (but practical limits apply)
Tag value length: up to 256 characters
Built-in policy definitions for tags: 'Require a tag and its value', 'Inherit a tag from the resource group if missing', 'Add or replace a tag on resources'
Permissions needed: Microsoft.Authorization/locks/write and delete
Edge Cases and Exceptions
Locks applied at a parent scope cannot be overridden by a less restrictive lock at a child scope. For example, if a subscription has a ReadOnly lock, you cannot apply a CanNotDelete lock at the resource group level to allow modifications. The child lock can only add restrictions.
Locks do not affect data plane operations. For example, a ReadOnly lock on a key vault does not prevent reading secrets; it only prevents management operations like deleting the vault or updating its properties.
Tags are not inherited. To inherit tags, you must use Azure Policy.
When using Azure Policy to enforce tags, the policy evaluation happens during resource creation or update. Existing non-compliant resources are marked as non-compliant but are not automatically remediated unless you use a DeployIfNotExists or Modify effect.
How to Eliminate Wrong Answers
If a question asks who can remove a lock, look for roles with Microsoft.Authorization/locks/delete permission: Owner and User Access Administrator.
If a question involves preventing deletion but allowing modification, choose CanNotDelete.
If a question involves preventing all changes, choose ReadOnly.
If a question about tag inheritance, remember that tags are not inherited by default; policy is required.
For scenarios involving both RBAC and locks, remember that locks override RBAC permissions.
Resource locks are applied at subscription, resource group, or resource scope and are inherited by child resources.
CanNotDelete prevents deletion; ReadOnly prevents deletion and modification.
Locks only affect control plane operations; data plane operations are unaffected.
To manage locks, you need Owner or User Access Administrator role (or custom role with Microsoft.Authorization/locks/*).
Tags are not inherited; use Azure Policy to enforce tag inheritance.
Each resource can have up to 50 tags.
Azure Policy can require tags, enforce tag values, and inherit tags from resource groups.
Locks are separate from RBAC and override RBAC permissions.
ReadOnly lock on a storage account does not prevent data reads/writes.
Common exam scenario: apply CanNotDelete lock to production resource group to prevent accidental deletion.
These come up on the exam all the time. Here's how to tell them apart.
Resource Locks
Prevents actions (delete/modify) on existing resources.
Applied at subscription, resource group, or resource scope.
Inherited by child resources.
Only two types: CanNotDelete and ReadOnly.
Overrides RBAC permissions; even Owner cannot bypass without removing lock.
Azure Policy
Enforces rules during resource creation or update (e.g., require tags, enforce SKU).
Assigned to management groups, subscriptions, or resource groups.
Policy effects (e.g., Deny, Audit, DeployIfNotExists) are evaluated on resources.
Many built-in and custom policy definitions.
Does not override RBAC; users with permissions can create non-compliant resources unless Deny effect is used.
Mistake
Resource locks are the same as Azure Policy.
Correct
Resource locks and Azure Policy are different. Locks prevent actions (delete/modify) on existing resources, while Policy enforces rules during resource creation or update. Locks are applied at scope and inherited; Policy uses policy definitions assigned to scopes.
Mistake
A ReadOnly lock on a storage account prevents users from reading data in the storage account.
Correct
A ReadOnly lock only prevents control plane operations (e.g., changing SKU, deleting the account). Data plane operations (e.g., reading blobs, writing files) are unaffected. To restrict data access, use RBAC or shared access signatures.
Mistake
Tags are automatically inherited from a resource group to its resources.
Correct
Tags are not inherited. You must explicitly apply tags to each resource, or use Azure Policy with the 'Inherit a tag from the resource group if missing' effect to automatically propagate tags.
Mistake
The Contributor role can manage resource locks.
Correct
Contributor role does not have permissions to create or delete locks. Only Owner and User Access Administrator have the necessary `Microsoft.Authorization/locks/*` permissions.
Mistake
A CanNotDelete lock also prevents modifications to the resource.
Correct
CanNotDelete only prevents deletion. Modifications (e.g., changing VM size, updating tags) are still allowed. To prevent modifications, use a ReadOnly lock.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
No, resource locks cannot be applied directly to management groups. They can only be applied to subscriptions, resource groups, or individual resources. However, you can use Azure Policy to enforce locks across management groups by assigning a policy with DeployIfNotExists effect that creates locks on resources.
A ReadOnly lock on a VM prevents any management operations, such as starting, stopping, restarting, resizing, or deleting the VM. However, it does not affect operations inside the VM (e.g., you can still log in and run applications). To change the VM, you must first remove the lock.
You can remove a lock via the Azure portal (navigate to the resource, select Locks, and delete the lock), Azure CLI (`az lock delete`), or PowerShell (`Remove-AzResourceLock`). You need permissions to delete locks (Owner or User Access Administrator).
No, you cannot override a parent lock with a less restrictive child lock. Locks are additive; the most restrictive lock applies. For example, if a subscription has a ReadOnly lock, you cannot apply a CanNotDelete lock at the resource group level to allow modifications. The child lock can only add restrictions (e.g., a ReadOnly lock at subscription and a CanNotDelete at resource group is still effectively ReadOnly at the resource group).
Use Azure Policy. Assign the built-in policy 'Require a tag and its value on resources' at the subscription scope. This policy will deny creation or update of any resource that does not have the specified tag. For existing resources, you can use a policy with 'DeployIfNotExists' effect to add missing tags.
Tags themselves do not grant or restrict access. However, you can use Azure Policy with 'Deny' effect to prevent creation of resources without specific tags. You can also use RBAC conditions (attribute-based access control) to allow or deny access based on tags, but this is more advanced.
Resource locks are a type of deny assignment created by Azure to prevent deletion/modification. Deny assignments are also used by Azure Blueprints and managed applications. However, resource locks are visible in the portal under 'Locks', while other deny assignments are not directly manageable via the Locks blade. Both prevent actions, but resource locks are user-managed.
You've just covered Resource Locks and Tag Governance — now see how well it sticks with free AZ-104 practice questions. Full explanations included, no account needed.
Done with this chapter?