Conditional Access — SC-300 Study Guide

The if-then engine: assignments and access controls

"If a guest signs in to the finance app from outside the corporate network, then require MFA and a compliant device." That sentence is a Conditional Access policy. Microsoft's own documentation frames every policy as an if-then statement of Assignments and Access controls^[1]: the assignments are the if (the signals that decide whether the policy applies), and the access controls are the then (what gets enforced when it does). Keep that one model in your head and the whole feature falls into place; everything below is just the parts of the if and the parts of the then.

The figure shows the two halves and how a sign-in flows through them. Read it left to right: signals are collected, the policy decides, and enforcement happens.

The two phases of evaluation

Entra evaluates every policy in two phases. Phase 1 collects the session details (network location, device identity, client app) for all enabled policies and all report-only policies. Phase 2 uses those details to find unmet requirements: if any matching policy is configured to Block, enforcement stops and the user is blocked. Otherwise the user is prompted to satisfy the grant controls that were not already met, in a fixed order, until the policy is satisfied: multifactor authentication, then compliant device, then Microsoft Entra hybrid joined device, then approved client app, then app protection policy, then password change, then terms of use^[1]. Once every grant control is met, session controls (sign-in frequency, persistent browser, and continuous access evaluation or CAE, detailed below) apply. The figure groups assignments as users and roles, target resources (apps, user actions, and authentication context), network and named locations, and conditions.

How policies and controls combine

Two combination rules carry most of the exam weight. First, all assignments in a single policy are combined with AND: every configured assignment must match before the policy triggers, so an over-scoped policy (too many conditions) simply never fires. Second, when several policies apply to one sign-in, all applicable policies must be satisfied. If one policy requires MFA and another requires a compliant device, the user completes MFA and uses a compliant device. The least-privileged role to author policies is Conditional Access Administrator^[2], and Conditional Access is a Microsoft Entra ID P1 capability^[3] (risk-based conditions need P2).

If-then flow modeled on Microsoft's signal-decision-enforcement diagram (cited in the section above): assignments match, the policy decides, access controls enforce.

Assignments: who, what, and where

The assignments are where you scope a policy, and scoping mistakes are the single biggest source of "my policy did not fire" problems. Because all assignments AND together, every one you add narrows the policy further. The figure groups the four dimensions you can set, who (users and groups), what (target resources), where (network and named locations), and the finer conditions, and the prose below walks them in the order the portal presents them.

Users and target resources

Users and groups^[1] answers who: all users, specific groups, directory roles, external guests, or (with Workload ID licensing) workload identities. A sharp behavior to remember: policies targeting roles or groups are evaluated only when a token is issued, so a user added to a targeted group is not subject to the policy until they get a new token; the policy does not apply retroactively to an existing valid token.

Target resources^[4] (formerly "cloud apps") answers what, and it has three flavors: cloud apps (Microsoft and any Entra-integrated app), user actions (only two exist: Register security information and Register or join devices), and authentication context (covered in its own section below). Group the Microsoft 365 services under the Office 365 app rather than targeting Exchange or SharePoint individually, because those services have interlocking dependencies and a partial policy creates gaps.

Network and conditions

Network^[1] answers where: IP ranges, countries/regions, and Global Secure Access compliant network. You define named locations and can mark some trusted. Conditions^[1] are the finer filters: sign-in risk and user risk (fed from Microsoft Entra ID Protection^[1], and the reason risk conditions need Entra ID P2), device platforms (derived from the user-agent string, so treat it as advisory not authoritative), client apps (browser vs. mobile/desktop, the lever for blocking legacy authentication), and filter for devices.

Filter for devices and device-enforced restrictions

Filter for devices^[2] targets or excludes devices by a rule over device-object attributes such as trustType (AzureAD = Entra joined, ServerAD = hybrid joined, Workplace = registered), isCompliant, deviceOwnership (Personal or Company), model, operatingSystem, and the customer-set extensionAttribute1-extensionAttribute15. The canonical privileged-access-workstation (PAW) pattern uses two policies: one grants admins access requiring MFA and compliance, and a second blocks access except on devices matching device.extensionAttribute1 -eq "SAW". One trap the docs call out: for an unregistered device every attribute is null, so a positive operator (Equals, In) never matches it; to catch unregistered devices use a negative operator (NotEquals, NotIn), which evaluates true against the null. Filter for devices is one expression of device-enforced restrictions; the other is the app-enforced restrictions^[1] session control, explained in full under Access controls below.

