You're a great admin... on-prem. Now, become a great admin in the cloud and prove it by passing the Microsoft Certified: Azure Administrator Associate exam!
Azure resource locks are a governance tool that adds a protective layer over your resources, overriding all user permissions to prevent accidental or unauthorized changes. There are two main lock types, each suited for different scenarios. The CanNotDelete lock (labeled Delete in the portal) allows authorized users to read and modify a resource but blocks its deletion. This is ideal for resources like production storage accounts or DNS zones that need to stay configurable but must not be removed. The ReadOnly lock is more restrictive, preventing both deletion and any updates to the resource, effectively granting everyone the permissions of the Reader role. This lock is best for resources where any change could break compliance or stability.
Locks can be applied at different scopes: subscription, resource group, or individual resource. A key concept is inheritance: a lock applied at a parent scope automatically applies to all existing and future child resources. When locks exist at multiple levels, the most restrictive lock in the chain takes precedence. For example, a Delete lock on a resource group prevents deletion of any resource inside it, even if a specific resource has no lock. Importantly, locks only restrict control plane operations—management actions performed through Azure Resource Manager, like scaling a VM or deleting a database. They do not block data plane operations, such as reading or writing data to a storage blob.
Applying locks, especially ReadOnly locks, can have significant operational impacts because they block all POST requests to Azure Resource Manager. This can disrupt common tasks like listing storage account keys, starting virtual machines, or running health checks on services like Application Gateway. Before applying a lock, evaluate whether it will interfere with required operations from Azure services like Backup or Site Recovery. Best practices include using CanNotDelete for resources that must remain configurable, reserving ReadOnly for strictly governed resources, and regularly reviewing locks to ensure they don't hinder operations. Locks should be combined with Azure RBAC and Policy for a layered defense strategy.
Locks can be managed through several tools. In the Azure Portal, you use the Locks blade on a resource, resource group, or subscription. For automation, you can use Azure CLI commands like az lock create or Azure PowerShell cmdlets like New-AzResourceLock. You can also define locks directly within ARM Templates for consistent deployment. To create or remove a lock, a user needs permissions like the Owner or User Access Administrator role. Once applied, the lock affects all users, providing a powerful safeguard independent of individual RBAC assignments.
Choosing the right lock depends on your governance needs. Use a CanNotDelete lock for resources that must stay online and configurable but are too critical to risk deletion, such as a core networking hub or a resource group containing production services. Apply a ReadOnly lock to resources that must be frozen in their current state, where any modification—including scaling, moving, or updating—would violate compliance or stability requirements. In complex environments, always consider lock inheritance and how locks interact with other governance tools to maintain both protection and operational integrity.
Resource locks are a critical security feature used to prevent the accidental deletion or modification of important Azure resources. Implementing them correctly is key to maintaining a stable and secure cloud environment.
There are two distinct lock types. The ReadOnly lock ensures the resource can only be read; no updates or deletions are permitted. The CanNotDelete lock allows users to modify the resource's configuration but blocks any attempt to delete it. Understanding this difference is the first step in applying the right control.
You can configure locks using multiple interfaces for flexibility. In the Azure Portal, navigate to the Locks section of your chosen resource, resource group, or subscription to add a new lock. For scripted or automated deployment, use PowerShell with the New-AzResourceLock cmdlet or Azure CLI with the az lock create command, specifying the resource, lock name, and lock type.
Applying locks has direct implications for management and security. They protect critical infrastructure from human error or malicious intent, ensuring essential services remain available. However, they also add complexity to resource management, as administrators must be aware of existing locks to avoid failed operations. From a security perspective, locks act as a final barrier, reducing the risk of configuration drift or catastrophic deletion, even for users with high-level permissions.
Follow best practices to use locks effectively. First, identify critical resources in your subscriptions, such as core networking components or production databases, and apply locks accordingly. Second, conduct a regular review of all locks to ensure they are still necessary and correctly scoped, removing any that obstruct legitimate operations. Finally, maintain clear documentation on why each lock was applied, which aids in troubleshooting and audit processes.
Resource locks are powerful administrative safeguards applied to subscriptions, resource groups, or individual resources. Their behavior is governed by rules of inheritance and scope, which are crucial to understand in multi-layered environments.
A core principle is lock inheritance: a lock applied at a parent scope (like a subscription) automatically flows down to all child resources within that scope. This inheritance is dynamic and applies to resources added after the lock is created. When multiple locks exist at different levels, the system enforces the most restrictive lock in the chain. This means a single ReadOnly lock on a child resource can override a less restrictive CanNotDelete lock on its parent, and a locked resource can prevent the deletion of its entire parent resource group.
A hierarchy showing how a CanNotDelete lock on a resource group inherits to child resources, and how a ReadOnly lock on a child resource takes precedence as the most restrictive lock in the chain.
The scope of locks is strictly limited to the control plane, which consists of all management operations sent to Azure Resource Manager. Locks do not affect the data plane, which involves direct interaction with the resource's data. For example, a ReadOnly lock on a storage account blocks you from updating its configuration but does not stop you from reading or writing blobs within it. Administrators must clearly distinguish between managing the resource itself and using the service it provides.
Applying locks, particularly ReadOnly locks, can introduce challenges because they block all POST requests. This can unexpectedly break administrative functions that rely on POST, such as listing storage account keys, accessing AKS cluster details in the portal, or checking the health of an Application Gateway. Furthermore, some Azure services use managed applications that create resource groups with system-level locks. These system locks cannot be modified directly; they can only be removed by deleting the parent managed service that created them, adding a layer of complexity to resource lifecycle management.
Prepare and test your skills
Prepare and test your skills
The CanNotDelete lock allows authorized users to read and modify a resource but blocks its deletion, while the ReadOnly lock prevents both deletion and any updates, effectively granting everyone the permissions of the Reader role. The ReadOnly lock is more restrictive and is best for resources where any change could break compliance or stability.
A lock applied at a parent scope automatically applies to all existing and future child resources through inheritance. When locks exist at multiple levels, the most restrictive lock in the chain takes precedence. For example, a Delete lock on a resource group prevents deletion of any resource inside it, even if a specific resource has no lock.
Resource locks only restrict control plane operations, which are management actions performed through Azure Resource Manager, such as scaling a VM or deleting a database. They do not block data plane operations, such as reading or writing data to a storage blob.
ReadOnly locks block all POST requests to Azure Resource Manager, which can disrupt common tasks like listing storage account keys, starting virtual machines, or running health checks on services like Application Gateway. Before applying a ReadOnly lock, evaluate whether it will interfere with required operations from Azure services like Backup or Site Recovery.
StudyCerts
StudyCerts