Episode 8 — Azure RBAC in Practice — Assigning and Interpreting Access

Episode 7 gave you the theory: a role assignment is the combination of a security principal, a role definition, and a scope, evaluated additively with deny assignments taking precedence. Now we put that model to work — assigning roles in the portal, reading the assignments that already exist, and keeping Azure roles clearly separated from Microsoft Entra roles.

Learning objectives

• Assign an Azure role in the portal using the Access control (IAM) wizard, including conditions and PIM assignment types.
• Identify which permission and which roles allow someone to create role assignments.
• Distinguish the five fundamental Azure roles and what each can and cannot do.
• Interpret existing access: inherited vs direct assignments, Check access results, downloads, and the per-subscription limit.
• Contrast Azure roles, Microsoft Entra roles, and the retired classic subscription administrator roles.

Why it matters

Almost every access-related ticket an Azure administrator handles — "give the team access to this resource group," "why can this contractor delete VMs?", "who owns this subscription?" — resolves to creating or interpreting a role assignment. The AZ-104 exam tests exactly these mechanics: which role lets you assign roles, where the Assignment type tab comes from, what Check access does and does not show, and why a Global Administrator sees no resources until they flip one specific switch. Getting the Azure-vs-Entra role boundary wrong is one of the most common real-world confusions.

Who is allowed to assign roles?

Creating a role assignment is itself a control-plane action. You need the permission Microsoft.Authorization/roleAssignments/write at the target scope. Out of the box, three built-in roles carry it: Owner, User Access Administrator, and Role Based Access Control Administrator. If you lack the permission, the Add role assignment option in the portal is simply disabled.

The five fundamental roles

Azure RBAC ships over 100 built-in roles, most of them service-specific (Virtual Machine Contributor, Network Contributor, Storage Blob Data Reader…), organized into categories (Privileged, General, Compute, Networking, Storage, and more). Five of them are the fundamental roles you must know cold — the first three apply to all resource types:

Role	Manage resources?	Assign roles?	Notes
Owner	✅ Full	✅ Yes	Full access to everything, including Azure RBAC.
Contributor	✅ Full	❌ No	Also can't manage Azure Blueprints assignments or share image galleries.
Reader	❌ View only	❌ No	Sees everything, changes nothing.
User Access Administrator	❌ No	✅ Yes	Manages user access only; can assign anyone (including self) the Owner role.
Role Based Access Control Administrator	❌ No	✅ Yes	Like UAA, but cannot manage access through other means such as Azure Policy.

The key distinction: Owner both manages resources and assigns roles; Contributor manages resources but cannot assign roles; User Access Administrator and Role Based Access Control Administrator assign roles but do not manage the resources themselves.

🧠 Mnemonic: "Owner assigns, Contributor builds, Reader looks, UAA grants."

Assigning a role in the portal

The wizard lives on the Access control (IAM) page, which exists at every scope level — management group, subscription, resource group, and resource. The flow condenses to seven steps:

Step by step:

1. Identify the scope — search for the management group, subscription, resource group, or specific resource. Remember from Episode 7: assign at the narrowest workable scope.
2. Open Access control (IAM) and click Add > Add role assignment.
3. Select the role. The Role tab splits roles into Job function roles (general or service-specific management) and Privileged administrator roles (Owner, Contributor, User Access Administrator, Role Based Access Control Administrator). You can search, filter by type and category, and click View for role details.
4. Select members. Choose User, group, or service principal or Managed identity (then pick system-assigned or user-assigned; system-assigned identities are selected by their Azure service instance). Add an optional description for the assignment — future-you will thank you.
5. (Optional) Add a condition. If the role supports it, a Conditions tab appears. Two flavors: a delegate condition on Owner/UAA/RBAC Administrator ("Allow user to only assign selected roles to selected principals") — delegation with fewer privileges — and storage conditions on blob/queue data roles, refining access by storage attributes (ABAC).
6. Select the assignment type — this tab appears at management group, subscription, and resource group scopes only with a Microsoft Entra ID P2 or Governance license (it is the PIM integration). Eligible means the user must perform actions (MFA check, business justification, approval) to activate the role; Active means the role works immediately. Duration is Permanent or Time-bound (start/end dates). Important restriction: Eligible is not available for applications, service principals, or managed identities. No PIM wanted? Pick Active + Permanent.
7. Review + assign.

With P2/Governance you can later edit an assignment: on the Role assignments tab, click the link in the State column (e.g. Eligible time-bound) and adjust it in the Edit assignment pane.

Interpreting existing access

Assigning is half the job; the other half is answering "who has access to what, and why?"

Per principal: in Microsoft Entra ID > Users (or Groups), open the user or group and click Azure role assignments — a cross-scope list of their roles (switch subscription via the Subscriptions list).

Per scope: open the resource's Access control (IAM) > Role assignments tab. Two things to read carefully:

