🔒 Guided

Pre-launch preview. Authorised access only.

Incorrect code

Guided by A Guide to Cloud
Explore AB-900 AI-901
Guided MS-102 Domain 2
Domain 2 — Module 7 of 7 100%
15 of 28 overall

MS-102 Study Guide

Domain 1: Deploy and Manage a Microsoft 365 Tenant

  • Establish and Configure Your M365 Tenant
  • Monitor Tenant Health and Network Readiness
  • Adoption Tracking and Microsoft 365 Backup
  • Manage Users, Contacts and External Identities
  • Groups, Shared Mailboxes and Licensing at Scale
  • Automate with PowerShell: Bulk User Operations
  • Roles, Role Groups and Workload Permissions
  • Delegate with Administrative Units and PIM

Domain 2: Implement and Manage Microsoft Entra Identity and Access

  • Prepare for Identity Synchronization
  • Implement Connect Sync and Cloud Sync
  • Monitor and Troubleshoot Identity Sync
  • Authentication Methods and Self-Service Password Reset
  • Password Protection and Authentication Troubleshooting
  • Entra Identity Protection and Risk Policies
  • Conditional Access and MFA Enforcement

Domain 3: Manage Security and Threats by Using Microsoft Defender XDR

  • Defender XDR: Security Posture and Threat Intelligence
  • Investigate Incidents with Advanced Hunting
  • Defender for Office 365: Threat Policies
  • Email Threats, Attack Simulation and Restricted Entities
  • Defender for Endpoint: Onboard and Protect
  • Vulnerability Management
  • Defender for Cloud Apps: Connect and Govern
  • Cloud App Discovery and Activity Monitoring

Domain 4: Manage Compliance by Using Microsoft Purview

  • Sensitive Information Types and Data Classification
  • Retention Labels and Data Lifecycle
  • Sensitivity Labels and Monitoring
  • DLP Policies Across M365 Workloads
  • Endpoint DLP and Alert Response

MS-102 Study Guide

Domain 1: Deploy and Manage a Microsoft 365 Tenant

  • Establish and Configure Your M365 Tenant
  • Monitor Tenant Health and Network Readiness
  • Adoption Tracking and Microsoft 365 Backup
  • Manage Users, Contacts and External Identities
  • Groups, Shared Mailboxes and Licensing at Scale
  • Automate with PowerShell: Bulk User Operations
  • Roles, Role Groups and Workload Permissions
  • Delegate with Administrative Units and PIM

Domain 2: Implement and Manage Microsoft Entra Identity and Access

  • Prepare for Identity Synchronization
  • Implement Connect Sync and Cloud Sync
  • Monitor and Troubleshoot Identity Sync
  • Authentication Methods and Self-Service Password Reset
  • Password Protection and Authentication Troubleshooting
  • Entra Identity Protection and Risk Policies
  • Conditional Access and MFA Enforcement

Domain 3: Manage Security and Threats by Using Microsoft Defender XDR

  • Defender XDR: Security Posture and Threat Intelligence
  • Investigate Incidents with Advanced Hunting
  • Defender for Office 365: Threat Policies
  • Email Threats, Attack Simulation and Restricted Entities
  • Defender for Endpoint: Onboard and Protect
  • Vulnerability Management
  • Defender for Cloud Apps: Connect and Govern
  • Cloud App Discovery and Activity Monitoring

Domain 4: Manage Compliance by Using Microsoft Purview

  • Sensitive Information Types and Data Classification
  • Retention Labels and Data Lifecycle
  • Sensitivity Labels and Monitoring
  • DLP Policies Across M365 Workloads
  • Endpoint DLP and Alert Response
Domain 2: Implement and Manage Microsoft Entra Identity and Access Premium ⏱ ~17 min read

Conditional Access and MFA Enforcement

Plan, implement, and manage Conditional Access policies — the zero-trust policy engine that controls who can access what, from where, under what conditions.

The zero-trust policy engine

☕ Simple explanation

Conditional Access is the bouncer at every door in your Microsoft 365 building.

It doesn’t just check if you have a valid badge (authentication). It checks: Where are you coming from? What device are you using? Is the device managed? What are you trying to access? What time is it? Is your sign-in looking suspicious? Based on ALL of these signals, it decides: let you in, make you verify your identity again, or block you entirely.

