SC-200: Security Operations from Detection to Response

SC-200 tests the practical judgment of a security operations analyst using tools such as Microsoft Defender XDR, Microsoft Sentinel and Defender for Cloud. The role includes managing investigation environments, analyzing alerts and incidents, hunting threats with Kusto Query Language (KQL), and coordinating responses that reduce actual risk. Microsoft has announced an SC-200 skills revision effective October 21, 2026. Use the earlier outline for an exam before that date and the revised objectives for later bookings; changes to Sentinel and response tooling make the effective version material. The difference between an alert and a confirmed incident remains foundational regardless of version.

An analyst is measured by the quality of decisions under incomplete evidence. A suspicious process, failed sign-in or network connection is a lead, not automatic proof of an attack. The goal is to develop enough context to prioritize action without waiting until containment is no longer possible. Architects studying SC-100 architecture decide what operations need to exist; SC-200 concentrates on operating and improving them day to day.

Organize data sources around investigation questions

A security operations environment must ingest signals that address meaningful attack paths. Identity sign-ins, endpoint activity, cloud-control operations, email telemetry and network events provide different perspectives. More data is not always better if it arrives late, lacks consistent identifiers or overwhelms analysts with duplicates. Decide which logs support an incident hypothesis, how long they need to be retained, and what authorization analysts need to query them.

Imagine an administrator account creates an unfamiliar application registration. Identity audit data may show who initiated it, but endpoint and workload events help assess whether it was legitimate maintenance or a compromise. A Sentinel workspace with missing identity connectors cannot answer the question simply because it contains large volumes of firewall traffic. Microsoft Sentinel operations begin with data quality, timestamps and source ownership rather than a dramatic dashboard.

Triage alerts by scope, confidence and business impact

Good triage distinguishes severity, confidence and urgency. An alert affecting an isolated test workstation may be technically interesting but less urgent than a probable privileged-account compromise on a payroll system. Correlation can connect low-confidence events into a stronger incident, although automated grouping can occasionally join unrelated activities. Analysts should verify asset criticality, affected identities and sequence before escalating or dismissing a case.

Suppose an email alert and an endpoint alert share the same user but occurred several hours apart. Was an attachment opened? Did a suspicious process execute? Were there unusual token requests? A complete investigation tests those relationships. Defender XDR investigations allow cross-workload context, but analysts must still distinguish a causal chain from coincidence. Document why an alert was classified as benign or malicious; unsupported closures erode the value of future detection tuning.

Use KQL to test hypotheses, not just retrieve rows

KQL is a means to ask precise questions about event streams. Filtering on time, identities and device IDs can reveal whether an unusual action was isolated or part of a campaign. Joins, aggregation and projections help connect tables, but careless use of time windows and duplicated keys can inflate results. Know the schema and timestamps of each data source before interpreting a query. A large result set is not necessarily useful evidence.

A hunt for rare administrative commands might begin with a baseline of usual activity. A single suspicious command becomes more important when followed by persistence changes and outbound connections. Test for known legitimate maintenance windows and automation accounts. KQL threat hunting should enable a peer reviewer to understand why each filter was selected and what conclusion the query supports. Saving queries without documenting assumptions turns a powerful analytical method into an opaque collection of snippets.

Respond while preserving the ability to investigate

Containment actions can include isolating a device, disabling an identity, revoking sessions or blocking an indicator. These may be warranted before every detail is known, but analysts need clear authority and an understanding of operational consequences. A disabled service account might interrupt manufacturing or patient care. Playbooks should distinguish urgent self-protective actions from those requiring human approval. Preserve relevant logs and volatile evidence before changes erase the trail where safe and feasible.

For example, a compromised user may have granted consent to a malicious enterprise application. Resetting the user's password may be insufficient if the application retains delegated access or tokens remain usable. Investigate permissions, revoke the relevant grants and inspect downstream data access. Incident triage and response should include confirmation of containment and a plan to restore legitimate activity. Closing a ticket because a host was isolated is premature if the attacker still controls another identity.

