Azure Policy vs RBAC: Which Governance Tool?
Azure RBAC focuses on "who" can perform actions (user permissions), while Azure Policy focuses on "what" those resources can look like (compliance and properties). While RBAC manages access control to prevent unauthorized changes, Azure Policy enforces organizational standards to ensure resources remain compliant across your entire cloud environment.
What exactly is Azure RBAC?
Think of Role-Based Access Control (RBAC) as the security guard at the front door of your Azure environment. RBAC is all about the "Who." It defines who has access to specific resources and what actions they can perform. Whether you are assigning a built-in role like Owner, Contributor, or Reader, or creating a custom role, you are managing permissions.
In a real-world scenario, you wouldn't give every developer 'Owner' rights to your production subscription. Instead, you'd use RBAC to grant them 'Contributor' access to a specific resource group. This ensures they can manage the resources they need without accidentally deleting the entire subscription. For the AZ-900 exam, remember that RBAC is strictly about authorization and access management.
What is Azure Policy and why is it different?
If RBAC is the security guard, Azure Policy is the building code inspector. Policy doesn't care who you are; it cares "what" is being created. It focuses on resource properties and compliance. For example, if your company mandates that all resources must be deployed in the 'East US' region to reduce latency, you don't handle that with RBAC—you handle it with Azure Policy.
Azure Policy evaluates resources based on rules you define. If a user tries to deploy a resource that violates a policy, Azure can either 'Audit' the action (let it happen but flag it) or 'Deny' it entirely. This is critical for maintaining a consistent environment and preventing "cloud sprawl," where resources are created haphazardly across different regions and sizes.
Can you use RBAC to limit VM sizes?
This is a classic point of confusion for students. The short answer is: No. RBAC can stop a user from creating a Virtual Machine (VM) entirely, but it cannot control the *settings* of that VM. If you give a user the 'Contributor' role, they have the permission to create a VM. However, they could potentially spin up a massive, expensive G-series VM that drains your budget in hours.
To prevent this, you need Azure Policy. You can create a policy that restricts the allowed VM SKUs (sizes) for a specific subscription. Even if a user has the RBAC permissions to create a VM, the Azure Policy engine will step in and block the deployment if the chosen size isn't on the approved list. This distinction between 'permission to act' and 'restriction on properties' is a high-yield topic for your certification.
How do Azure Policy and RBAC work together?
In a professional enterprise setup, you don't choose one over the other; you use both to create a 'Secure Landing Zone.' RBAC provides the first layer of defense by ensuring only authorized personnel can touch your infrastructure. Azure Policy provides the second layer by ensuring that whatever those authorized personnel build adheres to your organization's security and cost standards.
Imagine a scenario where a Cloud Architect has the RBAC permission to create storage accounts. Without Policy, they might forget to enable 'Secure Transfer Required,' leaving data vulnerable. By layering Azure Policy on top, the system automatically enforces encryption and secure transfer settings regardless of the user's role. This synergy reduces human error and ensures a baseline of security across thousands of resources.
Which one should you prioritize for the AZ-900 exam?
For the AZ-900, you need to be able to distinguish between these two tools instantly when reading a scenario. If the question mentions 'permissions,' 'roles,' or 'access,' think RBAC. If it mentions 'compliance,' 'standards,' 'allowed locations,' or 'resource properties,' think Azure Policy. These nuances are where many candidates lose easy points.
To truly master this, you need to see these scenarios in action. We provide 1,000 expert-curated Microsoft Azure Fundamentals (AZ-900) practice questions at Cert Sensei, specifically designed to mimic the actual exam. With our detailed expert reasoning for every answer and domain-level analytics, you can pinpoint exactly whether you're struggling with Governance or Identity and Access Management before test day.
How do you choose the right tool in a real-world project?
When you're on the job, ask yourself one simple question: 'Am I trying to control the person or the resource?' If the goal is to stop Bob from deleting the database, that is an RBAC problem. You need to change Bob's role from Contributor to Reader.
If the goal is to ensure that every database created in the company has a 'Department' tag for billing purposes, that is a Policy problem. You can't force a user to add a tag using RBAC; you must use Azure Policy to either deny the creation of untagged resources or automatically append the tag during deployment. Mastering this logic is what separates a junior admin from a certified Azure professional.
❓ Frequently Asked Questions
If I have the 'Owner' role in RBAC, can Azure Policy still block me?
Yes. Azure Policy is applied at the resource provider level and overrides RBAC permissions. Even an Owner cannot bypass a 'Deny' policy. This ensures that organizational guardrails are maintained regardless of a user's administrative privileges.
Can I use RBAC to enforce that all resources have specific tags?
No. RBAC only controls who can create or modify a resource. It cannot inspect the properties of the resource (like tags) during creation. You must use Azure Policy to enforce tagging requirements for compliance and billing.
Does Azure Policy replace the need for Azure Blueprints?
Not exactly. While Azure Policy handles the 'rules,' Blueprints are used to orchestrate the deployment of entire environments, including the RBAC assignments and Policies themselves, as a repeatable package.