A new hire confuses Azure Policy with Azure role-based access control. Which contrast is accurate for AZ-900?
Select an answer to reveal the explanation.
Short Explanation
RBAC is the badge reader—who is allowed to do what. Policy is the building code—what a resource is allowed to look like. Both matter for city Azure estates, but they are not the same lever.
Full Explanation
Azure Policy and Azure role-based access control (RBAC) are complementary but distinct. Policy defines and evaluates rules about how resources should be configured—allowed locations, required tags, banned public IPs, and similar standards. RBAC controls who can perform which actions on which scopes (subscriptions, resource groups, resources). A new hire who mixes “who can act” with “what configuration is allowed” will pick the wrong control for city governance tickets.
Policy does not decide who can sign in, and RBAC does not decide which Azure regions exist as a platform fact. They are not the same service under two marketing names. Policy does not replace Microsoft Entra ID, and RBAC does not replace subscriptions as billing/management containers.
Exam caveat: a user can have Owner rights (RBAC) and still be blocked by a Deny policy on a noncompliant deployment—authorization to try an action is not permission to violate configuration guardrails. Operational check: pick a test resource group, grant a colleague Contributor, assign a Deny policy for a disallowed SKU or location, and show that RBAC lets them open Create while Policy still fails the noncompliant template—then remove the lab assignments.