Lesson 03 — Role-Based Access Control (RBAC)

Domain 1 — Identity & Governance AZ-104: 20–25% ~30 min Prereq: Lessons 01–02

Why RBAC is the Cornerstone of Azure Security

Azure RBAC is the mechanism that answers: "Can this identity perform this action at this scope?" Every API call to Azure Resource Manager (ARM) is evaluated against RBAC before the operation is executed. Every mistake in RBAC — a role assigned at too broad a scope, a permanent privileged assignment instead of a just-in-time one, a misconfigured custom role — creates real security risk that compounds over time as an environment grows.

In the AZ-104 exam, RBAC questions are among the most common and the most nuanced. The exam tests not just what roles exist, but the precise mechanics of how permissions are evaluated: inheritance, additive accumulation, NotActions semantics, and the interaction between RBAC and Azure Policy.

The Four Components of a Role Assignment

Every Azure RBAC role assignment is the combination of exactly four things:

🔐 Role Assignment ├─ 👤 Security Principal — WHO: user, group, service principal, managed identity ├─ 📋 Role Definition — WHAT: the set of allowed (and excluded) actions ├─ 🎯 Scope — WHERE: MG / Subscription / Resource Group / Resource └─ 📌 Assignment — the binding record that connects the three above

Who can create role assignments?

Only two built-in roles can create role assignments:

Owner — full resource access plus the ability to manage access
User Access Administrator — can manage access only, with no resource permissions of their own

The additive model: permissions accumulate Azure RBAC is additive. If a user has the Reader role on a subscription and the Contributor role on a specific resource group, they have Contributor-level access within that resource group and Reader access everywhere else. Multiple role assignments stack — you never "cancel out" permissions with a lower-scoped role (unless a Deny assignment is involved — see later in this lesson).

Role Definitions: Structure and Semantics

A role definition is a JSON document containing five top-level fields. You must understand each — they appear in exam questions and in production custom role authoring.

{
  "Name": "Custom VM Operator",
  "Description": "Start, stop, and restart VMs. Cannot create or delete.",
  "Actions": [
    "Microsoft.Compute/virtualMachines/start/action",
    "Microsoft.Compute/virtualMachines/deallocate/action",
    "Microsoft.Compute/virtualMachines/restart/action",
    "Microsoft.Compute/virtualMachines/read",
    "Microsoft.Resources/subscriptions/resourceGroups/read"
  ],
  "NotActions": [],
  "DataActions": [],
  "NotDataActions": [],
  "AssignableScopes": [
    "/subscriptions/a1b2c3d4-1234-5678-abcd-ef1234567890"
  ]
}

Actions vs. DataActions — the most important distinction

Field	What it controls	Evaluated by	Examples
Actions	Azure Resource Manager (ARM) management plane operations — creating, deleting, and configuring resources	ARM / RBAC engine	`Microsoft.Storage/storageAccounts/write` `Microsoft.KeyVault/vaults/deploy/action`
DataActions	Data plane operations — reading/writing data within a resource (blob data, Key Vault secret values, queue messages)	The individual service's data plane, delegated from RBAC	`Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read` `Microsoft.KeyVault/vaults/secrets/getSecret/action`
NotActions	Subtracted from a wildcard `*` in Actions — does NOT mean deny	ARM / RBAC engine	`Microsoft.Authorization/*/Delete`
NotDataActions	Subtracted from a wildcard in DataActions — same semantics as NotActions but for data plane	Service data plane	`Microsoft.Storage/storageAccounts/blobServices/containers/blobs/delete`

