Azure RBAC Guide: Master Permissions for AZ-900
Azure Role-Based Access Control (RBAC) is a system used to manage access to Azure resources. It allows you to assign specific roles to users, groups, or service principals at various scopes—such as subscriptions or resource groups—ensuring users have only the permissions necessary to perform their tasks, following the principle of least privilege.
What is Azure RBAC and why does it matter?
Think of Azure RBAC as your digital security guard. Instead of giving every employee a master key to the entire building, you give them a keycard that only opens the doors they actually need to enter. In technical terms, RBAC allows you to manage who has access to Azure resources, what they can do with those resources, and where those permissions apply. For the AZ-900 exam, you need to understand that RBAC is built on three elements: the security principal (the 'who'), the role definition (the 'what'), and the scope (the 'where').
Without RBAC, managing a cloud environment would be a nightmare of manual permissions and security holes. By using roles, you can standardize access across your organization. Whether you are managing a small project or a global enterprise, RBAC ensures that your environment remains secure and manageable. We always tell our students that mastering this concept is non-negotiable because it forms the foundation of Azure's governance and security model.
How does the Principle of Least Privilege work in Azure?
The Principle of Least Privilege (PoLP) is a golden rule in IT security: give a user the minimum level of access they need to complete their job, and nothing more. In Azure, this means you should avoid the temptation to make everyone an 'Owner.' If a developer only needs to restart a virtual machine, they don't need the ability to delete the entire subscription. Giving excessive permissions increases your 'attack surface'—if an account is compromised, the damage is limited to what that specific role could access.
In a real-world scenario, you might start a new hire as a 'Reader' while they onboard, move them to 'Contributor' for a specific resource group once they start building, and only grant 'Owner' status to a very small number of highly trusted administrators. When you're practicing with our AZ-900 question sets, look closely at scenarios asking for the 'most secure' option; the answer is almost always the one that follows the principle of least privilege.
What are the different levels of Scope in Azure?
Scope is all about the boundary of your permissions. Azure uses a hierarchical structure, and permissions flow downward through inheritance. At the top, you have Management Groups, which can govern multiple subscriptions. Below that is the Subscription level, then Resource Groups, and finally, individual Resources (like a single Storage Account or VM). If you assign a user the 'Contributor' role at the Subscription level, they automatically have Contributor access to every single resource group and resource within that subscription.
To keep your environment tight, you should apply permissions at the lowest scope possible. For example, if a contractor only needs to manage a specific web app, assign their role at the Resource Group level rather than the Subscription level. This prevents 'permission creep' and ensures that a mistake in one area doesn't bring down your entire infrastructure. Understanding this hierarchy is a frequent focal point for AZ-900 exam questions, so make sure you can visualize the flow from Management Group down to the Resource.
When should you use Built-in roles versus Custom roles?
Azure provides several built-in roles that cover 90% of common use cases. The big ones you must know for the exam are Owner (full access, including granting access to others), Contributor (full access to resources, but cannot grant access), and Reader (can view resources but not change them). There is also the User Access Administrator, who specifically manages role assignments. These built-in roles are the fastest way to get your team up and running without overcomplicating your governance.
However, sometimes the built-in roles are too broad. This is where Custom Roles come in. A custom role allows you to pick and choose specific actions (permissions) and not-actions (exclusions). For instance, if you want a user to be able to start and stop VMs but not be able to delete them, a custom role is your only option. Just be warned: custom roles add administrative overhead. You have to maintain them and update them as Azure releases new features. In the exam, if a built-in role fits the requirement, always choose it over a custom role.
What is the difference between Azure RBAC and Azure Policy?
This is one of the most common points of confusion for AZ-900 candidates. Here is the simple breakdown: RBAC is about *who* can do something (Access), while Azure Policy is about *what* the resource must look like (Compliance). RBAC answers the question, 'Is John allowed to create a Virtual Machine?' Azure Policy answers the question, 'Is this Virtual Machine being created in the East US region and using a small size to save costs?'
Think of RBAC as the security guard at the door and Azure Policy as the building code inspector. Even if the security guard (RBAC) lets you into the room to build a wall, the inspector (Policy) will stop you if you try to build that wall out of cardboard. You need both to have a healthy environment. RBAC prevents unauthorized users from making changes, and Policy prevents authorized users from making mistakes that lead to security gaps or budget overruns.
How can you effectively practice for the AZ-900 RBAC questions?
Reading the documentation is a great start, but the AZ-900 exam tests your ability to apply these concepts to tricky scenarios. You need to move beyond memorization and start analyzing. This is why we built Cert Sensei to be more than just a question bank. We offer 1,000 expert-curated Microsoft Azure Fundamentals practice questions that mirror the actual exam's complexity, specifically targeting the nuances of RBAC and Governance.
What sets us apart is our detailed expert reasoning for every single answer. Instead of just telling you that 'B' is correct, we explain *why* A, C, and D are wrong based on Azure's logic. Plus, our domain-level analytics allow you to track your performance specifically in the 'Governance and Compliance' section. If you see your score dipping in RBAC questions, you know exactly where to focus your study hours before exam day. Stop guessing and start knowing exactly where you stand.
❓ Frequently Asked Questions
Can a user have multiple RBAC roles assigned to them?
Yes. Role assignments are additive. If a user is assigned the 'Reader' role at the subscription level and the 'Contributor' role at a specific resource group level, they will have Contributor permissions within that group and Reader permissions everywhere else.
What happens if there is a conflict between different role assignments?
In Azure RBAC, the most permissive assignment wins. There are no 'Deny' assignments in standard RBAC (though Azure Blueprints can implement them). If one role allows an action and another doesn't mention it, the permission is granted.
Does Azure RBAC control access to the data inside a storage account?
Not entirely. RBAC manages the 'management plane' (e.g., creating or deleting the account). Access to the 'data plane' (the actual files inside a blob) is managed via separate mechanisms like Access Keys, Shared Access Signatures (SAS), or Azure AD authentication.