AZ-104 Practice Question 11: Policy Deny Versus RBAC
Microsoft Azure Administrator Associate (AZ-104) · Test 2 · question 1 of 10
An engineer who holds the Contributor role on the resource group RG-Apps tries to deploy a virtual machine into the South India region. The deployment fails immediately, before any resource appears in the portal, with the error code RequestDisallowedByPolicy and HTTP status 403.
The engineer opens a ticket asking to be made an Owner of the subscription. What is actually happening, and what will resolve it?
Show answer and explanation
Answer:
RequestDisallowedByPolicy is the signature of the Azure Policy deny effect. For a Resource Manager mode definition, deny "prevents the request before being sent to the Resource Provider" and the request is returned as 403 (Forbidden). Policy evaluation is independent of Azure RBAC: it runs on every create or update request no matter who the caller is. The remedies are all on the policy side: deploy into a region the assignment permits, change the assignment's allowed-values parameter, or exclude/exempt the scope.
Option A is the wrong lever, and it is the most common wrong instinct. Contributor already grants Microsoft.Compute/virtualMachines/write; escalating to Owner adds only the ability to manage access, and an Owner is denied by the same policy. Elevating privileges to work around a governance control is also exactly what policy exists to prevent.
Option B does not match the error. A ReadOnly lock produces a different failure (ScopeLocked), and a lock blocks writes to existing resources and the group regardless of region, so the engineer would not be able to deploy anywhere in RG-Apps.
Option D confuses two different failures. An unregistered resource provider returns MissingSubscriptionRegistration / NoRegisteredProviderFound, and it has nothing to do with which regions are permitted.
Reference: Azure Policy definitions deny effect