Conditional Access Policy Planning and Templates – SC-300 Exam Guide
Why Is Conditional Access Policy Planning Important?
Conditional Access is the cornerstone of Microsoft's Zero Trust security model. It acts as the decision engine that evaluates signals (such as user identity, device state, location, application sensitivity, and real-time risk) and enforces granular access decisions. Without proper planning, organizations risk either being too permissive (leaving resources exposed) or too restrictive (blocking legitimate productivity). For the SC-300 exam, Microsoft expects you to understand not just how to create policies, but how to plan them strategically so they work together without conflicts, gaps, or unintended lockouts.
What Is Conditional Access Policy Planning?
Conditional Access Policy Planning is the structured process of designing, organizing, and deploying Conditional Access policies in Microsoft Entra ID (formerly Azure AD). It involves:
• Identifying the organization's security requirements and compliance obligations
• Mapping out which users, groups, applications, and conditions each policy should target
• Choosing the appropriate grant and session controls
• Ordering and naming policies logically for manageability
• Using Report-Only mode to test policies before enforcement
• Leveraging Conditional Access Templates provided by Microsoft to accelerate deployment
What Are Conditional Access Templates?
Microsoft provides pre-configured Conditional Access policy templates based on common security scenarios. These templates are aligned with Microsoft's recommendations and are categorized into groups such as:
• Secure foundation – e.g., Require MFA for all users, Require MFA for admins, Block legacy authentication
• Zero Trust – e.g., Require MFA for all users, Require compliant device, Require MFA for risky sign-ins
• Remote work – e.g., Require MFA for all users when outside trusted locations, Block access from certain regions
• Protect administrator – e.g., Require MFA for admin roles, Require phishing-resistant MFA for admins
• Emerging threats – e.g., Block access for high-risk users, Require password change for high-risk users
Templates help organizations quickly implement best-practice policies without building them from scratch. They can be deployed in Report-Only, On, or Off states.
How Does Conditional Access Policy Planning Work?
The planning process follows these key steps:
1. Define Personas and Groups
Identify user categories: administrators, regular employees, guests, service accounts, and emergency (break-glass) accounts. Always exclude break-glass accounts from restrictive policies to prevent lockout.
2. Inventory Target Applications
Determine which cloud apps and on-premises apps (published via App Proxy) need protection. Consider targeting All cloud apps for baseline policies, and specific apps for more restrictive controls.
3. Identify Conditions (Signals)
Plan which signals each policy will evaluate:
• User/Group membership – who the policy applies to
• Cloud apps or actions – which resources are targeted
• Sign-in risk level (requires Identity Protection P2) – low, medium, high
• User risk level (requires Identity Protection P2) – low, medium, high
• Device platform – Windows, iOS, Android, macOS, Linux
• Location – named locations (IP ranges), trusted locations, countries
• Client apps – browser, mobile apps and desktop clients, legacy authentication clients
• Device state / compliance – Intune-compliant, Hybrid Azure AD joined
• Filter for devices – device attributes for fine-grained targeting
4. Choose Grant Controls
Decide what happens when conditions are met:
• Block access – completely deny access
• Grant access with one or more requirements: Require MFA, Require device to be marked as compliant, Require Hybrid Azure AD joined device, Require approved client app, Require app protection policy, Require password change, Require authentication strength (e.g., phishing-resistant MFA)
• You can require all selected controls or one of the selected controls
5. Choose Session Controls
Optionally apply session-level restrictions:
• App enforced restrictions (e.g., limited access in SharePoint Online)
• Conditional Access App Control (routes sessions through Microsoft Defender for Cloud Apps)
• Sign-in frequency – how often users must re-authenticate
• Persistent browser session – allow or disallow persistent sessions
• Continuous access evaluation – enable strict enforcement or use default behavior
• Disable resilience defaults – in rare scenarios, prevent use of cached session data
6. Test with Report-Only Mode
Before turning on a policy, deploy it in Report-Only mode. This logs what would happen without actually enforcing the policy. Review sign-in logs and the Conditional Access insights workbook to validate impact.
7. Use the What If Tool
The What If tool in Microsoft Entra ID allows you to simulate a sign-in scenario and see which policies would apply. This is critical during planning and troubleshooting.
8. Implement a Naming Convention
Microsoft recommends a structured naming convention, for example:
CA001: Require MFA for all users – All cloud apps
CA002: Block legacy authentication – All users
This makes policies easier to manage, audit, and troubleshoot.
9. Plan for Known Exclusions
• Break-glass (emergency access) accounts – always exclude from blocking policies
• Service accounts / service principals – may need separate handling using workload identity policies
• Guest accounts – may require separate policies tailored to external collaboration
10. Document and Review Regularly
Document all policies, their purpose, assigned groups, and conditions. Review policies regularly as the organization's requirements evolve.
Key Concepts to Remember for the SC-300 Exam
• Conditional Access requires at minimum Microsoft Entra ID P1 licensing. Features like sign-in risk and user risk require Microsoft Entra ID P2 (Identity Protection).
• Policies are evaluated at sign-in time (with continuous access evaluation extending enforcement beyond sign-in).
• If multiple policies apply, all policies are evaluated and all applicable controls must be satisfied. If any policy blocks access, access is blocked regardless of other policies that might grant access. Block always wins.
• Report-Only mode does NOT enforce the policy. It only logs results.
• Conditional Access Templates provide Microsoft-recommended starting configurations but can be customized.
• The What If tool simulates policy evaluation for a hypothetical sign-in.
• Authentication strength is a grant control that allows you to specify which authentication method combinations are acceptable (e.g., phishing-resistant MFA only), going beyond just requiring MFA.
• Named locations can be defined by IP ranges or countries/regions and can be marked as trusted.
• Legacy authentication clients do not support MFA, so the best practice is to block legacy authentication entirely via Conditional Access.
• Security defaults cannot be used at the same time as Conditional Access policies. If you enable Conditional Access, security defaults should be disabled.
Common Exam Scenarios
1. Scenario: Require MFA for admins only when signing in from outside the corporate network.
Answer: Create a policy targeting admin roles, all cloud apps, exclude trusted named locations, grant control = Require MFA.
2. Scenario: Block access for users flagged as high risk.
Answer: Create a policy with user risk condition = High, grant control = Block access. (Requires P2 licensing.)
3. Scenario: Allow mobile device access only from Intune-compliant devices.
Answer: Create a policy targeting all users, condition = device platform iOS/Android, grant control = Require device to be marked as compliant.
4. Scenario: Test a new policy without affecting users.
Answer: Deploy the policy in Report-Only mode and review the sign-in logs.
5. Scenario: Prevent lockout of all administrators.
Answer: Always exclude at least two break-glass emergency access accounts from Conditional Access policies that block access.
Exam Tips: Answering Questions on Conditional Access Policy Planning and Templates
1. Read for licensing clues. If a question involves sign-in risk or user risk, the answer likely requires Microsoft Entra ID P2. If it just mentions MFA or device compliance, P1 is sufficient.
2. Remember that Block always wins. If one policy grants access with MFA and another policy blocks access for the same scenario, access is blocked. This is a frequently tested concept.
3. Break-glass accounts are critical. Any question about preventing admin lockout will expect you to mention excluding emergency access accounts from blocking policies.
4. Report-Only mode is always the safe testing answer. If a question asks how to test a Conditional Access policy without impacting users, choose Report-Only mode. Do not confuse this with the What If tool, which simulates a single sign-in but doesn't provide ongoing monitoring data.
5. Know the difference between What If and Report-Only. What If = one-time simulation before deployment. Report-Only = ongoing logging of what would happen if the policy were enforced.
6. Understand grant control combinations. When a question specifies "Require MFA AND compliant device," the policy must use the "Require all the selected controls" option. When it says "MFA OR compliant device," use "Require one of the selected controls."
7. Know when to use Authentication Strength vs. Require MFA. If the question requires phishing-resistant MFA (e.g., FIDO2 keys, Windows Hello for Business, or certificate-based authentication), the answer is Authentication Strength, not the basic Require MFA control.
8. Templates are shortcuts, not mandatory. Exam questions about templates test whether you know they exist and that they align with Microsoft best practices. They are pre-built but fully customizable.
9. Legacy authentication = Block it. If a question mentions preventing the use of IMAP, POP3, SMTP, or older Office clients, the answer is a Conditional Access policy that targets the "Other clients" client app condition and blocks access.
10. Pay attention to exclusions in the question. Many exam questions involve specific exclusions (guest users, specific groups, specific platforms). Make sure the policy you choose correctly includes and excludes the right targets.
11. Named locations matter for location-based policies. Know that named locations can be IP-based or country-based, and that you must mark them as trusted explicitly if you want to use them as trusted in Conditional Access policies.
12. Session controls vs. Grant controls. If the question is about controlling what happens during a session (e.g., limiting downloads in SharePoint, requiring re-authentication every 4 hours), the answer involves session controls. If it is about whether to grant or deny access at sign-in, the answer involves grant controls.
13. Conditional Access and Security Defaults are mutually exclusive. If a question states that Security Defaults are enabled and asks you to implement a Conditional Access policy, you must first disable Security Defaults.
14. Workload identities. If a question asks about applying Conditional Access to service principals or managed identities, remember that workload identity Conditional Access policies are a separate feature (requires Workload Identities Premium license).
By mastering these planning principles, understanding how templates accelerate deployment, and applying these exam-specific strategies, you will be well-prepared to answer SC-300 questions on Conditional Access Policy Planning and Templates with confidence.
