AZ-104 Manage Azure Identities and Governance Practice Question
A ReadOnly lock is applied to RG-App. Which two requested changes will fail because of the lock? Select two.
⚠ Common exam trap
Test-takers frequently confuse a ReadOnly lock with a 'read-only' permission on the resource group itself, forgetting that read operations like listing resources or viewing tags are still allowed, while any write operation (including resize or delete) is blocked.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Resize a virtual machine to a larger SKU.
A ReadOnly lock on a resource group prevents any operations that modify existing resources or create/delete resources within that group. Resizing a VM to a larger SKU requires a write operation to the VM resource (specifically, updating the hardware profile), which is blocked by the lock. Deleting an unused public IP address is also a write operation (delete), which is blocked. Read operations, such as listing resources or viewing tags, are allowed.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Resize a virtual machine to a larger SKU.
Why this is correct
Resizing a virtual machine to a larger SKU is a management-plane update that issues a PUT/PATCH to the Microsoft.Compute/virtualMachines resource, changing the vmSize property. The ReadOnly lock denies any change to resource configuration, so even if the machine remains online, the resize call fails with a conflict or forbidden error. This shows that the lock blocks write operations on the VM itself, not just destructive deletions.
- ✗
List the resources currently in the resource group.
Why it's wrong here
Listing the resources in the resource group is a read operation that executes a GET against the Azure Resource Manager API, enumerating the existing resource IDs, types, and names. Since the ReadOnly lock only blocks create, update, and delete requests, this inventory operation is still fully permitted. It lets you inspect exactly what is protected without altering the group or its contents, so it is not a blocked change.
When this WOULD be correct
If the question asked which operations would fail under a Delete lock (which prevents deletions and modifications), listing resources would still succeed, so it would not be correct. However, if the lock were a CanNotDelete lock, deleting resources would fail, but listing would still work. This option would never be correct for a lock that blocks operations.
- ✓
Delete an unused public IP address.
Why this is correct
Deleting an unused public IP address invokes the Microsoft.Network/publicIPAddresses/delete operation, which removes the resource entirely. A ReadOnly lock on the resource group prevents that delete action, no matter how idle or unattached the IP address might appear, because the lock is scoped to all resources in the group and applies to every user and role. This directly contrasts with read actions, which are unaffected, because delete is a state-changing operation.
- ✗
Read the current tag values on the resource group.
Why it's wrong here
Reading the current tag values on the resource group uses a GET request on the group's metadata, which retrieves the key/value pairs without changing them. A ReadOnly lock prevents PUT, PATCH, DELETE, and other state-changing actions, but it specifically allows GET requests that merely read metadata. Therefore, you can view the tags and still remain compliant with the lock's restriction.
When this WOULD be correct
If the lock were a CanNotDelete lock, reading tags would still be allowed. However, if the question asked which operations are blocked by a ReadOnly lock, reading tags would be incorrect. A scenario where reading tags fails would require a custom role that denies read access, not a lock.
- ✗
View the VM power state in the portal.
Why it's wrong here
Viewing the VM power state in the portal triggers an instance view GET, which returns details such as the running, stopped, or deallocated status from the VM's instanceView. This is fundamentally a read operation and does not modify any property or execution state of the virtual machine, so a ReadOnly lock has no effect on it. The lock applies to write, delete, and start/stop-like actions, not to observing current status.
When this WOULD be correct
If the question asked about a CanNotDelete lock applied to the resource group, then viewing the VM power state would still be allowed (not blocked), so it would be a wrong answer. However, if the lock were a Delete lock (custom lock that blocks delete but allows modifications), viewing power state would still be allowed. This option is never correct for a lock that blocks read operations.
Option-by-option analysis
Why each answer is right or wrong
Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The AZ-104 exam frequently reuses these exact scenarios with slightly different constraints.
✓Resize a virtual machine to a larger SKU.Correct answer▾
Why this is correct
Resizing a virtual machine to a larger SKU is a management-plane update that issues a PUT/PATCH to the Microsoft.Compute/virtualMachines resource, changing the vmSize property. The ReadOnly lock denies any change to resource configuration, so even if the machine remains online, the resize call fails with a conflict or forbidden error. This shows that the lock blocks write operations on the VM itself, not just destructive deletions.
✗List the resources currently in the resource group.Wrong answer — click to see why▾
Why this is wrong here
A ReadOnly lock allows read operations but prevents modifications. Listing resources is a read operation, so it is not blocked by the lock.
★ When this WOULD be the correct answer
If the question asked which operations would fail under a Delete lock (which prevents deletions and modifications), listing resources would still succeed, so it would not be correct. However, if the lock were a CanNotDelete lock, deleting resources would fail, but listing would still work. This option would never be correct for a lock that blocks operations.
Why candidates choose this
Candidates may confuse 'read' operations with 'write' operations, thinking that any action on resources is blocked by a ReadOnly lock, or they may misremember the effects of different lock types.
✗Read the current tag values on the resource group.Wrong answer — click to see why▾
Why this is wrong here
A ReadOnly lock only prevents modifications, not read operations. Reading tag values is a read operation, so it is not blocked by the lock.
★ When this WOULD be the correct answer
If the lock were a CanNotDelete lock, reading tags would still be allowed. However, if the question asked which operations are blocked by a ReadOnly lock, reading tags would be incorrect. A scenario where reading tags fails would require a custom role that denies read access, not a lock.
Why candidates choose this
Candidates may confuse ReadOnly lock with a deny read permission, or think that any lock restricts all operations including reads.
✗View the VM power state in the portal.Wrong answer — click to see why▾
Why this is wrong here
A ReadOnly lock prevents any modification or deletion of resources, but viewing the VM power state in the portal is a read operation and is not blocked by the lock.
★ When this WOULD be the correct answer
If the question asked about a CanNotDelete lock applied to the resource group, then viewing the VM power state would still be allowed (not blocked), so it would be a wrong answer. However, if the lock were a Delete lock (custom lock that blocks delete but allows modifications), viewing power state would still be allowed. This option is never correct for a lock that blocks read operations.
Why candidates choose this
Candidates may confuse 'viewing' with 'modifying' or think that any operation on a locked resource is blocked, not realizing that read operations are permitted under ReadOnly locks.
Analysis generated from the official AZ-104blueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”
Go deeper
Related to this question
Learn chapter
Managed Identities for Azure Resources
Key term
Resource group
A logical container in Microsoft Azure that holds related resources for an application or solution, enabling unified management, security, and billing.
Key term
IP address
An IP address is a unique numerical label assigned to each device connected to a computer network that uses the Internet Protocol for communication.
About these practice questions
One of 1,049 original AZ-104 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This AZ-104 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the AZ-104 exam.