Technical Lab: Configure resource locks
Questions
Question 1 — Multiple Choice
An administrator applied a ReadOnly lock on a storage account in Azure. Subsequently, the development team reported that they cannot list the storage account access keys, even though they have the Storage Account Contributor role assigned.
What is the correct technical explanation for this behavior?
A) The ReadOnly lock prevents any operation that requires authentication via Microsoft Entra ID, including key listing.
B) Key listing is considered a write operation by Azure Resource Manager, as it returns sensitive credentials, being blocked by the ReadOnly lock.
C) The ReadOnly lock can only be removed by an Owner, and the Storage Account Contributor role doesn't have permission to bypass it.
D) The ReadOnly lock blocks write operations at the data level, and key listing is classified as a data operation.
Question 2 — Technical Scenario
An engineer needs to delete a resource group called rg-producao. When attempting deletion through the portal, they receive an authorization error, even though they are Owner of the subscription. They check the resource group and find the following configuration:
Lock name : lock-rg-producao
Lock type : Delete
Scope : rg-producao (resource group)
They decide to remove the lock to proceed. Which statement correctly describes what happens when removing this lock?
A) Removing the resource group lock automatically removes all locks applied individually to the resources contained within it.
B) Removing the resource group lock does not affect locks applied directly to child resources; they need to be removed separately.
C) Since the lock is of Delete type, removal requires approval from a second Owner in the subscription.
D) Resource group level locks can only be removed via Azure CLI or PowerShell, not through the portal.
Question 3 — True or False
A ReadOnly lock applied to a resource group prevents new resources from being created within it, even if the user has the Owner role on the subscription.
True or False?
Question 4 — Technical Scenario
An operations team applied a Delete lock on a critical Virtual Machine. Days later, an administrator needs to resize the VM to a larger SKU. They attempt the operation through the portal and receive the following error:
The scope '/subscriptions/.../virtualMachines/vm-prod-01'
is locked for 'Delete' operations.
The administrator considers the following actions:
A) Remove the lock, perform the resize, and reapply the lock after completion.
B) Change the lock type from Delete to ReadOnly before performing the resize.
C) Perform the resize without changes, as the displayed error is a false positive caused by lock propagation latency.
D) Request the security team to temporarily elevate their role to Global Administrator in Microsoft Entra ID.
What is the correct approach?
Question 5 — Multiple Choice
An organization needs to ensure that no resource in a critical resource group is accidentally deleted or modified, but still needs to allow read and monitoring operations to function normally. Which combination of lock and scope meets this requirement with the least administrative effort?
A) Apply a Delete lock to each resource individually within the resource group.
B) Apply a ReadOnly lock to the resource group, as it inherits to all child resources and blocks deletions and modifications.
C) Apply a Delete lock to the resource group, as resource group locks propagate to all contained resources.
D) Apply a ReadOnly lock to each resource individually, as resource group locks are not automatically inherited.
Answer Key and Explanations
Answer Key — Question 1
Answer: B
The listKeys operation on a storage account is classified by Azure Resource Manager as a write action (POST), not read, because it returns secrets that can be used to modify data. The ReadOnly lock blocks all operations that are not pure reads (GET), which includes any POST or PUT action. Therefore, even a user with sufficient permissions cannot execute listKeys while the lock is active.
The conceptual error represented by the distractors is confusing the ReadOnly scope with authentication (A), with role permissions (C), or with data plane operations (D). The lock acts on the management plane via ARM and blocks based on the HTTP semantics of the operation, not by the type of data returned or the data plane.
Answer Key — Question 2
Answer: B
Locks in Azure are not removed in cascade. When a lock is applied directly to a child resource, it is independent of the parent resource group lock. Removing the resource group lock only releases the restriction inherited by that scope; resources that have their own locks remain protected.
The distractors explore common misconceptions: the idea that removal is cascading (A), that there is a dual approval flow (C), or that the portal is incapable of managing locks (D). In practice, locks can be created and removed through the portal, CLI, PowerShell, and ARM templates, without interface restrictions.
Answer Key — Question 3
Answer: True
A ReadOnly lock on a resource group prevents any operation that is not read, including creating new resources. Creating a resource is a write operation (PUT) in ARM. Locks override RBAC permissions: even an Owner cannot bypass a lock without first removing it. This is intentional behavior to protect critical environments against accidental changes, including from privileged users.
The non-obvious point here is that the Owner role, despite being the most privileged in Azure RBAC, does not take precedence over resource locks. Locks are a control mechanism distinct from RBAC.
Answer Key — Question 4
Answer: A
A Delete lock blocks exclusively deletion operations. The error displayed in the scenario is incorrect in the message displayed by the portal in certain situations or was misinterpreted by the administrator, as resize is a write operation (PATCH/PUT), not deletion. However, if the error is genuine and is blocking the resize, the only valid action is to remove the lock, execute the operation, and reapply it.
Alternative B is incorrect because changing a lock to ReadOnly would make the situation worse, also blocking write operations. Alternative C is incorrect because locks do not generate false positives due to latency. Alternative D is irrelevant, as the Global Administrator role in Microsoft Entra ID does not grant resource management permissions in Azure Resource Manager.
Answer Key — Question 5
Answer: C
Locks applied to a resource group are inherited by all resources contained within it. Applying a Delete lock to the resource group is sufficient to prevent accidental deletions of all child resources, with a single lock, meeting the requirement of least administrative effort. The Delete lock does not prevent reads or modifications, preserving monitoring and configuration operations.
Alternative B is incorrect because a ReadOnly would also block modifications, which contradicts the requirement to allow normal operations beyond reading. Alternatives A and D ignore the lock inheritance mechanism, proposing an individual resource management approach that unnecessarily increases operational complexity.