Setting the Conditional Access grant control to 'Block access' with the condition 'Sign-in risk: High' directly denies the authentication attempt before any token is issued. This policy can be scoped to the specific application, providing finer granularity than a global Identity Protection risk policy. Blocking is the only control that guarantees a high-risk sign-in cannot begin a session.
Why this answer
The requirement is to block sign-ins when the sign-in risk level is 'High' for a custom SaaS application. In Microsoft Entra ID (formerly Azure AD), a Conditional Access policy can be configured with a 'Block access' grant control, which directly denies authentication when the specified condition (sign-in risk level equals High) is met. This is the most straightforward and secure approach to prevent access without relying on additional authentication factors or session controls.
Exam trap
The trap here is that candidates often confuse Identity Protection risk policies with Conditional Access policies, or mistakenly think that requiring MFA is equivalent to blocking access when the requirement explicitly states 'block user sign-ins.'
How to eliminate wrong answers
Option A is wrong because requiring MFA when sign-in risk is high does not block access; it allows access after successful MFA, which does not meet the requirement to block sign-ins. Option C is wrong because session controls, such as 'Sign out users when risk is high,' apply after authentication has already occurred and do not prevent the initial sign-in; they manage active sessions but do not block the authentication request itself. Option D is wrong because Identity Protection risk policies (user risk or sign-in risk policies) are separate from Conditional Access and can automatically block users, but the question specifically asks for a Conditional Access policy configuration, making this option incorrect in context.