AZ-104 · Manage Azure identities and governance · Updated August 7, 2026
Azure RBAC Built-In Roles Explained: Owner, Contributor, Reader, and Access Administrators
Azure role-based access control (RBAC) ships with thousands of built-in roles, but five account for most of what shows up on the AZ-104 exam and most of what actually gets assigned in real tenants: Owner, Contributor, Reader, User Access Administrator, and Role Based Access Control Administrator. All five are built from the same three ingredients (a security principal, a role definition, and a scope), and all five inherit downward through the resource hierarchy from management group to subscription to resource group to resource. What separates them is one question worth memorizing cold: can this role assign access to other people, or can it only touch the resources themselves?
The role assignment building blocks
A “role assignment” is three things bound together: a security principal (a user, group, service principal, or managed identity), a role definition (the list of allowed actions), and a scope (where the grant applies). Change any one of the three and you have a different assignment; a role definition by itself grants nothing until assigned to a principal at a scope.
Scope sits at four levels, broadest to narrowest: management group, subscription, resource group, and individual resource. A role granted at a resource group flows down to every resource inside it automatically, present now or added later, without a second assignment. This is why the exam favors scope-selection scenarios: assigning a role at the highest scope that still satisfies the requirement is the efficient answer, and repeating it resource-by-resource is almost always wrong.
When more than one assignment applies to the same resource, Azure RBAC is additive: effective permissions are the sum of every role held at every applicable scope. A user with Reader at the subscription and Contributor on one resource group inside it ends up with Contributor there and Reader everywhere else. Only a deny assignment overrides this math, explicitly blocking a specific action regardless of what any role would otherwise permit. Resource locks impose a similar identity-independent block at the resource level, stopping deletes or edits even for Owners.
Owner
Owner grants full control over resources at its scope, including every management action Contributor has, plus one capability nothing else on this list combines with resource management: the ability to assign roles to other principals. An Owner at a resource group can create, modify, and delete anything in that group, and can also hand Contributor, Reader, or any other role to someone else at that scope. Because Owner combines resource control with access delegation, it’s the highest-privilege built-in role and the one governance teams are most cautious about assigning broadly.
Contributor
Contributor grants the same full resource-management rights as Owner: create, modify, delete, restart, resize, deploy, and so on, across virtually every resource type. What it withholds is delegation. A Contributor cannot assign roles in Azure RBAC, manage Azure Blueprints assignments, or share image galleries. This is the role most hands-on administrators and engineering teams should hold day to day: full operational power, no ability to reshape who else has access.
The Owner-versus-Contributor distinction is the single most tested pairing in this domain. Any exam stem that says someone needs to manage resources but must never grant access to others is describing Contributor, regardless of what job title the scenario attaches to that person.
Reader
Reader is strictly view-only: it can see resource configurations, properties, and metadata, but it cannot create, modify, or delete anything, and it cannot touch role assignments in any direction. Reader is the default choice for audit, monitoring, and reporting scenarios where a person or service needs visibility without any operational capability.
User Access Administrator
User Access Administrator flips the Owner/Contributor logic on its head: it manages who has access to resources, without granting any rights to manage the resources themselves. Someone holding this role at a subscription can create and remove role assignments for other users, groups, and service principals across that subscription, but can’t spin up a virtual machine or touch a storage account unless a separate role assignment grants that too.
This role matters for one structural reason the exam likes to probe: at the Tenant Root Group, nobody has default access, not even Global Administrators. A Microsoft Entra Global Administrator has to use the Elevate access action to grant themselves User Access Administrator at the root management group before they can assign any Azure role tenant-wide. That friction is deliberate, and it keeps identity administration (Microsoft Entra ID) separate from resource administration (Azure RBAC).
Role Based Access Control Administrator
Role Based Access Control Administrator is a narrower, more recent addition for organizations that want delegation without the full breadth of User Access Administrator. It can assign and manage Azure RBAC role assignments, but its scope stops there: it cannot manage access through other mechanisms such as Azure Policy. Treat it as User Access Administrator’s more tightly scoped sibling, useful when a person needs to grant and revoke RBAC roles and nothing more.
Comparing the five roles
| Role | Manage resources | Assign RBAC roles to others | Manage via Azure Policy |
|---|---|---|---|
| Owner | Yes | Yes | Yes (full rights) |
| Contributor | Yes | No | Read + trigger remediation only |
| Reader | No (view only) | No | Read only |
| User Access Administrator | No | Yes | Partial (access-related actions) |
| Role Based Access Control Administrator | No | Yes (RBAC only) | No |
Where PIM eligible and active assignments fit in
Everything above describes what a role grants once assigned. Privileged Identity Management (PIM), part of Microsoft Entra ID Governance, controls when that grant applies, and it works for Azure resource roles (Owner, Contributor, User Access Administrator, scoped to any level of the hierarchy) the same way it works for Microsoft Entra directory roles.
PIM assignments come in two types:
- Eligible: the principal can hold the role but must actively activate it before using it, an action that can require MFA, a business justification, and approver sign-off, and that lasts only for a bounded window before the privilege lapses again.
- Active: the principal already has the role’s privileges with no activation step required, functioning like a standard permanent assignment (though it can still be time-bound).
There is no difference in what an eligible and an active assignment grant once the eligible one is activated. The only difference is whether access sits ready at all times (active) or must be deliberately switched on for a limited window (eligible). That’s the core of just-in-time access: a subscription Owner role handed out as eligible rather than active means nobody carries standing rights they’re not actively using, which shrinks the attack surface if a credential is compromised.
Managing PIM for Azure resource roles requires being a subscription administrator, a resource Owner, or a resource User Access Administrator at that scope. Holding the Microsoft Entra Privileged Role Administrator directory role doesn’t by itself grant that visibility, since it’s a directory-role privilege, not a resource-role one. PIM itself requires Microsoft Entra ID Governance or Microsoft Entra ID P2 licensing.
How the AZ-104 exam tests this
- The Owner vs. Contributor discrimination. A stem describes someone who needs to fully manage resources but must never grant others access. The answer is Contributor. Swap that for “also needs to control who else has access” and the answer becomes Owner.
- The delegation-only role. A stem describes someone whose entire job is managing access to a subscription’s resources, with no operational rights over those resources. That’s User Access Administrator, or Role Based Access Control Administrator if delegation is limited to RBAC alone.
- The scope-and-inheritance question. A stem asks where to place a single role assignment so it covers many resource groups or resources without repeating it. This tests downward inheritance from management group through resource.
- The additive-permissions calculation. A stem grants one role at a subscription and a different, more specific role at a resource group, then asks the user’s effective access there. RBAC sums the assignments; only a deny assignment subtracts.
- The PIM eligible-vs-active scenario. A stem describes an administrator who should activate Owner rights for two hours with approval and MFA, rather than holding Owner permanently. That’s an eligible PIM assignment, not an active one, and not a Conditional Access policy (which governs sign-in conditions, not standing privilege).
Understanding scope inheritance here connects directly to the Azure resource hierarchy, and knowing where RBAC’s job ends and resource-state enforcement begins connects to Azure Policy vs. Azure RBAC.