The hard set (7 questions)
The hardest SC-200 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.
Legitimate mail from a business partner is landing in quarantine. The partner sends through a third-party service, so the Authentication-Results header shows spf=pass and dkim=pass for the service's own domain, but dmarc=fail (no alignment with the From-header domain) and compauth=fail. Spoof intelligence is flagging the sender as spoofed. What is the recommended remediation to reliably allow the partner's mail?
Correct answer: D. Create a spoof allow entry for the partner in the Tenant Allow/Block List (Spoofed senders).
The targeted fix for a spoof-intelligence false positive is a spoof allow entry for the spoofed-user/sending-infrastructure domain pair on the Spoofed senders tab of the Tenant Allow/Block List (New-TenantAllowBlockListSpoofItems). The trap is the passing SPF and DKIM: they authenticate the third-party service's own domain, not the partner's From-header domain, so DMARC fails on alignment, composite authentication fails (compauth=fail), and spoof intelligence flags the mail as spoofed. Spoofed-sender allow entries account for intra-org, cross-org, and DMARC spoofing, and they never expire.
Why the other options are wrong:
- A. Turning off spoof intelligence for the whole organization removes anti-spoofing protection for every sender - far too broad and never the recommended, targeted remediation.
- B. The Allowed senders list in the anti-spam policy is explicitly discouraged (high spoofing risk) and does not bypass high confidence phishing; it is not the recommended fix for a spoof-intelligence false positive.
- C. A mail flow rule that sets SCL -1 bypasses spam filtering only; it does not reliably override spoof/high-confidence-phishing verdicts and is a broad, risky override.
Memory hook: Spoof false positive (compauth=fail)? The fix lives on the Spoofed senders tab of the Tenant Allow/Block List, never the anti-spam Allowed senders list.
Microsoft Learn: Tenant allow block list email spoof configure
The group 'Contoso Executives' is included in both the Strict preset security policy and a custom anti-spam policy that you set to priority 0 (the highest custom priority). A bulk email arrives for a member of that group. Which policy's anti-spam settings are actually applied?
Correct answer: B. The Strict preset security policy
Preset security policies always take precedence over custom and default policies. The order of precedence is Strict preset, then Standard preset, then custom policies (by priority), then the Built-in protection preset and default policies. So the Strict preset settings win regardless of the custom policy's priority value.
Why the other options are wrong:
- A. Policy settings are never merged - only the first applicable policy of that type applies to the recipient.
- C. The default policy has the lowest precedence and is not a fallback used to resolve conflicts.
- D. Priority ordering only breaks ties among custom policies; presets are always evaluated before all custom policies.
Memory hook: Strict beats Standard beats custom beats default - presets always jump the line.
Microsoft Learn: Preset security policies
A threat hunting team uses case management in the Microsoft Defender portal to track a long-running phishing campaign that has generated roughly 250 related incidents. The team wants to link every incident to a single case so the whole campaign has one durable record. Which documented service limit forces a different design?
Correct answer: A. Each case supports a maximum of 100 linked incidents, so the campaign's 250 incidents must be split across multiple cases.
The Microsoft Sentinel service limits page documents the case management limits: 100,000 cases per tenant, 500 GB of attachments per tenant, and 100 linked incidents per case. Linking 250 incidents to one case exceeds the per-case incident cap, so the team must split the campaign across multiple cases (for example, by wave or by month) and use the case descriptions, tasks, or naming conventions to tie them together. Cases themselves are durable: they do not expire or auto-delete, and case IDs (starting at 1000) are never recycled, which is why archival is handled with custom statuses and filters rather than deletion.
Why the other options are wrong:
- B. Cases do not auto-close or auto-purge. They persist until manually deleted (which requires typing 'delete' in a confirmation dialog); archival is managed with statuses and filters.
- C. The tenant limit is 100,000 cases, not 1,000, and case IDs are never reused, so there is no ID recycling.
- D. There is no status-based restriction on linking. The constraint on this scenario is the documented cap of 100 linked incidents per case.
Memory hook: Case limits: 100 incidents per case, 100,000 cases per tenant, 500 GB of attachments. The '100 per case' is the one that bites campaign tracking.
Microsoft Learn: Sentinel service limits
While investigating in the incident graph, an analyst switches the associated-incidents view from This incident only to All associated incidents. What is the effect of this change?
Correct answer: A. It expands the graph to show related incidents and alerts for context only; it does not change grouping, correlation rules, merge logic, or the other incidents' separate ownership and lifecycle.
The All associated incidents view helps analysts see additional related incidents and alerts in the investigation graph for added context. It does not change incident grouping, correlation rules, or merge logic, and the associated incidents keep their own owner, status, and lifecycle until an actual merge occurs.
Why the other options are wrong:
- B. It does not reassign alerts; associated incidents retain their own ownership.
- C. It does not alter correlation rules or how future alerts are grouped.
- D. The view is contextual only; it does not perform a merge.
Memory hook: 'All associated incidents' = look wider, change nothing (no merge, no reassignment).
Microsoft Learn: Alerts incidents correlation
You want Microsoft Defender for Identity to disable a compromised on-premises Active Directory account and reset its password from the Microsoft Defender portal. All of your sensors are v2.x running on domain controllers. Which account performs these remediation actions, and how does it differ from the Directory Service Account (DSA)?
Correct answer: D. A dedicated action account (a gMSA you scope with the needed permissions) performs remediation, while the DSA is used only to read Active Directory data; by default the v2.x sensor uses the domain controller's LocalSystem account for actions.
Remediation actions such as disabling a user or resetting a password are performed by the action account. By default the v2.x sensor impersonates the domain controller's LocalSystem account; if you want scoped permissions you configure a dedicated gMSA as the action account. This is separate from the DSA, which only reads AD data.
Why the other options are wrong:
- A. The DSA only reads AD data; remediation is handled by the action account (LocalSystem by default, or a scoped gMSA), not the DSA.
- B. v2.x sensors on domain controllers already support action accounts; v3.x actually drops gMSA action accounts and always uses LocalSystem.
- C. A gMSA is the recommended scoped option for the action account; you do not have to use a stored regular user account.
Memory hook: DSA reads; the action account acts (LocalSystem by default, gMSA if you scope it).
Microsoft Learn: Manage action accounts
Executive and support staff need Microsoft's most aggressive email protection, with the admin releasing any blocked messages the users request. A custom anti-spam policy already targets some of these same users. The team assigns the Strict preset security policy to the executives. For those users, how are the anti-spam settings resolved, and how does Built-in protection relate?
Correct answer: A. The Strict preset security policy's settings are applied to those users before the custom anti-spam policy or the default policy; Built-in protection provides only Safe Links and Safe Attachments to recipients not covered by Standard/Strict or custom policies
Preset security policies sit at the top of the threat-policy order of precedence: Strict is applied first, then Standard, then Defender for Office 365 evaluation policies, then custom threat policies by priority, and finally the Built-in protection preset (Safe Links/Safe Attachments) and the default policies. So for a user in the Strict preset, the Strict anti-spam settings are applied instead of the custom or default anti-spam policy; no merging occurs. Built-in protection is assigned to all recipients by default but only provides Safe Links and Safe Attachments, and it is the lowest-precedence preset, so it never overrides Strict. Strict is the right choice because it quarantines more aggressively and is designed for high-value targets whose admins review and release messages.
Why the other options are wrong:
- B. Built-in protection is assigned to all recipients by default, but it only supplies Safe Links and Safe Attachments and is the lowest-precedence preset. It does not override the Strict preset's settings.
- C. Custom policy priority determines ordering only among custom policies. Preset security policies (Strict, then Standard) are always applied before any custom or default threat policy, so a custom anti-spam policy cannot outrank the Strict preset even at priority 0.
- D. Threat policies are not merged per setting. The first applicable policy in the precedence order wins for a given recipient, and preset policies are evaluated before custom and default policies.
Memory hook: Order: Strict then Standard then eval then custom (by priority) then Built-in protection and defaults. Presets always beat custom; Built-in protection is just Safe Links/Attachments at the bottom.
Microsoft Learn: Preset security policies
Your organization wants to protect 420 named executives and VIPs from user (sender) impersonation using a single anti-phishing policy in Microsoft Defender for Office 365. When you try to add all of them to user impersonation protection, you cannot. What is the limitation and the correct remedy?
Correct answer: B. A single anti-phishing policy supports a maximum of 350 users for user impersonation protection; split the users across additional anti-phishing policies.
Each anti-phishing policy in Defender for Office 365 supports a maximum of 350 users for user impersonation protection. To protect more than 350 named users, distribute them across multiple anti-phishing policies (accounting for the order of precedence between those policies).
Why the other options are wrong:
- A. The 50 limit applies to custom domains for domain impersonation, not user impersonation, and user impersonation is not unlimited.
- C. 60 is not the limit, and mailbox intelligence is a separate detection mechanism, not a workaround for the protected-user cap.
- D. 1,024 is the limit for trusted sender/domain exceptions, which is unrelated to the number of protected impersonation users.
Memory hook: 350 protected users per policy - a VIP list overflow needs a second anti-phishing policy.
Microsoft Learn: Anti phishing policies mdo configure
