Episode 7 — Azure RBAC — The Authorization Model

In Episode 6 you finished Part I of this module by wiring up SSPR — the reset flow, the method gates, registration, and writeback that keep identities self-sufficient. Part II now crosses from the identity plane to the resource plane: this episode dissects the model Azure uses to decide who may do what to your resources — Azure RBAC.

Learning objectives

• Describe the three elements of a role assignment: security principal, role definition, and scope.
• Compute effective permissions from Actions/NotActions and DataActions/NotDataActions.
• Predict the outcome of multiple role assignments using the additive model and group transitivity.
• Trace the nine-step evaluation flow Azure Resource Manager runs on every request, including deny assignments and conditions.
• Choose the appropriate scope level for an assignment and read a scope string.

Why it matters

Every action anyone takes on an Azure resource — portal click, CLI command, script — is authorized (or refused) by this model. As an administrator you will assign roles weekly and debug "access denied" tickets even more often; on the AZ-104 exam, "Manage access to Azure resources" questions almost always reduce to reasoning correctly about principal, role, and scope. Get the model right once and both the day job and the exam questions become mechanical.

What Azure RBAC is

Azure role-based access control (Azure RBAC) is the authorization system built on Azure Resource Manager (ARM) that provides fine-grained access management to Azure resources. It answers three questions about resource access: who has access, what they can do, and which areas (resources) they can reach. Typical uses: let one user manage virtual machines in a subscription while another manages virtual networks, let a DBA group manage SQL databases, or let an application access everything in one resource group.

Two facts to anchor immediately:

• Using Azure RBAC is free and included in your Azure subscription — and that includes Azure custom roles. Don't confuse this with Microsoft Entra custom roles (directory roles), which require an Entra ID P1 license. Two different systems, two different price tags.
• Azure RBAC governs Azure resources through ARM. Microsoft Entra roles (Global Administrator, User Administrator…) govern the directory — a separate role system we contrast fully in Episode 8.

The triad: principal + role + scope = assignment

Access is never granted to a person directly; it is granted by creating a role assignment, and revoked by removing one. A role assignment binds exactly three elements:

🧠 Mnemonic: PRS — Principal, Role, Scope: Who, What, Where. Every RBAC question on the exam is asking you to identify or fix one of these three letters.

Classic example from the documentation: the Marketing group is assigned the Contributor role on the pharma-sales resource group. Every user in Marketing can create and manage any resource inside that resource group — and nothing outside it, unless another assignment says otherwise. You can create assignments with the Azure portal, Azure CLI, Azure PowerShell, SDKs, or REST APIs.

Azure ships hundreds of built-in roles, organized in categories (Privileged, General, Compute, Networking, Storage, Databases, Identity, Security…). If none fits, you create an Azure custom role — still free.

Inside a role definition: the permissions math

A role definition lists permitted operations in four properties, split across two planes:

Effective permissions are pure subtraction:

• Actions − NotActions = effective control-plane permissions
• DataActions − NotDataActions = effective data-plane permissions

NotActions is not a deny — it merely carves operations out of what Actions granted, which matters most for wildcard roles (Actions: *). The two planes are independent: managing a storage account (control plane) does not by itself let you read its contents. Data actions exist precisely for that: a role like Storage Blob Data Reader grants read access to the blobs or messages within a storage account.

Scope: where the access applies

Scope is the set of resources the access applies to, specified at four levels: management group → subscription → resource group → resource, in a parent-child hierarchy. Lower levels inherit role permissions from higher levels — Contributor on a subscription means Contributor on every resource group and resource inside it. Management groups sit above subscriptions and support more complex hierarchies (Episode 9 territory).

The practical corollary: assign at the narrowest workable scope. Limiting scope limits the blast radius — what is at risk if that security principal is ever compromised.

For command-line tools, a scope is a slash-separated string — in the portal it appears as the Resource ID on the resource's properties:

You can list assignments (scope included) with Get-AzRoleAssignment (PowerShell) or az role assignment list (CLI). One architecture note that ties back to Episode 1: a role assignment is an ARM extension resource — it exists as a child of the resource it extends, which is why its ID is always the extended resource's ID plus /providers/Microsoft.Authorization/roleAssignments/{roleAssignmentId}.

The additive model — and groups

Azure RBAC is an additive model: your effective permissions are the sum of all your role assignments. There is no "most specific wins." If a user holds Contributor at subscription scope and Reader on one resource group, the Reader assignment adds nothing — the user is effectively Contributor everywhere in the subscription, including that resource group.

Role assignments are also transitive for groups: if a user is a member of group G2, G2 is a member of group G1, and G1 has a role assignment, the user gets the permissions of that assignment.