The four assignment dimensions as nested groups (no flow): every dimension you set ANDs with the rest, so each one narrows which sign-ins the policy matches.

Access controls: grant, block, and session

If the assignments said which sign-ins, the access controls say what to do about them. There is exactly one structural split here: a grant decision (which is itself either Block or Grant-with-requirements) and a set of session controls layered on top once access is granted. The figure shows the two groups side by side, the grant controls on the left and the session controls on the right, and the prose walks each column in turn.

Grant controls and their combination logic

The grant controls^[1] are Block access, or Grant access with one or more of: Require multifactor authentication, Require authentication strength, Require device to be marked as compliant (Intune), Require Microsoft Entra hybrid joined device, Require approved client app, Require app protection policy, Require password change, and Require terms of use. When you select more than one, the toggle Require all the selected controls ANDs them, while Require one of the selected controls ORs them; multiple controls default to all. Require authentication strength is the modern, granular form of "Require MFA": instead of "any second factor," it names an allowed set of methods (for example phishing-resistant MFA), which is exactly what you reach for on high-value targets.

A classic distractor lives in the device controls. Require device to be marked as compliant trusts an Intune compliance evaluation^[2] and works across platforms; Require Microsoft Entra hybrid joined device only checks that the device is hybrid joined to on-premises AD and Entra, with no compliance assessment. They are not interchangeable: a question that says "managed and healthy" wants compliant; one that says "domain-joined corporate Windows" wants hybrid joined.

Session controls

Session controls^[3] shape the granted session. Sign-in frequency overrides the default rolling 90-day session with a fixed interval (hours or days) or the Every time option for the most sensitive actions; note that every time re-prompts only when the session is evaluated, factoring in five minutes of clock skew, so it does not force a sign-in merely because the browser was closed and reopened. Persistent browser session controls the "Stay signed in?" behavior. App-enforced restrictions pass device state to Exchange Online and SharePoint Online only. Conditional Access App Control routes the session through Microsoft Defender for Cloud Apps^[1] to block download/print of sensitive files or require labeling. Customize continuous access evaluation lives here too. Before turning sign-in frequency on, disable "Remember MFA on trusted devices," or the two settings prompt users unexpectedly.

Access controls split into two groups (no flow): grant controls decide entry (Block, or grant with one or more requirements), session controls shape the granted session.

Continuous access evaluation: revoke without waiting for token expiry

The problem CAE solves in one line: an access token is normally valid for an hour, so a user you disabled can keep reaching email until their token expires. Continuous access evaluation (CAE)^[5] fixes this by turning the one-way "here is a token" into a two-way conversation between Microsoft Entra (the token issuer) and the resource (the relying party), so the resource can reject a still-valid token the moment something changes. The figure splits CAE into its two scenarios, critical event evaluation on the left and Conditional Access policy evaluation on the right, which the two subsections below take in turn.

Critical event evaluation

CAE has two scenarios. The first, critical event evaluation, does not depend on any Conditional Access policy and is therefore available in any tenant. Entra-aware services (Exchange Online, SharePoint Online, Teams) subscribe to a fixed set of critical events and enforce them near real time: user account deleted or disabled, password changed or reset, MFA enabled for the user, an admin explicitly revoking all refresh tokens, and high user risk detected by Entra ID Protection^[5]. When one fires, the resource returns a 401 + claim challenge, the CAE-capable client bypasses its token cache, and Entra re-evaluates and reauthenticates. The second scenario, Conditional Access policy evaluation, syncs key policies (notably IP-based location) into the resource so a move out of an allowed network is caught in near real time.

The counterintuitive part: longer tokens, not shorter

