SC-300 - Plan and Automate Identity Governance (25% of the exam) - Section 4.5

Manage PIM activation, approval, audit reporting, and break-glass accounts.

Manage PIM role activation requests, approvals, and audit history reports to maintain a clear record of privileged access. Configure alerts for risky PIM behaviours, run access reviews of privileged roles, and maintain break-glass emergency access accounts that bypass normal Conditional Access controls.

PIM request and approval processPIM audit history and reportsbreak-glass emergency access accountsalertsaccess reviews of privileged roles

Practice question for this objective

Free samplePlan and Automate Identity Governancehard

An identity administrator wants every activation of the Privileged Role Administrator role in Microsoft Entra Privileged Identity Management to require the activating user to satisfy a phishing-resistant multi-factor challenge bound to a specific Conditional Access policy, rather than the generic multi-factor prompt PIM offers on its own. Which PIM activation setting links the activation to that policy?

  • AEnable the require multi-factor authentication on activation setting, which automatically applies the strongest Conditional Access grant control available in the tenant
  • BRequire Microsoft Entra Conditional Access authentication context on activation, then target a Conditional Access policy at that context with the phishing-resistant control Correct
  • CConfigure a sign-in frequency Conditional Access policy targeting the Privileged Role Administrator role members and tighten the session interval
  • DRequire approval to activate and add the phishing-resistant approver as a delegated reviewer who confirms the method during each raise
Use a PIM activation authentication context to invoke a specific Conditional Access policy so a chosen grant control is enforced at role activation. PIM can require a Conditional Access authentication context on activation. Tagging the activation with an authentication context causes Conditional Access to evaluate a policy targeted at that context, so a grant control such as a phishing-resistant authentication strength is enforced precisely when the user raises the role. The plain require multi-factor option only triggers the generic challenge and cannot bind to a chosen policy.

Why A is wrong: The built-in require multi-factor setting only triggers the generic prompt and does not invoke a specific Conditional Access policy, so it cannot enforce a chosen phishing-resistant control.

Why B is correct: Authentication context lets the activation invoke a Conditional Access policy, so the phishing-resistant grant control is enforced at the moment of the raise, which is exactly what binding to a specific policy requires.

Why C is wrong: Sign-in frequency forces reauthentication on a schedule but is not invoked by a PIM activation and cannot bind a particular grant control to the act of raising the role.

Why D is wrong: Approval gates who may raise the role but does not impose an authentication strength on the activating user, and an approver cannot enforce the activating user's authentication method.

See more SC-300 practice questions, answers explained.

Exam traps in Plan and Automate Identity Governance

Answers that look right on this material and are not. Each one is a distractor from a different question in the SC-300 bank for this domain.

  • Make both emergency accounts eligible for Global Administrator in PIM and require approval on activation, so their privilege is granted just in time during a tenant outage.

    Why it is wrong: Eligible-with-approval is correct for ordinary admins, but it makes the emergency accounts depend on PIM activation and an available approver, which is exactly the dependency that can fail during the outage they exist to recover from.

  • The Microsoft Entra sign-in logs, filtered by the Security Administrator role, which record each activation along with the justification text and the approver decision.

    Why it is wrong: Sign-in logs capture authentication events, not PIM activation justifications or approval decisions, so they cannot supply the justification text or approver outcome the auditor needs.

  • The engineer must wait for the maximum activation duration to elapse, after which Privileged Identity Management releases the requested role permissions automatically

    Why it is wrong: Maximum activation duration caps how long an active role lasts after it starts; it is not a waiting period before activation, so this misreads the setting that gates the request.

Examworthy is not affiliated with or endorsed by Microsoft. Original, blueprint-aligned practice material only.