Azure Policy vs RBAC: who can do what, versus what's allowed.
Two governance tools people constantly confuse because both can say "no." One decides whether you are allowed to touch a resource; the other decides whether the resource you touched is allowed to exist. Get the split right and the whole subject clicks.
New to cloud? CAMPUX is a free, build-first course. Start here →
RBAC controls who can do what — it grants a user, group, or service principal permission to perform actions on resources. Azure Policy controls what is allowed to exist and how resources must be configured — it checks a resource against compliance rules and can block a non-compliant change no matter who made it. They are complementary, not alternatives: RBAC grants the permission, Policy constrains the result. That one distinction resolves most of the confusion, and the part the other guides skip is that both checks run on the same request, so a change only succeeds when RBAC says you may and Policy says the outcome is compliant.
The one-line split, said three ways
If you remember nothing else: RBAC is about access, Policy is about compliance. RBAC answers "are you allowed to do this?" Policy answers "is the thing you just did allowed to exist?" A person can be fully authorized and still be stopped, because those are two separate questions asked at the same moment.
Concretely: RBAC is what lets you create a virtual machine at all — without the right role assignment, the deployment never starts. Policy is what can still reject that VM after RBAC waved it through, if it is the wrong size, in a banned region, or missing a required tag. Neither one is a substitute for the other. Turn off RBAC and nobody can build anything; turn off Policy and the right people can build the wrong things.
Microsoft's documentation is unusually direct on this point. Azure Policy, it says, "ensures that resource state is compliant to your business rules without concern for who made the change or who has permission to make a change." RBAC, by contrast, "focuses on managing user actions at different scopes." Same platform, two different jobs.
Azure Policy vs RBAC, side by side
| Dimension | RBAC | Azure Policy |
|---|---|---|
| What it controls | Access — which identities can perform which actions on which resources. | Compliance — what resources are allowed to exist and how they must be configured. |
| Question it answers | "Are you allowed to do this?" | "Is the result allowed to exist?" |
| Enforced on | The identity making the request (user, group, service principal, managed identity), via a role assignment at a scope. | The properties of the resource, evaluated against rules at a scope — regardless of who made the change. |
| Example | Grant the Contributor role on a resource group so a teammate can create and manage VMs in it. | Allow only approved VM SKUs, restrict resources to West Europe, or require a cost-center tag on every resource. |
| When it blocks you | You lack a role granting the action — the request is denied for missing permission. | You have permission, but the resulting resource violates a rule — a Deny effect blocks the create or update. |
Read the last row twice. It is the whole article. RBAC blocks you for who you are; Policy blocks you for what you made. Behaviour in that table is confirmed against Microsoft Learn's Azure Policy overview and its Azure Policy–vs–RBAC section — treat any specific role or effect name as something to verify against the current docs, but the direction is settled.
Why you need both, and how they interact
Here is the interaction that trips up almost everyone new to Azure governance. You have the Contributor role on a subscription. You run az vm create for a Standard_M128 monster in a region your company doesn't operate in. RBAC checks your role: you're a Contributor, you're allowed to create VMs, green light. Then Policy checks the resource: the SKU isn't on the allowed list and the region is off-limits. Red light. The deployment fails — not because you lacked permission, but because the thing you asked for isn't allowed to exist.
That is the design working as intended. Microsoft states it plainly: "Even if an individual has access to perform an action, if the result is a non-compliant resource, Azure Policy still blocks the create or update." The two systems form an AND gate. RBAC grants the door key; Policy inspects what you carry through the door. You need to pass both.
RBAC blocks you for who you are. Policy blocks you for what you made.
This is also why "just give them less access" and "just write a policy" are not interchangeable fixes. If the problem is that the wrong people can act, tighten RBAC — Policy will not solve an access problem. If the problem is that the right people keep creating non-standard resources, write Policy — locking down RBAC any further would just stop them working. The combination, in Microsoft's words, "provides full scope control in Azure": one covers who, the other covers what.
The single most common mistake is thinking Azure Policy is an access-control tool. It is not. Policy does not grant or revoke anyone's permissions and it is not how you decide who can log in or hold a role — that is RBAC's entire job. Policy evaluates resource state and can block certain non-compliant actions. Newer identity-aware rules can even block an action based on who is requesting it, which blurs the line at the edges, but the mental model holds: if you want to manage access, reach for RBAC; if you want to manage what gets built and how, reach for Policy.
Where each one actually lives in your day
RBAC shows up every time you onboard a person or a pipeline. Someone needs to deploy to a resource group, so you assign a role at that scope. A service principal needs to read secrets, so it gets a narrowly scoped role on the vault. If you're still fuzzy on which built-in role does what, the practical breakdown of Owner vs Contributor vs Reader is the place to start — those three cover most real assignments.
Policy shows up when you're trying to keep an environment consistent across dozens of people who all have legitimate access. You assign policies at a scope — commonly a subscription or, for organization-wide rules, higher up the hierarchy — and every resource under it inherits them. Because both RBAC and Policy attach to the Azure scope hierarchy, understanding management groups pays off twice: it's where broad role assignments and broad policy assignments both tend to live. And Policy is not only Deny — the Policy effects (Audit, Deny, Modify, DeployIfNotExists, and friends) are what let it merely report drift, auto-fix a missing tag, or hard-block a bad deployment, depending on how aggressive you want to be.
One footnote that surprises people: managing Policy is itself gated by RBAC. Creating definitions and assignments needs a role like Resource Policy Contributor, and wiring up a DeployIfNotExists or Modify policy's managed identity needs User Access Administrator. So even the governance layer that isn't about access still depends on the access layer to operate. They're built to lean on each other.
The takeaway
Stop thinking of Azure Policy and RBAC as two answers to the same question. RBAC answers "who is allowed to act." Policy answers "what is allowed to result." Every meaningful change in Azure runs both checks, and it only goes through when both agree — permission from RBAC, compliance from Policy. Learn them as a pair. The teams that get governance right aren't choosing between them; they're using RBAC to decide who gets in and Policy to decide what those people are allowed to build once they're inside.
Questions people also ask
What is the difference between Azure Policy and RBAC?
RBAC controls who can perform which actions on resources — it grants or denies a user, group, or service principal the permission to do something. Azure Policy controls what is allowed to exist and how resources must be configured — it evaluates the properties of a resource against business rules and can block a non-compliant create or update regardless of who made it. RBAC is about access; Policy is about compliance. They solve different problems and are meant to run together.
Does Azure Policy override RBAC?
Not exactly — they operate on different questions, so neither overrides the other, but Policy can stop an action that RBAC allowed. RBAC decides whether you are permitted to make a change; Policy decides whether the resulting resource is compliant. Microsoft's own guidance is blunt about it: even if an individual has access to perform an action, if the result is a non-compliant resource, Azure Policy still blocks the create or update. You need both permissions and compliance for the change to succeed.
Can Azure Policy control access?
Not in the way RBAC does. Azure Policy does not grant or revoke a user's permissions, and it is not the tool for deciding who can log in or who holds which role. It evaluates resource state and can block certain create, update, or delete actions when the result would be non-compliant — and newer identity-aware rules can even block an action based on who is making the request. But if your goal is to manage user access to resources, RBAC is the correct tool; Policy is a governance layer, not an access-control system.
What is Azure Policy used for?
Azure Policy is used to enforce organizational standards and assess compliance at scale. Typical uses are restricting resources to approved regions, enforcing required tags, allowing only certain VM or storage SKUs, requiring diagnostic logs to a Log Analytics workspace, and auditing existing resources for drift. It works through effects such as Deny, Audit, Modify, and DeployIfNotExists, and reports overall compliance in a dashboard so you can see what does not meet the rules.
Do you need both Azure Policy and RBAC?
Yes, for any environment beyond a personal sandbox. RBAC without Policy means the right people can build anything, including resources in the wrong region or the wrong size. Policy without RBAC means the rules are enforced but everyone has the same access. Microsoft describes the combination as giving full scope control: RBAC decides who can act, Policy decides what the result is allowed to be. Used together they cover both halves of governance.