Conditional Access explained for exams
Conditional Access is the policy engine in Microsoft Entra that decides, after a user has passed the first sign-in step, whether to block access, allow it, or allow it only if extra requirements are met (MFA, a compliant device, a password change). Each policy is an if-then rule. The decision rule for exams: if the scenario says access should depend on a condition (location, device state, risk, which app), the answer is Conditional Access; if it says a role should be held only temporarily, it is Privileged Identity Management instead.
What one policy is made of
A policy has two halves. The first half says when the policy applies, the second says what happens.
| Half | Part | Examples |
|---|---|---|
| Assignments | Users, groups, roles | All users, a group, directory roles, guests (with Workload ID licences, workload identities too) |
| Assignments | Target resources | Cloud apps, user actions, authentication contexts |
| Assignments | Network and conditions | IP ranges and countries, sign-in risk, device platform, client app, device filter |
| Access controls | Grant | Block access, or grant with: MFA, authentication strength, compliant device, hybrid joined device, app protection policy, approved client app (read-only since June 30, 2026: existing policies still enforce it, but new policies should use app protection policy), password change, terms of use |
| Access controls | Session | Sign-in frequency, persistent browser, app-enforced restrictions, Conditional Access App Control, continuous access evaluation |
All assignments are combined with AND. If a policy targets “all users” and “Exchange Online” and “unmanaged devices”, it fires only when all three are true. Within the grant control, several selected requirements default to “require all”; the administrator can switch to “require one of the selected”.
One fact that the exam leans on: Conditional Access is enforced after first-factor authentication. It does not replace sign-in and it is not a firewall in front of the sign-in page. Per Microsoft, it needs Microsoft Entra ID P1 (also covered by Microsoft 365 Business Premium). Risk-based conditions (sign-in risk, user risk) come from ID Protection, which is a P2 feature. Security defaults are the free alternative, and they cannot be combined with Conditional Access policies.
How several policies combine
Policies do not compete and there is no priority order. Every enabled policy that applies to the sign-in is evaluated, and the user must satisfy all of them. Evaluation has two phases: the first collects session details such as location and device state, the second enforces. A block control ends the process there. Grant requirements that are still unmet are then requested, and only after that are session controls applied.
Two consequences that questions exploit:
- Block always wins. You cannot rescue a blocked sign-in with a more permissive policy. You fix it by excluding the user or the condition from the block policy.
- Exclusions are the exception mechanism. The standard pattern is a broad policy plus an exclusion for emergency access (break-glass) accounts, so a mistake in the policy cannot lock every administrator out.
New policies should first run in report-only mode, which logs what would have happened without enforcing it. The What If tool and the sign-in log’s Conditional Access tab show which policies applied to a specific sign-in.
Worked example
A company has three policies, all targeting Microsoft 365:
- P1 requires MFA for all users.
- P2 requires a compliant device for the Finance group.
- P3 blocks sign-ins from countries where the company does not operate.
Dana, in Finance, signs in from the office on an unmanaged laptop. P3 does not apply (location is fine). P1 and P2 both apply, so she needs MFA and a compliant device. The laptop is not compliant, so she is refused until she uses a managed device.
Now Dana travels to a blocked country and signs in from a compliant laptop with MFA. P1 and P2 would both be satisfied, but P3 applies and blocks. Nothing she does with MFA or the device changes that.
The lesson: read each policy independently, collect every policy whose assignments match, and the result is the strictest combination.
Which exams test this
| Exam | How it appears | Covered on this site |
|---|---|---|
| SC-300 | Implement authentication and access management (25–30%): plan policies, implement assignments and controls, test and troubleshoot, session management, continuous access evaluation, authentication context, protected actions and templates; user and sign-in risk policies sit in the same domain | Authentication and access |
| SC-900 | Capabilities of Microsoft Entra (25–30%): describe Microsoft Entra Conditional Access, at concept level | Microsoft Entra explained |
| AZ-900 | Describe Azure architecture and services (35–40%): describe Microsoft Entra Conditional Access, at concept level | Architecture and services |
| AZ-305 | Design identity, governance, and monitoring solutions (25–30%): recommend an authentication solution. Conditional Access is not named in the outline, so it is an indirect, design-level topic | Identity, governance and monitoring |
| SC-500 | Manage identity, access, and governance (20–25%): implement Conditional Access policies. Secure compute (20–25%) adds Conditional Access for Microsoft Entra Agent ID | Identity, access and governance, Secure compute |
| AB-900 | Core features and objects of Microsoft 365 services (30–35%): understand Conditional Access policies and use it as one of the tools to troubleshoot sign-in issues | Microsoft 365 core features |
Rows for SC-300, SC-900 and AB-900 follow the English outlines that apply from October 28, October 21 and October 14, 2026; their change logs list only minor changes.
How questions are built around it
The usual wrong answers are tools that sound related. If the requirement is “require MFA only when signing in from outside the corporate network”, the options will include RBAC, Azure Policy and a named location on its own. A named location only defines an IP range; the policy that uses it does the enforcing. RBAC controls what you may do after you are in, never how you sign in.
Words that decide the answer:
- “Only when” / “unless” / “from untrusted locations”: a condition, so Conditional Access.
- “Block”: the block grant control, not a grant with requirements.
- “Without affecting” or “before enforcing”: report-only mode.
- “Compliant device”: Intune compliance feeding a grant control. Conditional Access does not judge compliance itself.
- “Block downloads but still allow access”: a session control (Conditional Access App Control), not a block.
- “Every time an administrator activates a role”: an authentication context tied to PIM, covered in the PIM guide.
Another trap is timing. Policies that target roles or groups are evaluated when a token is issued, so a user added to a group is not affected until a new token is issued.
Practice questions
Question 1. A company wants to require multifactor authentication for Microsoft 365 only when users sign in from outside the corporate network. Users on the corporate network must not be prompted. What should you configure?
- A. An Azure RBAC role assignment at the subscription scope
- B. An Azure Policy assignment on the tenant root management group
- C. A Conditional Access policy with a location condition and a grant control that requires MFA
- D. A Microsoft Entra role assigned to all users
Show answer
Answer: C
A Conditional Access policy can combine a location condition (excluding the trusted corporate network) with a grant control that requires MFA, which gives exactly the described behaviour. Azure RBAC controls permissions on Azure resources, not how users sign in. Azure Policy governs resource configuration. A Microsoft Entra role assigned to users changes administrative permissions and has no effect on MFA prompts.
Question 2. Policy A requires MFA for all users of Microsoft 365. Policy B blocks sign-ins from a specific country. Both are enabled. A user in that country completes MFA successfully on a compliant device. What is the result?
- A. Access is granted because policy A is satisfied
- B. Access is granted because the device is compliant
- C. The user is prompted for MFA a second time
- D. Access is blocked
Show answer
Answer: D
Every enabled policy that applies must be satisfied, and a block control stops evaluation at enforcement. Completing MFA satisfies policy A only. Policy B still applies, so access is blocked. Policies have no priority order, and a more permissive policy cannot override a block. Compliance of the device is irrelevant because no policy here grants access based on it.
Go deeper
- What is Conditional Access (Microsoft Learn)
- Building a Conditional Access policy, including the two enforcement phases (Microsoft Learn)
- Report-only mode (Microsoft Learn)
- Related on this site: Privileged Identity Management, Azure RBAC vs Entra roles, Zero Trust explained and how to read a skills outline.