Here is the fact most exam questions hinge on, and it reads backwards at first. Because risk and policy are now evaluated continuously, CAE-aware sessions stop relying on a static token lifetime, and the token lifetime actually increases to long-lived, up to 28 hours. That is not a security regression: revocation is driven by critical events, not by an arbitrary clock, so the long token buys stability while CAE handles the security. Without CAE-capable clients, your default access token lifetime stays 1 hour. Two limits worth memorizing: CAE only understands IP-based named locations (not country/region or MFA-trusted-IPs), and if the sum of all IP ranges in your location policies exceeds 5,000, Entra falls back to a one-hour token for the location-change flow. CAE also does not support guest users, and standard location enforcement tolerates an allowed-egress-IP mismatch, whereas Strict Location Enforcement removes that tolerance.

CAE’s two scenarios as groups (no flow): critical event evaluation needs no policy and runs in any tenant; policy evaluation syncs IP-based location into the resource.

Authentication context and protected actions

Sometimes you do not want to gate a whole app, only one sensitive thing inside it: a single SharePoint site, a Purview-labeled document, or the act of deleting a Conditional Access policy. Authentication context is the mechanism that makes a Conditional Access policy enforceable at that granularity, and protected actions are authentication context applied to specific Entra permissions. The figure traces the authentication-context lifecycle, define a tag, publish it, attach it to a resource and a policy, then a claims challenge steps the user up, which the first subsection walks step by step.

Authentication context

An authentication context^[4] is a small tag, with a display name and a read-only ID in the range c1 through c99 (up to 99 definitions per tenant), that you select as a target resource in a Conditional Access policy. You then attach that tag to a resource: a SharePoint site, a Microsoft Purview sensitivity label^[4], a Microsoft Defender for Cloud Apps session policy, a custom app, or a Privileged Identity Management role's On activation setting. For the context to be assignable to resources, you must tick Publish to apps; an unpublished context is invisible to downstream resources. When a user touches the tagged resource, the app issues a claims challenge asking for that context, and Entra steps the user up through whatever the matching policy requires. The result is step-up authentication only at the sensitive boundary, instead of MFA on every sign-in.

Protected actions

Protected actions^[6] are Entra ID permissions that have a Conditional Access authentication context attached, so the policy is enforced when the user performs the action, not at sign-in or role activation. The protectable set is deliberately small and high-impact: managing Conditional Access policies (microsoft.directory/conditionalAccessPolicies/create, .../delete, .../basic/update), cross-tenant access settings, hard-deleting directory objects (microsoft.directory/deletedItems/delete), and managing named locations. The intended pattern is to require phishing-resistant MFA before an admin can, say, delete a CA policy. Protected actions require Microsoft Entra ID P1^[6].

Two distinctions the exam loves. First, protected actions versus PIM role activation: PIM enforces a policy when a user activates a role (broad, role-scoped); protected actions enforce when a user takes a specific action (narrow, permission-scoped, independent of role), and the two combine for stronger coverage. Second, protected actions are not an authorization control: they add an access requirement to a permission, they do not decide who holds the permission. Gating who can do something is a role assignment, not a protected action. And because new terms-of-use pages and custom controls register themselves with Conditional Access, creating one is itself subject to the CA-management protected action, which can briefly block you until you relax the policy.

Authentication context step-up flow: define the tag, publish it, attach it to a resource and a policy, and a claims challenge steps the user up at the boundary.

Plan, test, and troubleshoot: report-only, templates, and exam patterns

A Conditional Access policy that is wrong can lock out an entire organization, so Microsoft built the rollout and testing tools to be conservative by default. This section is the operational and exam-recognition layer over the model above. The figure shows the safe rollout path, report-only, then review impact, then exclude break-glass accounts, then On, which the report-only subsection details next.

Report-only and policy state

