Test Conditional Access With What If Before It Locks Users

A Conditional Access policy that is wrong does not fail quietly. It locks people out, sometimes everyone, sometimes the admins. So professionals never switch a new policy straight to On. They build it in report-only, test it with What If, read the sign-in log, and only then enforce it.

This is how we do it for the Dispatch team at Pragati Logistics in Part 6 of the SC-300 course.

Every policy has the same shape

• Assignments decide when it applies: users (include and exclude users, groups, roles and guests), target resources (apps, user actions or an authentication context), and conditions (location, platform, client app, risk and device filters).
• Access controls decide what happens: grant or block, and session controls such as sign-in frequency.

Step 1: Create the policy in report-only

1. Go to Protection → Conditional Access → Policies → New policy.
2. Name it SC300 - Require MFA for Dispatch.
3. Users or agents: select users and groups, then Pragati Dispatch Team, the dynamic group built in Part 2.

4. Target resources: all resources, every app.
5. Grant: grant access, require multifactor authentication.

6. Enable policy: Report-only, then Create.

In our tenant, security defaults were still on, and the portal only allowed report-only. That is the situation behind a classic exam question: security defaults and Conditional Access cannot both be on. You turn defaults off and replace them with policies, starting in report-only.

Step 2: Ask What If

What If answers one question: for this user, this app and these conditions, which policies would apply, which would not, and why?

1. Policies → What If.
2. User: Arjun Mehta, in Dispatch.
3. Cloud app: Microsoft Teams, where Dispatch works all day.
4. Device platform: Windows; client app: browser. Select What If.

How you know it worked

Policies that will apply lists SC300 - Require MFA for Dispatch, report-only, with its grant control, require multifactor authentication. Policies that will not apply explains every other policy, with the reason.

Then check the sign-in log after a real sign-in: it shows the result of every policy, including the report-only ones. When the log matches what you expect for a few days, switch the policy to On.

What If or report-only?

They answer different questions, and the exam tests the difference:

• What If tests one imagined sign-in, instantly.
• Report-only evaluates the policy at every real sign-in and logs the result, without enforcing it.

Use both: What If while you design, report-only before you enforce.

What a tech lead should take away

• No policy goes straight to On. Report-only plus What If is the change process.
• Exclude two emergency access accounts from every policy, so a broken policy or an MFA outage cannot lock every admin out, and alert on their use.
• Target groups, not people. A dynamic group like the Dispatch team keeps the policy right as people join and leave.