Role-Based Access Control (RBAC)

Azure RBAC is an authorization system built on Azure Resource Manager that provides fine-grained access management for Azure resources. It allows you to grant users, groups, service principals, or managed identities exactly the permissions they need to perform their jobs, following the principle of least privilege. RBAC is not about authentication (verifying who you are); it's about authorization (what you are allowed to do). On the AZ-900 exam, you must understand the difference: Azure AD handles authentication, while RBAC handles authorization.

Before RBAC, managing permissions in Azure was cumbersome. Administrators had to either grant full contributor access to everyone (too permissive) or manage access individually using resource-specific access control lists (ACLs) that were inconsistent across services. RBAC provides a unified, role-based model that works across all Azure services (except some data plane operations like blob storage, which use separate authorization). For example, a company might have a team of developers who need to create and manage virtual machines but should not be able to delete the resource group. With RBAC, you assign the 'Virtual Machine Contributor' role to the team at the resource group scope, giving them exactly the needed permissions.

When a security principal attempts to perform an action (e.g., create a VM), Azure Resource Manager checks all role assignments that apply to that principal (including group memberships) at the scope of the target resource. If any assignment includes the required action, the request is allowed. If multiple assignments deny the action, deny takes precedence (explicit deny overrides allow).

- Built-in Roles: Azure provides over 70 built-in roles, such as Owner, Contributor, Reader, User Access Administrator, and service-specific roles like Virtual Machine Contributor. The most common roles for AZ-900 are: - Owner: Full access to all resources, including the right to delegate access to others. - Contributor: Can create and manage resources but cannot grant access to others. - Reader: Can view resources but cannot make changes. - User Access Administrator: Can manage user access to resources (useful for delegating RBAC management). - Custom Roles: If built-in roles don't meet your needs, you can create custom roles with specific actions. Custom roles are defined in JSON and can be scoped to a subscription or management group. - Azure AD vs. RBAC: Azure AD is the identity provider (authentication); RBAC uses Azure AD objects as security principals but is separate. You can have a user in Azure AD but no RBAC permissions, meaning they can log in but cannot see any resources.

On-premises, you might use Active Directory Domain Services (AD DS) with group policies and ACLs. AD DS uses a flat permission model where permissions are often set directly on files or folders using NTFS permissions. In contrast, Azure RBAC is centralized, role-based, and scoped to Azure resources. RBAC is also more granular: you can grant 'read' access to all VMs in a resource group without affecting other resource types. On-premises, you would need to set ACLs on each VM or use group policies, which is more complex and less flexible. RBAC also supports 'deny assignments' (explicit deny), which are rare in on-premises environments.

You can manage RBAC through the Azure portal, Azure CLI, PowerShell, or REST API. In the portal, navigate to any resource, subscription, or resource group, then select 'Access control (IAM)'. Here you can view role assignments, add new ones, or check effective permissions. Using Azure CLI, common commands include:

# Assign the 'Reader' role to a user at the subscription scope
az role assignment create --assignee "user@contoso.com" --role "Reader" --scope "/subscriptions/12345678-1234-1234-1234-123456789abc"

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

# Create a custom role
az role definition create --role-definition '{"Name": "My Custom Role", "Description": "Can read and write VMs", "Actions": ["Microsoft.Compute/virtualMachines/*"], "AssignableScopes": ["/subscriptions/12345678-1234-1234-1234-123456789abc"]}'

A deny assignment is a special type of role assignment that explicitly denies actions, even if a role assignment allows them. Deny assignments are created by Azure Blueprints or managed applications, and they take precedence over all allow assignments. For example, if you assign a deny assignment that denies 'Microsoft.Compute/virtualMachines/write', no user can create or modify VMs, even if they are an Owner. Deny assignments are visible in the portal under 'Access control (IAM)' > 'Deny assignments' tab.

Permissions are inherited from higher scopes to lower scopes. For example, if you assign the 'Reader' role to a user at the subscription scope, they automatically have read access to all resource groups and resources within that subscription. If you then assign the 'Contributor' role at a specific resource group, the user will have Contributor permissions on that resource group (since Contributor includes all Reader permissions plus write actions). However, if you assign a role at a lower scope, it does not affect higher scopes. This hierarchical model is crucial for exam questions: always consider the scope when evaluating effective permissions.

It's easy to confuse RBAC roles with Azure AD roles (like Global Administrator). Azure AD roles grant permissions to manage Azure AD itself (e.g., reset user passwords, manage groups). RBAC roles grant permissions to manage Azure resources (e.g., VMs, storage accounts). They are separate systems, though both use Azure AD identities. A user can be a Global Administrator in Azure AD but have no RBAC permissions, meaning they can manage Azure AD but cannot see any Azure resources. Conversely, a user can be an RBAC Owner of a subscription but have no Azure AD administrative rights. The exam tests this distinction frequently.

A software company has a development team that needs to create and manage virtual machines in a shared subscription. The team also needs to view storage accounts but not modify them. The administrator creates an Azure AD group called 'DevTeam' and adds all developers to it. Then, the administrator assigns the 'Virtual Machine Contributor' role to the group at the subscription scope. This gives all developers the ability to create, start, stop, and delete VMs. However, they cannot access storage accounts (except by reading VM disk storage, which is part of VM management). To allow read access to storage, the administrator also assigns the 'Reader' role at the subscription scope. Now developers have both permissions. If a new developer joins, they are simply added to the 'DevTeam' group, and they automatically get the permissions. If a developer leaves, removing them from the group revokes access instantly. This setup is scalable and follows least privilege. Cost is not directly affected by RBAC, but proper RBAC can reduce security incidents and operational overhead.

A financial services company needs to ensure that no single person can approve and deploy changes to production. They create two custom roles: 'Change Approver' (can approve changes but not deploy) and 'Change Deployer' (can deploy but not approve). They assign these roles to different individuals at the resource group scope for the production environment. Additionally, they use Azure Blueprints to apply a deny assignment that prevents any user from deleting the resource group. This ensures compliance with regulatory requirements. If RBAC is set up incorrectly—for example, if the same person is assigned both roles—the separation of duties is broken. The company uses Azure AD Privileged Identity Management (PIM) to require approval for activating privileged roles, adding another layer of security.

A consulting firm is hired to audit an Azure environment. The administrator needs to give the consultants read-only access to all resources in a subscription but must not allow them to see any secrets or keys. The administrator assigns the 'Reader' role to the consultants' Azure AD guest users at the subscription scope. However, the Reader role includes read access to secrets in Key Vault, which is a problem. To restrict this, the administrator creates a custom role that includes all read actions except 'Microsoft.KeyVault/vaults/secrets/read'. This custom role is then assigned to the consultants. The exam tests that custom roles can be used to fine-tune permissions beyond built-in roles. If the administrator mistakenly assigns the built-in Reader role, the consultants could potentially read secrets, leading to a data breach.