Every policy is in one of three states: On, Off, or Report-only. Report-only^[7] evaluates the policy on each sign-in and logs the verdict but enforces nothing, so you measure impact before you bite. The result values you will see in the sign-in log are exact and testable: Report-only: Success, Report-only: Failure, Report-only: User action required (the controls would have prompted, but report-only never prompts), and Report-only: Not applied (conditions did not match). You review aggregate impact in the Conditional Access insights workbook (needs Entra ID P1 and a Log Analytics workspace) or the Policy impact view. One caveat: report-only does not work for the User Actions scope, and report-only compliant-device policies can still prompt macOS/iOS/Android users for a certificate, so exclude those platforms from such report-only policies.

Templates and exclusions

Rather than build from scratch, start from a policy template^[8]. Templates are grouped into categories (Secure foundation, Zero Trust, Remote work, Protect administrator, Emerging threats) and, crucially, each template is created in report-only mode by default. A template's user-exclusion only excludes the policy's creator, so after creating one you must edit it to exclude your emergency-access (break-glass) accounts and service principals^[8]. You can also export a template's JSON and re-import it for programmatic deployment.

Troubleshooting and exam-pattern recognition

When policy changes must apply immediately rather than waiting for the next token, the documented lever is to revoke the user's sessions (the Microsoft Graph PowerShell Revoke-MgUserSignInSession, or Revoke Session on the user's profile), because group/policy changes otherwise take up to a day to propagate to resources. Stem-to-answer cues: "a disabled user still reads email for an hour" points to CAE; "step up only when deleting a CA policy" points to protected actions; "protect one SharePoint site, not the whole tenant" points to authentication context; "test the new MFA policy without locking anyone out" points to report-only; "only corporate laptops" points to Require compliant device (Intune), while "domain-joined Windows" points to hybrid joined; "admins lost access after a policy change" points to a missing break-glass exclusion. The most common wrong answer across all of these is reaching for a shorter token lifetime, which CAE deliberately replaced.

Report-only rollout flow modeled on Microsoft’s report-only mode docs (cited above): start in report-only, review impact, exclude break-glass accounts, then turn the policy On.

The three parts of a Conditional Access policy

Part	Assignments (the "if")	Grant controls (the "then": entry)	Session controls (the "then": session)
What it decides	Which sign-ins the policy matches	Whether access is granted, and with what proof	How the granted session behaves
Example settings	Users, target resources, network, conditions	Block; or require MFA, compliant device, hybrid join, auth strength	Sign-in frequency, persistent browser, app-enforced, CAE
Combination logic	All assignments AND together	AND (all selected) or OR (one of selected); Block wins	Applied after all grant controls are satisfied
Key license/role	Conditional Access Administrator to author; Entra ID P1	P1; P2 for risk conditions	P1/P2; CAE works in any tenant for critical events
Common trap	Forgetting all assignments must match, so an over-scoped policy never fires	Assuming two MFA policies stack; one satisfied MFA claim covers both	Thinking sign-in frequency every-time logs out on browser close (it does not)

Decision tree

Cheat sheet

Sharp facts the exam loves — give these one last read before exam day.

Cheat sheet

Sharp facts the exam loves — scan these before test day.

A Conditional Access policy is an if-then statement: assignments then access controls

Read every Conditional Access policy as "if these signals match, then enforce these controls." The assignments are the if (users, target resources, network, conditions), and the access controls are the then (grant or block, plus session controls). All assignments in one policy combine with AND, so each one you add narrows the policy; an over-scoped policy with too many conditions simply never fires.

Trap Assuming an assignment you add only adds reach; every assignment ANDs, so adding one more condition can stop a policy from ever matching.

When several policies match a sign-in, all of them must be satisfied

Multiple Conditional Access policies can apply to one sign-in, and the user must satisfy every applicable policy, not just one. If one policy requires MFA and another requires a compliant device, the user does both. A Block grant in any matching policy overrides all the grants, so block always wins.

Trap Treating policies as OR so satisfying one is enough; they AND across policies, and a single Block policy denies regardless of what others would grant.

2 questions test this

Grant controls AND by default; choose 'require one' to OR them

Inside one Grant block, 'Require all the selected controls' ANDs them (MFA and compliant device) and is the default for multiple controls, while 'Require one of the selected controls' ORs them (compliant device or MFA). The phase-2 prompt order is fixed: MFA, then compliant device, then hybrid joined, then approved client app, then app protection policy, then password change, then terms of use.