• The scope column shows This resource for direct assignments versus (Inherited) for assignments made at a parent scope — inheritance in action.
• With P2 or Governance, a State column appears:

State	Meaning
Active permanent	Usable anytime, no action needed.
Active time-bound	Usable only between start and end dates.
Eligible permanent	Always eligible to activate.
Eligible time-bound	Eligible to activate only between start and end dates.

A Privileged tab on the same page lists privileged administrator role assignments (with a count card), where you can constrain them with a condition or remove them. To find subscription owners, open the subscription's Role assignments tab and scroll to the Owners section.

Check access: on the Check access tab, search for a principal to see their assignments at this scope plus those inherited to this scope — including deny assignments from Azure Blueprints or managed apps. Crucially, assignments at child scopes are NOT listed. Check access answers "what can they do here," not "what can they do anywhere below here."

Download: Download role assignments exports CSV or JSON, with checkboxes for Inherited / At current scope / Children (Children is disabled at management group scope). Caveats: without directory read permission (e.g. Directory Readers), the DisplayName/SignInName/ObjectType columns come back blank; assignments whose principal was deleted are excluded; classic administrator access is not included.

Two more interpretation traps:

• Azure Lighthouse assignments authorized by a service provider won't appear in these views.
• Each subscription holds at most 4,000 role assignments (counted across subscription, resource group, and resource scopes). Eligible and future-scheduled assignments don't count. The Role assignments tab charts your current count, and the Add role assignment pane warns you as you approach the ceiling — one more reason to assign to groups, not individuals.

Azure roles vs Microsoft Entra roles

These are two separate role systems for two separate worlds. Azure roles (RBAC) govern Azure resources; Microsoft Entra roles govern the directory — users, groups, licenses, domains.

	Azure roles (RBAC)	Microsoft Entra roles
Manage access to	Azure resources	Microsoft Entra resources (directory)
Custom roles	✅ Supported	✅ Supported
Scope	Management group, subscription, resource group, resource	Tenant (organization-wide), administrative unit, individual object
Tools	Azure portal, Azure CLI, Azure PowerShell, ARM templates, REST API	Azure portal, Microsoft Entra admin center, Microsoft 365 admin center, Microsoft Graph, Graph PowerShell
Portal page	Access control (IAM)	Roles and administrators

