Azure RBAC vs Azure Policy Explained

Role-Based Access Control (RBAC) and Azure Policy are both governance tools, and both appear frequently on the exam, which is exactly why they get confused. The cleanest way to separate them: RBAC controls who can do what; Azure Policy controls what is allowed to exist and how it must be configured.

RBAC assigns permissions to users, groups, or applications at a specific scope — management group, subscription, resource group, or individual resource. A role like Virtual Machine Contributor grants specific actions (like starting or stopping VMs) without granting unrelated permissions like managing networking or billing. This is about identity and access — who is allowed to act.

Azure Policy defines rules about resource configuration and compliance, independent of who is trying to make the change. A policy might require every storage account to have encryption enabled, or deny deployment of resources outside an approved list of regions. This applies to everyone, including users who technically have RBAC permission to deploy — Policy can still block the deployment if it violates the rule.

A useful example that separates the two clearly: an engineer with full RBAC permissions to deploy virtual machines might still have their deployment blocked by Azure Policy if they try to deploy in a region the organisation hasn't approved. RBAC said they could act; Policy said the specific action wasn't compliant.

Policies can also be bundled into initiatives — a group of related policy definitions managed and assigned together, useful for enforcing a broader compliance standard made up of many individual rules.

The exam typically tests this by describing a governance requirement and asking which tool enforces it. If the requirement is about restricting who can perform an action, it points to RBAC. If it's about restricting what configurations are allowed regardless of who is deploying, it points to Azure Policy.