Design solutions that align with security best practices and priorities →mediumMultiple ChoiceObjective-mapped

SC-100 Practice Question: Design solutions that align with security best practices and priorities

Exhibit

{
  "properties": {
    "displayName": "Block high-risk sign-ins",
    "conditions": {
      "userRiskLevels": ["high"],
      "signInRiskLevels": [],
      "clientAppTypes": ["all"],
      "applications": {
        "includeApplications": ["All"]
      },
      "users": {
        "includeUsers": ["All"]
      }
    },
    "grantControls": {
      "builtInControls": ["block"]
    }
  }
}

Refer to the exhibit. You are reviewing a Conditional Access policy JSON. What is the effect of this policy?

⚠ Common exam trap

Microsoft often tests the distinction between `userRiskLevels` and `signInRiskLevels` in Conditional Access policies, and candidates frequently confuse the two, thinking a high user risk policy blocks sign-in risk events rather than user account risk.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Blocks sign-ins from users with high user risk

The policy JSON specifies `"userRiskLevels": ["high"]` under the conditions block, which means it targets only users whose user risk level is assessed as high by Microsoft Entra ID Protection. The grant control is set to `"builtInControls": ["block"]`, so the policy blocks sign-ins for those high-risk users. Option B is correct because the policy explicitly blocks sign-ins from users with high user risk, not sign-in risk or all users.

Answer analysis

Option-by-option breakdown

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

✗
Blocks sign-ins from locations with high sign-in risk
Why it's wrong here
The policy shown does not include a sign-in risk condition — only user risk is evaluated — and sign-in risk is not configured in the conditional access policy. In Microsoft Entra ID, sign-in risk and user risk are independent risk dimensions with separate conditions and separate risk levels. Because the sign-in risk condition is absent, this policy cannot block based on sign-in risk, making the statement incorrect.
✓
Blocks sign-ins from users with high user risk
Why this is correct
This is the correct interpretation: the policy sets the 'User risk' condition to 'High' and the access control to 'Block.' When a user's risk level, as determined by Microsoft Entra ID Protection detections, is high, the conditional access engine denies the sign-in attempt. Thus, the policy's effective behavior is to block sign-ins from users with high user risk.
✗
Blocks all sign-ins from any user
Why it's wrong here
The policy does not indiscriminately block all sign-ins because the user risk condition acts as a guard that limits enforcement to accounts scored as high risk. Users with low or medium user risk are not affected by this policy even if they are in scope. Therefore, stating that it blocks every sign-in from any user overstates the policy's scope and ignores the risk filter.
✗
Requires multifactor authentication for high-risk users
Why it's wrong here
The access control configured in this policy is 'Block,' not 'Grant,' so multifactor authentication is never offered or required. A require-MFA outcome would be implemented via the Grant control with the 'Require multifactor authentication' checkbox selected, which is not present here. Instead, high-risk users are denied outright after risk evaluation, with no MFA challenge step.

Go deeper

SC-100 Practice Question: Design solutions that align with security best practices and priorities

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question