Engineer detections that analysts can trust

Detection rules need meaningful coverage and acceptable false-positive rates. Suppression can reduce noise, but broad exclusions may also conceal malicious activity. Describe the threat behavior a rule is intended to detect, the required events, baseline assumptions and conditions that make a hit actionable. Test with synthetic or controlled events when possible and examine both missed detections and excessive alerting. Rules should have owners and change histories, not simply accumulate over time.

A policy that flags every PowerShell invocation on servers is likely to become noisy in a heavily automated environment. A better detection may consider encoded commands, unexpected parent processes, rare users, network destinations and context—without assuming any one indicator proves malice. Detection engineering and tuning should also take attacker adaptation seriously. Periodic review of resolved incidents can identify blind spots as well as redundant alerts.

Automate repetitive work without losing judgment

Automation rules and playbooks can enrich incidents, attach context, route work and perform selected containment tasks. The value is faster, more consistent response to well-understood conditions. A playbook with overly broad permissions or an ambiguous trigger can damage legitimate systems. Define what information must be validated before a disruptive action and how analysts can pause, override or audit execution. Runbooks should specify behavior when dependencies fail.

Suppose a rule suspends accounts flagged for impossible travel. Remote workers using VPN exit nodes may create misleading signals. A responsible design might enrich the alert with device trust, known locations and sign-in context before escalating. Sentinel response automation should reduce avoidable manual work without making an unexamined confidence score into an irreversible decision. Build explicit rollback or restoration procedures for legitimate users affected by false alarms.

Extend investigations across workloads and cloud boundaries

Endpoint compromise can lead to identity abuse, cloud resource changes and data movement. Analysts should be comfortable linking Windows and Linux events, cloud activity and Microsoft 365 workloads while understanding differences in log availability. Defender for Cloud adds workload posture and protection context that may help determine exposure, but a recommendation is not itself evidence of exploitation. Cloud workload protection can reveal which resources need closer examination during an incident.

A container workload begins making unfamiliar outbound connections. Investigate deployment history, image provenance, workload identity and the destinations observed. If the cluster was recently updated, compare expected changes with the anomaly rather than assuming every network deviation indicates malware. Share findings with platform engineers in terms they can verify. Security operations works best when an analyst can explain the evidence and proposed action to the owner of the affected system.

Analysts also need to recognize telemetry gaps. A missing record does not prove that no malicious action occurred: audit settings may have been disabled, a device might have been offline or a connector may have dropped events. Treat negative evidence carefully and record which sources were available over the period under investigation. When making a containment decision, explain whether the absence of activity is meaningful given the data collection design. This avoids both premature case closure and unsupported conclusions of compromise.

Detection quality improves when incidents become structured feedback. After remediating an attack, assess whether the first alert arrived early enough and whether its context supported correct prioritization. Review the playbook, query logic and asset inventory. If the issue was a benign tool triggering noisy rules, refine the detection without masking adjacent malicious behavior. Operational learning should produce a specific, testable change, not merely a slide reporting that awareness needs improvement.

A useful individual exercise is to write the final case summary for two readers: the analyst on the next shift and the manager accountable for the service. The first needs event timestamps, queries, affected assets and actions; the second needs impact, residual risk and recovery status. Producing both accurately shows that technical evidence has been turned into an operational decision.

Learn by investigating one event through its lifecycle

Create a laboratory incident involving a user clicking a suspicious message link, signing in from an unusual device and accessing a sensitive storage account. Determine which connectors and tables are required; use queries to reconstruct the timeline; triage the evidence and decide what containment is authorized. Record a brief incident narrative and a list of uncertain assumptions. Then test whether your detections would identify the same sequence if one log source were delayed.

For SC-200, practice both the technical tools and the discipline of explaining decisions. A successful investigation should connect evidence, business risk, containment, recovery and detection improvement. Preparation that stops at memorizing portal navigation misses the central skill: finding what actually happened and helping the organization prevent recurrence without causing unnecessary disruption.