Azure RBAC Role Assignments at Scale

Azure RBAC is an authorization system built on Azure Resource Manager (ARM) that provides fine-grained access management for Azure resources. Unlike Azure Active Directory (Azure AD) authentication (who you are), RBAC controls authorization (what you can do). It is the primary mechanism for enforcing the principle of least privilege in Azure. The exam expects you to understand that RBAC is not a firewall or network control; it governs control-plane operations—actions performed via Azure Portal, Azure CLI, PowerShell, or REST API against the Azure Resource Manager endpoint. Data-plane operations (e.g., reading a blob in a storage account) require additional authorization mechanisms like storage account keys or Azure AD authentication with RBAC for data operations.

Every RBAC decision involves three components: a security principal, a role definition, and a scope. When a principal makes a request to ARM, the authorization system evaluates all applicable role assignments. The evaluation process:

Role assignments are stored in the ARM metadata store and replicated globally. There is no caching delay—changes are effective within a few minutes (typically 5 minutes, but can be up to 30 minutes in rare cases). The exam may test that role assignment changes are eventually consistent.

Security Principals:

Role Definitions:

Scopes:

Role Assignment Limits:

Default Values:

Azure CLI:

# Create a role assignment
az role assignment create --assignee "user@contoso.com" --role "Contributor" --scope "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/MyRG"

# List role assignments for a user
az role assignment list --assignee "user@contoso.com" --all

# List role definitions
az role definition list --name "Contributor"

# Create a custom role
az role definition create --role-definition '{"Name": "Custom VM Operator", "Description": "Can manage VMs but not network", "Actions": ["Microsoft.Compute/virtualMachines/*", "Microsoft.Compute/disks/read"], "NotActions": ["Microsoft.Compute/virtualMachines/delete"], "AssignableScopes": ["/subscriptions/00000000-0000-0000-0000-000000000000"]}'

PowerShell:

# Create a role assignment
New-AzRoleAssignment -SignInName "user@contoso.com" -RoleDefinitionName "Contributor" -ResourceGroupName "MyRG"

# Get role assignments
Get-AzRoleAssignment -SignInName "user@contoso.com"

Azure Portal:

In large enterprises, manually assigning roles to individual users is impractical. Best practices include:

For example, to assign the Reader role to a group at multiple subscriptions, you could loop through subscriptions with a script:

subscriptions=$(az account list --query "[].id" -o tsv)
for sub in $subscriptions; do
    az role assignment create --assignee "group-id" --role "Reader" --scope "/subscriptions/$sub"
done

Azure also supports Azure Lighthouse for managing RBAC across tenants (e.g., managed service providers).

A multinational company with 500 subscriptions uses Azure RBAC to manage access. They create a management group hierarchy: Root -> Business Units (e.g., Finance, Engineering) -> Departments -> Subscriptions. They assign the Reader role to a central audit group at the Root management group so auditors can read all resources across the entire tenant. They assign Contributor to development teams at their respective department management groups. This reduces the total number of role assignments from potentially thousands to a few hundred. However, they must be careful: assigning a role at a high scope grants permissions to all child subscriptions, which may violate least privilege. They mitigate by using Azure Policy to deny certain actions even for Contributors (e.g., deny creation of public IPs). They also use PIM for privileged roles like Owner at the subscription scope, requiring approval for activation.

An MSP manages multiple customer tenants. They use Azure Lighthouse to delegate access to customer subscriptions. For each customer, they create a role assignment at the subscription scope using the built-in 'Managed Services Registration Assignment Delete' role (which allows managing delegated resources). They assign this role to a group in the MSP's tenant that contains their engineers. This allows engineers to manage customer resources without needing separate accounts in each customer tenant. The key challenge is tracking which customers have delegated which subscriptions. They use Azure Policy to audit that only approved groups have the delegated role. Misconfiguration often occurs when the MSP assigns the Owner role instead of a more limited role, giving themselves excessive permissions.

A company runs a microservices application on Azure Kubernetes Service (AKS). Each microservice needs to access specific Azure resources (e.g., a storage account or Key Vault). They assign a user-assigned managed identity to each pod (via AKS pod identity) and then create RBAC role assignments for that managed identity at the resource scope (e.g., Storage Blob Data Contributor on a specific storage account). This avoids storing credentials in code. A common mistake is assigning the managed identity a broad role like Contributor at the subscription scope, which violates least privilege. Instead, they create custom roles with only the necessary data actions (e.g., Microsoft.Storage/storageAccounts/blobServices/containers/read). Performance is not an issue because RBAC evaluation is fast, but they must ensure the managed identity's role assignment exists before the pod starts. They automate role assignment creation using Terraform or ARM templates as part of the infrastructure deployment.