A subscription already grants Contributor to an application team. The organization wants to prevent deployments in unsupported Azure regions and ensure every new resource has an Environment tag. Which two controls should be implemented with Azure Policy rather than RBAC? Select two.
Trap 1: Create a custom RBAC role that blocks resources deployed outside…
RBAC authorizes actions, but it cannot conditionally deny based on a resource property such as region.
Trap 2: Add a CanNotDelete lock to every resource group.
Locks prevent deletion or writes, but they do not validate required tags or allowed locations.
Trap 3: Grant User Access Administrator to the deployment team.
This only changes authorization capabilities and does not enforce deployment compliance rules.
- A
Assign an allowed-locations policy at the management group or subscription scope.
Location is a resource property that policy can evaluate and deny, while RBAC cannot inspect deployment metadata like region.
- B
Create a custom RBAC role that blocks resources deployed outside approved regions.
Why wrong: RBAC authorizes actions, but it cannot conditionally deny based on a resource property such as region.
- C
Assign a policy that enforces the Environment tag on new resources.
Tag enforcement is a classic Azure Policy use case, especially with deny, append, or modify effects.
- D
Add a CanNotDelete lock to every resource group.
Why wrong: Locks prevent deletion or writes, but they do not validate required tags or allowed locations.
- E
Grant User Access Administrator to the deployment team.
Why wrong: This only changes authorization capabilities and does not enforce deployment compliance rules.