3 questions test this

Require authentication strength is the granular replacement for Require MFA

Require authentication strength names an allowed set of methods (for example phishing-resistant MFA) rather than 'any second factor,' so reach for it on high-value targets and admin actions. Plain Require multifactor authentication accepts any registered second factor. Authentication strengths let one grant control demand specifically phishing-resistant credentials.

Trap Using Require multifactor authentication when the requirement is phishing-resistant; plain MFA accepts SMS or a push, so you need Require authentication strength to force FIDO2 or certificate-based methods.

5 questions test this

Require compliant device (Intune) is not the same as Require hybrid joined

Require device to be marked as compliant trusts an Intune compliance evaluation and works across Windows, macOS, iOS, and Android; Require Microsoft Entra hybrid joined device only checks that the device is joined to both on-premises AD and Entra, with no health assessment. A stem about 'managed and healthy' wants compliant; one about 'domain-joined corporate Windows' wants hybrid joined.

Trap Choosing Require hybrid joined device when the goal is Intune-managed and healthy; hybrid join proves domain membership but performs no compliance check, so a non-compliant domain device still passes.

Block legacy authentication by targeting the legacy client-app condition

Legacy authentication protocols cannot perform MFA, so they are the most common path around an MFA policy. Block them with a Conditional Access policy whose client-apps condition selects the legacy/other clients and whose grant control is Block. This closes the bypass that an MFA-for-all-users policy alone leaves open.

Filter for devices targets devices by attribute rules like trustType and extensionAttribute

Filter for devices is a condition that includes or excludes devices by a rule over device-object attributes: trustType (AzureAD = Entra joined, ServerAD = hybrid joined, Workplace = registered), isCompliant, deviceOwnership (Personal or Company), model, operatingSystem, and the customer-set extensionAttribute1 through extensionAttribute15. The privileged-access-workstation pattern blocks access except where device.extensionAttribute1 equals SAW.

Use a negative operator in a device filter to catch unregistered devices

For an unregistered device every attribute is null, so a positive operator (Equals, In, StartsWith) never matches it and the filter does not apply. To target unregistered devices, use a negative operator (NotEquals, NotIn, NotStartsWith), which evaluates true against the null value. This is why PAW exclusion rules are written with -ne rather than -eq.

Trap Writing a device filter with a positive operator to catch unmanaged devices; an unregistered device has null attributes, so only a negative operator applies the rule to it.

Target resources includes apps, two user actions, and authentication context

Target resources (formerly cloud apps) has three flavors: cloud apps (Microsoft and Entra-integrated apps), user actions, and authentication context. Only two user actions exist: Register security information and Register or join devices. Group Microsoft 365 services under the Office 365 app instead of targeting Exchange or SharePoint individually, because their dependencies otherwise leave coverage gaps.

Trap Targeting Exchange Online or SharePoint Online individually for an M365 MFA policy; service dependencies mean only the Office 365 grouping covers all the related metadata and child services.

3 questions test this

Risk is a condition Conditional Access consumes, not something it computes

Conditional Access can use sign-in risk and user risk as conditions, but the scoring comes from Microsoft Entra ID Protection, which is why risk-based conditions require Entra ID P2. Conditional Access itself is a P1 capability. So a policy can act on 'High user risk,' but only ID Protection decides what counts as high.

Trap Assuming Conditional Access detects risk on its own; it only reads a risk level supplied by Entra ID Protection, and that pairing is what needs Entra ID P2.

Session controls shape the granted session, starting with sign-in frequency

Once grant controls are satisfied, session controls apply. Sign-in frequency overrides the default rolling 90-day session with a fixed hours/days interval or 'Every time' for sensitive actions. Persistent browser session governs 'Stay signed in?'. App-enforced restrictions pass device state to Exchange Online and SharePoint Online only. Conditional Access App Control routes the session through Microsoft Defender for Cloud Apps.

4 questions test this

Sign-in frequency 'Every time' does not log a user out on browser close