At the Expert level, the question isn’t “what is Conditional Access?” — it’s “how do you design 15-20 policies that work together without locking people out?”

Conditional Access (CA) is Microsoft Entra’s policy-driven access control engine. Every sign-in to Microsoft 365 is evaluated against CA policies. Each policy defines:

  • Assignments — WHO (users/groups), WHAT (applications), WHERE (locations), WHEN (device state, risk level)
  • Conditions — additional signal requirements (device platform, client app, sign-in risk)
  • Grant controls — what’s required to access (MFA, compliant device, Entra hybrid joined, approved app)
  • Session controls — restrictions after access is granted (app-enforced restrictions, sign-in frequency, persistent browser)

Policies are additive — if ANY policy blocks, access is denied. If multiple policies grant, ALL grant controls must be satisfied (unless configured as “require one of selected controls”). Requires Entra ID P1+.

Anatomy of a Conditional Access policy

ComponentOptionsExample
UsersAll users, specific groups, exclude groupsAll users except break-glass accounts
Target resourcesAll cloud apps, specific apps, user actionsOffice 365, Azure portal
ConditionsDevice platform, location, client app, sign-in risk, user risk, device filteriOS and Android, outside corporate network
GrantBlock, require MFA, require compliant device, require Entra hybrid joined, require approved appRequire MFA AND compliant device
SessionApp-enforced restrictions, sign-in frequency, persistent browser, CASB controlsRe-authenticate every 8 hours

Priya’s CA policy architecture for GlobalReach

Policy NameUsersAppsConditionsGrant
Require MFA for all usersAll users (excl. break-glass)All cloud apps—Require MFA
Block legacy authenticationAll usersAll cloud appsClient apps: Other clientsBlock
Require compliant device for sensitive appsAll usersSharePoint, Exchange—Require compliant device
Block access from risky locationsAll usersAll cloud appsNamed location: Blocked countriesBlock
Require phishing-resistant MFA for adminsAdmin roles groupAll cloud apps—Require authentication strength: Phishing-resistant MFA
Risk-based MFAAll usersAll cloud appsSign-in risk: Medium+Require MFA
Force password change for high-risk usersAll usersAll cloud appsUser risk: HighRequire password change + MFA
💡 Exam tip: Policy evaluation order

Conditional Access policies don’t have a specific order — they’re ALL evaluated for every sign-in. Key rules:

  • Block wins — if any policy results in Block, access is denied regardless of other policies
  • All grant controls must be met — if Policy A requires MFA and Policy B requires compliant device, the user needs BOTH
  • Exclusions are powerful — break-glass accounts MUST be excluded from blocking policies
  • Report-only mode — test policies before enforcement by enabling Report-only

The exam often presents scenarios where multiple policies apply and asks what the combined effect is.

💡 Exam tip: Security Defaults vs Conditional Access

Security Defaults provide baseline identity protection for tenants without Conditional Access:

FeatureSecurity DefaultsConditional Access
LicensingFree (Entra ID Free)Requires Entra ID P1+
MFA enforcementAll users, all sign-insConfigurable by user, app, condition
Block legacy authYes (blanket block)Configurable per policy
CustomisationNone — take it or leave itFull policy control
Best forSmall tenants, no dedicated adminEnterprises needing granular control

Critical: Security Defaults and Conditional Access are mutually exclusive. Enabling CA policies requires disabling Security Defaults. The exam may ask: “Which approach should a 50-person company with no IT staff use?” → Security Defaults.

MFA enforcement through Conditional Access

The migration from per-user MFA

Microsoft recommends moving from per-user MFA (legacy) to Conditional Access-based MFA:

Per-User MFA vs Conditional Access MFA
FeaturePer-User MFA (Legacy)Conditional Access MFA (Recommended)
ConfigurationPer-user toggle in EntraPolicy-based in Conditional Access
GranularityMFA always required for enabled usersConditional — based on location, risk, app, device
ExceptionsDifficult to manageGroup-based exclusions and conditions
Trusted locationsTrusted IPs onlyNamed locations (IP ranges, countries, GPS)
Risk-basedYes — require MFA only for risky sign-ins
Report-only modeYes — test before enforcing
Authentication strengthYes — require specific methods (e.g., phishing-resistant)

Authentication strength policies

Authentication strength lets you specify WHICH MFA methods satisfy a CA policy — not just “any MFA”:

