The hard set (5 questions)
The hardest SC-300 questions this guide publishes, none of them repeated from the placement quiz above: the answer first, why every other option is wrong, and the Microsoft Learn page behind it. The practice book for this exam holds the full bank.
A Conditional Access policy requires a custom authentication strength that includes ONLY Windows Hello for Business. On a shared Windows device, a user signed in to Windows with a password (not Windows Hello) as their primary method, then opens an application protected by this policy. What is the expected behavior?
Correct answer: D. The user is not prompted for Windows Hello for Business; they must restart the session, select Sign-in options, and choose Windows Hello for Business.
This is a documented Windows Hello for Business behavior for authentication strengths: if the user signed in with a different primary method (such as a password), Microsoft Entra ID does not prompt them to switch to Windows Hello for Business. The user must restart the session, choose Sign-in options, and select a method that the authentication strength requires.
Why the other options are wrong:
- A. Conditional Access does not fail open here; access is not granted until the required method is used.
- B. There is no silent step-up to Windows Hello for Business in this scenario; that is the common misconception.
- C. A password does not satisfy a strength that requires Windows Hello for Business.
Memory hook: WHfB not your primary? No prompt - restart and pick it from Sign-in options.
Microsoft Learn: Concept authentication strengths
An administrator builds one Conditional Access policy: 'If a user in the Finance group accesses the Payroll app, require MFA and a compliant device.' During a review, they discover that users who are NOT in Finance are still able to obtain access tokens for the Payroll app. The Finance policy is enabled and working. Why are non-Finance users getting in, and what is the correct fix?
Correct answer: B. Access tokens are issued by default when no Conditional Access policy triggers a control; a grant-only policy scoped to Finance does not restrict anyone else, so a complementary Block policy for non-Finance users (or app-level authorization) is required
Conditional Access is not restrictive by default: access tokens are issued whenever no policy condition triggers an access control. A policy that grants access with conditions to a specific subset (Finance accessing Payroll) only governs that subset; it says nothing about everyone else, so non-Finance users fall through and receive tokens. That coverage gap is the trap this question sets. The fix is a complementary policy that blocks non-Finance users from Payroll (Microsoft's own example pairs a Finance grant policy with a 'not-Finance, block' policy), or enforcing authorization at the application layer. The Conditional Access gap analyzer workbook helps surface apps and users with no policy coverage.
Why the other options are wrong:
- A. Grant policies do not implicitly deny users outside their assignment. A policy scoped to Finance simply does not evaluate for non-Finance users, so it neither grants nor blocks them; they are covered by no policy and get a token by default.
- C. The scenario states the Finance policy is enabled and working (Finance users are correctly challenged). The non-Finance access is a coverage gap, not a report-only artifact.
- D. There is no implicit deny-all in Conditional Access. Default behavior is that a token is issued unless a matching policy blocks or adds a required control, so the cause is a missing block policy, not a disabled one.
Memory hook: Conditional Access is allow-by-default. A grant policy for a subset protects no one else. To keep others out of a resource, add a Block policy.
Microsoft Learn: Plan conditional access
A company is deploying Microsoft Entra Password Protection for its on-premises Active Directory environment. The security team wants to ensure that domain controllers never communicate directly with the internet as part of this deployment. Which component fulfills this network isolation requirement?
Correct answer: C. The Microsoft Entra Password Protection Proxy service, which acts as an intermediary between DC Agents and Microsoft Entra ID.
On-premises Microsoft Entra Password Protection is designed so that domain controllers never communicate directly with the internet. The DC Agent service requests password policies from the Microsoft Entra Password Protection Proxy service using RPC over TCP within the local network. The Proxy service then communicates with Microsoft Entra ID on the internet and returns the policy to the DC Agent. The DC Agent never listens on a network-accessible port and the Proxy service is stateless.
Why the other options are wrong:
- A. Microsoft Entra Connect Health monitors sync health and is unrelated to password policy distribution for Password Protection.
- B. Password Hash Synchronization is a separate feature that Password Protection does not require. It plays no role in distributing password policy.
- D. The DC Agent intentionally never communicates directly with the internet. Direct internet connectivity from DCs is a core anti-pattern this architecture was designed to prevent.
Memory hook: DC Agent talks to Proxy. Proxy talks to the cloud. DCs stay off the internet - the Proxy is the internet-facing middleman.
Microsoft Learn: Concept password ban bad on premises
An organization has Conditional Access policies that enforce location-based controls using named IP locations. A user is authenticated from an allowed IP range. Their access token is valid. The user then moves to a different physical location, and their outbound IP changes to one outside the trusted range. Using Continuous Access Evaluation with IP-based location policies, which type of named location condition is enforced in near real time when the IP changes?
Correct answer: D. IPv4 and IPv6 address range-based named locations.
CAE only has insight into IP-based named locations defined by IPv4 and IPv6 address ranges. When a user moves outside these ranges and the resource provider detects the IP change, CAE can enforce the location policy near-real-time by issuing a claim challenge. CAE does not have insight into country/region-based locations or the MFA trusted IPs feature in the legacy MFA service settings page. If only country/region or MFA trusted IP locations are used, CAE issues a standard one-hour token without real-time IP enforcement.
Why the other options are wrong:
- A. Not all named location types are treated equally by CAE. Only IP address range-based named locations are eligible for real-time CAE enforcement.
- B. Country/region-based named locations are not supported by CAE. When these location conditions are used, CAE cannot enforce real-time location changes; a standard one-hour access token is issued instead.
- C. MFA Trusted IPs configured in the legacy MFA service settings are not supported by CAE. Using them means CAE does not enforce the location change in real time.
Memory hook: CAE location enforcement = IP ranges ONLY. Country/region and MFA Trusted IPs are invisible to CAE's real-time checks.
Microsoft Learn: Concept continuous access evaluation
Your organization uses Conditional Access with a named location policy that blocks access from outside trusted IP ranges. A user working from a coffee shop loses access to Exchange Online immediately after moving locations, even though their access token has not expired. Which feature is responsible for this near-real-time enforcement?
Correct answer: C. Continuous access evaluation (CAE) Conditional Access policy evaluation
Continuous access evaluation enables resource providers such as Exchange Online to synchronize key Conditional Access policies and evaluate them in near real time. When a user moves outside a trusted IP range, the resource provider detects the location change and issues a 401 claim challenge, forcing the client to request a new token from Microsoft Entra. This results in immediate or near-immediate loss of access rather than waiting for the one-hour default token lifetime to expire. CAE-enabled sessions also use long-lived tokens of up to 28 hours, with security enforced through real-time event evaluation rather than short token lifetimes.
Why the other options are wrong:
- A. Sign-in frequency controls how often users must reauthenticate, but it operates on the configured interval (e.g., one hour) and does not provide immediate enforcement when location conditions change.
- B. Microsoft Entra Password Protection blocks weak passwords during password change events. It has no role in session revocation or location-based access enforcement.
- D. ID Protection sign-in risk policy detects anomalous sign-in behaviors and can require MFA or block access. It does not enforce location-based Conditional Access policy changes in real time after a user's session is already established.
Memory hook: CAE = continuous security conversation between Entra and the app. No expired token needed to kick you out.
Microsoft Learn: Concept continuous access evaluation
