AZ-900 Describe Azure management and governance Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Azure RBAC permissions

  Why it's wrong here

  Azure RBAC permissions control which identities (users, groups, or service principals) can perform actions on resources, such as creating, reading, updating, or deleting VMs. RBAC says nothing about the characteristics of the resource being created—it grants or denies the ability to act, not whether the resulting configuration is acceptable. Even a user with full Contributor permission could provision a non-compliant VM size unless Azure Policy explicitly rejects it, so RBAC is fundamentally about authorization, not configuration governance.

• ✗

  Azure Subscription quotas

  Why it's wrong here

  Azure Subscription quotas define the maximum number or aggregate capacity of resources you can provision (for example, 200 VMs per region). They do not inspect the actual configuration attributes of each resource, such as whether the VM size is a prohibited SKU or whether a storage account uses an unapproved redundancy type. Quotas are administrative ceilings for resource counts and total compute/storage capacity, not conditional checks on allowed property values, so they cannot enforce the kind of 'deny if non-compliant configuration' behavior that Azure Policy has.

• ✓

  Azure Policy definitions

  Why this is correct

  Azure Policy definitions are the correct mechanism because they are explicit rules that evaluate resource properties during and after deployment. A policy definition includes a condition (for example, 'VM SKU is one of the allowed values') and an effect such as Deny, Audit, or Modify, and it can be assigned to a management group, subscription, or resource group to enforce required configurations. When a user attempts to create a VM with a size not in the allowed list, the policy blocks the deployment, which is exactly the scenario described in the question.

• ✗

  Azure Resource Locks

  Why it's wrong here

  Azure Resource Locks are designed to prevent accidental deletion or modification of a resource by applying a CanNotDelete or ReadOnly lock at the management-plane level. They do not evaluate whether the resource's configuration complies with an organizational standard; a lock merely stops any user or process from deleting or changing the resource, regardless of whether the resource uses an allowed VM size or storage type. Thus locks enforce operational protection, not configuration compliance, making them the wrong answer here.

Go deeper

Related to this question