Domain 1 of 4 · Chapter 1 of 4

Entra Tenant Configuration

The model: definition, principal, scope

A regional helpdesk that should reset passwords for the Seattle office but touch nobody else, and a contractor who needs to rotate one app's client secret and nothing more, are both solved by the same machine. Get that machine straight and every task on this page is just turning one of its three dials.

A Microsoft Entra role assignment[1] is always three things bound together:

  • a role definition, a named collection of permissions (the operations allowed on directory objects);
  • a security principal that receives them, which is a user, a role-assignable group[2], or a service principal;
  • a scope that constrains where those permissions apply.

The three parts above are exactly the three inputs the figure binds into one assignment.

Built-in versus custom role definitions

Microsoft authors the built-in roles[3] (Global Administrator, User Administrator, Helpdesk Administrator, and many more), and their permission sets are fixed: you cannot edit a built-in role. When no built-in role fits, you build a custom role[1] by selecting permissions from the same preset list the built-in roles draw from, then assign it. Granting access with a custom role is therefore a two-step act: create the definition once, then create one or many assignments of it at different scopes. The licensing line is the testable one: built-in roles are free, but every user holding a custom role assignment requires Microsoft Entra ID P1.

Entra roles are not Azure roles

A predictable trap: Microsoft Entra roles and Azure RBAC roles[4] are two separate systems that do not span each other by default. Entra roles govern the directory (users, groups, applications, domains) through Microsoft Graph; Azure roles govern Azure resources (VMs, storage) through Azure Resource Manager. A Global Administrator has no access to Azure resources, and an Owner cannot manage directory users, until a Global Administrator flips the Access management for Azure resources toggle, which grants them User Access Administrator at the Azure root scope. Entra-role permissions cannot be used in an Azure custom role and vice versa. One more tooling fact the exam likes: Azure CLI is not supported for Microsoft Entra role assignments; use the Microsoft Entra admin center, Microsoft Graph PowerShell, or the Microsoft Graph API.

Role definitionBuilt-in (fixed) or customSecurity principalUser, group, or service principalScopeTenant, AU, or resourceRole assignmentThe actual grantbinds
Every Microsoft Entra role assignment binds three inputs (role definition, security principal, scope) into one grant. Modeled on the Entra RBAC custom-role overview.

Scope, effective permissions, and administrative units

Scope is the dial this subtopic turns most, so lead with the rule that decides every effective-permission question: a role on a container grants you its members, a role on a resource grants you that object only, and Entra roles add up.

An Entra role assignment carries one of three scope[1] types:

  • Tenant (organization-wide), the default and broadest;
  • an administrative unit;
  • a Microsoft Entra resource, which can be a group, an enterprise application, or an app registration.

When a role is assigned over a container scope (the tenant or an administrative unit) it grants permissions over the objects inside the container, not over the container object itself. When it is assigned over a resource scope it grants permissions over that object and does not extend beyond it; in particular it does not reach the members of a group. Because Microsoft Entra evaluates effective permissions as the union of every assignment a principal holds at every applicable scope, you compute what someone can do by adding their grants together, never by intersecting them.

Administrative units

An administrative unit (AU)[5] is a Microsoft Entra container that can hold only users, groups, or devices. You use it to scope a directory role to a slice of the org: the classic example is delegating the Helpdesk Administrator[3] role over a School of Business AU so regional staff manage only their own people. Three constraints the exam leans on:

  • AUs cannot be nested. A user can belong to several flat AUs (Megan can be in both Seattle and Marketing), which is how you model overlap.
  • A group in an AU brings the group, not its members. An AU-scoped User Administrator[3] can rename the group and edit its membership, but cannot reset the passwords or edit the profiles of the users inside it unless those users are also added to the AU directly. This is the single most tested AU subtlety.
  • Assign a user that is in no AU and a tenant-scoped role, and the scope is the whole tenant. Membership can be set by hand or by a dynamic membership rule[6] that targets users OR devices.

