9 real SC-200 sample questions, each with a worked explanation and a rationale for every option, right and wrong. No account, no card. This is the reasoning the SC-200 tests: knowing why the tempting answer is wrong, not just spotting the right one.
The real SC-200 is Typically 40 to 60 questions questions in 100 minutes, pass mark 700 / 1000. For a domain-by-domain breakdown and a study plan, read the SC-200 study guide. The full bank has 284 questions.
lock_openFree sampleManage a Security Operations Environmentmedium
Threat intelligence has supplied a list of malicious URLs and IP addresses that you import as custom indicators in Microsoft Defender for Endpoint. The security team requires that every onboarded Windows device is stopped from reaching those destinations regardless of which browser or application initiates the connection. After importing the indicators, traffic to the listed destinations is still allowed. Which TWO advanced features in Microsoft Defender for Endpoint must be turned on together so the imported URL and IP indicators are actually enforced across any process? Select TWO.
- ATurn on network protection in block mode, because it is the component that inspects outbound connections from any process and is what enforces the custom URL and IP indicators at the network layer on the device.check_circle Correct
- BTurn on custom network indicators, because this advanced feature is the switch that allows the imported URL and IP indicators to be applied by Microsoft Defender for Endpoint and used for enforcement on the onboarded devices.check_circle Correct
- CTurn on web content filtering, because it categorises and reports the websites that users visit and is the feature responsible for blocking the specific destinations carried in the imported custom indicator list.
- DTurn on tamper protection, because it secures the security settings on the device and is the control that activates the imported custom indicators so they cannot be bypassed by a malicious process on the endpoint.
Custom URL and IP indicators in Microsoft Defender for Endpoint enforce only when both custom network indicators and network protection in block mode are enabled. Imported URL and IP indicators are applied at the device only when the custom network indicators advanced feature is enabled, and the actual blocking is performed by network protection. Network protection inspects outbound connections from any process, not just supported browsers, so it must be in block mode for the listed destinations to be stopped. With either feature off the indicators are stored but unenforced, which is why the traffic was still allowed.
Why A is correct: Network protection is the enforcement layer that evaluates outbound connections from any process against the indicator list, and in block mode it actively stops connections to the listed URLs and IP addresses rather than only auditing them.
Why B is correct: Custom network indicators is the advanced feature that permits the imported URL and IP entries to be honoured by the endpoints, and without it the indicators are stored but never applied so no destination is blocked.
Why C is wrong: Web content filtering blocks whole site categories and reports browsing, which sounds related, but it does not enforce individual imported URL or IP indicators and only governs supported browser traffic rather than every process.
Why D is wrong: Tamper protection stops malware altering Microsoft Defender settings, which is useful hardening, but it plays no part in evaluating or enforcing custom network indicators and leaves the listed destinations reachable.
lock_openFree sampleManage a Security Operations Environmentmedium
Your organisation wants to enable the attack surface reduction rule that blocks executable content from email clients and webmail across all onboarded Windows devices. Security operations is concerned that a small number of line-of-business workflows might rely on this behaviour, and they must measure the real-world impact for two weeks before any block takes effect, while still generating telemetry the team can hunt over. How should the rule be configured for this initial rollout?
- ASet the rule to Block, then add per-application exclusions for any line-of-business tool that breaks, so the rule enforces immediately while the discovered exceptions keep the workflows running during the trial.
- BSet the rule to Warn, which prompts the user with a dismissible message each time the rule triggers, so end users decide whether to proceed while the team reviews how often the prompt is dismissed.
- CSet the rule to Audit, which lets the offending action proceed but records a DeviceEvents entry each time the rule would have triggered, so the team can measure impact for two weeks before switching it to Block.check_circle Correct
- DSet the rule to Not configured, then rely on Microsoft Defender for Endpoint device discovery to passively report which devices use email-borne executables, so impact is gauged without enabling the rule at all.
Use ASR rule Audit mode to log would-be blocks to DeviceEvents and measure impact before promoting a rule to Block enforcement. An attack surface reduction rule set to Audit still evaluates the rule logic but allows the action to complete, writing an event to the DeviceEvents table each time the rule would have blocked. This produces measurable, huntable telemetry across the fleet during a pilot, so the team can size the line-of-business impact and build exclusions before switching the same rule to Block.
Why A is wrong: Block enforces straight away, which is exactly what the requirement forbids during the measurement window, and chasing breakages with exclusions reacts after disruption has already occurred rather than measuring impact safely first.
Why B is wrong: Warn does surface the rule and can be bypassed by the user, but it already disrupts the workflow with a prompt and is not the non-intrusive measurement mode the requirement calls for during a silent two-week impact assessment.
Why C is correct: Audit mode evaluates the rule and logs every would-be block to DeviceEvents without stopping the action, giving the exact telemetry needed to gauge impact over the trial before promoting the rule to Block enforcement.
Why D is wrong: Not configured leaves the rule inactive so it produces no ASR evaluation telemetry, and device discovery inventories unmanaged devices on the network rather than recording which workflows the rule would have blocked.
lock_openFree sampleManage a Security Operations Environmentmedium
A device group in Microsoft Defender for Endpoint contains the servers in an isolated, lightly staffed branch site. Leadership requires that when automated investigation finds a malicious artefact on these servers, the remediation action is taken immediately without waiting for an analyst to approve it, because no analyst is reliably on shift for that site. Which automation level should you assign to this device group to meet the requirement?
- ASemi - require approval for any remediation, so every action that automated investigation proposes is queued in the Action centre until an analyst reviews and approves the verdict for the branch servers.
- BSemi - require approval for core folders remediation, so actions on operating-system directories are queued for approval while remediation elsewhere on the branch servers proceeds automatically after investigation.
- CNo automated response, so the automated investigation engine is disabled for the branch servers and any malicious artefact is left for an analyst to triage and remediate manually from the device timeline.
- DFull - remediate threats automatically, so automated investigation acts on its verdict and applies remediation to the branch servers without queueing the action for analyst approval first.check_circle Correct
Assign the Full automation level to a device group so automated investigation remediates threats immediately without queuing actions for analyst approval. Automation level is set per device group and governs how automated investigation handles its remediation verdicts. Full - remediate threats automatically applies actions without an approval step, whereas the Semi levels queue some or all actions in the Action centre for a human. For an unattended site, Full is the only level that guarantees immediate remediation, while the Semi and No automated response levels all depend on analyst availability.
Why A is wrong: Semi - require approval for any remediation does run automated investigation, but it holds every action pending analyst sign-off, which directly conflicts with the requirement to remediate immediately at a site with no reliable analyst coverage.
Why B is wrong: This level auto-approves actions outside core folders but still queues remediation in core operating-system locations, so malicious artefacts found there would wait for an absent analyst, failing the immediate-action requirement.
Why C is wrong: No automated response turns off automated investigation entirely, meaning nothing is remediated without a human, which is the opposite of the unattended immediate remediation the isolated branch site needs.
Why D is correct: Full automation lets automated investigation execute its remediation decision immediately without an approval gate, which is precisely what an isolated, lightly staffed site requires when no analyst is available to approve actions.
lock_openFree sampleRespond to Security Incidentshard
A security operations team is investigating an incident in Microsoft Defender XDR that began with a phishing email, progressed to a malicious sign-in, and then to suspicious process execution on a server. The analysts want to see how these alerts from Microsoft Defender for Office 365, Microsoft Entra ID, and Microsoft Defender for Endpoint were correlated into a single attack, including the timeline and the relationships between the involved entities. Which part of the Microsoft Defender XDR incident view should the analysts open to see this correlated end-to-end picture?
- AThe Microsoft Defender vulnerability management dashboard, which ranks exposed devices by their weaknesses so the team can see which assets the attacker most likely targeted during the campaign.
- BThe advanced hunting schema reference, which documents the available tables and columns so analysts can build a custom query that reconstructs the sequence of events for the incident.
- CThe threat analytics report for the relevant campaign, which describes the actor techniques and supplies recommended mitigations the team should apply to reduce the impact of the attack.
- DThe incident graph and attack story, which lay out the correlated alerts, affected assets, and entity relationships across the workloads as a connected timeline of how the attack unfolded.check_circle Correct
Use the Microsoft Defender XDR incident graph and attack story to understand how cross-workload alerts correlate into a single multi-stage attack. Microsoft Defender XDR automatically correlates related alerts from across its workloads into a single incident. The incident graph and attack story render those alerts, the affected entities, and their relationships as a connected timeline, so analysts can trace how an attack moved from email to identity to endpoint without manually piecing the stages together.
Why A is wrong: Vulnerability management surfaces device exposure and misconfigurations to drive proactive hardening, which is tempting when assessing attacker reach; it does not correlate alerts or render an incident timeline, so it cannot show how the stages connected.
Why B is wrong: The schema reference helps an analyst write hunting queries and could be used to rebuild a sequence manually, but it is documentation rather than the built-in correlated view; the incident already provides the joined attack story without query effort.
Why C is wrong: Threat analytics gives intelligence on actors and techniques with mitigation guidance, which feels relevant to a campaign; it is generic reporting and does not display this specific incident's correlated alerts, entities, or timeline.
Why D is correct: The incident graph and attack story are purpose-built to visualise how alerts from different Defender workloads were stitched into one incident, showing the entity relationships and the chronological progression an analyst needs to understand a multi-stage, multi-domain attack.
lock_openFree sampleRespond to Security Incidentshard
During a lateral movement investigation, an analyst has a list of devices that an attacker reached and wants to determine which user accounts authenticated to those devices and from which source devices, so the spread can be traced hop by hop. The analyst needs the table in Microsoft Defender XDR advanced hunting that records authentication and logon activity on endpoints, including the account, the logon type, and the remote device. Which table should the analyst query?
- ADeviceLogonEvents, which records sign-ins and authentication activity observed on devices, including the account, logon type, and the remote device, so each authentication hop can be reconstructed.check_circle Correct
- BDeviceProcessEvents, which records process creation on devices, including the command line and the parent process, so the analyst can see which programs ran during the attacker's lateral movement.
- CDeviceNetworkEvents, which records network connections made by devices, including remote IP addresses and ports, so the analyst can map the connectivity the attacker used between hosts.
- DIdentityLogonEvents, which records authentication activity seen by Microsoft Defender for Identity from domain controllers and Active Directory, including logons against identity infrastructure.
Choose DeviceLogonEvents to reconstruct endpoint authentications and trace lateral movement by account, logon type, and remote device. Tracing lateral movement means following authentications from device to device. DeviceLogonEvents is the Microsoft Defender for Endpoint table that records logons observed on each device with the account, logon type, and remote device, letting an analyst connect each hop. Process, network, and identity-layer tables capture different telemetry and cannot attribute device logons to users.
Why A is correct: DeviceLogonEvents captures endpoint logon and authentication activity with the account, logon type, and remote device fields, which is exactly what is needed to trace which users authenticated to which devices and follow lateral movement hop by hop.
Why B is wrong: DeviceProcessEvents is essential for execution analysis and may show tools used to move laterally, which makes it tempting; it captures process creation rather than logon events, so it does not reveal which accounts authenticated to which devices.
Why C is wrong: DeviceNetworkEvents shows connection-level telemetry such as remote IPs and ports and can hint at host-to-host traffic, but it does not record the authenticating account or logon type, so it cannot attribute logons to specific users.
Why D is wrong: IdentityLogonEvents reflects authentication observed by Microsoft Defender for Identity at the identity layer, which is useful for directory-side analysis; it does not record the endpoint-observed device logons needed to trace authentications onto the specific reached devices.
lock_openFree sampleRespond to Security Incidentshard
A multi-stage attack has produced several related incidents in Microsoft Sentinel that were generated from different analytics rules but clearly belong to the same campaign across identity, endpoint, and cloud app signals. The lead analyst wants to investigate them as one connected case so the full attack chain can be examined together, while keeping the original incidents intact for tracking. Which action in Microsoft Sentinel should the analyst take?
- AReopen each incident in turn and copy the entities into a shared workbook, then investigate the campaign from the workbook so the analysts have a single place to review the combined evidence.
- BMerge the related incidents into a single Microsoft Sentinel incident so their alerts, entities, and comments combine into one case that can be investigated as a unified attack chain.check_circle Correct
- CCreate an automation rule that tags every incident from the campaign with the same label, then filter the incident queue by that tag to investigate all of them side by side.
- DRun a scheduled analytics rule that re-queries the same data with a broader correlation window so a new single incident covering the whole campaign is generated for investigation.
Merge related Microsoft Sentinel incidents into one case to investigate a multi-stage campaign as a single connected attack chain. When separate analytics rules raise incidents that belong to the same campaign, Microsoft Sentinel lets an analyst merge them. Merging combines the alerts, entities, and comments into a single incident so the full attack story is investigated together, while the merged-away incidents are redirected and remain visible for tracking. Workbooks, tags, and broader rules organise data but do not unify the cases.
Why A is wrong: A workbook can aggregate data for reporting and is tempting as a single pane, but it does not link the incidents or carry their investigation state; the analysts would lose the native incident graph and entity correlation that an investigation needs.
Why B is correct: Merging incidents in Microsoft Sentinel consolidates the alerts, entities, and comments from related incidents into one case, which lets the analysts investigate the full multi-stage campaign together while the redirected incidents remain referenced for tracking.
Why C is wrong: Tagging through an automation rule groups incidents visually in the queue and helps triage, which sounds efficient; it leaves them as separate cases with separate graphs, so the attack chain still cannot be examined as one connected investigation.
Why D is wrong: Broadening a scheduled rule may correlate future events more aggressively, which seems to solve fragmentation; it generates new incidents going forward rather than uniting the existing ones, and re-querying does not combine the cases already raised.
lock_openFree samplePerform Threat Huntinghard
During an Advanced Hunting investigation in Microsoft Defender XDR, you must reconstruct a suspected malware execution chain on a single workstation by listing every process that was launched, together with its full command line and its initiating parent process, so that you can trace the lineage from the original loader. Which table should the Kusto Query Language (KQL) query target to obtain the parent and child process command lines directly?
// Goal: child process, its command line, and its parent process command line
<Table>
| where DeviceName == "FIN-WKS-014"
| project Timestamp, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine
- ADeviceProcessEvents, because it records one row per process creation with the child FileName and ProcessCommandLine alongside the InitiatingProcess fields for the parent, giving the full lineage on the device.check_circle Correct
- BDeviceEvents, because it is the general endpoint event table and therefore records every action a device takes, including each process that is created along with its parent and child command lines.
- CDeviceImageLoadEvents, because the loader and every subsequently launched binary must be mapped into memory, so the image load records reveal the parent and child process command lines for the chain.
- DDeviceFileEvents, because the loader writes the child executables to disk before running them, so the file create and modify records carry the process command lines for each stage of the chain.
Use DeviceProcessEvents in Advanced Hunting for process creation telemetry, as it carries both the child and initiating-parent command lines. DeviceProcessEvents is the schema table dedicated to process creation in Microsoft Defender for Endpoint telemetry. Each row pairs the spawned process FileName and ProcessCommandLine with the InitiatingProcessFileName and InitiatingProcessCommandLine of its parent, which lets an analyst pivot up and down the chain from a single table rather than joining across general event tables.
Why A is correct: DeviceProcessEvents is purpose-built for process creation telemetry, exposing the spawned process command line and the InitiatingProcess parent fields in the same row, which is exactly what is needed to walk a malware execution chain on one host.
Why B is wrong: DeviceEvents is a catch-all table for miscellaneous security and audit events such as protection toggles and ASR triggers; it does not provide a dedicated row per process creation with both the child and initiating-parent command lines, so the lineage reconstruction would be incomplete.
Why C is wrong: DeviceImageLoadEvents tracks DLL and module loads into a process, not process creation, so it lacks a per-spawn child command line and is the wrong surface for reconstructing parent-to-child execution lineage.
Why D is wrong: DeviceFileEvents captures file create, modify, rename, and delete activity, which is useful for tracking dropped payloads, but it does not record process command lines or parent-child execution, so it cannot reconstruct the run chain on its own.
lock_openFree samplePerform Threat Huntinghard
You are hunting in Microsoft Defender XDR for lateral movement that uses domain credentials, and you need authentication events that Microsoft Defender for Identity collects from domain controllers, including the protocol used and both the source and destination devices for each logon. Which Advanced Hunting table provides these on-premises Active Directory authentication events with the source-to-destination logon detail?
- ASigninLogs, because it is the authoritative authentication table and therefore contains the on-premises domain controller logons together with the logon protocol and the source and destination device for each event.
- BIdentityLogonEvents, because Microsoft Defender for Identity collects authentication events from monitored domain controllers, exposing the logon protocol and the source and destination devices for each on-premises logon.check_circle Correct
- CDeviceLogonEvents, because Microsoft Defender for Endpoint records every interactive and network logon seen on each onboarded device, so it reports the domain controller authentications with their protocol and source and destination hosts.
- DIdentityQueryEvents, because lateral movement relies on directory reconnaissance, so the LDAP, SAMR, and DNS queries it records include the authentication protocol and the source and destination devices for each domain logon.
Choose IdentityLogonEvents for on-premises Active Directory authentication telemetry that Microsoft Defender for Identity gathers from domain controllers. IdentityLogonEvents is fed by Microsoft Defender for Identity, which monitors domain controllers and AD FS servers. It captures authentication activity such as Kerberos and NTLM logons with the protocol, logon type, account, and the source and destination devices, making it the correct surface for hunting credential-based lateral movement against on-premises identities rather than the cloud-focused SigninLogs.
Why A is wrong: SigninLogs is a Microsoft Entra ID interactive sign-in table surfaced in Log Analytics, not in the Defender Advanced Hunting schema, and it records cloud sign-ins rather than the on-premises domain controller authentications that Defender for Identity collects.
Why B is correct: IdentityLogonEvents is the Advanced Hunting table populated by Microsoft Defender for Identity from monitored domain controllers and Active Directory Federation Services, carrying the LogonType, Protocol, and both DeviceName and target fields needed to trace credential-based lateral movement.
Why C is wrong: DeviceLogonEvents reports logons observed by the endpoint sensor on onboarded devices, which is valuable telemetry, but it is sourced from Defender for Endpoint rather than from domain controllers and may miss authentications on hosts that are not onboarded.
Why D is wrong: IdentityQueryEvents records directory queries such as LDAP and SAMR collected by Defender for Identity, which helps spot reconnaissance, but it does not represent authentication or logon events, so it cannot supply the source-to-destination logon detail required here.
lock_openFree samplePerform Threat Huntinghard
A phishing wave delivered malicious links by email, and you must determine which recipients actually clicked the links in the messages, capturing each click with the URL, the click verdict, and whether Safe Links allowed or blocked it. Which Advanced Hunting table in Microsoft Defender XDR records the user click events on URLs wrapped by Microsoft Defender for Office 365 Safe Links?
- AEmailEvents, because it records the full delivery and post-delivery handling of each message, so it captures every recipient who clicked a link together with the click verdict and the Safe Links block or allow decision.
- BEmailUrlInfo, because it enumerates the URLs found inside each message, so a query against it returns the click time, the click verdict, and the Safe Links allow or block result for every recipient who followed a link.
- CUrlClickEvents, because Microsoft Defender for Office 365 logs each Safe Links click with the wrapped URL, the account that clicked, the click verdict, and whether the click was allowed or blocked.check_circle Correct
- DDeviceNetworkEvents, because Safe Links protection redirects each click through the endpoint network stack, so this table records the click with the destination URL, the click verdict, and the allow or block result.
Use UrlClickEvents to identify which users clicked Safe Links protected URLs, with the per-click verdict and allow or block result. UrlClickEvents is generated by Microsoft Defender for Office 365 Safe Links whenever a user clicks a wrapped URL in email, Teams, or Office apps. It records the clicking account, the URL, the action type, and whether the user was allowed through or blocked, which separates it from EmailEvents and EmailUrlInfo that describe messages and their embedded URLs rather than the act of clicking.
Why A is wrong: EmailEvents records message-level delivery, detection, and post-delivery actions such as ZAP, which is essential context, but it does not log an individual user clicking a URL or the per-click Safe Links verdict, so it cannot identify who clicked.
Why B is wrong: EmailUrlInfo lists the URLs extracted from messages and is ideal for correlating which mails contained a given link, but it describes the URLs present rather than user click actions, so it carries no click time or per-click Safe Links verdict.
Why C is correct: UrlClickEvents is populated by Safe Links in Defender for Office 365 and records each user click on a protected URL, including the AccountUpn, the Url, the ActionType, and the IsClickedThrough and UrlChain detail, which is exactly the click-level evidence needed.
Why D is wrong: DeviceNetworkEvents records network connections observed by the endpoint sensor and may show traffic to a domain, but it has no concept of an email Safe Links click verdict and would miss clicks made on devices that are not onboarded to Defender for Endpoint.
Examworthy is not affiliated with or endorsed by Microsoft. All questions are original, blueprint-aligned practice material. We never reproduce live exam items. SC-200 and related marks belong to their respective owners.