This post is a part of the "SC-500: Implementing End-to-End Security Controls for Cloud and AI Workloads" Exam Prep Hub.
This topic falls under these sections:
Manage identity, access, and governance (20–25%)
   --> Secure access to resources by using Microsoft Entra ID
      --> Implement conditional access policies

Note that there are 10 practice questions (with answers) at the end of each section to help you solidify your knowledge of the material. Also, there are 4 practice tests with 30 questions each available from the hub's main page below the exam topics section.

Overview

Microsoft Entra Conditional Access is a policy-based access-control capability that allows an organization to make access decisions based on contextual information about a sign-in.

Rather than simply asking:

“Is this user allowed to access the resource?”

Conditional Access enables an organization to ask:

“Under what circumstances should this user be allowed to access this resource, and what security requirements must be satisfied?”

Conditional Access policies can evaluate signals such as:

User or group
Target resource
Device platform
Client application
Network location
User risk
Sign-in risk
Device state
Authentication context
Other contextual signals

Based on those conditions, a policy can:

Allow access
Require additional security controls
Require stronger authentication
Require a compliant device
Require an approved client application
Apply session restrictions
Block access

This makes Conditional Access an important component of a Zero Trust security strategy.

1. The Basic Conditional Access Model

A Conditional Access policy can be understood as:

IF certain conditions are met
THEN apply specified access controls.

For example:

IF a user accesses Microsoft 365 from an unmanaged device
THEN require multifactor authentication.

Another example:

IF a user attempts to access an application from a high-risk sign-in
THEN block access.

A more sophisticated policy might be:

IF a privileged administrator accesses sensitive resources from outside trusted locations
THEN require strong authentication and a compliant device.

The fundamental structure is:

Assignments + Conditions → Access Controls

2. Conditional Access Policy Components

A Conditional Access policy generally contains several major components:

Users and workload identities
Target resources
Conditions
Grant controls
Session controls
Policy state

Understanding these components is essential for the SC-500 exam.

3. Users and Workload Identities

The first question is:

Who should the policy apply to?

Conditional Access can target users and groups.

For example, a policy could apply to:

All users
Members of a specific group
Administrators
Guest users
External users
Specific directory roles

You can also configure exclusions.

For example:

Include all users except members of the Emergency Access Accounts group.

This is extremely important for preventing administrative lockout.

Example

A company wants MFA for all employees.

The policy could be:

Include: All users
Exclude: Emergency access accounts

Grant: Require multifactor authentication

4. Workload Identities

Conditional Access also has capabilities for workload identities, such as service principals.

This is important because user-targeted Conditional Access policies shouldn’t be assumed to protect service principals.

For example:

A service principal authenticates to Azure programmatically.

A Conditional Access policy scoped only to users doesn’t provide the same control over that service principal.

Organizations can instead use Conditional Access for workload identities where applicable.

This is an important exam distinction:

User Conditional Access ≠ workload identity Conditional Access

5. Target Resources

The next question is:

What is being accessed?

Conditional Access policies can target resources such as:

Cloud applications
Microsoft services
Specific applications
All resources

Microsoft’s terminology has evolved, so you may encounter older material referring to Cloud apps or actions and newer interfaces referring to Target resources or Resources.

For exam purposes, understand the underlying concept:

Target resources identify what the policy is protecting.

Example

A company might create a policy that requires MFA only when users access:

Exchange Online
SharePoint Online
Microsoft Teams
A specific enterprise application

rather than requiring the control for every resource.

6. Conditions

Conditions determine when the policy should apply.

Common Conditional Access conditions include:

User risk
Sign-in risk
Device platforms
Locations
Client applications
Filter for devices
Authentication context
Other supported contextual signals

The important concept is:

Conditions determine whether the policy applies to a particular sign-in.

7. Device Platforms

Conditional Access can evaluate the platform being used.

Examples include:

Windows
macOS
iOS
Android
Linux
Other or unknown platforms

This allows organizations to create policies such as:

Require compliant devices when accessing corporate applications from Windows.

Or:

Block access from unsupported platforms.

However, device-platform detection is based on signals such as the user-agent information and should not necessarily be treated as a complete device-security solution. Microsoft recommends combining platform-based controls with stronger controls such as device compliance or application protection where appropriate.

8. Locations

Conditional Access can make decisions based on network location.

Organizations can define named locations to represent trusted or known network locations.

Examples include:

Corporate offices
Corporate VPN ranges
Approved network ranges
Specific countries or regions

