Azure RBAC is the single most frequent topic in our AZ-104 question bank. The exam rarely stops at "what is Contributor?" Instead, it shows you a table of role assignments that mixes users, groups, and scopes, and asks things like "Can User1 restart VM2?" or "Which role, at which scope, gives this team least-privilege access?" The official skills outline even lists "manage built-in Azure roles," "assign roles at different scopes," and "interpret access assignments" as separate items.
This article focuses on reading and interpreting role assignments. We cover the three parts of every role assignment, the built-in roles you must tell apart, scope and inheritance, the difference between deny assignments and NotActions, the boundary between Microsoft Entra roles and Azure roles, and how to confirm real permissions with Check access on the Access control (IAM) page. The RBAC basics are covered first in Identity and Governance.
---
Every Role Assignment Has Three Parts
Think of an office access badge. It says whose badge it is (the person), what level it carries (visitor, employee, or administrator), and which floors it opens (the zone). Change any one of the three and you have a completely different badge. An Azure role assignment is the same kind of combination.
| Part | Question | Possible values | |------|------|------| | Security principal | Who? | User, group, service principal, managed identity | | Role definition | What? | A list of allowed operations (Actions, DataActions) | | Scope | Where? | Management group, subscription, resource group, resource |
!A role assignment combines a security principal, a role definition, and a scope
Assigning roles to groups is easier to manage than assigning them to individuals. When you assign a role to a group, anyone who joins the group gets the access automatically and loses it automatically on leaving. When a resource such as a VM or an App Service app needs to reach another resource, you turn on a managed identity and assign the role to that identity. A system-assigned managed identity is created and deleted together with its resource; a user-assigned managed identity is a standalone resource that several resources can share.
Exam tip: "Let a VM access storage without storing credentials in code or configuration files" means assigning a storage data role to the VM's managed identity.
---
Built-in Roles You Must Tell Apart
Azure has hundreds of built-in roles, but the ones that keep appearing in AZ-104 questions are a short list. Memorize what each role cannot do as well as what it can, because that is how you eliminate wrong answers.
| Role | Can do | Cannot do | |------|------|------| | Owner | Manage all resources + assign roles | Access the data plane with an Entra account (needs a separate data role) | | Contributor | Manage all resources | Assign roles, manage Blueprints assignments, share image galleries | | Reader | View all resources | Make any changes | | User Access Administrator | Manage user access (assign roles) | Create or modify the resources themselves | | Role Based Access Control Administrator | Assign roles with Azure RBAC, optionally constrained by conditions | Manage access in other ways, such as Azure Policy | | Virtual Machine Contributor | Create and manage VMs, manage disks | Manage the VNet or storage account the VM uses, assign roles | | Network Contributor | Manage networks | Deploy or manage VMs | | Storage Account Contributor | Manage storage accounts + access the account keys | Assign roles | | Storage Blob Data Contributor | Read, write, and delete containers and blobs | Manage storage account settings | | Tag Contributor | Manage tags | Access the resources themselves |
Control Plane vs Data Plane
A role's permissions live in two columns. Actions are control plane operations, such as creating a resource or changing its settings. DataActions are data plane operations, such as reading or writing the contents of a blob. Owner and Contributor have a wildcard (*) in Actions but an empty DataActions list, so reading blob data with a Microsoft Entra account requires a separate role.
There is a catch. Contributor and Storage Account Contributor include the operation that lists account keys (listkeys), and when you have it, the portal uses the account key to show blob data. In the other direction, if you only have a data role and no control plane role of at least Reader, you cannot even navigate to the storage account in the portal.
Exam tip: "Let users only read blobs in the portal using their Microsoft Entra accounts" is Reader plus Storage Blob Data Reader at the storage account scope. Storage Blob Data Reader alone does not let them browse in the portal.
---
Scope and Inheritance: Access Flows Downward
Someone who holds the building's master key can open every room on every floor. Azure works the same way: a role assigned at a higher scope is inherited by every lower scope. From broadest to narrowest, the four levels are management group → subscription → resource group → resource.
The second principle to remember is that Azure RBAC is an additive model. When several role assignments overlap for one person, their effective permissions are the sum of all of them. Assigning a lower role at a lower scope never takes away a higher role inherited from above.
| Situation | Effective access | |------|------| | Contributor on the subscription, Reader on RG1 | Contributor in RG1 as well (sum) | | Contributor on RG1, Reader on VM1 | Contributor on VM1 as well (inheritance + sum) | | Group has Contributor on RG1, user has Reader on the subscription | Manage RG1, only view other resource groups | | Owner on RG1 | Can assign roles to others inside RG1, no access to RG2 |
Exam tip: When a requirement narrows the scope, as in "manage only the VMs in RG2 and nothing else," pick the answer that assigns Virtual Machine Contributor at the RG2 scope, not the subscription. If a higher role already exists at the subscription scope, access does not shrink until that assignment is removed.
---
Two Ways to Subtract Access: NotActions and Deny Assignments
These two "subtractions" sound alike but behave completely differently, and the exam mixes them up on purpose.
| Item | NotActions | Deny assignment | |------|------|------| | Where it lives | Inside a role definition | A separate object at the same level as a role assignment | | Meaning | Operations removed from a wildcard in Actions | Explicitly blocks the listed operations | | If another role allows the same operation | Allowed (it is not a deny rule) | Still blocked | | Who creates it | The administrator writing a custom role | Created and managed by Azure (you can't create one directly) | | Example | Contributor excludes role assignment operations | Delete protection for managed applications and deployment stacks |
Knowing the order in which Azure Resource Manager evaluates a request also speeds up table questions.
Collect every role assignment and deny assignment that applies to the requested operation If a deny assignment applies, block immediately If the sum of role assignments doesn't include the operation, block If the role assignment has conditions, evaluate them before deciding
Exam tip: "A custom role puts the delete operation in NotActions, yet the user can still delete" means another role assignment grants delete. To stop a specific resource from being deleted at all, consider a resource lock (CanNotDelete).
---
Entra Roles and Azure Roles Live in Different Worlds
Two "administrators" can manage entirely different things. HR manages the employee directory; facilities manages the building and the equipment. Being head of HR does not hand you the key to the server room.
| Item | Microsoft Entra roles | Azure roles (Azure RBAC) | |------|------|------| | What they manage | Directory objects such as users, groups, licenses, and domains | Azure resources such as VMs, storage, and VNets | | Typical roles | Global Administrator, User Administrator, Billing Administrator | Owner, Contributor, Reader, User Access Administrator | | Assignment scope | Whole tenant or an administrative unit | Management group, subscription, resource group, resource | | Where you assign | Roles and administrators in the Entra admin center | Access control (IAM) at each scope |
By default, neither world reaches into the other. The exception is elevated access for a Global Administrator. Setting "Access management for Azure resources" to Yes in the Entra ID properties assigns that person User Access Administrator at root scope (/), which lets them assign roles in every subscription and management group in the tenant. Set it back to No once the work is done.
The classic subscription administrator roles that older material mentions, Account Administrator, Service Administrator, and Co-Administrator, were retired on August 31, 2024. Today the Azure RBAC Owner role covers that job.
Exam tip: "Must be able to create new users and reset their passwords" is an Entra role (User Administrator); "manage resources in a subscription" is an Azure role. If a question says "a Global Administrator can't access a subscription," the answer is elevating access.
---
Confirming Real Access on the IAM Page
When role assignments are scattered across several scopes, adding them up in your head is hard. That is what the Access control (IAM) page on each resource is for.
| Feature | Where | What it shows | |------|------|------| | Check access | IAM → Check access tab | Role assignments and deny assignments for a selected user, group, or service principal | | View my access | IAM → Check access tab | Your own role assignments and eligible assignments | | Role assignments tab | IAM → Role assignments | Every assignment at this scope, with the scope column showing "This resource" or "(Inherited)" | | A user's Azure role assignments | Entra ID → Users → Azure role assignment