Sign-in frequency 'Every time' forces reauthentication when the session is evaluated, factoring in five minutes of clock skew, not whenever the browser closes and reopens. Before enabling sign-in frequency, disable 'Remember MFA on trusted devices' or the two settings prompt users unexpectedly. The default user sign-in frequency is a rolling window of 90 days.

Trap Believing 'Every time' reauthenticates on every browser restart; it re-prompts only on session evaluation with a five-minute clock-skew buffer, so closing and reopening the browser does not necessarily prompt.

6 questions test this

Continuous access evaluation revokes still-valid tokens on critical events

CAE turns token issuance into a two-way conversation so a resource can reject a non-expired token in near real time. Critical event evaluation needs no Conditional Access policy and works in any tenant, firing on: user deleted or disabled, password changed or reset, MFA enabled for the user, admin revokes all refresh tokens, and high user risk from ID Protection. The resource returns a 401 plus claim challenge and the client bypasses its cache.

Trap Shortening token lifetimes to enforce a disablement faster; Microsoft replaced that 'blunt object' approach with CAE, which revokes on the critical event instead of waiting for expiry.

7 questions test this

CAE sessions use long-lived tokens up to 28 hours, not shorter ones

Because CAE evaluates risk and policy continuously, CAE-aware sessions stop honoring static token lifetimes and the access token grows to long-lived, up to 28 hours. Revocation is driven by critical events, not a clock, so the long token improves stability without weakening security. Without CAE-capable clients the default access token lifetime stays 1 hour.

Trap Assuming CAE shortens token lifetime; it lengthens it to up to 28 hours because critical events, not expiry, now drive revocation.

5 questions test this

CAE only enforces IP-based named locations and falls back past 5,000 ranges

CAE has insight only into IP-based named locations, not country/region locations or MFA-trusted-IPs; coming from those, CAE will not enforce the location change. If the sum of all IP ranges in location policies exceeds 5,000, Entra falls back to a one-hour token for the location-change flow while still enforcing other events. CAE also does not support guest users, and Strict Location Enforcement removes the standard tolerance for an allowed-egress-IP mismatch.

Trap Configuring a country/region named location and expecting CAE to enforce a move in real time; CAE only understands IP-based named locations.

2 questions test this

Authentication context protects a single resource or action, with IDs c1 to c99

An authentication context is a tag (display name plus a read-only ID in the range c1 to c99, up to 99 per tenant) that you select as a target resource in a Conditional Access policy and then attach to a specific resource: a SharePoint site, a Microsoft Purview sensitivity label, a Defender for Cloud Apps session policy, a custom app, or a PIM role's On activation setting. You must tick 'Publish to apps' or the context is invisible to downstream resources.

Trap Creating an authentication context but leaving 'Publish to apps' unchecked; an unpublished context cannot be assigned to any resource and the protection never takes effect.

10 questions test this

Protected actions step up specific Entra permissions at action time

Protected actions attach a Conditional Access authentication context to a small set of high-impact Entra permissions, enforcing the policy when the user performs the action rather than at sign-in or role activation. The protectable set includes managing Conditional Access policies (create/delete/basic update), cross-tenant access settings, hard-deleting directory objects, and managing named locations. The intended pattern is to require phishing-resistant MFA before deleting a CA policy. Protected actions need Entra ID P1.

1 question tests this

You have a Microsoft Entra tenant. An administrator named Admin1 has a permanent active assignment for the Conditional Access Administrator…

Protected actions add a requirement to a permission, they do not decide who holds it

Protected actions apply an access requirement (such as step-up MFA) to performing a permission; they are not an authorization control and do not block a permission based on identity or group membership. Who can do something is a role-assignment decision. Protected actions differ from PIM role activation, which enforces a policy when a user activates a role; the two combine for stronger coverage.

Trap Using protected actions to stop a specific user or group from holding a permission; that is an authorization decision made by role assignment, while protected actions only add a step-up requirement to performing the action.

Report-only mode evaluates and logs a policy without enforcing it

