This chapter covers Azure Resource Locks, a critical compliance and governance feature that prevents accidental or malicious deletion or modification of Azure resources. On the SC-900 exam, approximately 5-10% of questions touch on resource locks, often in scenarios involving preventing deletion of production resources or enforcing compliance. You will learn the difference between ReadOnly and Delete locks, how they interact with Azure RBAC, and how to apply them effectively. This knowledge is essential for ensuring resource governance and meeting compliance requirements.
Jump to a section
Imagine a large office building with many rooms. Each room contains valuable equipment and documents. The building manager has a master key that can open every room, but for certain critical rooms (like the server room or the HR records vault), the manager installs a special padlock on the door. This padlock has two modes: one mode allows anyone with the master key to enter but they cannot remove anything (they can read but not delete or change items inside). The other mode prevents the door from being opened at all (no one can delete the room or its contents). The padlock is not the same as the room's lock; it is an additional security layer. If a fire alarm triggers an automatic door release, the padlock remains engaged, preventing unauthorized removal even in an emergency. The padlock can only be removed by someone with a special 'padlock key' (which is different from the master key). This is exactly how Azure resource locks work: they are an additional, elevated permission layer on top of Azure RBAC. A ReadOnly lock prevents any write operations (like modifying or deleting) but allows read operations. A Delete lock prevents only delete operations but allows all other operations. These locks apply to all users and services, including the resource owner, unless the lock itself is removed. They are inherited by child resources, meaning if you lock a resource group, all resources inside are also locked. To remove a lock, you need specific permission (Microsoft.Authorization/locks/write), which typically requires Owner or User Access Administrator role at the scope of the lock. This ensures that even if a user has Contributor or Owner role on the resource, they cannot delete or modify it while the lock is in place.
What Are Azure Resource Locks?
Azure Resource Locks are a governance mechanism that sets a restriction on a resource, resource group, or subscription to prevent accidental or unauthorized changes. They are an additional layer of authorization that operates above Azure RBAC. Even if a user has Owner-level permissions, they cannot perform operations that are blocked by a lock unless they first remove the lock. Locks are inherited from parent scopes to child scopes.
There are two types of locks: - CanNotDelete (Delete lock): Authorized users can read and modify a resource, but cannot delete it. - ReadOnly (Read-only lock): Authorized users can read a resource, but cannot delete or modify it. This is analogous to a read-only replica.
Locks apply to all users and services, including the resource owner. The only way to bypass a lock is to remove it, which requires the Microsoft.Authorization/locks/write permission, typically granted to the Owner or User Access Administrator role at the lock's scope.
How Locks Work Internally
When a user or service principal makes an Azure Resource Manager (ARM) API call, the request goes through several layers of authorization:
1. Authentication: The caller's identity is verified.
2. RBAC Authorization: Azure checks if the caller has the required role-based permissions for the operation (e.g., Microsoft.Compute/virtualMachines/write for modifying a VM).
3. Resource Lock Check: After RBAC passes, ARM checks if any lock exists at the resource, resource group, or subscription scope that would block the operation. If a lock prohibits the action, the request is denied with an HTTP 403 Forbidden error, regardless of RBAC permissions.
This two-step check (RBAC then lock) ensures that locks are a 'hard stop' for certain operations. The lock check is performed at the ARM API level, meaning it applies to all management operations (Azure Portal, PowerShell, Azure CLI, REST API, SDKs) but does not affect data plane operations (e.g., reading data from a storage blob, writing to a SQL database). For example, a ReadOnly lock on a storage account prevents you from changing the account's configuration but does not prevent you from reading or writing blobs inside it.
Key Components and Defaults
Scope: Locks can be applied at the subscription, resource group, or individual resource level. They are inherited by all child resources.
Lock type: CanNotDelete or ReadOnly. There is no other type.
No timers: Locks persist indefinitely until removed. They are not time-bound.
Permissions required to manage locks:
To create or delete a lock: Microsoft.Authorization/locks/write permission.
Built-in roles with this permission: Owner, User Access Administrator, and custom roles that include the action.
Inheritance: If you apply a ReadOnly lock on a resource group, all resources within that group inherit the ReadOnly lock. You cannot override a parent lock with a child lock; a child lock only adds further restrictions. For example, if a resource group has a ReadOnly lock, you cannot apply a CanNotDelete lock on a child resource to allow modifications (the parent lock still blocks modifications).
Configuration and Verification Commands
Azure CLI
Apply a ReadOnly lock on a resource group:
az lock create --name "ReadOnlyRG" --lock-type ReadOnly --resource-group MyResourceGroupApply a CanNotDelete lock on a specific VM:
az lock create --name "NoDeleteVM" --lock-type CanNotDelete --resource-group MyResourceGroup --resource-name MyVM --resource-type Microsoft.Compute/virtualMachinesList all locks at a subscription scope:
az lock list --subscription MySubscriptionDelete a lock:
az lock delete --name "ReadOnlyRG" --resource-group MyResourceGroupAzure PowerShell
Apply a ReadOnly lock:
New-AzResourceLock -LockName "ReadOnlyRG" -LockLevel ReadOnly -ResourceGroupName MyResourceGroupApply a CanNotDelete lock:
New-AzResourceLock -LockName "NoDeleteVM" -LockLevel CanNotDelete -ResourceName MyVM -ResourceType Microsoft.Compute/virtualMachines -ResourceGroupName MyResourceGroupList locks:
Get-AzResourceLock -ResourceGroupName MyResourceGroupRemove a lock:
Remove-AzResourceLock -LockName "ReadOnlyRG" -ResourceGroupName MyResourceGroupAzure Portal
Navigate to the resource, resource group, or subscription blade, then under 'Settings' select 'Locks'. Add a lock with a name and type.
Interaction with Related Technologies
Azure RBAC: Locks are separate from RBAC. RBAC controls who can perform actions, locks control which actions are allowed regardless of who. Locks cannot be used to grant permissions; they only restrict.
Azure Policy: Policies enforce rules on resource configurations (e.g., require tags, enforce location). Locks prevent operations on resources. They are complementary: you might use a policy to auto-apply a lock to new resources, or a policy to prevent removal of locks.
Azure Blueprints: Blueprints can include resource locks as part of an artifact definition, allowing consistent governance across subscriptions.
Management Groups: Locks can be applied at the management group scope, affecting all subscriptions underneath. This is powerful for enterprise governance.
Azure Resource Graph: You can query locks using Azure Resource Graph to audit their existence.
Common Use Cases
Preventing accidental deletion of production resources (e.g., a critical VM, database, or network resource).
Enforcing read-only state for compliance (e.g., a resource that must not be modified after audit).
Protecting shared infrastructure in a team environment where multiple users have Contributor roles.
Safeguarding resources during migration or maintenance windows.
Limitations
Locks do not affect data plane operations. For example, a ReadOnly lock on a storage account does not prevent users from reading or writing blobs; it only prevents changes to the account configuration.
Locks do not prevent changes made directly to the resource's data via its API (e.g., writing to a SQL database).
Locks can be removed by users with appropriate permissions, so they are not a security boundary against malicious admins with Owner role.
Locks are not inherited across management groups unless explicitly applied at that scope.
Some resource types may have specific behavior; for example, deleting a resource group with a lock fails even if you have Owner permissions.
Identify Resource to Protect
Determine which Azure resource, resource group, or subscription requires protection. For example, a production virtual machine hosting a critical application. The decision to apply a lock is based on the risk of accidental deletion or modification. In enterprise environments, locks are often mandated by compliance policies for resources containing sensitive data or supporting essential services.
Choose Lock Type
Select between CanNotDelete and ReadOnly. If the goal is to prevent deletion but allow updates (e.g., patching a VM), use CanNotDelete. If the resource must remain immutable (e.g., a configuration file or a security log), use ReadOnly. Note that ReadOnly also prevents deletion because deletion is a write operation. The exam tests that ReadOnly blocks all write operations including delete.
Apply Lock at Appropriate Scope
Apply the lock at the resource, resource group, or subscription level. The scope determines inheritance. For example, applying a ReadOnly lock on a resource group locks all child resources. This is efficient for bulk protection but may be too restrictive if some resources need updates. Locks can be applied via Azure Portal, CLI, PowerShell, or REST API. The lock name must be unique within the scope.
Verify Lock Application
Use Azure CLI `az lock list` or PowerShell `Get-AzResourceLock` to confirm the lock is in place. You can also attempt to delete the resource in the portal; a lock will cause a 'Failed to delete resource' error with a message indicating the lock. Verification is critical after applying locks to ensure they are effective.
Test Lock Enforcement
Simulate an attempt to perform the blocked operation. For a CanNotDelete lock, try to delete the resource. For a ReadOnly lock, try to modify the resource (e.g., change a tag). The operation should fail with a 403 Forbidden error. This step confirms that the lock is working as expected and no other permissions are bypassing it.
In a large enterprise, Azure resource locks are essential for maintaining compliance and preventing accidental downtime. Consider a financial services company that uses Azure to host its trading platform. The production environment includes virtual machines, databases, and network resources. The company applies a CanNotDelete lock at the resource group level for all production resource groups. This ensures that even if a developer with Contributor rights accidentally clicks 'Delete resource group', the operation is blocked. The lock is applied via Azure Policy as part of a 'DenyDelete' initiative that automatically assigns locks to any resource group with a 'Production' tag.
Another scenario involves a healthcare organization that stores patient records in Azure SQL databases. To meet HIPAA compliance, they need to ensure that database configurations are not altered after deployment. They apply a ReadOnly lock on the SQL server resource (not the databases themselves) to prevent changes to firewall rules, threat detection settings, and auditing configurations. However, they allow data modifications within the databases (which are data plane operations). This requires careful planning because a ReadOnly lock on the server also prevents adding or removing databases (a control plane operation). They work around this by applying the lock only to the server-level settings and using RBAC to restrict data plane access.
A common misconfiguration is applying a ReadOnly lock on a storage account that hosts a static website. The lock prevents updating the blob content (e.g., uploading new HTML files) because that is a data plane write operation? Actually, no: ReadOnly lock on the storage account does NOT block data plane operations like uploading blobs. It only blocks control plane operations like changing the account's replication type or removing the account. So the website can still be updated. However, if you apply a ReadOnly lock on the resource group containing the storage account, it still does not block data plane operations. The lock only affects management operations. This nuance is often misunderstood and leads to false assumptions.
When misconfigured, locks can cause operational issues. For example, applying a ReadOnly lock on an entire resource group that contains a virtual machine scale set prevents the autoscaler from adding or removing VM instances (since those are management operations). This can cause outages if the scale set cannot scale out. Similarly, a CanNotDelete lock on a resource group prevents Terraform or ARM template deployments that delete and recreate resources (a common pattern for immutable infrastructure). Engineers must either remove the lock temporarily or design deployments to update in-place.
Performance considerations are minimal because locks are checked at the ARM API layer and add negligible latency. However, excessive locks (thousands) can slightly increase management overhead. Best practice is to apply locks at the highest practical scope (resource group or subscription) to minimize the number of locks.
The SC-900 exam tests Azure Resource Locks under Domain 4: 'Describe the capabilities of Microsoft compliance solutions' (Objective 4.1). Specifically, you need to understand the purpose of resource locks, the two types, and how they differ from Azure RBAC and Azure Policy.
Common Wrong Answers:
1. 'Locks can be used to grant permissions.' – WRONG. Locks only restrict; they never grant access.
2. 'A ReadOnly lock prevents all read operations.' – WRONG. It prevents write operations (including delete) but allows read operations.
3. 'Locks apply to data plane operations.' – WRONG. Locks only apply to control plane (management) operations.
4. 'Anyone with Contributor role can remove a lock.' – WRONG. Only users with Microsoft.Authorization/locks/write permission (Owner, User Access Administrator, or custom role) can remove locks.
Specific Numbers and Terms:
- Lock types: CanNotDelete and ReadOnly (exact names).
- Permission required: Microsoft.Authorization/locks/write.
- Built-in roles that can manage locks: Owner and User Access Administrator.
- Inheritance: Locks are inherited from parent to child scopes.
- Locks are evaluated after RBAC.
Edge Cases the Exam Loves: - Applying a ReadOnly lock on a resource group: all resources inside become read-only (cannot be modified or deleted). - Applying a CanNotDelete lock on a subscription: prevents deletion of any resource in the subscription (but modifications are still allowed). - Locks do not prevent deletion of a resource by its parent resource group deletion? Actually, if a resource group has a CanNotDelete lock, you cannot delete the resource group itself, but you can delete individual resources within it (unless they have their own locks). Wait, that's a key point: a CanNotDelete lock on a resource group prevents deletion of the resource group but does NOT prevent deletion of individual resources inside it. That is a common exam trap. To prevent deletion of individual resources, apply the lock at the resource level or use Azure Policy.
How to Eliminate Wrong Answers:
- If the question mentions 'prevent deletion but allow modifications', the answer is CanNotDelete.
- If the question mentions 'prevent both modification and deletion', the answer is ReadOnly.
- If the question says 'applies to all users including administrators', it is describing locks.
- If the question mentions 'compliance' or 'governance', locks are a likely answer.
- If the question contrasts with 'Azure Policy', remember Policy enforces configurations, locks enforce operations.
Exam Tips: - Memorize the two lock types and their exact names. - Understand that locks are inherited but can be overridden? Actually, they cannot be overridden; a child lock adds restrictions but cannot remove restrictions from a parent lock. - Know that locks are not a security boundary; they are a governance tool.
Azure Resource Locks are a governance tool that prevent accidental deletion or modification of resources.
There are two lock types: CanNotDelete (prevents deletion only) and ReadOnly (prevents all write operations).
Locks are inherited from parent scopes (subscription, resource group) to child resources.
Locks are evaluated after Azure RBAC; they can block even the resource owner.
Managing locks requires `Microsoft.Authorization/locks/write` permission (Owner or User Access Administrator).
Locks only affect control plane operations, not data plane operations.
A CanNotDelete lock on a resource group does NOT prevent deletion of individual resources within it.
Locks cannot be used to grant permissions; they only restrict.
Locks are commonly used in production environments to protect critical resources.
You can apply locks via Azure Portal, CLI, PowerShell, or REST API.
These come up on the exam all the time. Here's how to tell them apart.
Azure Resource Locks
Restricts operations on resources regardless of user permissions.
Two types: CanNotDelete and ReadOnly.
Applied at subscription, resource group, or resource scope.
Requires Microsoft.Authorization/locks/write to manage.
Does not grant access; only denies specific operations.
Azure RBAC
Controls access based on role assignments.
Multiple built-in roles (Owner, Contributor, Reader, etc.).
Applied at management group, subscription, resource group, or resource scope.
Requires Microsoft.Authorization/roleAssignments/write to manage.
Can grant or deny access to perform actions.
CanNotDelete Lock
Prevents deletion of the resource.
Allows modifications (e.g., change tags, update configuration).
Useful for preventing accidental deletion while allowing updates.
Does not block read operations.
Less restrictive than ReadOnly.
ReadOnly Lock
Prevents any write operations, including deletion and modification.
Allows read operations only.
Useful for making a resource immutable (e.g., for compliance).
Does not block read operations.
More restrictive than CanNotDelete.
Mistake
Resource locks are a form of Azure RBAC.
Correct
Locks are separate from RBAC. RBAC controls who can perform actions; locks control which actions are allowed. Locks are evaluated after RBAC and can block even authorized users.
Mistake
A ReadOnly lock prevents all read operations on the resource.
Correct
A ReadOnly lock prevents write operations (including delete) but does not prevent read operations. For example, you can still view the resource properties in the portal.
Mistake
Locks apply to data plane operations, like reading or writing data inside a storage account.
Correct
Locks only apply to control plane operations (management operations via Azure Resource Manager). Data plane operations (e.g., reading blobs, writing to a database) are not affected.
Mistake
Any user with the Contributor role can remove a lock.
Correct
Removing a lock requires `Microsoft.Authorization/locks/write` permission. The built-in roles with this permission are Owner and User Access Administrator. Contributor does not have this permission.
Mistake
A CanNotDelete lock on a resource group prevents deletion of all resources within that group.
Correct
A CanNotDelete lock on a resource group only prevents deletion of the resource group itself. Individual resources inside the group can still be deleted unless they have their own lock. To prevent deletion of child resources, apply the lock at a lower scope or use Azure Policy.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
CanNotDelete lock prevents deletion of the resource but allows all other operations, including modifications. ReadOnly lock prevents any write operations (including deletion and modifications) but allows read operations. Choose CanNotDelete when you want to protect against accidental deletion but still allow updates. Choose ReadOnly when you need the resource to be immutable, such as for compliance or security logging.
No, a user with Owner role cannot bypass a lock. The lock blocks the operation regardless of the user's role. The only way to perform the blocked operation is to first remove the lock, which requires `Microsoft.Authorization/locks/write` permission (which Owner has). So an Owner can remove the lock and then perform the operation, but they cannot perform the operation while the lock is in place.
No, resource locks only apply to control plane operations (management operations via Azure Resource Manager). Data plane operations (e.g., reading/writing data in a storage account, querying a SQL database) are not affected. For example, a ReadOnly lock on a storage account does not prevent you from uploading blobs.
All resources within that resource group inherit the ReadOnly lock. This means you cannot modify or delete any resource in the group, nor can you delete the resource group itself. You can still view the resources. This is useful for protecting an entire environment, but be careful because it also prevents updates that might be needed.
No, you can only apply one lock at a time on a given scope. However, you can have locks at different scopes that combine. For example, a resource group might have a ReadOnly lock, and a specific resource within it might have a CanNotDelete lock. The effective restriction is the most restrictive combination: ReadOnly from the parent prevents modifications, so the CanNotDelete on the child is redundant but does not add more restriction.
To remove a lock, you need `Microsoft.Authorization/locks/write` permission. You can remove it via Azure Portal (under Locks blade), Azure CLI (`az lock delete`), PowerShell (`Remove-AzResourceLock`), or REST API. After removal, the resource is no longer protected by that lock.
Yes, resource locks are a free feature in Azure. There is no additional cost for applying locks. However, they are a management feature and do not incur charges.
You've just covered Azure Resource Locks: ReadOnly and Delete — now see how well it sticks with free SC-900 practice questions. Full explanations included, no account needed.
Done with this chapter?