The hard set (5 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.
A threat hunter wants to write a Microsoft Defender XDR Advanced Hunting query to find all devices where a file from a known malicious sender (MaliciousSender@example.com) was delivered as an email attachment and is now present on the device. Which table join correctly maps email attachment file hashes to device file events?
Correct answer: B. Join EmailAttachmentInfo (filtered by SenderFromAddress) to DeviceFileEvents on SHA256 to find devices where the attachment exists.
The canonical Microsoft hunting scenario for 'check if files from a known malicious sender are on your devices' filters EmailAttachmentInfo by SenderFromAddress, then joins to DeviceFileEvents on SHA256. The hash is what makes the correlation trustworthy: file names get renamed, but the SHA256 stays consistent from email attachment to file on disk.
Why the other options are wrong:
- A. AlertEvidence contains alert-related artifacts (files, IPs, etc. associated with triggered alerts), not comprehensive file delivery data from email. Joining on FileName is unreliable due to file renaming and is not the documented approach.
- C. EmailPostDeliveryEvents tracks post-delivery security actions (like ZAP) and DeviceLogonEvents tracks device sign-ins. This join would identify users who logged on after receiving emails, not devices where the attachment file is present.
- D. EmailEvents does not contain file hashes for attachments. Joining on NetworkMessageId to DeviceFileEvents would not work because DeviceFileEvents does not have a NetworkMessageId column. File hash correlation requires EmailAttachmentInfo.
Memory hook: Malicious attachment on device = EmailAttachmentInfo (filter sender) JOIN DeviceFileEvents ON SHA256. Hash is the reliable link between email and endpoint.
Microsoft Learn: Advanced hunting query emails devices
During a Microsoft Sentinel hunt, an analyst bookmarks several interesting query result rows, carefully adding names, notes, and MITRE ATT&CK technique mappings, but skips the entity mapping section to save time. Later, the analyst selects a bookmark and chooses Investigate to visualize the finding. What happens, and what is required to fix it?
Correct answer: B. The bookmark cannot be usefully investigated in the graph; every bookmark you investigate must have at least one mapped entity, so the analyst must edit the bookmark and map an entity first
The investigation graph will not usefully render a bookmark without entities: each bookmark you want to investigate must have at least one mapped entity, and if it does not, you must edit the bookmark to add one before you begin. Entity mapping happens in the Add bookmark pane by mapping entity types and identifiers to columns in the query results, with account, host, IP, and URL types supported. Skipping the step at creation time is the classic time-waster because the fix is a manual edit of every affected bookmark afterward. Map entities when you create the bookmark, not after.
Why the other options are wrong:
- A. Entities are not auto-extracted from arbitrary bookmarked rows. The analyst must explicitly map entity types and identifiers to result columns in the Entity mapping section of the bookmark pane.
- C. Investigate opens the investigation graph directly; it does not create an incident. Escalating a bookmark to an incident is a separate, deliberate action: Incident actions, then Create new incident or Add to existing incident.
- D. MITRE tactic and technique mappings classify the finding for coverage and correlation purposes; they do not create graph nodes. The investigation graph is built on mapped entities, and no technique mapping can substitute for them.
Memory hook: No mapped entity, no investigation graph. Map at least one entity at bookmark creation, not after.
Microsoft Learn: Bookmarks
An analyst investigating a potential business email compromise (BEC) attack needs to find all logon events made by email recipients within 30 minutes after they received emails that were identified as malware and where Zero-hour Auto Purge (ZAP) failed. Which pair of Advanced Hunting tables provides the data needed to correlate these events in a single KQL query?
Correct answer: B. EmailPostDeliveryEvents and IdentityLogonEvents
EmailPostDeliveryEvents captures security events that occur after email delivery, including ZAP actions and their results (ActionType contains 'ZAP' and ActionResult can be 'Error' for failures). IdentityLogonEvents captures authentication events on Active Directory and Microsoft online services, enabling correlation with RecipientEmailAddress matching AccountUpn. This is the canonical table pair for ZAP-failure + subsequent logon correlation shown in Microsoft's own hunting scenario examples.
Why the other options are wrong:
- A. EmailEvents captures email delivery and blocking events at delivery time but does not contain post-delivery ZAP action results. DeviceLogonEvents captures device sign-ins from endpoints, not cloud identity logon events.
- C. AlertInfo contains alert metadata not raw ZAP events. IdentityQueryEvents captures Active Directory object queries (e.g., LDAP queries), not user logon events.
- D. EmailAttachmentInfo contains file attachment metadata. DeviceProcessEvents captures process creation. Neither table provides ZAP failure events or post-delivery identity logon correlation.
Memory hook: ZAP fail + logon after = EmailPostDeliveryEvents (for ZAP result) + IdentityLogonEvents (for who logged in). Post-delivery = the key word.
Microsoft Learn: Advanced hunting query emails devices
You want to hunt for hosts whose outbound connection counts spike abnormally versus their own seasonal baseline over the past 14 days, using KQL's built-in time-series anomaly detection. Which approach produces input in the correct shape for series_decompose_anomalies()?
Correct answer: D. make-series Count=count() default=0 on TimeGenerated from ago(14d) to now() step 1h by DeviceName, then pipe to series_decompose_anomalies(Count)
series_decompose_anomalies() operates on a dynamic numeric array (a series). make-series produces exactly that: one evenly-spaced, gap-filled (default=0) numeric array per DeviceName over the time axis, which is the required input. The function decomposes each series into seasonal/trend/residual components and scores outliers on the residual.
Why the other options are wrong:
- A. autocluster() finds common attribute-value patterns; it is not time-series decomposition and does not score seasonal anomalies.
- B. summarize ... by bin() returns individual scalar rows, not a dynamic array; it also leaves time gaps, so the decomposition function cannot consume it directly.
- C. make-list(TimeGenerated) builds an array of timestamps, not the per-bin numeric metric the decomposition needs.
Memory hook: Anomaly hunt = make-series (evenly-spaced array) then series_decompose_anomalies; bin() gives rows, not a series.
Microsoft Learn: Anomaly detection
An analyst is writing an Advanced Hunting query in Microsoft Defender XDR to find all devices where a potentially compromised user account (username: 'jsmith') has logged on, and then list all active alerts triggered on those devices. Which table should be the starting point, and what join strategy correctly avoids duplicating device records?
Correct answer: B. Start from DeviceInfo filtered for LoggedOnUsers containing 'jsmith', get distinct DeviceIds, then join kind=inner to AlertEvidence on DeviceId, project AlertId, then join AlertInfo on AlertId.
The documented Microsoft example for this exact scenario starts with DeviceInfo filtered for LoggedOnUsers containing the account name, then takes distinct DeviceIds to avoid duplication, then performs a kind=inner join to AlertEvidence on DeviceId (inner join prevents deduplication of left-side DeviceId values that could cause fan-out), projects AlertId, and then joins AlertInfo to retrieve alert details. This is the canonical multi-table hunting pattern shown in the Microsoft Advanced Hunting documentation.
Why the other options are wrong:
- A. IdentityLogonEvents captures authentication events but does not contain the DeviceId column directly in a way that maps to AlertEvidence. The documented pattern uses DeviceInfo (which tracks LoggedOnUsers) as the starting point for device-centric correlation.
- C. DeviceLogonEvents captures device-level sign-in events. A fullouter join to AlertInfo would produce a cross-product of unmatched rows and would not correctly constrain alerts to the specific compromised user's devices.
- D. Starting from AlertInfo and joining to DeviceInfo would not efficiently filter to the specific compromised user's devices first. A left outer join would also include devices with no matching alerts, which is the opposite of what is needed. This approach is less efficient and not the documented pattern.
Memory hook: Compromised user hunting: DeviceInfo (LoggedOnUsers filter), then distinct DeviceId, then inner join AlertEvidence, then AlertInfo. Inner join = no DeviceId fan-out duplication.
Microsoft Learn: Advanced hunting query emails devices