Report-only is a policy state (alongside On and Off) that evaluates the policy on each sign-in and logs what it would have done without enforcing grant or session controls, so users are never prompted or blocked. Review impact in the sign-in log's Report-only tab, the Conditional Access insights workbook (needs Entra ID P1 and a Log Analytics workspace), or the Policy impact view. It is the standard way to measure blast radius before turning a policy On.

8 questions test this

Report-only result values: Success, Failure, User action required, Not applied

A report-only policy logs one of four results per sign-in: Report-only: Success (controls already satisfied), Report-only: Failure (conditions matched but a non-interactive control or block was not satisfied), Report-only: User action required (conditions matched but the user would have been prompted, and report-only never prompts), and Report-only: Not applied (conditions did not match). Report-only does not work for the User Actions scope.

Trap Reading 'Report-only: User action required' as a failure; it means the conditions matched and the policy would have prompted the user, but report-only mode suppresses the prompt.

Create policies from templates, which start in report-only by default

Policy templates deploy Microsoft-recommended policies grouped into categories (Secure foundation, Zero Trust, Remote work, Protect administrator, Emerging threats), and each template is created in report-only mode by default. A template's user exclusion only excludes the policy's creator, so after creating one you must edit it to exclude your other break-glass accounts. You can export a template's JSON and re-import it for programmatic deployment.

Trap Assuming a template already excludes all your emergency accounts; it excludes only the creating admin, so you must add break-glass exclusions after creating it.

3 questions test this

Always exclude break-glass and service accounts from every policy

Exclude emergency-access (break-glass) accounts and service principals from every Conditional Access policy so a misconfiguration cannot lock out all administrators. A break-glass account that is itself caught by a faulty MFA or device policy defeats its purpose. Service accounts are noninteractive and should be replaced with managed identities where possible, with workload-identity Conditional Access used to target service principals.

Trap Applying a require-MFA-for-all-admins policy without excluding the break-glass account; if the policy misfires, the recovery account is locked out along with everyone else.

1 question tests this

You are creating a Conditional Access policy that requires MFA for all users when accessing all resources. You need to follow Microsoft…

Conditional Access policy changes take up to a day; revoke sessions to apply now

Group membership and policy changes can take up to a day (optimized to about two hours for some policy updates) to propagate to resources like Exchange Online and SharePoint Online. To apply a change immediately to a user, revoke their sessions with Revoke-MgUserSignInSession in Microsoft Graph PowerShell or Revoke Session on the user's profile, which forces fresh evaluation on the next token request.

Trap Waiting for a policy or group-membership change to apply on its own when it must take effect immediately; revoke the user's sessions to force re-evaluation rather than waiting up to a day for propagation.

Conditional Access policies apply only to built-in directory roles

When you target directory roles in a Conditional Access policy, only built-in roles are honored; the policy is not enforced for administrative-unit-scoped or custom roles. Policies targeting roles or groups are also evaluated only when a token is issued, so a user newly added to a targeted role is not subject to the policy until their next token, not retroactively.

Trap Expecting a Conditional Access policy that targets a custom or administrative-unit-scoped role to enforce; only built-in directory roles are supported as a target.

2 questions test this

Persistent browser session control requires All resources as the target

The persistent browser session control (Never persistent / Always persistent) can only be saved when target resources is set to All resources (formerly All cloud apps). Browser session persistence is governed by a single authentication session token shared across all tabs in the browser, so it can't be scoped to one app; the control requires selecting all cloud apps as a condition.

Trap Sign-in frequency can target specific apps, but persistent browser session cannot; the fix when the control won't save is to widen target resources to All resources, not to change the session control.

4 questions test this

Token protection covers only specific native apps, not browsers

Require token protection for sign-in sessions cryptographically binds the session token to the device (using the device-bound Primary Refresh Token) to stop token replay. It currently supports native applications only — browser-based applications are not supported. Enforcement is generally available on Windows 10+ devices that are Entra joined, hybrid joined, or registered (preview on iOS/iPadOS and macOS), and it can be enforced for Exchange Online, SharePoint Online, and Microsoft Teams (plus Azure Virtual Desktop and Windows 365 on Windows). Because browsers aren't covered, the policy should target the Mobile apps and desktop clients client-app condition.