Licensing splits along admin versus member: using an AU needs Microsoft Entra ID P1 for each AU administrator assigned a role over the AU, and Microsoft Entra ID Free for each AU member; creating AUs is free, but dynamic AU membership rules require P1 for every member. The Privileged Role Administrator[3] creates AUs and assigns AU-scoped admins. Note the scope syntax in Graph differs by intent: /administrativeUnits/{id} means manage the members of the AU, while a bare /{id} (used for an app registration or group resource scope) means manage that object itself.

Which roles can be AU-scoped, and PIM

Not every role can be narrowed to an AU. Only roles with permissions relevant to users, groups, or devices appear, such as User Administrator, Groups Administrator, Helpdesk Administrator, Authentication Administrator, License Administrator, and Cloud Device Administrator[7], plus any custom role whose definition includes at least one user/group/device permission. To see who holds what, list role assignments in the admin center (downloadable as CSV) or via the List unifiedRoleAssignments[8] API. With Microsoft Entra ID P2 and Privileged Identity Management (PIM)[9], an assignment can be eligible (the user activates it just-in-time, time-boxed) rather than active (permanent), which is how effective permissions are governed at the high end. Role-assignable groups, used to assign a role to a group instead of individuals, require Entra ID P1.

Tenant scopeWhole directoryNarrow to a sliceNarrow to one objectAdministrative unit (container)Users, groups, devices insideResource scopeGroup, app reg, enterprise appGrants the MEMBERS,not the container objectGrants the OBJECT itself,not a group's membersEffective permissions = union of every assignment at every scope (additive)
Entra role scopes broad to narrow: a container scope grants its members, a resource scope grants the object, and effective permissions are the additive union. Modeled on the Entra RBAC scope docs.

Restricted management AUs, domains, branding, and settings

The plain administrative unit delegates down: it hands a slice of the directory to local admins. A restricted management administrative unit[10] does the opposite, it walls a slice off so that even the tenant's own top admins cannot touch it.

Restricted management administrative units

The scenario is the CEO's account that a Helpdesk Administrator could otherwise reset. Place sensitive objects in a restricted management AU and only administrators explicitly assigned at that AU's scope can modify the contained objects' Entra properties. A tenant-level Global Administrator[3] or Privileged Role Administrator is blocked from changing those objects unless they first assign themselves a role at the restricted AU scope, which is an auditable event. Those two roles can still manage the AU container itself (create or delete it, add or remove members, assign AU-scoped roles). The details that get tested:

  • Supported members are users, devices, and security groups only; Microsoft 365, distribution, and mail-enabled security groups are not supported.
  • The restricted-management flag is chosen at creation and is immutable afterward; you cannot convert a regular AU into a restricted one or back.
  • Objects inside are excluded from Microsoft Entra ID Governance features: PIM, entitlement management, lifecycle workflows, and access reviews cannot manage them.
  • A tenant allows at most 100 restricted management AUs, and deleting one can take up to 30 minutes to lift protection from the former members.
  • Only the directory operations are blocked; related Microsoft 365 actions (Exchange mailbox settings, Intune device policy, SharePoint site ownership, license assignment) still work. It requires P1 per AU admin, Free per member.

Domains in Microsoft Entra ID and Microsoft 365

Every tenant ships with an initial domain[11] like contoso.onmicrosoft.com that you cannot change or delete. You add your own DNS name as a custom domain and optionally set it primary so new users get UPNs like alain@contoso.com. Ownership is proven by creating a TXT or MX record (recommended TTL 3600 seconds) at your registrar, then selecting Verify; the minimum role is Domain Name Administrator[3]. The figure below walks that add-record-verify path. Two facts the exam turns on: a domain name can be verified in only one directory at a time (to move it, delete it from the old tenant first), and Microsoft Entra ID and Microsoft 365 share the same tenant domain list, so a domain added in one is the same object in the other. A domain cannot be deleted while users, groups, or apps still reference it.

Company branding

Company branding[12] customizes the sign-in page: background image or color, favicon, header and banner and square logos, sign-in page text, footer links, and the layout template. It needs Microsoft Entra ID P1 or P2, or Microsoft 365 Business Standard, or SharePoint (Plan 1), and the minimum role is Organizational Branding Administrator. There is one default sign-in experience plus optional per-browser-language overrides that replace the default for matching languages. Edge cases that show up as distractors: branding does not apply to personal Microsoft accounts; for B2B cross-tenant sign-ins the guest sees their home tenant's branding; external URLs render as non-clickable text; sign-in page text is capped at 1,024 Unicode characters; and custom CSS is unavailable for tenants created after January 5, 2026 (older tenants keep it).