StrengthAllowed MethodsUse Case
MFA (built-in)Any MFA method (Authenticator, SMS, phone call, FIDO2, WHfB)General users
Passwordless MFA (built-in)Authenticator passwordless, FIDO2, WHfB, certificate-basedUsers moving to passwordless
Phishing-resistant MFA (built-in)FIDO2, WHfB, certificate-based ONLYAdmins, high-security roles
Custom strengthAny combination you defineSpecific requirements

Elena requires phishing-resistant MFA for all MedGuard Health administrators:

Policy: Require phishing-resistant MFA for admins
Users: Admin roles group
Apps: All cloud apps
Grant: Require authentication strength → Phishing-resistant MFA

This means admins MUST use FIDO2, Windows Hello, or certificate-based auth — regular Authenticator push won’t satisfy the policy.

Named locations

Named locations define trusted and blocked network locations:

Location TypeHow It WorksExample
IP rangesTrusted corporate IP addressesGlobalReach’s office egress IPs
Countries/regionsGeographic location from IPBlock all sign-ins from high-risk countries
Compliant networkMicrosoft’s Global Secure AccessDevices connecting through secure access edge

Priya creates named locations:

  • Corporate offices (trusted) — IP ranges for all 6 offices
  • Blocked countries — countries where GlobalReach has no business presence
ℹ️ Deep dive: Report-only mode

Before enforcing a new CA policy, always test it in Report-only mode:

  1. Create the policy with all conditions and grant controls
  2. Set the policy state to Report-only (not On)
  3. Monitor sign-in logs — each sign-in shows what would have happened if the policy were enforced
  4. Review for unexpected blocks or excessive MFA prompts
  5. Adjust conditions/exclusions as needed
  6. Switch to On when confident

The exam expects you to recommend Report-only mode for any new or modified policy. Going straight to enforcement risks locking out users.

Key concepts to remember

Question

What happens when multiple Conditional Access policies apply to a sign-in?

Click or press Enter to reveal answer

Answer

All policies are evaluated. Block wins over everything. If no policy blocks, ALL grant controls from ALL applicable policies must be satisfied. Example: Policy A requires MFA and Policy B requires compliant device → user needs both MFA AND compliant device.

Click to flip back
Question

What is authentication strength in Conditional Access?

Click or press Enter to reveal answer

Answer

Authentication strength lets you specify WHICH MFA methods satisfy a policy, not just 'any MFA.' Built-in strengths: MFA (any method), Passwordless MFA (Authenticator passwordless, FIDO2, WHfB), Phishing-resistant MFA (FIDO2, WHfB, certificate only). You can also create custom strengths.

Click to flip back
Question

Why must break-glass accounts be excluded from Conditional Access policies?

Click or press Enter to reveal answer

Answer

Break-glass accounts are emergency Global Admin accounts used when CA policies, MFA, or Identity Protection is misconfigured and locks out all admins. If break-glass accounts are subject to CA policies, you could be permanently locked out of your tenant. Always exclude them from Block policies and MFA requirements.

Click to flip back
Question

What mode should you use to test a new CA policy before enforcement?

Click or press Enter to reveal answer

Answer

Report-only mode. It evaluates the policy against every sign-in and logs the result (would have blocked, would have required MFA, etc.) without actually enforcing it. Review sign-in logs for unexpected outcomes, then switch to On when confident.

Click to flip back

Knowledge check

Knowledge Check

Priya has two CA policies: Policy A requires MFA for all users accessing Exchange Online. Policy B requires a compliant device for all users accessing Exchange Online. A user signs in from an unmanaged personal device. What happens?
Knowledge Check

Elena wants to ensure MedGuard Health administrators can only sign in using FIDO2 keys or Windows Hello — not standard Authenticator push. How should she configure this?

🎬 Video coming soon

Domain 2 complete! Next up: Domain 3 — Defender XDR: Security Posture and Threat Intelligence — the unified security portal that ties all your defences together.

← Previous

Entra Identity Protection and Risk Policies

Next →

Defender XDR: Security Posture and Threat Intelligence

Guided

I learn, I simplify, I share.

A Guide to Cloud YouTube Feedback

© 2026 Sutheesh. All rights reserved.

Guided is an independent study resource and is not affiliated with, endorsed by, or officially connected to Microsoft. Microsoft, Azure, and related trademarks are property of Microsoft Corporation. Always verify information against Microsoft Learn.