A policy might say:

Require MFA when users sign in from outside corporate locations.

Another might say:

Block access from a specific geographic region.

Important distinction

A trusted location doesn’t automatically mean:

“This user is safe.”

It simply provides a contextual signal that can be incorporated into an access decision.

9. Named Locations

Named locations provide administrators with a reusable way to identify network locations.

For example:

Corporate Headquarters

could represent:

203.0.113.0/24

A policy could then reference Corporate Headquarters instead of repeatedly specifying the IP range.

Named locations can be useful for:

Trusted corporate networks
VPN ranges
Specific countries/regions
Other known network locations

10. Client Applications

Conditional Access can evaluate how the user is accessing a resource.

Examples include:

Browser
Mobile applications
Desktop clients
Legacy authentication clients
Other supported client types

This can be used to create policies such as:

Block legacy authentication.

This is an important security practice because older authentication protocols may not support modern authentication protections.

11. User Risk

User risk represents the likelihood that an identity or account has been compromised.

Microsoft Entra ID Protection provides risk information that Conditional Access can use to make access decisions.

For example:

If the user’s risk is high, require remediation or stronger authentication.

Possible responses can include:

Require additional authentication
Require risk remediation
Block access

Example

A user’s credentials are detected in a way that suggests the account may be compromised.

Conditional Access can detect the elevated user risk and require appropriate remediation before access is allowed.

12. Sign-In Risk

Sign-in risk represents the probability that a particular authentication request isn’t being performed by the legitimate identity owner.

This is different from user risk.

User risk

Is this user’s account likely to be compromised?

Sign-in risk

Is this particular sign-in likely to be suspicious?

This distinction is very important for the exam.

13. User Risk vs. Sign-In Risk

Risk	Focus
User risk	Likelihood that the identity/account is compromised
Sign-in risk	Likelihood that the current authentication request is suspicious

Example

A user might have:

Low user risk

but experience:

High sign-in risk

because the current login originates from an unusual location or demonstrates suspicious characteristics.

Conversely, a user may have elevated user risk even when the current sign-in itself doesn’t appear particularly unusual.

14. Grant Controls

Once Conditional Access determines that a policy applies, it needs to determine:

What should happen?

This is where grant controls are used.

Common grant controls include:

Require multifactor authentication
Require authentication strength
Require device to be marked as compliant
Require Microsoft Entra hybrid joined device
Require approved client app
Require app protection policy
Require password change
Block access

Current Conditional Access supports combining grant controls using either:

Require all selected controls

Require one of the selected controls.

15. Require Multifactor Authentication

One of the most common Conditional Access controls is:

Require multifactor authentication

This requires the user to satisfy Microsoft Entra MFA requirements.

For example:

Condition:

User accesses Microsoft 365 from outside trusted locations.

Grant:

Require multifactor authentication.

Result:

Users accessing Microsoft 365 from outside the trusted location must perform MFA.

16. Authentication Strength

Conditional Access can require a particular authentication strength rather than simply requiring generic MFA.

This allows organizations to establish stronger authentication requirements.

For example, an organization might require:

Phishing-resistant authentication
A particular authentication method
A custom authentication-strength configuration

This is particularly useful for highly sensitive applications and privileged operations.

Exam clue

If the question says:

“Require a specific or stronger authentication method.”

Think:

Authentication strength

rather than simply:

Require MFA

17. Require a Compliant Device

Conditional Access can require the device to be marked as compliant.

This is commonly integrated with Microsoft Intune.

For example:

Users can access corporate applications only from devices that satisfy the organization’s device-compliance policies.

A device might need to satisfy requirements such as:

Encryption
Password requirements
Security software
Operating-system requirements
Other organizational compliance requirements

The important distinction is:

Conditional Access determines whether a compliant device is required; Intune evaluates device compliance.

18. Require Microsoft Entra Hybrid Joined Device

Conditional Access can require users to access resources only from devices that are Microsoft Entra hybrid joined.

This can be useful in organizations operating a hybrid identity environment where corporate Windows devices are joined to both:

On-premises Active Directory
Microsoft Entra ID

This is different from simply requiring an Intune-compliant device.

19. Require an Approved Client App

Conditional Access can require users to access supported resources through an approved client application.

This can help organizations control which applications are permitted to access corporate data.

20. Require App Protection Policy

Conditional Access can require an app protection policy.

App protection policies are associated with Microsoft Intune and can provide application-level protection for organizational data.