Tenant, user, group, and device settings

The user settings page sets the default permissions[13] every member inherits. By default a member user can register applications and create security and Microsoft 365 groups; you can set Users can register applications, Users can create security groups, and Users can create Microsoft 365 groups to No (a User Administrator can still create groups). Restrict non-admin users from creating tenants set to Yes limits tenant creation to holders of the Tenant Creator[3] role. Guest defaults are governed by Guest user access restrictions (same access as members, or restricted to their own directory objects). A device setting can restrict users from self-service recovering BitLocker keys for their owned devices.

Debunk the obvious trap now: the Restrict access to the Microsoft Entra admin center switch is not a security measure. It adds browsing friction for non-admins but does not block PowerShell or Microsoft Graph and does not apply to admin roles. To actually block non-admin access to management endpoints, use a Conditional Access policy targeting the Windows Azure Service Management API.

Add custom domainYour DNS nameCreate TXT or MXDNS record at registrarSelect VerifyDomain Name AdminVerifiedCan set primary
Custom domain verification: add the name, create a TXT or MX record, then Verify as Domain Name Administrator before you can set it primary. Modeled on the Entra add-custom-domain docs.

Exam-pattern recognition

SC-300 turns this subtopic into scenario questions that hinge on one precise rule. Here is what the stems look like and which answer wins.

What the questions look like

  • "Helpdesk should reset passwords for one region only." Create an administrative unit, add that region's users, and assign Helpdesk Administrator at the AU scope. Distractor: assigning the role at tenant scope (too broad), or adding a group to the AU and expecting password reset on its members (a group in an AU brings the group, not its members).
  • "Protect the CEO's account so even Global Admin / Helpdesk can't reset it." A restricted management administrative unit. Distractor: a regular AU (tenant admins still reach in), or Conditional Access (controls sign-in, not who can administer the object).
  • "No built-in role grants exactly these permissions and nothing more." A custom role built from the preset permission list, scoped where needed. Distractor: editing a built-in role (impossible, they are fixed) or over-granting a broad built-in role.
  • "How many can manage this object / what does X effectively have?" Add the assignments: effective permissions are the union across all scopes. Distractor: assuming a narrower assignment subtracts from a broader inherited one.
  • "A custom role assignment needs a license." Entra ID P1 per assignee; built-in roles are free. Distractor: claiming custom roles are free, or that they need P2 (P2 is PIM/eligible assignments).
  • "Add a vanity domain / verify ownership." Add the domain, create a TXT or MX DNS record, then Verify as Domain Name Administrator. Distractor: a CNAME record, or expecting to verify a domain already verified in another tenant.
  • "The initial onmicrosoft.com name must be removed/renamed." It cannot be changed or deleted; set a custom domain primary instead.
  • "Brand the sign-in page." Company branding as Organizational Branding Administrator with P1/P2 (or M365 Business Standard / SharePoint Plan 1). Distractor: expecting branding on personal Microsoft accounts, or that a B2B guest sees the resource tenant's branding (they see their home tenant's).
  • "Stop end users creating tenants / registering apps." Toggle the matching user setting; tenant creation then needs the Tenant Creator role.
  • "Hide the admin portal from non-admins as a security control." The Restrict access to the Microsoft Entra admin center switch is not security; the correct control is Conditional Access on the Windows Azure Service Management API.

A note on tooling

When a stem names the tool, remember Azure CLI cannot create Entra role assignments; the supported paths are the Microsoft Entra admin center, Microsoft Graph PowerShell (New-MgRoleManagementDirectoryRoleAssignment), and the Microsoft Graph API. An answer that scripts an Entra role assignment with az role assignment create is testing whether you know that command is for Azure RBAC, not directory roles.

Choosing the admin construct: role definition vs scope

