14.1 PIM for Entra Roles & Azure Resources
Key Takeaways
- Microsoft Entra Privileged Identity Management (PIM) implements just-in-time privileged access so admins activate roles only when needed instead of holding standing permanent rights.
- Eligible assignments allow time-boxed activation with MFA, justification, ticket, and optional approval; active permanent assignments grant the role immediately without activation and should be rare for high-privilege roles.
- Role settings control maximum activation duration, MFA on activation, require justification, require ticket information, require approval, and notification behavior for each role.
- PIM for Microsoft Entra roles governs directory roles (Global Administrator, Privileged Role Administrator, User Administrator, and custom Entra roles) at tenant scope.
- PIM for Azure resources governs Azure RBAC at management group, subscription, resource group, or resource scope and is configured separately from Entra directory-role PIM.
Why PIM dominates Domain 4 privileged-access skills
Domain 4 of SC-300—Plan and automate identity governance (about 20–25%)—pairs entitlement management and access reviews with privileged access. Microsoft Entra Privileged Identity Management (PIM) is how organizations move from “everyone important is always Global Administrator” to just-in-time (JIT) elevation: admins hold eligibility, activate for a limited duration when work requires it, then drop back to least privilege.
What problem PIM solves
Standing permanent Global Administrator, Owner on every subscription, and always-on User Administrator accounts create permanent blast radius. If a password is phished or a token is stolen, the attacker inherits full privilege immediately. PIM reduces that surface:
| Pain | PIM response |
|---|---|
| Permanent privileged roles | Prefer eligible assignments with activation |
| Unlimited elevation time | Maximum activation duration (hours, not forever) |
| Silent privilege use | Justification, optional ticket, and notifications |
| Single rubber-stamp elevation | Require approval for sensitive roles |
| Weak second factor on elevation | MFA on activation (plus CA authentication strength for daily sign-in) |
| Azure Owner sprawl | PIM for Azure resources at MG/subscription/RG scope |
| No visibility of who elevated | PIM audit history and access reviews of privileged assignments |
Licensing (exam-level): PIM for Microsoft Entra roles and related governance features are associated with Microsoft Entra ID P2 / Entra ID Governance suites (historically Azure AD P2). SC-300 scenarios that require eligible Global Admin activation, approval workflows, or privileged access reviews assume P2-class licensing—do not answer with “Entra Free only” for full PIM designs.
Eligible vs active permanent assignments
Every PIM assignment has a type that the exam tests relentlessly.
| Assignment type | User holds role how? | When to use |
|---|---|---|
| Eligible | Role is not effective until the user activates it in PIM (subject to settings) | Default for human admins of privileged roles |
| Active (often called active permanent when no end date) | Role is effective immediately without activation | Break-glass edge cases, carefully justified automation, short fixed windows only when design requires |
| Active time-bound | Role is active but has a start/end date | Temporary standing access with a hard end (still prefer eligible when activation controls are needed) |
| Eligible time-bound | Eligibility itself expires on a date | Contractors, project admins, quarterly privilege hygiene |
Eligible (preferred model)
- Privileged Role Administrator (or equivalent) makes User A eligible for User Administrator.
- User A’s day-to-day token does not include User Administrator until activation.
- User A opens PIM → My roles → Activate, satisfies MFA/justification/approval as configured.
- For up to the max duration (for example 8 hours), User A exercises the role.
- When the activation ends, privilege is removed automatically; no helpdesk ticket to “remember to remove Global Admin.”
Active permanent (use sparingly)
Active permanent means the assignment is always on. That reintroduces standing privilege. SC-300 treats always-on Global Administrator for daily work as an anti-pattern. Legitimate narrow uses include certain service scenarios that cannot activate interactively—but for humans, prefer eligible. Break-glass accounts are a special design (section 14.3): they are often permanently assigned highly privileged roles by design, with compensating monitoring and CA exclusions—not casual “active permanent for convenience.”
Assignment metadata you configure
| Setting | Meaning |
|---|---|
| Principal | User, group (including role-assignable / PIM group patterns), or service principal as supported |
| Role | Entra directory role or Azure RBAC role |
| Scope | Tenant (Entra roles) or MG/subscription/RG/resource (Azure resources) |
| Type | Eligible or active |
| Start / end | Optional time box on the assignment itself |
| Assignment reason | Why this person should ever hold the role |
Exam cue: “Admins should not have permanent Global Administrator” → convert standing active assignments to eligible and configure activation settings—not “delete all Global Admins forever” without a recovery path.
Role settings: the activation contract
For each role (Entra or Azure resource role definition in PIM), role settings define what happens when someone activates.
Core activation settings
| Setting | Effect | SC-300 design guidance |
|---|---|---|
| Maximum activation duration | Longest continuous activation (for example 1–24 hours depending on role risk) | Shorter for Global Admin / Owner; longer only for lower-risk operational roles if justified |
| On activation, require MFA | User must complete multifactor authentication at activation | Always for privileged roles; complements Conditional Access on daily sign-in |
| Require justification | Free-text business reason recorded on activation | Enable for auditability |
| Require ticket information | Ticket/change number captured | Enable when change-management is mandatory |
| Require approval to activate | One or more approvers must approve before activation succeeds | Dual control for Global Admin, Privileged Role Administrator, Owner on production subscriptions |
| Approver list | Users or groups who can approve activations | Prefer a small privileged-ops group, not “all Global Admins approving themselves” without thought |
| Notification settings | Emails when eligible, activated, approved, denied, expiring | Keep admins and security informed |
| Allow permanent eligible / permanent active | Whether permanent assignments of that type are permitted for the role | Tighten so permanent active is blocked for high-risk roles where policy allows |
| Require Conditional Access authentication context (where configured) | Step-up CA at activation | Advanced design linking PIM activation to CA auth context |
How settings interact with Conditional Access
PIM activation MFA is not a full substitute for admin Conditional Access. Best practice stack:
- CA for privileged users/roles: phishing-resistant authentication strength, compliant device where possible, target Microsoft Azure Management and admin portals.
- PIM eligible assignments with MFA on activation, justification, and approval for Tier-0 roles.
- Access reviews of who remains eligible (section 14.2).
- Break-glass excluded carefully from lockout-prone CA (section 14.3).
If an exam answer only “turns on MFA in authentication methods” without PIM or CA enforcement, it is incomplete for privileged access design.
PIM for Microsoft Entra roles
PIM for Microsoft Entra roles manages directory roles in the tenant: built-in roles such as Global Administrator, Privileged Role Administrator, Security Administrator, User Administrator, Exchange Administrator, and custom Microsoft Entra roles you defined earlier in the role model.
Scope and mental model
- Scope: the directory / tenant (and where administrative units apply to role assignment patterns, understand AU-scoped role assignment as a separate least-privilege technique from earlier chapters).
- What it protects: who can change identities, security settings, roles, applications, and tenant-wide configuration.
- Admin experience: Microsoft Entra admin center → Identity Governance → Privileged Identity Management → Microsoft Entra roles.
Common Entra roles on the exam
| Role | Why it is privileged |
|---|---|
| Global Administrator | Near-complete tenant control; Tier-0 |
| Privileged Role Administrator | Can manage role assignments and PIM settings—can create other admins |
| Security Administrator | Security posture and many security features |
| User Administrator | User lifecycle and some group management |
| Application Administrator / Cloud Application Administrator | App registrations, credentials, permissions risk |
| Conditional Access Administrator | Can change access policies and potentially weaken MFA |
Separation of duties: the person who is eligible for Privileged Role Administrator should not casually also be the only approver for every elevation if your design requires dual control. Document approvers for Tier-0 activations.
Configure Entra role PIM (exam workflow)
- Identify which directory roles are in use (inventory standing Global Admins first).
- Open PIM → Microsoft Entra roles → Roles → select role → Settings → set max duration, MFA, justification, ticket, approval, notifications.
- Assignments → add eligible members (users or eligible groups as designed).
- Remove unnecessary active permanent assignments for human admins.
- Pilot activation with a non-production privileged role or pilot cohort.
- Train admins: activate only when needed; provide ticket numbers; expect approval delays for sensitive roles.
- Review Audit and Activations regularly; schedule access reviews of privileged role assignments.
PIM for Azure resources
PIM for Azure resources applies the same JIT model to Azure RBAC roles (Owner, Contributor, User Access Administrator, custom RBAC roles, and built-in operational roles) at Azure resource hierarchy scopes.
Scopes
| Scope | Typical use |
|---|---|
| Management group | Broad landing-zone or platform-wide admin eligibility |
| Subscription | Subscription owners/contributors without permanent Owner |
| Resource group | App team elevate only within their RG |
| Resource | Narrowest elevation for a single resource |
Least privilege prefers the narrowest scope that still allows the task. “Eligible Owner on the root management group for every engineer” is still a bad design even if JIT-enabled.
Entra roles PIM vs Azure resources PIM
| Dimension | PIM for Microsoft Entra roles | PIM for Azure resources |
|---|---|---|
| Privilege plane | Directory / identity tenant | Azure Resource Manager RBAC |
| Example roles | Global Administrator, User Administrator | Owner, Contributor, User Access Administrator |
| Scope | Tenant (directory) | MG, subscription, RG, resource |
| Portal entry | Entra ID / PIM Entra roles | PIM Azure resources (discover subscriptions/MGs) |
| Activation settings | Per directory role | Per Azure role at a resource scope configuration |
| Exam trap | “Make them Global Admin to manage VMs” | Wrong plane—use Azure RBAC Contributor/Owner with PIM, not Global Admin |
Classic SC-300 wrong answer: granting Global Administrator so someone can restart VMs or change NSGs. Correct plane is Azure RBAC (often with PIM for Azure resources), not directory Global Admin.
Configure Azure resource PIM (exam workflow)
- Onboard the management group or subscription to PIM for Azure resources as required by the environment.
- Select the scope (subscription/RG) → Roles → choose Owner or other role → configure settings (duration, MFA, justification, approval).
- Add eligible assignments for the ops group at that scope.
- Eliminate standing permanent Owner for human operators where possible.
- Align with Azure landing-zone separation: platform team eligible at higher scopes; app teams eligible only on their RGs.
Just-in-time admin model (preview of section 14.2)
The JIT model is: standing least privilege → eligible privileged role → activate under controls → work → automatic deactivation → audit. Entitlement management packages are for groups/apps/sites; PIM is for privileged roles. Do not put “temporary Global Admin” into a normal employee access package as your primary control—use PIM eligibility and activation.
Common exam traps
- Treating eligible and active permanent as synonyms.
- Configuring Azure Owner needs by assigning Global Administrator.
- Forgetting approval and max duration on Tier-0 roles.
- Assuming PIM MFA on activation replaces Conditional Access for daily admin sign-ins.
- Leaving dozens of standing Global Admins because “PIM is licensed later.”
- Believing Entra role PIM automatically covers subscription Owner—different PIM blades/scopes.
Summary of section 14.1
An identity team wants administrators to hold User Administrator only when performing user lifecycle tasks, with MFA and a business justification required at elevation. Which PIM assignment model best fits?
What is the primary difference between PIM for Microsoft Entra roles and PIM for Azure resources?
A platform engineer needs temporary permission to manage resources in one production subscription, not tenant-wide identity settings. Which approach is most appropriate?
Which role setting forces a second person to authorize elevation before a Global Administrator activation becomes effective?