This is particularly relevant for mobile scenarios and bring-your-own-device environments.

For example:

A user can access corporate email from a personal mobile device, but the application must satisfy organizational app-protection requirements.

21. Block Access

Block access is the strongest Conditional Access decision.

If the policy applies and the block control is selected, access is denied.

For example:

Block access to corporate resources from unsupported device platforms.

Or:

Block access from a prohibited geographic region.

Block policies must be designed carefully because a misconfigured block policy can prevent legitimate users or administrators from accessing critical resources. Microsoft recommends testing and validating such policies before broad enforcement.

22. Require All vs. Require One

When multiple grant controls are selected, Conditional Access can be configured to require:

Require all selected controls

Every selected requirement must be satisfied.

Example:

Require MFA AND compliant device.

The user must satisfy both.

Require one of the selected controls

Any one of the selected requirements can satisfy the policy.

Example:

Require MFA OR compliant device.

The user needs to satisfy one of them.

Exam tip

Pay close attention to:

AND vs. OR

A question can change the correct answer simply by changing whether all controls or only one control must be satisfied.

23. Session Controls

Grant controls determine what must happen to allow access.

Session controls control what happens after access has been granted.

Examples include:

Sign-in frequency
Persistent browser session
Other supported session-management controls

This distinction is important.

Grant control

“You must perform MFA.”

Session control

“You must authenticate again after a specified period.”

24. Sign-In Frequency

Sign-in frequency can be used to control how often users must authenticate.

For example:

Require users to authenticate again every 8 hours.

This can help reduce the risk associated with long-lived authenticated sessions.

A more sensitive application might use a shorter sign-in frequency than a lower-risk application.

25. Persistent Browser Session

Conditional Access can control whether browser sessions remain persistent.

This can influence whether users remain signed in when they close and reopen their browser.

This is useful when an organization wants to reduce persistent authentication sessions on devices or in environments where persistent sessions aren’t desirable.

26. Policy States

Conditional Access policies have different states.

The most important are:

On
Off
Report-only

On

The policy is enforced.

Off

The policy isn’t evaluated for enforcement.

Report-only

The policy is evaluated for sign-ins, but its access controls aren’t enforced.

Report-only mode is extremely important when deploying new policies because administrators can evaluate the expected impact before enforcement. Results are available through sign-in logs and Conditional Access reporting capabilities.

27. Report-Only Mode

A recommended deployment pattern is:

Create → Report-only → Test → Analyze → Adjust → Enable

Report-only mode allows administrators to see how a policy would affect users without actually enforcing its grant or session controls.

For example:

A new policy requires MFA for all users accessing Microsoft 365.

Before enabling it, the administrator puts the policy into Report-only mode.

The administrator then examines sign-in activity to determine:

Which users would be affected
Which applications would be affected
Which users would be blocked
Which requirements users would need to satisfy
Whether exclusions are appropriate

Only after validating the results should the policy be enabled.

28. Conditional Access Sign-In Logs

The Microsoft Entra sign-in logs are one of the most important troubleshooting tools for Conditional Access.

When investigating a sign-in, administrators can determine:

Which policies applied
Which policies didn’t apply
Whether a policy succeeded
Whether a policy failed
What conditions were evaluated
Which access controls affected the sign-in

This makes sign-in logs particularly valuable when a user reports:

“I can’t access the application.”

29. The Conditional Access What If Tool

The What If tool allows administrators to simulate how Conditional Access policies would evaluate a particular scenario.

Administrators can specify factors such as:

Identity
Target resource
Device platform
Client application
Location
Other conditions

The tool then identifies the policies that would affect the simulated sign-in.

Exam clue

If the question asks:

“You need to determine which Conditional Access policies would apply to a particular user and scenario without performing an actual sign-in.”

Think:

What If

30. Conditional Access Insights and Reporting

Organizations can use Conditional Access reporting capabilities to analyze policy impact.

These capabilities can help answer questions such as:

How many users are affected?
Which policies are blocking access?
Which policies are requiring MFA?
Which policies are being triggered?
What would happen if a report-only policy were enabled?

This is particularly useful when several Conditional Access policies interact.

31. Multiple Conditional Access Policies

Multiple Conditional Access policies can apply to the same sign-in.

For example:

Policy 1

All users accessing Microsoft 365:

Require MFA.

Policy 2

Administrators accessing Microsoft 365:

Require compliant device.