Decision axisBuilt-in roleCustom roleAU-scoped assignmentRestricted management AU
What it isFixed Microsoft permission setPermissions you pick from the preset listAny role narrowed to an AU's membersAn AU that locks out tenant admins too
Use whenA standard job maps to a named roleNo built-in role fits, need least privilegeDelegate a region or divisionProtect sensitive objects (e.g. execs)
LicenseFreeEntra ID P1 per assigneeP1 per AU admin, Free per memberP1 per AU admin, Free per member
Member object typesn/a (definition)n/a (definition)Users, groups, devicesUsers, devices, security groups only
Tenant Global Admin reachFullFullFull (tenant scope overrides)Blocked unless self-assigned at AU scope

Decision tree

Does a built-in rolefit the permissions needed?NoCustom rolePreset permissions, P1 per assigneeYesMust tenant admins be locked out too?Protect sensitive objects (e.g. execs)YesRestricted management AUEven Global Admin blockedUsers, devices, security groupsNoDelegate only a slice of the org?One region or divisionYesAU-scoped assignmentRole over the AU's membersP1 per AU adminNoBuilt-in role, tenant scopeFree, org-wideBroadest reachWith Entra ID P2 + PIM, make any assignment eligible (just-in-time) instead of active
Cheat sheet

Sharp facts the exam loves — give these one last read before exam day.

Cheat sheet

Sharp facts the exam loves — scan these before test day.

An Entra role assignment is a definition plus a principal plus a scope

A Microsoft Entra role grant always binds three things: a role definition (a bundle of permissions), a security principal (a user, a role-assignable group, or a service principal), and a scope where they apply. Built-in role definitions are authored by Microsoft and have a fixed permission set you cannot edit; a custom role reuses the same preset permission list. You create the definition once and can assign it many times at different scopes.

Built-in Entra roles are free; custom roles need P1 per assignee

Using Microsoft Entra built-in roles costs nothing, but every user holding a custom role assignment requires Microsoft Entra ID P1. Granting access with a custom role is a two-step process: assemble a role definition from the preset permission list, then create a role assignment that binds it to a principal at a scope. Reach for a custom role only when no built-in role matches the least-privilege need.

Trap Assuming custom roles are free like built-in roles, or that they need P2; P2 buys PIM and eligible assignments, not the right to use a custom role.

2 questions test this
You cannot edit a built-in role; build a custom role instead

Built-in Microsoft Entra role definitions are fixed and cannot be modified. When a built-in role grants too much or too little, the answer is a custom role assembled from the same preset permission list, not an attempt to trim or extend a built-in one.

Trap Editing or cloning a built-in role's permissions to fit a narrower need; built-in definitions are read-only, so a custom role is the only path.

1 question tests this
Entra roles and Azure RBAC roles do not span each other by default

Microsoft Entra roles govern the directory (users, groups, apps, domains) via Microsoft Graph; Azure RBAC roles govern Azure resources (VMs, storage) via Azure Resource Manager. By default a Global Administrator has no access to Azure resources and an Owner cannot manage directory users. The only built-in bridge is a Global Administrator toggling Access management for Azure resources, which grants User Access Administrator at the Azure root scope.

Trap Expecting a Global Administrator to manage Azure subscriptions, or an Owner to manage directory users, without the Access management for Azure resources toggle.

Azure CLI cannot create Microsoft Entra role assignments

Entra directory role assignments are made through the Microsoft Entra admin center, Microsoft Graph PowerShell (New-MgRoleManagementDirectoryRoleAssignment), or the Microsoft Graph API. Azure CLI is not supported for Entra roles; az role assignment create targets Azure RBAC on Azure resources, a different system.

Trap Using az role assignment create to grant a directory role; that command is for Azure RBAC, not Microsoft Entra roles.

Entra role scope is tenant, an administrative unit, or one resource

A role assignment carries one of three scope types: tenant (org-wide, the default and broadest), an administrative unit, or a single Microsoft Entra resource. A resource scope can be a group, an enterprise application, or an app registration, which lets you grant management of one object without a tenant-wide grant.

