MS-102 A company uses Azure AD Identity Protection 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.

• ✗

  Conditional Access policy with user risk condition

  Why it's wrong here

  Conditional Access policies can indeed utilise user risk as a condition to enforce controls, making this option tempting. However, to automatically block users specifically when their *user risk level* is 'High' as part of Microsoft Entra ID Identity Protection, the dedicated **User risk policy** within Identity Protection itself is the precise mechanism. Conditional Access policies are typically used to apply specific access controls (such as requiring multi-factor authentication or blocking) based on various conditions, including risk signals, but the Identity Protection policies are designed for direct, automated responses to the risk levels they calculate.

• ✗

  Sign-in risk policy

  Why it's wrong here

  The Sign-in risk policy in Microsoft Entra ID Protection evaluates the risk associated with a specific, real-time authentication attempt—using signals such as anonymous IP addresses, impossible travel, or atypical sign-in locations—rather than the aggregate risk profile of the user account. To block a user because their user risk level is 'High', you need a policy that evaluates cumulative, user-level signals like leaked credentials or compromised account behavior. Therefore, a Sign-in risk policy might block an individual sign-in due to sign-in risk, but it will not block based on the user's persistent risk rating, making it an incorrect choice for this scenario.

• ✓

  User risk policy

  Why this is correct

  The User risk policy in Microsoft Entra ID Protection allows you to automatically respond when the system detects that a user account is likely compromised—based on signals such as leaked credentials, password spray, or anomalous user behavior—and is rated with a user risk level of High. It can be configured to 'Block access' directly at the policy level, providing the exact mechanism needed for this scenario. Separately, it can also require a secure password change or MFA, but with the condition 'User risk High' and the control 'Block access', it matches the required behavior precisely.

• ✗

  MFA registration policy

  Why it's wrong here

  The MFA registration policy in Microsoft Entra ID Protection is not a risk-based block control; it simply requires users to register for Microsoft Entra multifactor authentication at their next sign-in, regardless of any risk level. It does not evaluate user risk or sign-in risk and cannot block access based on a 'High' user risk assessment. While engaging the User risk policy may require MFA as part of remediation, the MFA registration policy alone only enforces enrollment and does not block compromised users.

Go deeper

Related to this question