Flagship Entra roles to recognize: Global Administrator (all administrative features in Entra ID and federated services; assigns admin roles; resets any password — the tenant's first sign-up account becomes one), User Administrator (creates and manages users and groups, resets passwords for users, Helpdesk Administrators, and other User Administrators), and Billing Administrator (purchases, subscriptions, support tickets).

By default the two systems do not overlap. A Global Administrator has no access to Azure resources — which surprises everyone the first time. The bridge is elevate access: flipping the "Access management for Azure resources" switch grants the Global Administrator the User Access Administrator Azure role at root scope, over all subscriptions of the tenant. That is the standard way to regain access to an orphaned subscription — and the only default path to manage the root management group (more on that in Episode 9).

History box — classic administrator roles

Before RBAC, Azure had exactly three roles: Account Administrator (1 per account, the billing owner), Service Administrator (1 per subscription, Owner-equivalent at subscription scope), and Co-Administrator (up to 200 per subscription, Service-Administrator-like but couldn't change the directory association or the Service Administrator). Timeline: retired as of August 31, 2024; starting December 2025, remaining Co-Administrators and Service Administrators were automatically assigned Owner at subscription scope; as of May 2026, classic roles are fully retired — Azure RBAC is the only current model. Expect them on the exam only as history and in old exports (classic access is excluded from role-assignment downloads).

Exercises

Exercise 8.1 — Assign Reader to a group at resource-group scope

In your trial subscription, grant the group Ops-Viewers read-only access to the resource group rg-training. List the portal steps, and state which of your own roles makes this possible.

Solution

You need Microsoft.Authorization/roleAssignments/write on rg-training — i.e. you are Owner, User Access Administrator, or Role Based Access Control Administrator there (directly or by inheritance).

1. Portal > search Resource groups > open rg-training.
2. Click Access control (IAM).
3. Add > Add role assignment.
4. Role tab > Job function roles > select Reader > Next.
5. Members tab > User, group, or service principal > Select members > search Ops-Viewers > Select. Add a description like "Read-only audit access for Ops."
6. (No Conditions tab — Reader has no condition support here; if an Assignment type tab appears you have P2/Governance: choose Active + Permanent for a standing assignment.)
7. Review + assign.

Every current and future member of Ops-Viewers can now view (but not change) everything in rg-training — group assignments are transitive, as seen in Episode 7.

Exercise 8.2 — Interpret a Check access result

On a storage account's IAM page, you run Check access for user Dana. The pane shows: Contributor — (Inherited) from the subscription, and nothing else. Answer: (a) can Dana upload a blob configuration change to this storage account via ARM? (b) Can Dana grant her colleague Reader on it? (c) Dana claims she also has Owner on a container inside the account — could Check access be missing it?

Solution

(a) Yes. Contributor inherited from the subscription flows down to the storage account and grants full control-plane management of it.

(b) No. Contributor cannot assign roles — that requires Microsoft.Authorization/roleAssignments/write (Owner, User Access Administrator, or RBAC Administrator).

(c) Yes, plausibly. Check access shows assignments at this scope and inherited to this scope, but not assignments at child scopes. An assignment made directly on a child resource below the checked scope would not appear here. (Also remember: Azure Lighthouse-authorized assignments never show in these views.)

Exercise 8.3 — The invisible subscription

A newly appointed Global Administrator opens the Azure portal and cannot see or manage the resources in the company's production subscription. No one else can grant access — the previous Owner left. What do they do, and exactly which role do they end up with, where?

Solution

This is expected: Azure roles and Microsoft Entra roles don't overlap by default, so Global Administrator confers no Azure resource access. The fix is elevate access: enable the "Access management for Azure resources" switch. The Global Administrator is then granted the User Access Administrator Azure role at root scope, spanning all subscriptions in the tenant. With it, they can assign a proper Owner on the production subscription (then switch elevation back off — it is a break-glass mechanism, not a working posture).

Exercise 8.4 (optional MCQ) — Who can create role assignments?

Which of these roles at subscription scope allow the holder to assign Reader to a colleague on that subscription? (Select all that apply.) A. Contributor B. Owner C. User Access Administrator D. Reader E. Role Based Access Control Administrator

Solution

B, C, and E. All three carry Microsoft.Authorization/roleAssignments/write. Contributor (A) is the classic trap: full resource management, but no role assignment, no Blueprints assignment management, no image-gallery sharing. Reader (D) can only view. Note the E nuance: RBAC Administrator manages access only via role assignments — not "through other means such as Azure Policy."

Key takeaways

• Assigning roles requires Microsoft.Authorization/roleAssignments/write: held by Owner, User Access Administrator, and Role Based Access Control Administrator.
• Owner manages and assigns; Contributor manages but cannot assign roles; Reader views; UAA/RBAC Administrator assign roles without managing resources.
• The portal wizard: scope → Access control (IAM) → role (Job function vs Privileged administrator) → members → optional conditions → Assignment type (Eligible/Active, Permanent/Time-bound, P2/Governance only; Eligible not for service principals) → review.
• On the Role assignments tab, (Inherited) vs This resource tells you where access was granted; the State column (P2) tells you how (active/eligible, permanent/time-bound).
• Check access shows assignments at the current scope plus inherited — never child scopes; Azure Lighthouse assignments are invisible; downloads exclude deleted principals.
• Limit: 4,000 role assignments per subscription (eligible/scheduled excluded) — prefer group assignments.
• Azure roles ≠ Microsoft Entra roles: resources vs directory, different scopes, different portal pages, no overlap by default; a Global Administrator bridges them only via elevate access → User Access Administrator at root scope.
• Classic administrator roles (Account/Service/Co-Administrator) are history: retired Aug 31, 2024, auto-converted to Owner from Dec 2025, fully gone as of May 2026.

Quick recall

Q: A user has Contributor on a subscription. Can they grant a teammate Reader on a resource group inside it? A: No. Contributor lacks Microsoft.Authorization/roleAssignments/write; only Owner, User Access Administrator, or Role Based Access Control Administrator can assign roles.

Q: What license makes the Assignment type (Eligible/Active) tab appear, and at which scopes? A: Microsoft Entra ID P2 or Governance; the tab appears at management group, subscription, and resource group scopes. Eligible is unavailable for applications, service principals, and managed identities.

Q: Check access on a resource group shows nothing for a user, yet they can manage a VM inside it. How? A: Check access doesn't list child-scope assignments — the user likely has a role assigned directly on the VM. (Or the access comes through Azure Lighthouse, which these views never show.)

Q: How many role assignments fit in one subscription, and what doesn't count? A: 4,000, across subscription/RG/resource scopes; eligible and future-scheduled assignments don't count.

Q: Where do Azure roles and Microsoft Entra roles each appear in the portal? A: Azure roles on Access control (IAM) at each scope; Entra roles on Roles and administrators in Microsoft Entra ID.

Q: What exactly does "elevate access" grant? A: The Global Administrator receives the User Access Administrator Azure role at root scope, over all subscriptions in the tenant — the default way to regain subscription access and to manage the root management group.

Coming up

You can now grant and read access anywhere in the hierarchy — next we build the hierarchy itself. Episode 9 organizes the estate: management groups and their inheritance cascade, creating subscriptions, resource-group lifecycle rules, and a tagging strategy that respects Azure's real limits.