Trap Picking a subscription or resource group as the resource scope; an Entra resource scope is a group, enterprise application, or app registration, never an Azure subscription or resource group (that is Azure RBAC).

A container scope grants the members; a resource scope grants the object

A role assigned at a container scope (the tenant or an administrative unit) grants permissions over the objects inside the container but not the container object itself. A role assigned at a resource scope grants permissions over that object only and does not reach through to a group's members. In Graph this shows in the scope string: /administrativeUnits/{id} means manage the AU's members, while a bare /{id} means manage that object itself.

Trap Assigning a role at a single group's resource scope and expecting it to reach that group's members; a resource scope grants the object only, so use an administrative unit (or add the users directly) to manage members.

1 question tests this
Entra effective permissions are the additive union across all scopes

A principal's effective Entra permissions are the union of every role assignment they hold at every applicable scope, so you compute access by adding grants together. A narrower assignment never subtracts from a broader one. To audit who has what, list role assignments in the admin center (downloadable as CSV) or via the List unifiedRoleAssignments Graph API.

Trap Assuming a narrow scoped assignment limits or overrides a broader tenant-scope grant the same user already holds; permissions only add.

An administrative unit contains only users, groups, or devices and cannot nest

An administrative unit (AU) is a Microsoft Entra container that holds only users, groups, or devices, used to scope a directory role to part of the org (for example a Helpdesk Administrator over one region). AUs cannot be nested, so model overlap by adding an object to multiple flat AUs (a user can be in both Seattle and Marketing). A user in no AU who is given a tenant-scoped role has tenant-wide scope.

Trap Trying to nest one administrative unit inside another; AUs are flat, so use multiple memberships for overlapping structure.

A group added to an AU brings the group, not its members

Adding a group to an administrative unit puts the group object in scope, so an AU-scoped User Administrator can rename the group and edit its membership, but cannot reset passwords or edit profiles of the users inside it. To manage those users, add them to the AU directly as members. This is the most tested AU subtlety.

Trap Adding only a group to an AU and expecting the scoped admin to reset its members' passwords; the members must be added to the AU directly.

3 questions test this
AUs price by role: P1 per admin, Free per member; dynamic membership needs P1

Creating administrative units is free, but using one requires Microsoft Entra ID P1 for each AU administrator assigned a role over the AU scope, and Microsoft Entra ID Free for each AU member. If you populate the AU with a dynamic membership rule, each AU member then requires P1. The Privileged Role Administrator creates AUs and assigns AU-scoped admins.

Trap Assuming every AU member needs Entra ID P1; members are Free, only the AU administrator needs P1 unless the AU uses a dynamic membership rule (then each member needs P1).

2 questions test this
Only user/group/device roles (plus matching custom roles) can be AU-scoped

An AU scope is offered only for roles whose permissions touch users, groups, or devices, such as User Administrator, Groups Administrator, Helpdesk Administrator, Authentication Administrator, License Administrator, and Cloud Device Administrator, plus any custom role with at least one user/group/device permission. AU-scoped permissions that act on users (password reset, auth methods) apply only to non-administrator targets within the AU.

Trap Expecting to AU-scope a tenant-wide role like Global Administrator, or expecting an AU-scoped Helpdesk Administrator to reset another admin's password; only user/group/device roles can be AU-scoped and they act on non-administrator targets only.

4 questions test this
A restricted management AU blocks even tenant admins from its objects

A restricted management administrative unit protects sensitive objects so only admins explicitly assigned at that AU scope can modify the contained objects' Entra properties. Even a tenant Global Administrator or Privileged Role Administrator is blocked from changing those objects unless they first self-assign a role at the AU scope, which is an auditable event. Those two roles can still manage the AU container itself.

Trap Using a regular administrative unit to protect executive accounts; a regular AU still lets tenant-scoped admins reach in, so only a restricted management AU walls them off.

3 questions test this
Restricted management AUs take users, devices, and security groups only

A restricted management administrative unit supports only users, devices, and security groups as members; Microsoft 365 groups, distribution groups, and mail-enabled security groups are not supported. The restricted-management flag must be set when the AU is created and is immutable afterward, so you cannot convert a regular AU into a restricted one or back.

