AZ-104 Manage Azure Identities and Governance Practice Question
The platform team wants to block deployment of virtual machines that use any size except a small approved list. Operators already have Contributor access and should keep that access for other tasks. Which Azure control should the administrator use to enforce the size restriction?
⚠ Common exam trap
Many exam-takers confuse Azure Policy (which controls resource properties) with RBAC (which controls who can perform actions), leading them to incorrectly choose a custom RBAC role when the requirement is to restrict a specific configuration, not the action itself.
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
✓
Assign an Azure Policy with an allowed virtual machine size rule and the Deny effect at the subscription scope.
Azure Policy with the 'allowed virtual machine sizes' built-in policy and the Deny effect is the correct control because it enforces a deny action at the resource creation or update level, preventing any VM deployment that does not match the approved size list. This works independently of RBAC permissions, so operators retain their Contributor role for other tasks while the policy blocks non-compliant VM sizes. The policy is assigned at the subscription scope to cover all resource groups, ensuring consistent enforcement across the environment.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Assign an Azure Policy with an allowed virtual machine size rule and the Deny effect at the subscription scope.
Why this is correct
Azure Policy is designed to enforce configuration rules such as allowed regions or allowed VM sizes. The Deny effect blocks noncompliant deployments even when the user has Contributor permissions, because policy enforcement is separate from RBAC authorization.
- ✗
Create a custom RBAC role that excludes unsupported VM sizes from the Contributor role.
Why it's wrong here
RBAC role definitions authorize actions such as Microsoft.Compute/virtualMachines/write, but they cannot inspect the request body or evaluate properties like the selected SKU. A custom role cannot "exclude unsupported VM sizes" because size is a deployment parameter evaluated by Azure Policy, not an RBAC permission. Even with full Contributor equivalent write permissions, an RBAC-only approach will still allow an operator to deploy any VM SKU if no policy denies it.
When this WOULD be correct
This option would be correct if the question required restricting operators from deploying any VMs at all (e.g., deny the write action for VM resources) while still allowing other Contributor tasks. A custom RBAC role with explicit 'NotActions' for VM write permissions would achieve that.
- ✗
Apply a CanNotDelete lock to the resource group that contains the virtual machines.
Why it's wrong here
A CanNotDelete lock is an Azure management lock that protects resources from deletion, not from creation or update. It functions at the resource/management level and does not validate or constrain configuration values such as VM size during a PUT operation. Applying CanNotDelete to a resource group would block deleting the group and its resources, but it would do nothing to stop an administrator from deploying a VM with a non-approved SKU.
When this WOULD be correct
A CanNotDelete lock would be correct if the question asked: 'The administrator needs to prevent accidental deletion of a critical resource group containing production VMs, while still allowing operators to modify resources within it.'
- ✗
Assign Reader permissions to the operators and rely on Azure portal validation.
Why it's wrong here
Assigning Reader permission would revoke all write capabilities, so users could not deploy any virtual machine at all—far exceeding the intent of blocking only unsupported VM sizes. Relying on Azure portal validation is also not an enforceable control because it exists only in the portal UI; any call through Azure CLI, PowerShell, or the REST API can bypass portal warnings and submit a compliant deployment. The requirement is to actively deny disallowed SKUs, which requires an Azure Policy definition and assignment, not a restrictive RBAC role or a user-facing UI guard.
When this WOULD be correct
If the requirement was to prevent accidental modifications to existing VMs while allowing read access, and the operators only need to view resources, assigning Reader permissions would be correct.
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.
✓Assign an Azure Policy with an allowed virtual machine size rule and the Deny effect at the subscription scope.Correct answer▾
Why this is correct
Azure Policy is designed to enforce configuration rules such as allowed regions or allowed VM sizes. The Deny effect blocks noncompliant deployments even when the user has Contributor permissions, because policy enforcement is separate from RBAC authorization.
✗Create a custom RBAC role that excludes unsupported VM sizes from the Contributor role.Wrong answer — click to see why▾
Why this is wrong here
RBAC roles control permissions to perform actions, not resource configurations. A custom role cannot restrict specific VM sizes because RBAC does not evaluate resource properties like size; it only grants or denies actions such as 'Microsoft.Compute/virtualMachines/write'.
★ When this WOULD be the correct answer
This option would be correct if the question required restricting operators from deploying any VMs at all (e.g., deny the write action for VM resources) while still allowing other Contributor tasks. A custom RBAC role with explicit 'NotActions' for VM write permissions would achieve that.
Why candidates choose this
Candidates may think RBAC can filter by resource properties because they confuse Azure Policy (which evaluates resource configurations) with RBAC (which controls access). The similarity in names and the concept of 'restricting' leads to this misconception.
✗Apply a CanNotDelete lock to the resource group that contains the virtual machines.Wrong answer — click to see why▾
Why this is wrong here
A CanNotDelete lock prevents deletion of resources but does not restrict which VM sizes can be deployed. The question requires blocking deployment of non-approved VM sizes, which is a configuration enforcement, not a deletion prevention.
★ When this WOULD be the correct answer
A CanNotDelete lock would be correct if the question asked: 'The administrator needs to prevent accidental deletion of a critical resource group containing production VMs, while still allowing operators to modify resources within it.'
Why candidates choose this
Candidates may confuse resource locks with policy enforcement, thinking that locking a resource group can also prevent changes like deploying unauthorized VM sizes, when locks only affect deletion or modification of existing resources.
✗Assign Reader permissions to the operators and rely on Azure portal validation.Wrong answer — click to see why▾
Why this is wrong here
Reader permissions prevent operators from deploying any resources, and Azure portal validation only warns but does not block unsupported VM sizes. This does not enforce the restriction.
★ When this WOULD be the correct answer
If the requirement was to prevent accidental modifications to existing VMs while allowing read access, and the operators only need to view resources, assigning Reader permissions would be correct.
Why candidates choose this
Candidates may think that portal validation provides enforcement, but it is only a client-side check that can be bypassed via CLI or API.
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?”
Quick reference
Access Control Model Comparison
| Model | Acronym | Who Controls Access? | Best For |
|---|---|---|---|
| Discretionary Access Control | DAC | Resource owner | Small teams, file shares |
| Mandatory Access Control | MAC | System / security labels | Classified govt / military |
| Role-Based Access Control | RBAC | Administrator (via roles) | Enterprise environments |
| Attribute-Based Access Control | ABAC | Policy engine (user + resource attributes) | Fine-grained, dynamic policies |
| Rule-Based Access Control | RuBAC | System rules / ACLs | Firewall rules, network ACLs |
Go deeper
Related to this question
Learn chapter
Dynamic Membership Groups
Key term
RBAC
RBAC is a method of restricting network access based on the roles of individual users within an organization, where permissions are assigned to roles rather than to individuals directly.
Key term
Contributor role
The Contributor role is a built-in Azure role that grants full access to manage resources within a scope but does not allow granting access to other users.
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.