MS-102 A company uses Microsoft Entra ID P2 licenses Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Assign policy to 'All users', exclude 'Emergency Access' group, set 'Sign-in risk' condition to 'High and Medium'

  Why this is correct

  The correct configuration targets every user except the Emergency Access group, and the Sign-in risk condition set to 'High and Medium' ensures the policy only triggers when the authentication attempt itself has been flagged as medium or high risk by Microsoft Entra ID Protection. This matches the requirement precisely: the policy is scoped broadly, the break-glass accounts are excluded to guarantee availability, and the control (such as requiring MFA or blocking access) is enforced based on the risk score of that specific sign-in event.

• ✗

  Assign policy to 'All users', exclude 'Emergency Access' group, set 'User risk' condition to 'High and Medium'

  Why it's wrong here

  This configuration is incorrect because the User risk condition evaluates the probability that the user's account has been compromised, based on aggregated historical signals and activities, rather than the risk level of the current sign-in attempt. The requirement explicitly calls for a sign-in–risk condition, so applying a policy to user risk would trigger on account-level compromise indicators, not on the real-time assessment of the authentication event. In practice, this means you could miss a high-risk sign-in for a user whose account is otherwise not flagged, or apply the policy to a sign-in that is low risk but tied to a previously compromised account.

• ✗

  Assign policy to 'Emergency Access' group, set 'Device state' condition to 'All device states'

  Why it's wrong here

  Assigning the policy only to the Emergency Access group directly contradicts the intended scope of 'all users' — the policy would apply solely to break-glass accounts, exactly those that should be exempted from risk-based controls to prevent accidental lockout. The Device state condition set to 'All device states' is also unrelated to the requirement, as it checks whether the device is compliant or hybrid joined rather than evaluating sign-in risk. This option does not address the scenario at all and would create a severe availability risk for emergency access.

• ✗

  Assign policy to 'All users', exclude 'Emergency Access' group, set 'Locations' condition to 'All trusted locations'

  Why it's wrong here

  The Locations condition with 'All trusted locations' would limit the policy to only apply when the sign-in originates from an IP address defined as a trusted location, which is a network-based criterion rather than a risk-based one. The requirement explicitly focuses on sign-in risk, so using a trusted-locations scope means the policy would incorrectly bypass risky sign-ins from untrusted (outside) networks and possibly trigger on low-risk sign-ins from inside trusted ranges, failing to align with the stated intent. This option ignores the risk signal entirely and is therefore an ineffective and incorrect policy design.

Go deeper

Related to this question