Trap Adding a Microsoft 365 group to a restricted management AU, or expecting to flip an existing AU to restricted; the member types are limited and the flag is creation-time only.

Restricted management AU limits: 100 per tenant, excluded from governance, 30-min delete

A tenant allows at most 100 restricted management administrative units. Objects inside one cannot be managed by Microsoft Entra ID Governance features (PIM, entitlement management, lifecycle workflows, access reviews). Deleting a restricted management AU can take up to 30 minutes to lift protection from its former members. Only directory operations are blocked; related Microsoft 365 actions (Exchange mailbox, Intune policy, SharePoint, license assignment) still work. It needs P1 per AU admin, Free per member.

Trap Expecting PIM, access reviews, or entitlement management to manage objects inside a restricted management AU; those Entra ID Governance features cannot reach restricted-AU members.

The initial onmicrosoft.com domain cannot be changed or deleted

Every Microsoft Entra tenant ships with an initial domain like contoso.onmicrosoft.com that you cannot rename or delete. To give users friendly sign-in names, add your own DNS name as a custom domain and set it as the primary (default) domain so new users get UPNs like alain@contoso.com.

Trap Trying to delete or rename the onmicrosoft.com initial domain; you can only add a custom domain and mark it primary.

Verify a custom domain with a TXT or MX DNS record, in one directory only

To add a custom domain you create a TXT or MX DNS record (recommended TTL 3600 seconds) at your registrar, then select Verify in the Microsoft Entra admin center as at least a Domain Name Administrator. A given domain name can be verified in only one directory at a time, so to move it you must delete it from the old tenant first. Microsoft Entra ID and Microsoft 365 share the same tenant domain list.

Trap Using a CNAME record to verify domain ownership, or trying to verify a domain already verified in another tenant; verification is TXT or MX and exclusive to one directory.

3 questions test this
A domain cannot be deleted while objects still reference it

You cannot delete a custom domain from a tenant while users, groups, or applications still use that domain (for example in their UPNs). Reassign or remove the dependent objects first, then delete the domain. Because Entra ID and Microsoft 365 share the domain, the same dependency rule applies across both.

Trap Trying to delete a custom domain while users still carry UPNs on it; the delete is blocked until every dependent user, group, or app is reassigned off that domain first.

Company branding needs P1/P2 (or qualifying M365/SharePoint) and a branding admin role

Customizing the Microsoft Entra sign-in page (background, favicon, header/banner/square logos, sign-in text, footer, layout) requires Microsoft Entra ID P1 or P2, or Microsoft 365 Business Standard, or SharePoint Plan 1. The minimum role to configure it is Organizational Branding Administrator. There is one default sign-in experience plus optional per-browser-language overrides that replace the default for matching languages.

Trap Assuming Global Administrator is the role needed to customize branding, or that branding is free; the minimum role is Organizational Branding Administrator and it needs P1/P2 (or qualifying M365/SharePoint).

3 questions test this
Branding skips personal accounts and shows the guest's home-tenant brand

Company branding does not apply to personal Microsoft accounts. For B2B cross-tenant sign-ins the guest sees their own home tenant's branding, not the resource tenant's. External URLs in the sign-in experience render as non-clickable text, sign-in page text is capped at 1,024 Unicode characters, and custom CSS is unavailable for tenants created after January 5, 2026 (older tenants keep it).

Trap Expecting your organization's branding to appear when a B2B guest signs in; the guest sees their home tenant's branding instead.

3 questions test this
Tenant user settings gate app registration and group creation

By default a member user can register applications and create security and Microsoft 365 groups. User settings let you set Users can register applications, Users can create security groups, and Users can create Microsoft 365 groups to No. A User Administrator can still create groups even when end-user creation is turned off, so the switch limits ordinary members, not admins.

Trap Assuming turning off group creation also blocks a User Administrator; admins with the role can still create groups regardless of the setting.

Restricting tenant creation requires the Tenant Creator role

Setting Restrict non-admin users from creating tenants to Yes limits creation of new Microsoft Entra tenants to holders of the Tenant Creator role; otherwise any member user can create a tenant (and becomes its Global Administrator). Tenant creation is always recorded in the audit log under Create Company.