An administrator signing in to Microsoft 365 could be subject to both policies.

Therefore, the effective access decision can depend on the combined effect of multiple policies.

Exam tip

Don’t analyze a Conditional Access policy in isolation when a question describes several policies.

Look for:

Includes
Exclusions
Conditions
Grant controls
Session controls
Other policies affecting the same sign-in

32. Exclusions Are Extremely Important

Exclusions can prevent a Conditional Access policy from applying to specific users, groups, or other supported identities.

A common example is excluding emergency access/break-glass accounts from policies that could otherwise lock out administrators.

Microsoft specifically recommends protecting emergency access accounts from accidental lockout caused by Conditional Access misconfiguration.

Important principle

Don’t blindly exclude large groups of users simply to make a policy easier to deploy.

Exclusions should be:

Deliberate
Documented
Minimal
Reviewed regularly

33. Emergency Access Accounts

Emergency access accounts are particularly important when implementing Conditional Access.

Imagine an organization creates:

All users → Block access from outside the corporate network.

If the policy is incorrectly configured, administrators might also be blocked.

An emergency access account provides a recovery mechanism.

These accounts should be:

Highly protected
Monitored
Used only for emergencies
Excluded appropriately from policies that could cause tenant-wide lockout

34. Conditional Access and Zero Trust

Conditional Access is closely aligned with the Zero Trust principles of:

Verify explicitly

Use least privilege

Assume breach

Conditional Access doesn’t simply trust a user because the user successfully authenticated.

Instead, access can depend on multiple signals.

For example:

Identity + device + location + application + risk + authentication strength

This creates a more contextual access decision.

35. Common Conditional Access Design Patterns

Pattern 1: Require MFA for all users

Users: All users
Resources: All resources
Grant: Require MFA

This establishes a foundational authentication requirement.

Pattern 2: Require MFA outside trusted locations

Users: All users
Resources: Corporate applications
Location: Any location except trusted locations
Grant: Require MFA

This reduces unnecessary MFA prompts from trusted corporate networks while requiring stronger verification from elsewhere.

Pattern 3: Require compliant devices

Users: Employees
Resources: Corporate applications
Grant: Require device to be marked as compliant

This helps ensure that corporate resources are accessed from appropriately managed devices.

Pattern 4: Protect administrators

Users: Privileged administrators
Resources: Sensitive resources
Grant: Require authentication strength and/or compliant device

This creates stronger controls for high-value identities.

Pattern 5: Block legacy authentication

Users: All users
Client app: Legacy authentication clients
Grant: Block access

This prevents older authentication methods from bypassing modern security controls.

Pattern 6: Respond to risky sign-ins

Users: Users affected by risk policy
Condition: Elevated sign-in risk
Grant: Require MFA or block access

This allows security controls to respond dynamically to risk.

36. Conditional Access and Authentication Methods

Conditional Access determines when additional authentication is required.

Authentication policies determine which authentication methods are available.

For example:

Conditional Access: Require authentication strength.

The authentication-strength configuration then determines what authentication methods satisfy that requirement.

This distinction is important.

Conditional Access

When should stronger authentication be required?

Authentication methods/authentication strength

What authentication is strong enough?

37. Conditional Access and Microsoft Intune

Conditional Access and Microsoft Intune frequently work together.

A typical pattern is:

Intune evaluates device compliance → Conditional Access requires a compliant device → Access allowed or denied

For example:

A device is:

Encrypted
Running an approved operating-system version
Protected by required security software
Meeting organizational compliance policies

Intune marks the device compliant.

Conditional Access then allows the user to access the protected resource because the policy requirement has been satisfied.

38. Conditional Access and Microsoft Entra ID Protection

Microsoft Entra ID Protection provides risk signals.

Conditional Access can use these signals to make access decisions.

This creates a relationship:

ID Protection detects risk → Conditional Access responds to risk

For example:

High sign-in risk → Require stronger authentication.

Or:

High user risk → Require remediation.

39. Conditional Access for AI and Agents

As AI workloads increasingly use identities and agents, Conditional Access can also participate in securing AI-related access scenarios.

The SC-500 material you provided specifically includes AI security topics involving:

Microsoft Entra Agent Identity
Microsoft Defender XDR
Copilot Studio
Microsoft Foundry
Microsoft Defender for Cloud
Microsoft Purview

Conditional Access should therefore be understood as part of a larger identity-centric security architecture rather than as a control that applies only to traditional human users.

