Examworthyexamworthy.comMicrosoft Security Operations Analyst (SC-200) cheat sheet
Microsoft
Free to share. Examworthy is not affiliated with or endorsed by Microsoft; SC-200 and related marks belong to their respective owners.
At a glance
Format: Multiple choice and multiple response, at a Pearson VUE testing center or online proctored
Domain weight map
Heaviest first - spend your time hereHow this exam thinks
SC-200 is a run-the-SOC exam: nearly every question hands you a constrained Microsoft Sentinel or Microsoft Defender XDR scenario and asks for the single capability that meets it with the least admin effort, the correct signal source, and the right scope, and the traps are real features that fit all but one constraint.
Spot the trap
Tempting wrong answers, and why they failTempting but wrong
Setting an ASR rule to Block with per-application exclusions is a safe way to measure impact during a trial.
Why it fails
Block enforces immediately, which violates a requirement to measure impact silently first. Chasing breakages with exclusions reacts only after disruption has occurred. Audit mode logs would-be blocks to DeviceEvents without stopping any action, so it measures impact safely.
Manage a Security Operations Environment
Tempting but wrong
The Microsoft Defender vulnerability management dashboard shows how an incident's cross-workload alerts were correlated into a single attack timeline.
Why it fails
It does not. Vulnerability management ranks device exposure and misconfigurations to drive proactive hardening; it neither correlates alerts nor renders an incident timeline. The correlated end-to-end picture comes from the incident graph and attack story.
Respond to Security Incidents
Tempting but wrong
DeviceEvents is the general endpoint table, so it records a row per process creation with both parent and child command lines.
Why it fails
DeviceEvents is a catch-all table for miscellaneous security and audit events such as protection toggles and ASR rule triggers. It does not provide a dedicated per-spawn row carrying both the child and initiating-parent command lines, so lineage reconstruction would be incomplete. Use DeviceProcessEvents for process creation telemetry.
Perform Threat Hunting
Tempting but wrong
Warn mode is the non-intrusive way to silently measure an ASR rule's impact for two weeks.
Why it fails
Warn surfaces a dismissible prompt to the user every time the rule triggers, so it already disrupts the workflow and lets users bypass the rule. That is not a silent measurement mode. Audit mode lets the action proceed and only logs to DeviceEvents, giving impact data without prompting anyone.
Manage a Security Operations Environment
Tempting but wrong
The advanced hunting schema reference is where you view an incident's already-correlated attack timeline in Microsoft Defender XDR.
Why it fails
No. The schema reference is documentation of tables and columns to help write hunting queries; rebuilding a sequence with KQL is manual effort. The incident already provides the joined attack story through its incident graph, with no query needed.
Respond to Security Incidents
Tempting but wrong
DeviceImageLoadEvents reveals parent and child process command lines because every launched binary is mapped into memory.
Why it fails
DeviceImageLoadEvents tracks DLL and module loads into a process, not process creation. It lacks a per-spawn child command line and parent-child execution detail, so it is the wrong surface for reconstructing run lineage. DeviceProcessEvents holds the child and InitiatingProcess command lines instead.
Perform Threat Hunting
Tempting but wrong
Leaving an ASR rule Not configured and relying on device discovery can gauge what the rule would have blocked.
Why it fails
Not configured leaves the rule inactive, so it produces no ASR evaluation telemetry at all. Device discovery inventories unmanaged devices on the network rather than recording which workflows the rule would have blocked. Only Audit mode logs would-be blocks to DeviceEvents.
Manage a Security Operations Environment
Tempting but wrong
A threat analytics report displays a specific incident's correlated alerts, entities, and timeline in Microsoft Defender XDR.
Why it fails
It does not. Threat analytics provides generic intelligence on actor techniques with recommended mitigations for a campaign; it is not tied to one incident's data. The incident graph and attack story show this incident's correlated alerts, entities, and timeline.
Respond to Security Incidents
Key terms
Exam-day rules
- Name the owning capability first. Decide whether the stem is about a Sentinel analytics rule, a Defender XDR custom detection, an automation rule, a playbook, a device response action, or a hunting artefact before you read the options, so you narrow the field before comparing details.
- Separate real-time from scheduled and automatic from manual. If the stem demands sub-minute latency on one source it is a near-real-time rule; if it demands autonomous containment of an active attack it is automatic attack disruption; if it demands recurring aggregation across tables it is a scheduled analytics rule.
- Pick the right telemetry table in KQL. Process lineage with parent and child command lines is DeviceProcessEvents, not DeviceEvents; outbound connections are DeviceNetworkEvents; reach for make-series, not summarize with bin, when you need an even gap-filled time series for beaconing.
- Choose the least-privilege, lowest-effort option. When more than one configuration would technically work, the exam wants the narrowest scope and the fewest manual steps, such as Microsoft Sentinel Contributor over a subscription role, or an Azure Policy deployIfNotExists over per-resource diagnostic settings.
- Match the verdict to the workload. In Microsoft Entra ID Protection use Confirm user compromised to record a true positive; in Microsoft Purview use eDiscovery (Premium) for holds and defensible export; on a device use the live response run command to execute a pre-approved library script.
Revision schedule
- Day 1Read the refreshed blueprint and book a date
- Week 1Build the detection and automation backbone
- Week 1 to 2Master data connectors and ingestion
- Week 2 to 3Work through cross-workload incident response
- Week 3Drill KQL and threat hunting