Trap Assuming Global Administrator is the role that lets a user still create tenants once the restriction is on; it is the Tenant Creator role that grants the exception, not Global Administrator.

Restrict access to the admin portal is friction, not a security control

The Restrict access to the Microsoft Entra admin center switch adds browsing friction for non-admins but is explicitly not a security measure: it does not block PowerShell or Microsoft Graph and does not apply to users with an admin role. To actually block non-admin access to management endpoints, use a Conditional Access policy targeting the Windows Azure Service Management API.

Trap Relying on the Restrict access to the Microsoft Entra admin center toggle as a security boundary; it leaves Graph and PowerShell open, so enforce with Conditional Access on the Windows Azure Service Management API.

Guest defaults and a BitLocker device setting live in tenant settings

Guest user defaults are governed by Guest user access restrictions, which can grant guests the same access as members or restrict them to only their own directory objects. A device setting can restrict users from self-service recovering BitLocker keys for their owned devices, forcing them to contact the helpdesk. These tenant-wide toggles shape what every guest or device owner inherits.

Trap Assuming guests get the same directory access as members by default; the default Guest user access restrictions level limits guests, and tightening it to own-objects-only is a deliberate setting.

PIM (P2) makes a role assignment eligible instead of active

With Microsoft Entra ID P2 and Privileged Identity Management, a role assignment can be eligible (the user activates it just-in-time and time-boxed) rather than active (permanent standing access). This is how privileged effective permissions are minimized at the high end; assigning a role to a role-assignable group instead of individuals requires Entra ID P1.

Trap Assuming Microsoft Entra ID P1 enables eligible, just-in-time PIM assignments; eligible (activate-on-demand) role assignments require P2 and PIM, while P1 only covers role-assignable groups.

An AU-scoped role manages only that AU's members, never tenant-wide settings

A role assigned at administrative-unit scope (for example User Administrator or Groups Administrator) applies its permissions only when managing the objects that are members of that AU. It cannot touch tenant-level configuration. The scope is a management boundary, not a visibility boundary: administrative units apply scope only to management permissions and do not prevent the admin from using default user permissions to browse other users, groups, or resources outside the AU.

Trap Assuming the AU scope hides or blocks read/browse access to objects outside the AU

4 questions test this
A dynamic administrative unit needs membershipType, membershipRule, and membershipRuleProcessingState

To create or convert an administrative unit to dynamic membership via the Microsoft Graph API (POST or PATCH /directory/administrativeUnits), set membershipType to Dynamic, supply the membershipRule expression, and set membershipRuleProcessingState to On to activate rule evaluation. Setting membershipRuleProcessingState to Paused stops updating membership dynamically while keeping the rule and current members.

Trap Omitting the /directory/ prefix on the v1.0 path; the documented v1.0 endpoint is /directory/administrativeUnits

5 questions test this
A dynamic administrative unit holds one object type, so users and devices need separate AUs

A dynamic membership rule for an administrative unit targets users OR devices, never both, and dynamic AUs do not support group rules. To automatically maintain both users and devices, create two AUs: one with a Dynamic User rule and one with a Dynamic Device rule. Dynamic AU membership requires one Microsoft Entra ID P1 license per unique member; you don't have to assign the licenses to those users, but the tenant must hold at least enough licenses to cover them.

Trap Trying to add groups to, or mix users and devices in, a single dynamic AU

2 questions test this

Also tested in

References

  1. https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/custom-overview
  2. https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/groups-concept
  3. https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference
  4. https://learn.microsoft.com/en-us/azure/role-based-access-control/rbac-and-directory-admin-roles
  5. https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/administrative-units
  6. https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/admin-units-members-dynamic
  7. https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/manage-roles-portal
  8. https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/view-assignments
  9. https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-configure
  10. https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/admin-units-restricted-management
  11. https://learn.microsoft.com/en-us/entra/fundamentals/add-custom-domain
  12. https://learn.microsoft.com/en-us/entra/fundamentals/how-to-customize-branding
  13. https://learn.microsoft.com/en-us/entra/fundamentals/users-default-permissions