Associate-level certification covering security operations with Microsoft Sentinel and Microsoft Defender XDR: configuring automation and detections, responding to incidents across Defender workloads, and threat hunting with KQL.
Free sample questions
No account needed. Every question has a worked explanation, just like the full bank.
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 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 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.
More free SC-200 practice questions with worked answersExamworthy 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.
