Users, Groups, and Role Assignments

Azure Role-Based Access Control (RBAC) is the authorisation system that controls who can do what on Azure resources. Instead of assigning permissions directly to individuals, you assign roles to security principals (users, groups, service principals, or managed identities) at a specific scope. This separation keeps permissions manageable as your organisation grows.

Every RBAC assignment involves three components. A security principal is who gets access (user, group, or managed identity). A role definition is what actions are allowed (e.g., read VMs, write to storage). A scope is where access applies — from broadest to narrowest: management group, subscription, resource group, or individual resource. Access is inherited downward through the scope hierarchy.

Azure provides hundreds of built-in roles. The four most commonly used across all resource types are: Owner — full access including the ability to assign roles to others; Contributor — full access to create and manage resources but cannot grant access to others; Reader — view-only access; and User Access Administrator — can manage role assignments without contributing to resources themselves.

A role assignment grants the specified security principal the permissions defined in the role definition at the specified scope. Role assignments propagate to all child scopes — assigning Contributor at the resource group level gives Contributor access to every resource within that group. Assigning at subscription level gives Contributor across all resource groups in that subscription.

The principle of least privilege states that every identity should have only the minimum permissions necessary to perform its job. In Azure RBAC this means: prefer Reader over Contributor where write is not needed, prefer resource-group scope over subscription scope, and use specific resource-level roles (e.g., Storage Blob Data Contributor) instead of the broad Contributor role where possible.

When no built-in role matches your requirements exactly, you can create a custom role. A custom role definition specifies a set of Actions (control-plane operations permitted), NotActions (excluded from the permitted set), DataActions (data-plane operations on resources like reading blob content), and AssignableScopes (subscriptions or management groups where the role can be assigned).

Assigning roles to groups rather than individual users is a best practice. When a new developer joins the DevTeam, you add them to the DevTeam security group in Entra ID — they automatically inherit all role assignments the group holds, without any Azure RBAC changes. This single management point prevents scattered individual assignments that become difficult to audit or revoke at offboarding.

A service principal is an identity used by applications, scripts, and automation tools to authenticate to Azure and access resources. Unlike a user identity, service principals have no interactive sign-in capability. You create them from App Registrations in Entra ID, then assign RBAC roles at the appropriate scope — for example, giving a CI/CD pipeline Contributor access to a single resource group to deploy infrastructure.

Deny assignments block specific actions for security principals even if a role assignment would otherwise permit them. Unlike role assignments, deny assignments cannot be created directly by administrators — they are attached by Azure Blueprints or managed applications to prevent users from modifying protected resources. A deny assignment takes precedence over any matching role assignment.

Privileged Identity Management (PIM) is an Entra ID P2 feature that provides just-in-time privileged access. Instead of permanently assigning an Owner or Global Administrator role, you make users eligible for that role. When they need it, they activate the assignment for a time-limited window (e.g., 1-8 hours), optionally requiring an approval workflow and justification. This dramatically reduces the standing attack surface from over-privileged accounts.

Access Reviews (Entra ID P2) are periodic automated reviews that ask resource owners or managers to confirm whether their team members still need their current role assignments. Reviewers approve or deny continued access directly from the review interface. This catches stale permissions left over from role changes, project completions, or employee departures — a key requirement for regulatory compliance programmes.

Test your understanding of Microsoft Azure Fundamentals (AZ-900) concepts from this lesson.

In this lesson you learned: Azure RBAC assigns roles to security principals at a specific scope, the principle of least privilege means granting only the minimum permissions required, and PIM provides just-in-time activation for high-privilege roles instead of permanent assignment. Next up we cover Multi-Factor Authentication and Conditional Access in Entra ID.