4.3 Microsoft Entra Roles and Role-Based Access Control

Two separate role systems

Microsoft maintains two distinct role-based access control systems, and SC-900 specifically tests telling them apart.

Microsoft Entra roles (directory roles) control access to Microsoft Entra and Microsoft 365 resources — users, groups, applications, service principals, and Entra settings — via the Microsoft Graph API. Their scope is the tenant (organization-wide), with optional administrative-unit scoping. Examples include Global Administrator, User Administrator, Security Administrator, Helpdesk Administrator, and Privileged Role Administrator.

Azure roles (Azure RBAC) control access to Azure resources — virtual machines, storage accounts, databases, networks — through Azure Resource Manager. Their scope is flexible: management group → subscription → resource group → individual resource, inheriting downward. Examples include Owner, Contributor, Reader, and User Access Administrator.

How Azure RBAC is built

An Azure role assignment has three parts that the exam may ask you to name:

1. Security principal — who gets access (user, group, service principal, or managed identity).
2. Role definition — what they can do (a collection of permissions, e.g. read, write, delete). Azure ships 100+ built-in roles, and you can author custom roles.
3. Scope — where the access applies (management group, subscription, resource group, or single resource).

Azure RBAC is an additive, allow-only model: your effective permissions are the sum of all your role assignments at the relevant scope. To take permissions away, you use deny assignments (created by Azure, e.g. by Blueprints/Managed Apps), not by stacking conflicting roles. Assignments inherit downward, so a Contributor at the subscription level is a Contributor on every resource group and resource inside it.

• Principal + role definition + scope = a role assignment.
• Permissions are cumulative across assignments.
• Inheritance flows top-down through the scope hierarchy.

Interoperability and least privilege

A heavily tested fact: the two role systems do not share permissions. Microsoft Entra role permissions cannot be used in Azure custom role definitions, and Azure resource permissions cannot be used in Entra roles. They are administered separately. The one bridge is that a Global Administrator can toggle Access management for Azure resources to temporarily gain User Access Administrator rights over all Azure subscriptions — but that is an elevation action, not shared permissions.

Both systems exist to enforce least privilege: grant an identity only the role it needs for its task. If a scenario says an administrator has too much standing access, the fix is a narrower role plus Privileged Identity Management (Section 4.5), not a stronger authentication method.

Common role question traps

Do not answer MFA just because an administrator is involved — if the admin already signed in and the problem is excessive capability, the issue is authorization (roles), not authentication. Do not answer access review when the question asks for the initial model of assigning permissions; access reviews check whether access should continue. And watch the Entra-vs-Azure split: a question about managing Azure storage or VMs is Azure RBAC, while a question about managing directory users and groups is Entra roles.

• Sign-in strength problem → MFA / authentication.
• Permission model / who-can-do-what → roles and RBAC.
• Directory objects (users, groups) → Entra roles.
• Azure resources (VMs, storage) → Azure RBAC.
• Reducing always-on admin power → PIM.

Built-in roles, least privilege, and scope in practice

Microsoft strongly recommends using built-in roles before creating custom ones, and choosing the most specific role rather than a broad one. On the Azure RBAC side, the three foundational roles illustrate the least-privilege ladder: Reader can view resources but change nothing; Contributor can create and manage resources but cannot grant access to others; Owner has full control including the ability to assign roles. A frequent exam distinction is exactly that line — only Owner and User Access Administrator can manage other people's access; a Contributor cannot.

Granting Owner when Contributor would do is a least-privilege violation.

On the Entra side, Global Administrator is the most powerful role and should be tightly limited (Microsoft suggests a small number of Global Admins, protected by PIM and MFA). More specific Entra roles — User Administrator, Groups Administrator, Helpdesk Administrator, Security Reader, Security Administrator — let you delegate narrow duties without handing out full tenant control. Choosing Helpdesk Administrator to let a support agent reset passwords, instead of Global Administrator, is the least-privilege answer.

Scope is the other lever. Because Azure RBAC inherits downward, you assign a role at the lowest scope that still covers the need: a single resource group rather than the whole subscription, or one storage account rather than the resource group. The combination of the narrowest role at the narrowest scope is how Azure RBAC operationalizes least privilege.

The takeaway: never pick the broadest role offered; pick the one whose name matches the task at the smallest scope.