Trap Browser sessions are unaffected by token protection (not supported); if users report the web app is unprotected while the desktop app is protected, that is expected behavior, not a misconfiguration.

4 questions test this

Use the What If tool to simulate which policies apply before a real sign-in

The Conditional Access What If tool evaluates which policies would apply to a chosen user under conditions you specify (device platform, IP address or country, app) without the user signing in and without enforcing anything. It includes both enabled and report-only policies and explains why policies do not apply. It does not test for Conditional Access service dependencies (for example a Teams sign-in that also depends on Exchange Online), so a user can still be blocked by a dependency policy the tool reports as not applying.

Trap What If ignores service dependencies; if it shows no blocking policy yet the user is still blocked, suspect a policy on a dependent service (such as Exchange Online behind Teams).

6 questions test this

Exempt the office from MFA by excluding trusted named locations

To require MFA only off the corporate network, set the network condition to include Any location and exclude All trusted locations, then define the office IP ranges as a named location and select Mark as trusted location. The All trusted locations exclusion applies only to locations that carry the trusted designation, so an unmarked named location still triggers MFA. Sign-ins from trusted named locations also improve the accuracy of Microsoft Entra ID Protection's risk calculation.

Trap Creating the named location is not enough; if users on the corporate network are still prompted, the named location was not marked trusted and therefore is not covered by the All trusted locations exclusion.

3 questions test this

Prepare for CAE strict location enforcement with the CAE Insights workbook

Before enabling strictly enforce location policies for continuous access evaluation, use the Continuous Access Evaluation Insights workbook to find sessions where the IP address seen by Microsoft Entra ID differs from the IP address seen by the resource, then add all known organizational egress IPs to IP-based named locations. Split-tunnel network configurations cause these mismatches and will otherwise block users once strict enforcement is on.

Trap The discrepancy is between Entra ID's detected IP and the IP address (seen by resource) value; compare against your named locations and add egress IPs first rather than disabling the policy.

3 questions test this

Block only sensitive files with a Defender for Cloud Apps inspection session policy

To allow access but block only files containing sensitive data, use the Conditional Access App Control session control with a Defender for Cloud Apps session policy whose session control type is Control file download (with inspection) or Control file upload (with inspection), then set the action to Block. Content inspection scans the file and blocks only matches, leaving non-sensitive transfers allowed. Block activities is the control type for in-session actions like print and copy.

Trap Setting Control file download (with inspection) with a Block action and no file filter blocks every download, including non-sensitive ones; selective blocking requires the inspection-based file filter so only sensitive matches are blocked.

6 questions test this

Trust inbound MFA so guests satisfy auth strength with home-tenant credentials

When an authentication strength policy applies to external Microsoft Entra users, enable Trust multifactor authentication from Microsoft Entra tenants in your inbound cross-tenant access settings. The resource tenant then accepts MFA claims completed in the guest's home tenant, so acceptable home-tenant methods satisfy the strength without forcing the guest to register new credentials in your tenant.

Trap Without inbound MFA trust, B2B guests can't satisfy the strength with their home-tenant MFA; the fix is the cross-tenant trust setting, not changing or relaxing the authentication strength.

3 questions test this

Also tested in

AZ-900 Microsoft Azure Fundamentals

The if-then engine: assignments and access controls

The two phases of evaluation

How policies and controls combine

Assignments: who, what, and where

Users and target resources

Network and conditions

Filter for devices and device-enforced restrictions

Access controls: grant, block, and session

Grant controls and their combination logic

Session controls

Continuous access evaluation: revoke without waiting for token expiry

Critical event evaluation

The counterintuitive part: longer tokens, not shorter

Authentication context and protected actions

Authentication context

Protected actions

Plan, test, and troubleshoot: report-only, templates, and exam patterns

Report-only and policy state

Templates and exclusions

Troubleshooting and exam-pattern recognition

The three parts of a Conditional Access policy

Decision tree

Cheat sheet

Also tested in

References