2.2. Microsoft Entra Conditional Access

💡 First Principle: Conditional Access is an if-then policy engine sitting at the token-issuance chokepoint: if the sign-in matches my assignments and conditions, then grant only under these controls (or block). It's how "verify explicitly" becomes an enforceable rule rather than a slogan — every signal (user, app, device, location, risk) funnels into one decision point.

Care about the failure modes, because the exam does: a policy scoped too broadly locks out your admins (hence break-glass exclusions); scoped too narrowly, it leaves the service desk convinced MFA is on when half the estate never triggers it. And because all matching policies apply — controls accumulate, and any block wins — misdiagnosing "which policy fired" is the everyday troubleshooting task 2.2.4 trains.

⚠️ Common Misconception: "Turning on a require-MFA policy will lock out users who haven't registered." Unregistered users are pushed through registration at next sign-in (and registration campaigns can front-run this). The real lockout risk is a block policy with no break-glass exclusion — which is why emergency access accounts are excluded from every CA policy.