SC-300 - Plan and Automate Identity Governance - 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.

More in this domain

Back to all Plan and Automate Identity Governance objectives, or the SC-300 cert hub.

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