In Azure, resource locks are a critical governance tool designed to prevent the accidental deletion or modification of mission-critical resources. While Role-Based Access Control (RBAC) manages who can perform actions, resource locks apply a restriction to the resource itself, overriding permission…In Azure, resource locks are a critical governance tool designed to prevent the accidental deletion or modification of mission-critical resources. While Role-Based Access Control (RBAC) manages who can perform actions, resource locks apply a restriction to the resource itself, overriding permissions. Even a user with the 'Owner' role cannot perform a restricted action without first removing the lock, ensuring that destructive actions are always intentional.
There are two types of locks you can configure:
1. **CanNotDelete**: This allows authorized users to read and modify a resource, but strictly prohibits deletion. This is ideal for active production resources that require updates but must not be removed.
2. **ReadOnly**: This is more restrictive. It permits users only to read the resource; they cannot delete it or make any changes to it. This acts similarly to restricting all users to the 'Reader' role for that specific resource.
A crucial concept in configuration is **inheritance**. When you apply a lock at a parent scope—such as a Subscription or a Resource Group—all resources contained within that scope inherit the lock. Furthermore, any new resources added to that scope in the future will also inherit the lock automatically. Administrators must be cautious with 'ReadOnly' locks at the parent level, as they can block unexpected operations; for example, restarting a Virtual Machine requires a write action, which a 'ReadOnly' lock would prevent.
Locks can be managed via the Azure Portal, Azure CLI, PowerShell, or ARM templates. Only users with `Microsoft.Authorization/locks/*` permissions (typically Owners and User Access Administrators) can create or delete these locks.
Configure Resource Locks
Introduction to Resource Locks As an Azure Administrator, ensuring the stability and availability of your environment is paramount. One of the simplest yet most powerful tools for governance is the Resource Lock. Resource locks prevent accidental deletion or modification of Azure resources. While Role-Based Access Control (RBAC) manages who can perform actions, Resource Locks apply restrictions to the resources themselves, regardless of the user's permissions.
Why is it Important? Human error is inevitable. Even an administrator with the highest privileges (like a Global Administrator or Owner) might accidentally delete a critical production Resource Group or modify a setting on a virtual network peering. Resource locks act as a safety catch, ensuring that critical infrastructure remains untouched or undeleted unless the lock is explicitly removed.
Types of Locks There are two primary types of enforcement levels you need to know for the AZ-104 exam: 1. CanNotDelete (Delete): Authorized users can read and modify a resource, but they cannot delete the resource. This is often used for production resources where configuration changes are allowed, but removal would cause an outage. 2. ReadOnly: Authorized users can read a resource, but they cannot delete or update the resource. Applying this lock is similar to restricting all authorized users to the permissions granted by the Reader role.
How Inheritance Works When you apply a lock at a parent scope, all resources within that scope inherit the same lock. The most restrictive lock in the inheritance chain takes precedence. Scope: Subscription Level -> Resource Group Level -> Resource Level. Example: If you apply a ReadOnly lock to a Resource Group, every Virtual Machine, Storage Account, and Network Interface within that group becomes read-only. You cannot unlock a single resource inside that group; you must remove the lock from the Resource Group first.
Considerations and System Operations While locks primarily affect the management plane (control plane), they can sometimes impact data plane operations if those operations rely on control plane tokens. The Storage Account Scenario: This is a critical concept. If you place a ReadOnly lock on a Storage Account, users cannot list the access keys (because listing keys is a Write operation on the control plane). Without access keys, clients cannot access the data blobs or files unless they use Entra ID authentication.
Exam Tips: Answering Questions on Configure resource locks When facing AZ-104 exam questions regarding resource locks, apply the following logic:
1. Identify the Restriction: If the scenario states an administrator can modify a resource but fails to remove it, look for a CanNotDelete lock. If they fail to change a tag or update a setting, look for a ReadOnly lock.
2. Remember RBAC vs. Locks: A frequent trick question involves a user with the Owner role who cannot delete a resource. The answer is usually that a lock is present. Locks override RBAC permissions. To delete the resource, the Owner must first remove the lock.
3. Check Inheritance: If a question asks why a specific VM cannot be deleted and there is no lock on the VM itself, look at the Resource Group or Subscription level. The lock is likely inherited.
4. Who can manage locks? Only Owners and User Access Administrators can create or delete management locks. Contributors cannot remove locks by default.
5. Watch for 'Unexpected' Side Effects: Be prepared for scenarios involving Azure App Service or Storage Accounts. For example, a ReadOnly lock might prevent an App Service from restarting (since changing the state is a write operation) or prevent Visual Studio from deploying code to it.