This chapter covers Azure Role-Based Access Control (RBAC) role assignments, a core identity governance mechanism for managing access to Azure resources. RBAC is a critical topic for the AZ-104 exam, with approximately 15-20% of questions touching on role assignments, role definitions, scopes, and built-in vs custom roles. Understanding RBAC is essential for any Azure administrator because it is the primary way to enforce the principle of least privilege and control who can do what across your Azure environment. This chapter will give you the deep technical knowledge needed to answer exam questions confidently and to implement RBAC correctly in production.
Jump to a section
Azure RBAC is like a corporate building with multiple floors, rooms, and secure areas. The building is your Azure subscription, and each employee (user or group) needs a badge to enter. But not all badges are the same. A 'Reader' badge lets you walk through the lobby and look at the floor directory—you can see what rooms exist, but you can't open any doors. A 'Contributor' badge lets you enter rooms and rearrange furniture, but you can't change the building's security policies or hire new employees. An 'Owner' badge gives you full access: you can unlock any door, change the floor plan, and even issue or revoke badges for others. The badge system is managed by a security office (Azure AD) that defines roles—each role is a template of permissions, like a pre-set list of doors you can open. When you assign a role to someone, you specify a 'scope'—the floor, wing, or specific room they can access. If you assign the 'Reader' role on the entire building (subscription), they can see everything; if you assign it only on the 3rd floor (resource group), they can only see that floor. The system checks the badge at every door: when an employee tries to open a door (perform an action), the system checks their badge against the door's access list (role definition) and the scope where the badge was issued. If the badge lacks that specific permission, the door stays locked and an audit log records the attempt.
What is Azure RBAC and Why Does It Exist?
Azure Role-Based Access Control (RBAC) is an authorization system built on Azure Resource Manager (ARM) that provides fine-grained access management for Azure resources. Unlike Azure AD authentication (which verifies identity), RBAC handles authorization—determining what actions an authenticated user, group, service principal, or managed identity can perform on a given resource. RBAC is essential for implementing the security principle of least privilege, ensuring that identities have only the permissions necessary to perform their tasks.
RBAC is enforced at the Azure Resource Manager layer, not at the resource itself. Every management operation (creating a VM, reading a blob, deleting a network security group) is an ARM API call. ARM intercepts every call and checks whether the caller has the required RBAC permission for the target resource at the specified scope. This means RBAC applies to all Azure resource types consistently.
How RBAC Works Internally
RBAC uses a three-part model: Security Principal, Role Definition, and Scope. When a request is made to ARM, the following steps occur:
Authentication: ARM verifies the identity of the caller via Azure AD. The caller can be a user, group, service principal, or managed identity.
Authorization: ARM retrieves all role assignments that apply to the caller at the requested scope (and above, due to inheritance).
Permission Evaluation: For each role assignment, ARM checks the role definition to see if it includes the action being attempted. If any assignment grants the action (and no deny assignment blocks it), the request is allowed.
Deny Assignments: Blueprints and managed applications can create deny assignments that explicitly block an action, even if a role assignment grants it. Deny assignments take precedence over role assignments.
Role assignments are stored in Azure Resource Manager and replicated across regions. The maximum number of role assignments per subscription is 4,000 (including assignments at root management group, management groups, subscription, resource group, and resource scopes). This limit is per subscription, not per scope.
Key Components: Role Definitions, Scopes, and Assignments
Role Definition: A collection of permissions, typically called a role. Each role definition has a name, description, ID, and a set of Actions, NotActions, DataActions, and NotDataActions. Actions are ARM operations (e.g., Microsoft.Compute/virtualMachines/start/action). NotActions are subtracted from Actions. DataActions apply to data plane operations (e.g., reading a blob), while NotDataActions subtract from DataActions. Built-in roles include Owner, Contributor, Reader, and many resource-specific roles like Virtual Machine Contributor.
Scope: The boundary within which a role assignment applies. Scopes are hierarchical: Management Group > Subscription > Resource Group > Resource. Permissions are inherited from higher scopes. For example, assigning the Reader role at the subscription scope grants read access to all resource groups and resources in that subscription.
Role Assignment: The process of binding a security principal to a role definition at a particular scope. A role assignment is an object with properties: PrincipalId (the Azure AD object ID), RoleDefinitionId, and Scope. When you assign a role, Azure creates an assignment object that is evaluated at authorization time.
Defaults, Limits, and Timers
Maximum role assignments per subscription: 4,000 (including assignments at root management group, management groups, subscription, resource group, and resource scopes). This is a hard limit; exceeding it will block new assignments.
Maximum role assignments per management group: 500.
Propagation time: Role assignments are eventually consistent. Changes typically propagate within 5 minutes (sometimes up to 30 minutes in rare cases). This is not a timer but a replication delay.
Built-in roles: Approximately 70+ built-in roles. Custom roles can be created with up to 4,096 characters in the description and up to 4,096 Actions/NotActions/DataActions/NotDataActions combined.
Role assignment deletion: When you delete a role assignment, the change propagates similarly to creation. The principal loses access after propagation.
Configuration and Verification Commands
Azure CLI:
# Create a role assignment
ez role assignment create --assignee <object-id> --role "Reader" --scope "/subscriptions/<subscription-id>/resourceGroups/<rg-name>"
# List role assignments for a user
ez role assignment list --assignee <user-principal-name> --all
# List role assignments at a scope
ez role assignment list --scope "/subscriptions/<subscription-id>/resourceGroups/<rg-name>"
# Verify effective permissions
ez role assignment list --assignee <object-id> --include-inherited --allAzure PowerShell:
# Create a role assignment
New-AzRoleAssignment -ObjectId <object-id> -RoleDefinitionName "Reader" -ResourceGroupName "<rg-name>"
# List role assignments
Get-AzRoleAssignment -ObjectId <object-id> -ExpandPrincipalGroups
# Get role definitions
Get-AzRoleDefinition | Where-Object {$_.IsCustom -eq $false} | Format-Table Name, IdAzure Portal: Navigate to the resource, select "Access control (IAM)", then "Add role assignment". Choose role, assign access to user/group/managed identity, and select scope.
Interaction with Related Technologies
Azure AD Privileged Identity Management (PIM): PIM provides time-bound role assignments and just-in-time activation. For Azure RBAC, PIM can be used to activate eligible assignments for Azure resources (not just Azure AD roles). This is a premium feature.
Azure Blueprints: Blueprints can assign roles as part of artifact definitions. When a blueprint is assigned, it creates role assignments for specified principals at the blueprint's scope.
Azure Policy: Policy enforces rules on resources, but does not grant access. RBAC controls who can create/modify resources; policy controls what resources are allowed.
Azure AD roles vs Azure RBAC roles: Azure AD roles manage access to Azure AD itself (e.g., Global Administrator) and Microsoft 365 services. Azure RBAC roles manage access to Azure resources (VMs, storage, etc.). They are separate but can overlap in some cases (e.g., User Access Administrator can manage RBAC assignments).
Custom Roles
Custom roles are defined using a JSON document with the same structure as built-in roles. They can be created at subscription or management group scope. Example custom role JSON:
{
"Name": "Virtual Machine Operator",
"Id": "<generated-guid>",
"IsCustom": true,
"Description": "Can start, stop, and restart VMs, but not create or delete them.",
"Actions": [
"Microsoft.Compute/virtualMachines/start/action",
"Microsoft.Compute/virtualMachines/restart/action",
"Microsoft.Compute/virtualMachines/deallocate/action",
"Microsoft.Compute/virtualMachines/read"
],
"NotActions": [
"Microsoft.Compute/virtualMachines/write",
"Microsoft.Compute/virtualMachines/delete"
],
"DataActions": [],
"NotDataActions": [],
"AssignableScopes": [
"/subscriptions/12345678-1234-1234-1234-123456789abc"
]
}Custom roles can only be assigned within the scopes listed in AssignableScopes. The AssignableScopes must include at least one management group, subscription, or resource group. You cannot use a resource as an assignable scope.
Inheritance and Effective Permissions
Permissions are cumulative and inherited. A user assigned the Reader role at the subscription scope gets read access to all resource groups and resources in that subscription. If the same user is also assigned the Contributor role at a specific resource group, they have both read (from subscription) and write (from resource group) on that resource group. The effective permissions are the union of all allowed actions from all assignments, minus any deny assignments.
Deny assignments are created by Azure Blueprints or managed applications. They cannot be created directly via RBAC. A deny assignment explicitly blocks an action even if a role assignment grants it. For example, a blueprint can deny the ability to delete a specific resource. Deny assignments are evaluated after role assignments, and they always take precedence.
Conditional Access and RBAC
Conditional Access policies in Azure AD apply to access to Azure management portals and APIs, but they do not directly affect RBAC permissions. Conditional Access can block or require MFA for signing in to Azure, but once signed in, RBAC determines what the user can do. This means a user might be able to sign in but have no RBAC permissions, or they might have RBAC permissions but be blocked by Conditional Access from signing in entirely.
Identify the Security Principal
Determine who needs access: a user, group, service principal, or managed identity. For groups, note that Azure AD groups can be security groups or Microsoft 365 groups. Service principals are used by applications and automation. Managed identities are a special type of service principal automatically managed by Azure for Azure resources like VMs or App Services. You must have the object ID (GUID) of the principal from Azure AD. You cannot assign roles to organizational groups (like 'All Users') or dynamic groups unless they are security groups.
Select the Role Definition
Define the Scope
Determine the scope at which the role assignment will apply. Scopes are hierarchical: management group, subscription, resource group, or individual resource. The scope is specified as an Azure resource ID (e.g., /subscriptions/{id}/resourceGroups/{rg}). Permissions are inherited to all child scopes. For example, assigning a role at the subscription scope applies to all resource groups and resources within that subscription. You can also assign at a resource scope to limit access to a specific resource only.
Create the Role Assignment
Use Azure Portal (Access Control IAM), Azure CLI, Azure PowerShell, or REST API to create the role assignment. The assignment binds the principal, role, and scope. In the Portal, you navigate to the scope's IAM blade, click 'Add role assignment', select the role, select the principal, and confirm. In CLI: az role assignment create --assignee <object-id> --role "RoleName" --scope "/subscriptions/...". After creation, the assignment is stored in ARM and replicated. Propagation typically takes up to 5 minutes but can be longer.
Verify and Monitor Access
After the assignment, verify that the principal has the expected permissions. Use the 'Check access' tab in the IAM blade to test a specific user's permissions at a scope. Use Azure CLI: az role assignment list --assignee <object-id> --all --include-inherited. Also, monitor role assignments using Azure Monitor activity logs. Changes to role assignments are logged as administrative operations. You can set up alerts for critical role assignments (e.g., Owner role assigned to a user).
Enterprise Scenario 1: Segregating Duties for a Multi-Team Subscription
A large enterprise has a single Azure subscription shared by development, QA, and operations teams. The security team needs to ensure that developers can only deploy to dev resource groups, QA can only test in QA resource groups, and operations can manage production resources. The solution is to create three resource groups (dev-rg, qa-rg, prod-rg) and assign the Contributor role to each team only on their respective resource group. Additionally, the operations team gets Reader access to dev and QA for visibility. This is configured by creating role assignments at the resource group scope. The security team must be careful not to assign roles at the subscription scope, which would grant permissions across all resource groups. Common misconfiguration: assigning Contributor at subscription scope to all users, which violates least privilege. In production, if a developer accidentally deletes a production resource, the audit log will show the user's object ID and the role assignment that allowed the action.
Enterprise Scenario 2: Using Managed Identities for Application Access
A company runs a web application on Azure App Service that needs to read blobs from a storage account. Instead of storing credentials in connection strings, the developers enable a system-assigned managed identity for the App Service. They then assign the 'Storage Blob Data Reader' role to the managed identity at the storage account scope. The application uses Azure SDK to obtain a token for the managed identity and accesses blobs. This eliminates credential management. In production, if the managed identity is accidentally deleted, the role assignment becomes orphaned (the principal no longer exists). Azure does not automatically clean up orphaned assignments; they remain but are ineffective. Administrators must periodically audit for orphaned assignments using Azure CLI: az role assignment list --all --query "[?principalType=='ServicePrincipal' && principalId=='<nonexistent>']".
Enterprise Scenario 3: Custom Roles for Compliance
A financial services company needs to enforce that only specific users can create virtual machines in a regulated subscription, but those users should not be able to delete VMs or modify networking. The built-in 'Virtual Machine Contributor' role allows creating, managing, and deleting VMs, which is too permissive. The company creates a custom role 'VM Operator' that includes Microsoft.Compute/virtualMachines/read, write (for creation), start/action, restart/action, deallocate/action, but excludes delete and write to network interfaces. The custom role is created at the subscription scope and assigned to a security group containing authorized operators. The custom role JSON is stored in ARM and can be exported for auditing. A common pitfall: forgetting to add 'Microsoft.Compute/virtualMachines/read' to the custom role, which prevents users from seeing VMs in the portal even though they can create them.
What AZ-104 Tests on RBAC Role Assignments
The AZ-104 exam objective 'Manage Azure identities and governance' includes subtopics: 'Configure Azure roles' and 'Create and manage Azure role-based access control (RBAC)'. Specific areas tested:
Distinguishing between Azure AD roles and Azure RBAC roles.
Understanding built-in roles: Owner, Contributor, Reader, User Access Administrator, and resource-specific roles like Virtual Machine Contributor, Storage Blob Data Contributor, etc.
Scope inheritance: knowing that permissions flow down the hierarchy (management group > subscription > resource group > resource).
Creating custom roles: understanding the JSON structure, especially AssignableScopes, Actions, NotActions.
Deny assignments: knowing they are created by Blueprints/managed apps and override role assignments.
Role assignment limits: 4,000 per subscription, 500 per management group.
Propagation delays: up to 5 minutes (sometimes 30).
Using PIM for Azure RBAC: time-bound assignments and activation.
Common Wrong Answers and Why Candidates Choose Them
Mistaking Azure AD roles for Azure RBAC roles: Candidates see 'Global Administrator' and think it grants full access to Azure resources. In reality, Global Administrator has only 'User Access Administrator' equivalent for Azure RBAC, meaning they can grant themselves Owner, but do not automatically have Owner access.
Thinking inheritance works upward: Candidates assume assigning a role at resource group scope gives permissions at subscription scope. Inheritance is downward only.
Confusing Deny assignments with role assignments: Candidates think deny assignments can be created directly in IAM. Deny assignments are only created by Blueprints or managed applications.
Assuming role assignments are instant: Candidates expect immediate effect, but propagation can take up to 5 minutes (or more). The exam tests this with questions about 'a user reports they cannot access a resource 2 minutes after assignment'.
Misunderstanding custom role AssignableScopes: Candidates think custom roles can be assigned at any scope, but they are restricted to the scopes listed in AssignableScopes.
Specific Numbers, Values, and Terms
4,000 role assignments per subscription (hard limit).
500 role assignments per management group.
5 minutes typical propagation, up to 30 minutes.
Built-in role IDs: Owner (8e3af657-a8ff-443c-a75c-2fe8c4bcb635), Contributor (b24988ac-6180-42a0-ab88-20f7382dd24c), Reader (acdd72a7-3385-48ef-bd42-f606fba81ae7).
Role definition structure: Actions, NotActions, DataActions, NotDataActions.
AssignableScopes must include at least one management group, subscription, or resource group (not a resource).
Deny assignments have a higher priority than role assignments.
Edge Cases and Exceptions
Classic subscription administrators: Co-Administrator and Service Administrator are legacy roles that are equivalent to Owner. They are being phased out but still exist. The exam may ask about them.
User Access Administrator role: This role can manage RBAC assignments at a scope. It is the only built-in role that can grant the Owner role to others.
Resource-specific roles with DataActions: For data plane access (e.g., reading a blob), you need roles with DataActions like 'Storage Blob Data Reader'. The exam distinguishes between management plane (ARM) and data plane.
Orphaned role assignments: When a principal is deleted, the role assignment remains but is ineffective. The exam may ask about cleaning them up.
How to Eliminate Wrong Answers
If a question mentions 'access to Azure AD resources', it's about Azure AD roles, not RBAC.
If a question says 'assign at subscription scope', remember that permissions flow down, not up.
If a question mentions 'deny', think Blueprints or managed applications.
If a question asks about 'immediate access', look for an answer that mentions propagation delay.
For custom roles, check if the AssignableScopes includes the target scope; if not, the role cannot be assigned there.
RBAC uses three components: Security Principal, Role Definition, Scope.
Maximum 4,000 role assignments per subscription, 500 per management group.
Permissions are inherited downward from management group to resource.
Deny assignments (from Blueprints/managed apps) override role assignments.
Propagation delay: up to 5 minutes typical, 30 minutes worst case.
Custom roles require AssignableScopes (management group, subscription, or resource group).
User Access Administrator role can manage RBAC assignments at a scope.
Data plane access requires roles with DataActions (e.g., Storage Blob Data Reader).
Orphaned role assignments (deleted principal) remain but are ineffective; audit periodically.
Azure AD roles and Azure RBAC roles are separate; Global Admin does not grant Azure resource access.
These come up on the exam all the time. Here's how to tell them apart.
Azure RBAC Roles
Control access to Azure resources (VMs, storage, etc.)
Use ARM API for authorization
Scopes: management group, subscription, resource group, resource
Built-in roles include Owner, Contributor, Reader
Managed via IAM blade, CLI, PowerShell
Azure AD Roles
Control access to Azure AD itself and Microsoft 365 services
Use Azure AD Graph or Microsoft Graph for authorization
Scopes: tenant-wide or administrative unit
Built-in roles include Global Administrator, User Administrator
Managed via Azure AD Roles blade, Azure AD PowerShell
Mistake
Azure AD Global Administrator has full access to all Azure resources by default.
Correct
Global Administrator has only 'User Access Administrator' equivalent for Azure RBAC, meaning they can grant themselves Owner role but do not automatically have Owner permissions on resources. They must explicitly assign themselves a role.
Mistake
Role assignments are effective immediately.
Correct
Role assignments propagate via eventually consistent replication. Typical propagation is within 5 minutes, but can take up to 30 minutes in some cases.
Mistake
You can create deny assignments directly in the IAM blade.
Correct
Deny assignments can only be created by Azure Blueprints or managed applications. They cannot be created manually via IAM.
Mistake
Assigning a role at a resource group scope grants permissions to the subscription.
Correct
Inheritance is downward only. A role at resource group scope applies only to that resource group and its resources, not to the subscription or other resource groups.
Mistake
Custom roles can be assigned at any scope, including individual resources.
Correct
Custom roles can only be assigned within the scopes listed in the role's AssignableScopes property. AssignableScopes must be management groups, subscriptions, or resource groups—not individual resources.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Azure RBAC controls access to Azure resources (VMs, storage, etc.) using ARM, while Azure AD roles control access to Azure AD itself and Microsoft 365 services. RBAC uses scopes like subscription and resource group; AD roles are tenant-wide or administrative unit. They are separate systems; a Global Administrator does not automatically have access to Azure resources unless they assign themselves an RBAC role.
Role assignments are eventually consistent. Typical propagation is within 5 minutes, but in rare cases it can take up to 30 minutes. If a user reports they cannot access a resource shortly after assignment, advise them to wait and try again.
No. Custom roles can only be assigned within the scopes listed in the role's AssignableScopes property, which must be management groups, subscriptions, or resource groups. You cannot assign a custom role at an individual resource scope unless that resource is within an allowed assignable scope.
The role assignment becomes orphaned—it still exists in Azure but is ineffective because the principal no longer exists. Orphaned assignments count toward the 4,000 limit per subscription. You should periodically audit and remove orphaned assignments using Azure CLI or PowerShell.
You cannot create deny assignments directly. They are automatically created by Azure Blueprints or managed applications. For example, a blueprint can include a deny assignment to prevent deletion of certain resources. Deny assignments always take precedence over role assignments.
The maximum is 4,000 role assignments per subscription, including assignments at root management group, management groups, subscription, resource group, and resource scopes. If you exceed this limit, you cannot create new assignments until you delete some.
Yes, you can assign any Azure RBAC role, including Owner, to an Azure AD security group. This is a best practice for managing access at scale. Members of the group inherit the role's permissions.
You've just covered Azure RBAC Role Assignments — now see how well it sticks with free AZ-104 practice questions. Full explanations included, no account needed.
Done with this chapter?