⚠️ Contrast with Episode 3: in Microsoft Entra ID, nested groups do not propagate access to apps/shared resources or licenses — only the parent group's direct members benefit. In Azure RBAC, nesting does flow through: assignments are transitive across (security) group nesting. Same word "group," two different systems, opposite behaviors — a favorite exam trap.

Deny assignments

Alongside role assignments, Azure supports deny assignments: they block specified actions even when a role assignment grants them, and they take precedence — deny is checked first. You cannot create deny assignments directly; they are created and managed by Azure on your behalf, for example by Azure Blueprints and Azure managed applications, to protect resources those systems own.

How ARM decides: the evaluation flow

Every request runs through this sequence in Azure Resource Manager:

Read the flow's pressure points: the token already contains transitive group memberships (that is where group nesting pays off); deny assignments are evaluated before roles; the wildcard subtraction happens during evaluation; and conditions (attribute-based access control, e.g. on storage) get the last word when present.

Where RBAC data lives

Role definitions, role assignments, and deny assignments are stored and replicated globally, not per region. The reason: ARM itself has a global endpoint — requests are routed to the nearest region for speed and resilience — so authorization data must be available in all regions. When you delete RBAC data, it is deleted globally.

Exercises

Exercise 7.1 — The wildcard subtraction

A custom role contains:

{
  "Actions": [ "*" ],
  "NotActions": [
    "Microsoft.Authorization/*/Write",
    "Microsoft.Authorization/*/Delete"
  ]
}

What are the effective control-plane permissions? Can a user with this role assign Azure roles to someone else?

Exercise 7.2 — Additive model scenario

Amira has two role assignments:

1. Reader at the subscription scope.
2. Contributor on the resource group rg-app-prod (inside that subscription).

What can Amira do (a) inside rg-app-prod, and (b) in the rest of the subscription? Would the answer change if assignment 2 were Reader on the RG and assignment 1 were Contributor on the subscription?

Exercise 7.3 — Nested groups

Group G1 has a Virtual Machine Contributor assignment on subscription Sub-A. Group G2 is a member of G1. User Ben is a member of G2 only. Ben successfully manages VMs in Sub-A. Explain, step by step in the evaluation flow, why this works — and say why the same nesting would NOT deliver an app assignment or a license in Microsoft Entra ID.

Key takeaways

• Azure RBAC is the authorization system built on Azure Resource Manager; using it — including custom roles — is free (unlike Microsoft Entra custom roles, which need P1).
• A role assignment = security principal (who) + role definition (what) + scope (where); access is granted by creating one and revoked by removing it.
• Effective permissions = Actions − NotActions (control plane) and DataActions − NotDataActions (data plane); data actions reach inside resources (e.g., Storage Blob Data Reader reads blobs).
• Scope has four levels — management group, subscription, resource group, resource — and lower levels inherit assignments from higher ones; assign at the narrowest workable scope to limit the blast radius.
• The model is additive: effective permissions are the sum of all assignments; Reader on an RG cannot restrict a Contributor inherited from the subscription.
• Assignments are transitive for groups in Azure RBAC — the opposite of Entra ID nesting behavior for apps and licenses.
• Deny assignments (created by Azure via Blueprints/managed applications, never directly by you) are evaluated first and override role assignments.
• RBAC data (definitions, assignments, deny assignments) is stored and replicated globally, because ARM's global endpoint must enforce it in every region.

Quick recall

Q: What three elements make up a role assignment? A: A security principal (user, group, service principal, or managed identity), a role definition, and a scope — Who, What, Where.

Q: How are effective permissions computed for a role with wildcards? A: Actions − NotActions for the control plane and DataActions − NotDataActions for the data plane; NotActions carves out, it does not deny.

Q: A user has Contributor at subscription scope and Reader on one resource group in it. What are their effective rights on that resource group? A: Contributor — the model is additive; the Reader assignment adds nothing and cannot subtract anything.

Q: Scenario — you must let an external audit script read one specific storage container's blobs and nothing else. Which role and which scope? A: A data-plane role such as Storage Blob Data Reader, assigned at the resource scope (the container/storage account) — narrowest workable scope, smallest blast radius.

Q: Who creates deny assignments, and when are they evaluated? A: Azure creates them on your behalf (e.g., Azure Blueprints, managed applications) — you can't create them directly; they are checked before role assignments and take precedence.

Q: Why is Azure RBAC data replicated globally? A: Because Azure Resource Manager has a global endpoint and requests route to the nearest region — authorization must therefore be enforceable in all regions.

Coming up

You now own the theory; Episode 8 makes it operational: assigning roles in the portal through Access control (IAM), PIM assignment types (eligible vs active, permanent vs time-bound), listing and interpreting existing assignments, the fundamental roles in depth — and the crucial three-way distinction between Azure roles, Microsoft Entra roles, and the retired classic administrator roles.