40. Common Implementation Mistakes

Mistake 1: Enabling a broad policy immediately

A policy that applies to all users and all resources can have a massive impact.

Better: Use report-only mode and test first.

Mistake 2: Forgetting exclusions

A policy might unintentionally affect emergency access accounts or other critical identities.

Better: Carefully evaluate exclusions.

Mistake 3: Using block access too broadly

A block policy can cause widespread outages.

Better: Test thoroughly before enforcement.

Mistake 4: Confusing user risk and sign-in risk

These represent different security signals.

Remember:

User risk = account compromise

Sign-in risk = suspicious authentication event

Mistake 5: Assuming MFA and authentication strength are identical

Authentication strength can impose more specific authentication requirements than a generic MFA requirement.

Mistake 6: Assuming report-only means nothing is evaluated

Report-only policies are evaluated during sign-in; they simply don’t enforce their grant or session controls. Results can be reviewed in sign-in logs and reporting tools.

Mistake 7: Ignoring workload identities

A policy scoped to users isn’t automatically a policy protecting service principals.

Use workload-identity Conditional Access where appropriate.

41. Conditional Access Deployment Strategy

A good deployment strategy is:

Step 1 — Identify the security objective

Example:

Require MFA for privileged administrators.

Step 2 — Identify the users

Example:

Members of the Security Administrators group.

Step 3 — Identify the resources

Example:

Sensitive administrative applications.

Step 4 — Identify the conditions

Example:

Any location.

Step 5 — Define the grant control

Example:

Require authentication strength.

Step 6 — Define exclusions

Example:

Emergency access accounts.

Step 7 — Deploy in report-only mode

Observe the expected impact.

Step 8 — Test

Test:

Included users
Excluded users
Different devices
Different locations
Different applications
Different authentication methods

Step 9 — Review logs

Use sign-in logs and Conditional Access reporting.

Step 10 — Enable the policy

Only after validating the expected behavior.

Microsoft currently recommends using report-only mode and reviewing policy impact before enforcement.

42. SC-500 Conditional Access Quick Reference

Concept	Key point
Conditional Access	Context-based access control
Users/groups	Defines who the policy applies to
Workload identities	Controls supported non-user identities such as service principals
Target resources	Defines what the policy protects
Conditions	Determine when the policy applies
Locations	Uses network/location context
Device platforms	Evaluates device platform
User risk	Likelihood that the account is compromised
Sign-in risk	Likelihood that the current sign-in is suspicious
Grant controls	Determine what is required to gain access
MFA	Requires multifactor authentication
Authentication strength	Requires a particular authentication strength
Compliant device	Requires Intune-compliant device
Hybrid joined device	Requires Microsoft Entra hybrid joined device
Approved client app	Requires an approved application
App protection policy	Requires an applicable Intune app-protection policy
Block access	Denies access
Session controls	Control aspects of an authenticated session
Sign-in frequency	Controls how often authentication is required
Report-only	Evaluates without enforcing grant/session controls
What If	Simulates which policies would apply
Sign-in logs	Shows policy evaluation for actual sign-ins
Emergency access accounts	Help prevent administrative lockout
Zero Trust	Conditional Access supports explicit verification and least privilege

Practice Exam Questions

Question 1

An organization wants to require MFA whenever employees access Microsoft 365 from outside the company’s trusted corporate networks.

Which Conditional Access configuration should you use?

A. Include all users, exclude trusted locations, and require MFA

B. Include trusted locations and block access

C. Include all users and require a compliant device

D. Include all users and require an approved client application

Answer: A

Explanation: The policy should target the users and apply when the sign-in originates from locations other than the organization’s trusted locations. The appropriate grant control is Require multifactor authentication.

Question 2

A security administrator wants to determine which Conditional Access policies would apply if a specific user attempted to access an application from an Android device without actually performing the sign-in.

Which tool should the administrator use?

A. Microsoft Entra audit logs

B. Conditional Access What If

C. Microsoft Defender for Cloud

D. Access reviews

Answer: B

Explanation: The Conditional Access What If tool allows administrators to simulate a sign-in scenario and determine which enabled or report-only Conditional Access policies would apply.

Question 3

An organization wants to deploy a new Conditional Access policy requiring compliant devices. Administrators want to evaluate the policy’s effect without preventing users from accessing applications.

What should they do first?

A. Enable the policy

B. Configure the policy as a block policy

C. Configure the policy in report-only mode

