RBAC: Who Can Do What in Azure
Role-Based Access Control is how you grant — and limit — access to Azure resources. Learn built-in roles, scope hierarchy, and how to read access assignments like a pro.
What is Azure RBAC?
RBAC is like giving hotel key cards that only open specific doors.
In an on-prem world, you might give someone “Domain Admin” and they can do everything. That’s like giving them a master key. In Azure, RBAC lets you be precise: “You can manage virtual machines in the Production resource group, but you can’t touch the networking or delete anything in Staging.”
Every RBAC assignment has three parts: Who (the user/group), What (the role — what actions they can perform), and Where (the scope — which resources the role applies to).
The scope hierarchy
Permissions in Azure flow downward. A role assigned at a higher scope is inherited by everything below it.
Management Group
└── Subscription
└── Resource Group
└── Resource- Assign Owner at a subscription → that user owns every resource group and resource in it
- Assign Reader at a resource group → that user can read all resources in that group but not other groups
- Assign Contributor at a specific VM → only that VM
Exam tip: Inheritance is automatic and you can't block it
Unlike on-prem NTFS permissions where you can “break inheritance,” Azure RBAC inheritance cannot be blocked. If someone has Owner at the subscription level, you cannot prevent them from managing a resource group within that subscription.
The only way to restrict access is to not grant roles at higher scopes. Follow least privilege — assign at the lowest scope possible.
Built-in roles you must know
Azure has over 100 built-in roles, but the exam focuses on these:
| Role | What It Can Do | Common Use |
|---|---|---|
| Owner | Full access + can delegate access to others | Subscription or RG owners |
| Contributor | Full access EXCEPT managing role assignments | Developers, DevOps |
| Reader | Read-only access to all resources | Auditors, stakeholders |
| User Access Administrator | Manage role assignments (but not resources) | Security team |
| Virtual Machine Contributor | Manage VMs (but not the VNet or storage they use) | VM operators |
| Storage Blob Data Reader | Read blob data (not management plane) | Data consumers |
| Storage Blob Data Contributor | Read/write/delete blob data | App service accounts |
| Network Contributor | Manage network resources | Network team |
| Feature | Owner | Contributor | Reader |
|---|---|---|---|
| Create resources | Yes | Yes | No |
| Delete resources | Yes | Yes | No |
| Read resources | Yes | Yes | Yes |
| Assign roles to others | Yes | No | No |
| Manage resource locks | Yes | No — read only, cannot create or delete | No |
Exam tip: Contributor cannot assign roles
This is one of the most tested RBAC facts. Contributor can do everything EXCEPT manage access. If a question says “a user needs to deploy resources AND grant access to other team members,” the answer is Owner, not Contributor.
Also: User Access Administrator can assign roles but cannot manage resources. It’s the inverse of Contributor.
Azure RBAC vs Entra ID roles
This is a common confusion point — and a frequent exam trap.
| Feature | Azure RBAC Roles | Entra ID Roles |
|---|---|---|
| What they control | Azure resources (VMs, storage, networking) | Entra ID directory (users, groups, apps) |
| Where assigned | Management group, subscription, RG, resource | Entra ID tenant level |
| Example roles | Owner, Contributor, Reader | Global Admin, User Admin, Application Admin |
| Managed in | Azure portal → Access control (IAM) | Entra admin center → Roles and administrators |
| Overlap? | Global Admin CAN grant themselves Azure access | Azure roles do NOT grant Entra directory access |
Exam tip: The Global Administrator escape hatch
By default, Entra ID Global Administrators do NOT have Azure RBAC access. However, there’s a toggle in Entra ID (Properties → Access management for Azure resources) that lets a Global Admin elevate themselves to User Access Administrator at the root management group scope. This is tested on the exam.
At Meridian Financial, this toggle is monitored by the security team — if anyone enables it, an alert fires immediately.
Interpreting access assignments
The exam expects you to read an Access Control (IAM) blade and determine effective permissions.
How to check a user’s access:
- Go to the resource, resource group, or subscription
- Click Access control (IAM)
- Click Check access tab
- Search for the user/group
- Review all role assignments (including inherited ones)
What to look for:
- Direct assignments — roles assigned at this specific scope
- Inherited assignments — roles assigned at a parent scope (subscription, management group)
- Deny assignments — system-managed only (e.g., Azure Blueprints)
- Effective permissions — the union of all allowed actions minus any denies
Knowledge check
Alex needs to give a junior admin the ability to deploy VMs and storage accounts in the 'Dev' resource group, but NOT allow them to give access to anyone else. Which role should Alex assign?
Meridian Financial has the following setup: User 'Sarah' has Reader at the subscription level and Contributor on the 'Prod-DB' resource group. What can Sarah do with a VM in the Prod-DB resource group?
A security auditor asks: 'How can I verify all the RBAC assignments on the Production subscription, including inherited ones?' Where should they look?
🎬 Video coming soon