NotActions is NOT a deny — this is the most common RBAC misconception NotActions: ["Microsoft.Authorization/*/Delete"] does not prevent a user from deleting role assignments. It only means "exclude this from the wildcard in my Actions list." If a second role assignment grants Microsoft.Authorization/*/Delete explicitly, the user can perform that action. The only way to prevent an action unconditionally is a Deny assignment — which you cannot create directly via RBAC (see the Deny Assignments section below).

Why Actions vs. DataActions matters for Key Vault and Storage The Contributor role has Actions: ["*"] which includes all management plane operations on Key Vault and Storage. But Contributor has no DataActions — meaning a Contributor can create a Key Vault but cannot read the secrets inside it. To read secrets, you need Key Vault Secrets User (a data plane role). This separation of management plane and data plane is critical for zero-trust architecture.

Built-In Roles to Memorise

There are over 100 built-in roles in Azure. The exam tests a specific subset. Memorise these precisely.

General-purpose roles

Role	What it can do	What it cannot do
Owner	Full access to all resources and can manage access (create role assignments)	Cannot override Azure Policy Deny assignments
Contributor	Full access to create, update, delete all resources	Cannot manage access (no role assignment creation). Cannot grant access to others.
Reader	View all resources	Cannot make any changes, cannot read secrets/data plane
User Access Administrator	Manage user access (create role assignments) at the assigned scope	Cannot manage resources themselves — no compute, network, or storage actions

Service-specific roles (exam-relevant)

Role	Purpose
Storage Blob Data Contributor	Read, write, delete blob data (DataActions). Does not grant management plane access to storage accounts.
Storage Blob Data Reader	Read blob data only. Common for application identities needing read-only storage access.
Key Vault Secrets Officer	Manage secrets in Key Vault (create, update, delete, list). Also a DataActions role.
Key Vault Secrets User	Read (get) secret values only. Minimum required role for applications reading secrets.
Network Contributor	Manage virtual networks, NSGs, load balancers, route tables. Cannot manage VMs or subscriptions.
Virtual Machine Contributor	Create and manage VMs. Does not include access to VNets, Storage, or Key Vaults — those require separate assignments.
Monitoring Contributor	Read monitoring data and edit monitoring settings. Required for policy remediation tasks that deploy diagnostic settings.

Custom Role Definitions

When no built-in role matches your least-privilege requirement precisely, you create a custom role. Custom roles are defined at the tenant level but are scoped to specific subscriptions or management groups via AssignableScopes.

Key facts about custom roles

Maximum of 5,000 custom role definitions per tenant (a hard limit).
Custom roles are stored in the tenant but can only be assigned within the scopes listed in AssignableScopes.
You can update a custom role definition at any time — existing assignments automatically reflect the updated permissions.
Custom roles can be created via the portal, Azure CLI, PowerShell, ARM/Bicep templates, or Terraform.

AssignableScopes — a common exam source of confusion

AssignableScopes defines where the role can be assigned, not where it applies. Setting AssignableScopes to /subscriptions/sub-A means an administrator in sub-B cannot assign this role in their subscription — even though the role definition technically lives in the shared tenant. This is a tenant-level definition with a subscription-level assignment restriction.

"AssignableScopes": [
  "/subscriptions/a1b2c3d4-1234-5678-abcd-ef1234567890",
  "/subscriptions/b2c3d4e5-2345-6789-bcde-fg2345678901"
]

# Or scoped to the entire tenant (management group root):
"AssignableScopes": [
  "/providers/Microsoft.Management/managementGroups/tenant-root-group"
]

Best practice: start from the closest built-in role When creating a custom role, start from the JSON of the closest built-in role and modify it. Use az role definition list --name "Contributor" --output json to export the definition. This ensures you don't accidentally miss a required action that the built-in role includes through a wildcard.

Privileged Identity Management (PIM)

Privileged Identity Management is the Entra ID P2 feature that converts permanent ("standing") privileged access into time-bounded, auditable, just-in-time access. It is not optional in any enterprise environment — it is the control that makes privileged access manageable at scale without accepting permanent standing risk.

Active vs. Eligible assignments

Assignment Type	What it means	When to use
Active assignment	The principal has the role right now, continuously, without any activation step	Break-glass accounts, automation service accounts, read-only monitoring roles. Never for Owner, Contributor, or any privileged role.
Eligible assignment	The principal has the ability to activate the role, but it is not active until they request activation through PIM	All privileged roles in production. Engineers activate when they need to perform privileged work, with a business justification, and the activation expires.

PIM activation workflow

1. Engineer opens PIM portal → "My roles" → selects Eligible role 2. Engineer provides business justification, optionally an incident ticket number 3. If approval required: approver receives notification and must approve 4. Role becomes Active for the configured duration (e.g. 4 hours maximum) 5. Engineer performs privileged work within the activation window 6. Role expires automatically — or engineer deactivates it early

PIM for Azure Resources vs. PIM for Entra ID roles PIM covers two distinct domains. PIM for Azure Resources manages Azure RBAC roles (Owner, Contributor, etc.) scoped to subscriptions, resource groups, and resources. PIM for Entra ID roles manages Entra directory roles (Global Administrator, Privileged Role Administrator, etc.). Both require Entra P2, but they are configured in different blades within the PIM interface.

Permanent Owner assignments in production are a compliance failure In any regulated environment (SOC 2, ISO 27001, PCI-DSS, HIPAA), a finding of "permanent standing Owner or Contributor assignments on production subscriptions" will result in an audit finding. The correct implementation is: remove all permanent privileged assignments; configure Eligible assignments in PIM with approval workflows, MFA enforcement on activation, and maximum 4-hour windows. This is not a recommendation — it is an expectation.

Deny Assignments

A deny assignment blocks a security principal from performing specific actions, even if a role assignment would otherwise allow those actions. Deny takes absolute precedence over allow.

How deny assignments are created

You cannot create deny assignments directly via the Azure RBAC interface. They are created by specific Azure mechanisms:

Azure Blueprints (now deprecated — being replaced by Deployment Stacks) — could lock down resources deployed by the blueprint
Managed Applications — the managed resource group managed by a publisher has deny assignments to prevent the consumer from modifying the managed resources
Azure Deployment Stacks — the modern replacement for Blueprints; deny assignments protect stack-managed resources from out-of-band changes

Exam trap: deny assignment exemptions Even with a deny assignment in place, there is always an exemption: the principal that created the deny assignment (or the assignment's designated "exempt principals" list) is not blocked by it. This prevents a lockout scenario. Also: deny assignments do not apply to actions performed as a Global Administrator who has elevated to User Access Administrator at the root management group scope.

Classic Administrator Roles (Deprecated — Know for the Exam)

Azure has a legacy model from the pre-RBAC era with three classic administrator roles. These have been fully deprecated and removed from new subscriptions, but the exam may still reference them. Know what they were:

Classic Role	What it was equivalent to	Status
Account Administrator	Billing owner of the subscription (the person who signed up)	Deprecated; replaced by billing roles in MCA/EA
Service Administrator	Equivalent to Owner at subscription scope	Deprecated; replaced by RBAC Owner
Co-Administrator	Equivalent to Owner at subscription scope (up to 200 per subscription)	Deprecated; replaced by RBAC Owner assignments

RBAC Best Practices for Enterprise Environments

Assign roles to groups, not individual users. When a user leaves and is disabled, their individual role assignments linger until cleaned up. Group-based assignments are removed automatically when the user is removed from the group.
Use PIM for all privileged roles. Any role that can create, modify, or delete resources or manage access should be Eligible in PIM, not Active.
Apply least privilege — start with Reader, escalate with justification. The default access posture for any new team member should be Reader at the subscription scope. Escalation to Contributor or above requires documented justification.
Never use Owner at subscription scope for day-to-day operations. Owner at subscription scope is appropriate only for break-glass accounts (held in PIM as Eligible) and automation that specifically requires access management.
Conduct regular access reviews. Entra ID P2 provides Access Reviews. Schedule quarterly reviews for privileged role holders. Remove access that hasn't been used in 90+ days (detectable via Entra sign-in and audit logs).
Prefer resource-group-scoped assignments over subscription-scoped. Narrower scope = smaller blast radius. Assign roles at the most specific scope that satisfies the requirement.

The governance test: can you answer these questions? For any Azure environment, you should be able to answer: Who can create role assignments? Who has standing Owner access? When was each privileged assignment last used? If you cannot answer these quickly, your RBAC posture needs work — start with PIM and Access Reviews.

Hands-On: Inspect and Author RBAC in the Portal

Check your effective access: Open any subscription or resource group → Access control (IAM) → View my access. This shows all role assignments that apply to you at this scope — including inherited assignments from parent scopes. Note the "Inherited from" column.
Inspect a built-in role definition: In Access control (IAM) → Roles, find Contributor and click the three-dot menu → View. Examine the JSON definition. Note Actions: ["*"], the NotActions list (which includes Microsoft.Authorization/*/Write and Microsoft.Authorization/*/Delete — this is why Contributor cannot manage access), and the empty DataActions.
Create a custom role via JSON: In Access control (IAM) → Add → Add custom role. Start from scratch. Name it VM-StartStop-Operator. On the JSON tab, paste a definition that includes only Microsoft.Compute/virtualMachines/start/action, Microsoft.Compute/virtualMachines/deallocate/action, Microsoft.Compute/virtualMachines/restart/action, and Microsoft.Compute/virtualMachines/read. Set AssignableScopes to your subscription. Review and create.
Verify scope inheritance: Assign the Reader role to any user at the subscription scope. Then navigate to any resource group inside that subscription → Access control (IAM) → Role assignments. You will see the Reader assignment appear here, labelled as "Inherited" — this demonstrates the scope inheritance model.

Checkpoint You should be able to read any role assignment in the portal and explain: what principal has what actions, at what scope, and whether those permissions are inherited or directly assigned.

Primary source for this lesson What is Azure role-based access control (Azure RBAC)? — Microsoft Learn

Also read: Understand Azure role definitions and Configure PIM for Azure resources. The role definitions article covering Actions vs. DataActions is the most-tested technical distinction in this domain.

Questions for your teacher (the AI agent)
This lesson covered the mechanics of RBAC. There is significant depth to explore — ask your teacher to go deeper on any of these:

Walk me through authoring a custom role JSON definition for a "read-only Key Vault auditor" who can list secrets but not read their values.
How does Azure RBAC evaluation order work when a user has multiple role assignments at different scopes — what is the exact resolution algorithm?
How do Deployment Stacks deny assignments work differently from Blueprint deny assignments, and why are Stacks the better choice?
What happens to PIM eligible assignments when a user's Entra P2 license is removed — do they immediately lose access?

Coming up: Lesson 04 — Azure Policy: Governance at Scale RBAC controls who can act. Azure Policy controls what configurations are allowed — regardless of who is asking. In the next lesson, we cover the complete policy effect model (Audit, Deny, Modify, DeployIfNotExists, and more), policy initiatives for compliance frameworks, remediation tasks, and the difference between exemptions and exclusions. Policy is what makes governance operate at thousands-of-resources scale.

Why RBAC is the Cornerstone of Azure Security

The Four Components of a Role Assignment

Who can create role assignments?

Role Definitions: Structure and Semantics

Actions vs. DataActions — the most important distinction

Built-In Roles to Memorise

General-purpose roles

Service-specific roles (exam-relevant)

Custom Role Definitions

Key facts about custom roles

AssignableScopes — a common exam source of confusion

Privileged Identity Management (PIM)

Active vs. Eligible assignments

PIM activation workflow

Deny Assignments

How deny assignments are created

Classic Administrator Roles (Deprecated — Know for the Exam)

RBAC Best Practices for Enterprise Environments

Hands-On: Inspect and Author RBAC in the Portal

Check Your Understanding