The platform team wants to block deployment of Azure resources in any region except East US and West US. What should they configure?
Azure Policy is designed to enforce configuration rules such as approved regions. An allowed locations policy can deny deployments outside East US and West US, which directly matches the requirement. This is governance, not authorization, so RBAC is not the right tool for controlling where resources can be created.
Why this answer
Azure Policy's 'allowed locations' built-in policy definition enables you to restrict the regions where resources can be deployed. By assigning this policy at a management group or subscription scope with a parameter list containing only 'East US' and 'West US', any attempt to deploy resources in other regions will be denied at the Azure Resource Manager level, effectively blocking non-compliant deployments.
Exam trap
The trap here is that candidates often confuse Azure Policy with Azure RBAC roles or resource locks, mistakenly thinking that a Reader role or a CanNotDelete lock can restrict where resources can be deployed, when in fact only Azure Policy can enforce such location-based governance rules.
How to eliminate wrong answers
Option B is wrong because a Reader role assignment grants read-only access to resources but does not enforce any deployment restrictions or location controls. Option C is wrong because a CanNotDelete lock prevents deletion of resources but does not block creation or modification of resources in disallowed regions. Option D is wrong because a tag requirement enforced only by resource group naming is not a native Azure governance feature; tags are metadata and do not prevent deployment in unauthorized regions.