D. Disable all existing Conditional Access policies

Answer: C

Explanation: Report-only mode evaluates the policy without enforcing its grant or session controls. Administrators can review the results in sign-in logs and Conditional Access reporting before enabling the policy.

Question 4

A company wants administrators accessing sensitive applications to use phishing-resistant authentication rather than simply satisfying a generic MFA requirement.

Which Conditional Access control is most appropriate?

A. Require an approved client app

B. Require authentication strength

C. Require a compliant device

D. Require password change

Answer: B

Explanation: Authentication strength allows an organization to specify the strength and type of authentication required. This is more precise than simply requiring generic MFA.

Question 5

An organization wants to block users from accessing corporate applications from unknown or unsupported device platforms.

Which Conditional Access configuration should be used?

A. Require MFA

B. Require an authentication strength

C. Require a compliant device

D. Block access based on the device platform condition

Answer: D

Explanation: The policy should use the Device platforms condition to identify the relevant platforms and use Block access as the grant control. Device-platform policies should be designed carefully because platform identification alone isn’t a complete device-security control.

Question 6

A Conditional Access policy applies to all users and requires MFA. The organization’s emergency access account is also subject to the policy. A configuration error causes all administrators to be unable to satisfy the policy.

What is the primary concern?

A. The emergency account could be locked out along with other administrators

B. The policy will automatically disable MFA

C. The emergency account will become a service principal

D. Conditional Access will automatically remove the policy

Answer: A

Explanation: Emergency or break-glass accounts should be appropriately excluded from policies that could cause administrative lockout. They provide a recovery mechanism if Conditional Access is misconfigured.

Question 7

An administrator wants to require both MFA and a compliant device before users can access a sensitive application.

How should the Conditional Access grant controls be configured?

A. Require one of the selected controls

B. Require only MFA

C. Require all the selected controls

D. Use session controls instead of grant controls

Answer: C

Explanation: Because users must satisfy both requirements, the policy should use Require all the selected controls. Conditional Access supports both “require all” and “require one” behavior when multiple grant controls are configured.

Question 8

A user has a low user-risk level but the current authentication request has been identified as highly suspicious.

Which Conditional Access condition should be used to respond specifically to the current authentication event?

A. User risk

B. Sign-in risk

C. Device platform

D. Named location

Answer: B

Explanation: Sign-in risk evaluates the likelihood that a particular authentication request isn’t being performed by the legitimate identity owner. User risk, by contrast, concerns the likelihood that the user’s account or identity is compromised.

Question 9

A user reports that access to an application was denied. The security administrator needs to determine which Conditional Access policy caused the denial and why the policy applied.

Where should the administrator investigate first?

A. Microsoft Entra sign-in logs

B. Azure Cost Management

C. Azure Resource Graph

D. Microsoft Entra access reviews

Answer: A

Explanation: Microsoft Entra sign-in logs provide detailed information about Conditional Access policy evaluation for individual sign-in events, including policies that applied, succeeded, failed, or weren’t applied.

Question 10

An organization has a Conditional Access policy that applies to all users accessing a sensitive application. The policy requires MFA. The organization also has a second policy that applies only to administrators and requires a compliant device.

An administrator attempts to access the application.

What should the administrator expect?

A. Only the first policy can apply because Conditional Access policies cannot overlap

B. Only the more restrictive policy applies

C. The administrator is automatically excluded from the first policy

D. Multiple applicable Conditional Access policies can affect the sign-in

Answer: D

Explanation: Multiple Conditional Access policies can apply to the same sign-in. The administrator can therefore be subject to both the MFA requirement from the first policy and the compliant-device requirement from the second policy. This is why policy interactions must be evaluated together during deployment and troubleshooting.

Final Exam Takeaways

For the SC-500 exam, remember Conditional Access as a context-driven access decision engine:

Who + What + Conditions → Grant/Block + Session Controls

The distinctions most worth memorizing are:

User risk ≠ sign-in risk
Grant controls ≠ session controls
MFA ≠ authentication strength
User policies ≠ workload-identity policies
Report-only evaluates but doesn’t enforce
What If simulates policy applicability
Sign-in logs show what happened during an actual sign-in
Require all ≠ require one
Compliant device ≠ hybrid joined device
Block access is powerful and must be tested carefully
Emergency access accounts should be protected from accidental lockout
Multiple Conditional Access policies can affect the same sign-in
Conditional Access works particularly well alongside Microsoft Entra ID Protection and Intune