7.1 Planning, Assignments & Controls

Why Conditional Access dominates SC-300 Domain 2

Conditional Access (CA) is the enterprise policy engine in Microsoft Entra ID that answers: Given this identity, this resource, and this context, should we allow, block, or allow only after additional requirements? Domain 2—Implement authentication and access management—is the heaviest SC-300 slice (about 25–30%). CA questions appear constantly because nearly every modern MFA, device, location, risk, guest, and admin-protection design ends in a Conditional Access policy.

You already met CA at a high level when comparing Security defaults versus Conditional Access MFA. This chapter is the deep dive: policy anatomy, grant controls, session controls, Continuous Access Evaluation, authentication context, protected actions, templates, and troubleshooting.

/practice/azure-sc-300Practice questions with detailed explanations

Zero Trust and the CA mental model

Zero Trust assumes breach, verifies explicitly, and uses least-privilege access. Conditional Access operationalizes that at sign-in (and, with Continuous Access Evaluation, during the session for supported critical events):

1. Who is requesting access? (users, groups, directory roles, workload identities, guests)
2. What are they trying to reach? (cloud apps, user actions, authentication contexts)
3. Under what conditions? (location, device platform, client app, device state filters, sign-in risk, user risk, and more)
4. What must be true to grant? (MFA, strength, compliant device, hybrid joined, app protection, and combinations)
5. How constrained is the session? (sign-in frequency, browser persistence, app-enforced restrictions, Microsoft Defender for Cloud Apps control)

If any enforced policy blocks, access is denied. If multiple policies apply, all matching policies must be satisfied—a frequent exam trap when candidates assume only the “strongest single policy” runs.

Licensing and when CA is available

SC-300 stems often assume the license required by the feature. If the scenario says “no P1,” prefer Security defaults for baseline MFA—not a full CA design. If the scenario needs exceptions, per-app rules, device grants, or authentication strengths, answer Conditional Access.

Plan Conditional Access for the organization

Planning questions rarely say “create one policy for everything.” They describe maturity, risk, and operational constraints.

Recommended rollout pattern for SC-300 design answers:

1. Inventory apps, user populations, and emergency access accounts.
2. Enable authentication methods and drive registration (previous chapter).
3. Create baseline policies from templates or carefully designed custom policies (MFA for admins, MFA for all users, block legacy auth).
4. Put new policies in report-only first; review insights and sign-in logs.
5. Pilot with IT / security groups; refine exclusions.
6. Enforce for production; monitor false positives and guest impact.
7. Layer device, location, risk, authentication strength, and session controls as maturity grows.

Policy components: assignments

Every Conditional Access policy has assignments and access controls. Assignments answer who and what—and under which conditions.

Users, groups, roles, and workload identities

Exclude is as important as include. Classic failure: policy includes All users, targets All cloud apps, requires MFA, and accidentally includes emergency accounts that have no second factor registered—tenant lockout risk.

Cloud apps, user actions, and authentication context

Exam cue: “Require MFA when users register security info” → target the Register security information user action, not only Exchange Online. “Protect Azure portal admin access” → include Microsoft Azure Management (or equivalent Azure management app targeting in CA), not only Office 365.

Conditions

Conditions refine when the policy applies.

Named locations replace old “trusted IPs that skip MFA” thinking with explicit include/exclude logic. Marking a location as trusted can interact with risk calculations and policy design—do not treat “trusted = safe forever.”

Legacy authentication (older protocols that cannot do interactive MFA cleanly) should typically be blocked with a dedicated CA policy targeting legacy client apps. Leaving legacy open undermines MFA for many mail clients and scripts.

Grant controls

Grant controls decide whether access is blocked or allowed only if requirements are met.

You can select multiple grant controls and choose:

• Require all the selected controls — every chosen control must pass (stricter).
• Require one of the selected controls — any one is enough (flexible).

Classic design: for Windows hybrid users, require one of compliant or hybrid joined so either managed path works. For executives on a sensitive app, require all of phishing-resistant authentication strength and compliant device.

Authentication strength vs plain MFA

Require multifactor authentication accepts any method the tenant allows that satisfies MFA. Require authentication strength points at a built-in or custom strength definition (for example Phishing-resistant MFA covering FIDO2, CBA, Windows Hello for Business in appropriate configurations). When a stem says “phishing-resistant,” do not answer plain MFA alone—answer authentication strength (plus methods enablement/registration from chapter 6).

Approved client app vs app protection policy

SC-300 increasingly favors app protection policy (and device compliance) over relying only on approved client app for modern mobile scenarios.

Report-only mode

Report-only is a policy state that evaluates the policy and logs what would have happened without enforcing block/grant challenges in the full enforcement sense used for production impact analysis. Use it to:

• Estimate how many users would be prompted or blocked.
• Find apps and populations missing MFA registration or compliant devices.
• Validate guest impact before go-live.

Workflow: create policy → Report-only → review Conditional Access insights / sign-in logs → fix exclusions and registration gaps → On for a pilot group → expand.

Report-only is not a permanent security control. Leaving “require MFA” in report-only forever means attackers still get password-only access.

What If tool (concepts)

The What If tool simulates a sign-in: you pick a user, app, IP/location, device platform, client app, and other signals. Entra returns which policies would apply and what grants would be required. Use What If when:

• A user reports unexpected MFA or blocks.
• You are validating that break-glass exclusions work.
• You need to explain multi-policy stacking (“why two MFA policies hit this app”).

What If is a simulation, not a substitute for reading sign-in logs after a real failure. On the exam, if the stem says “predict impact before enabling,” think report-only + What If; if it says “user failed yesterday at 14:02,” think sign-in logs / policy details.

Break-glass (emergency access) exclusions

Break-glass accounts are emergency admin accounts used when normal identity systems fail (MFA outage, misconfigured CA, IdP issues). Microsoft guidance emphasizes:

• At least two cloud-only emergency accounts (not dependent on a single on-premises sync path).
• Excluded from Conditional Access policies that could prevent their use.
• Strong credentials (long complex passwords and/or FIDO2), stored securely, not used daily.
• Continuous monitoring and alerting on any sign-in.
• Documented emergency procedures.

Exam wrong answers: “Never exclude anyone from CA,” or “Put break-glass in the same MFA policy as Global Administrators with SMS only.” Right answers balance lockout prevention with detection.

Putting assignments and grants together

Example policy set (conceptual, not the only valid design):

When you read an SC-300 stem, extract who, what resource, which condition, and which grant. If the answer choice only configures authentication methods policy without CA, it enables factors but may not enforce them. If it only toggles Security defaults, it cannot express per-app phishing-resistant device grants.

/practice/azure-sc-300Practice questions with detailed explanations