Microsoft SC-200: Defender XDR Investigations

Microsoft Defender XDR investigation questions on SC-200 are less about memorizing where a button lives and more about reconstructing an attack from correlated evidence. The current Microsoft SC-200 objectives place heavy emphasis on operating a security environment, responding to incidents, and hunting for threats across endpoints, identities, email, cloud applications, and other connected sources. Defender XDR sits at the center of that work because it brings signals together into incidents and investigation views.

The analyst’s job is to decide what happened, how far it spread, which entities are affected, and what must be contained first. A single alert rarely answers those questions. Strong investigation technique moves from incident context to evidence, from evidence to scope, and from scope to a response plan that preserves enough information for follow-up while reducing immediate risk.

Start with the incident, not the loudest alert

Defender XDR can correlate related alerts into an incident so the analyst sees a broader attack story. That matters because an identity alert, an endpoint alert, and suspicious email activity may be parts of the same compromise. Treating each alert separately wastes time and can obscure the attacker’s sequence.

Begin by reviewing incident severity, affected assets, alert chronology, and the evidence graph. The question to answer is not “which alert looks scariest?” but “which evidence explains the attack path?” An alert about suspicious PowerShell may be more important when it occurs immediately after a risky sign-in and before credential access activity. Context changes priority.

Use entity context to establish scope

Users, devices, mailboxes, IP addresses, files, and processes are investigation entities. Each has history and relationships that can reveal whether the incident is isolated or part of a larger campaign. If one user account appears in several incidents across multiple devices, the identity may be the common point of compromise rather than any single endpoint.

Entity timelines help answer practical questions: when did suspicious activity begin, what happened next, and what was normal beforehand? Analysts should compare activity across time rather than assuming the first visible alert is the start of the attack. An attack lifecycle can leave separate traces of reconnaissance, initial access, persistence, lateral movement, and impact; building a coherent sequence from those traces is part of the investigation.

Read the process tree as a narrative

Endpoint investigations often revolve around process relationships. A suspicious executable is more meaningful when you know which parent launched it, which child processes followed, which command line was used, and whether the sequence matches known administrative behavior. Parent-child relationships can distinguish a legitimate tool from a legitimate tool being abused.

Command lines deserve particular attention because attackers often use trusted binaries, scripts, encoded commands, or remote-management utilities. The file hash alone may not be malicious. Instead, the combination of parent process, command arguments, user context, network connection, and timing reveals intent. Exam scenarios frequently reward this behavioral view over signature-only reasoning.

Correlate identity evidence with endpoint activity

Modern attacks often cross identity and endpoint boundaries. A stolen token or password can lead to a suspicious sign-in, after which the attacker accesses a device, executes tooling, or changes security settings. Defender XDR investigations should therefore include identity risk and authentication evidence, not only device telemetry.

Impossible travel, unusual sign-in properties, MFA changes, or abnormal privilege use can help explain how an attacker obtained access. Policies such as Microsoft Entra Conditional Access reduce exposure through contextual restrictions, while SC-200 asks what the analyst should investigate when suspicious identity activity has already become part of an incident.

Use automated investigation results as evidence, not as a substitute for judgment

Defender XDR can perform automated investigation and response actions that collect evidence, analyze suspicious entities, and recommend or execute remediation. Those capabilities reduce repetitive work, but the analyst still needs to understand what was investigated and why an action was taken.

Automation can classify artifacts and accelerate containment, yet unusual business context may require human review. A script that looks suspicious in one organization may be an approved deployment tool in another. Analysts should inspect the evidence and confidence behind an automated conclusion, especially before accepting remediation that could disrupt a critical system.

Distinguish containment from remediation

Containment stops or limits active harm. Remediation removes the cause or persistence of the compromise. Isolating a device, disabling an account, blocking an indicator, or terminating a malicious process can reduce immediate risk. Resetting credentials, removing persistence mechanisms, patching exploited software, and restoring trusted configuration address the longer-term problem.

SC-200 scenarios often describe pressure to act quickly. The best answer usually contains the threat without destroying useful evidence and then moves into remediation. For example, wiping a system immediately may be premature if isolation can stop communication while preserving artifacts needed to understand how the attacker entered and whether other systems are affected.

Use threat intelligence to enrich, not replace, local evidence

Indicators such as hashes, domains, IP addresses, and URLs can be enriched with threat intelligence, but reputation alone does not determine the incident. A newly registered domain may be suspicious but not malicious. A known-bad hash on an endpoint is stronger evidence, yet you still need to understand execution context and spread.

Local telemetry remains decisive because it shows what happened in the organization. Threat intelligence helps prioritize and interpret that telemetry. Familiar enterprise security threats provide hypotheses worth testing, but Defender XDR still requires the analyst to correlate evidence before treating an attack pattern as confirmed.

Build an evidence-backed incident timeline

A good timeline connects authentication, process execution, network activity, file events, email actions, and response steps. It should distinguish observed facts from analyst hypotheses. “User signed in from address X at 09:12” is evidence; “attacker stole the password through phishing” is a hypothesis until other evidence supports it.

Chronology is also how analysts identify the first known malicious action and later persistence. If the endpoint alert occurs at noon but the account received a malicious message at 08:00 and granted a suspicious application permission at 08:20, the endpoint event is not the beginning. Timeline thinking prevents a narrow response that cleans one device while leaving the initial access path intact.

Evidence quality should influence investigative confidence. A single heuristic alert may be weak evidence; the same alert supported by process telemetry, risky sign-in data, and a known malicious indicator is much stronger. Analysts should look for independent signals that corroborate one another rather than counting multiple alerts generated from the same underlying event as separate proof.

Attack disruption features can automatically interfere with active threats when Microsoft’s correlated signals reach sufficient confidence. From an exam perspective, understand the purpose: shorten attacker dwell time by taking coordinated action across affected assets. From an operational perspective, review what was disrupted, which entities were involved, and whether follow-up remediation is still required. Automatic containment does not close the incident by itself.

Investigation quality also depends on knowing normal administrative behavior. Remote management tools, PowerShell, archive utilities, and credential-access commands can all be legitimate. Baseline information such as approved management servers, automation accounts, maintenance windows, and software deployment tools helps distinguish expected administration from attacker abuse. Context reduces false positives without forcing analysts to ignore powerful tools completely.

Finally, record investigation decisions. Notes should explain why an artifact was judged malicious or benign, which entities were searched, and what response actions were taken. Clear documentation lets another analyst continue the case, supports later review, and prevents the team from repeating the same discovery work if a related incident appears days later.

Defender XDR investigations also benefit from prioritizing evidence that can change the response. A duplicate alert may confirm what you already know, while a new sign-in token, lateral movement event, or persistence mechanism can expand scope dramatically. During time-sensitive incidents, investigate the evidence most likely to alter containment or severity first.

Analysts should be cautious with “absence of evidence.” If a device has limited telemetry or a connector stopped reporting, the lack of suspicious events does not prove the asset is clean. Coverage gaps should be documented as uncertainty and may justify additional collection or manual validation before the incident is closed.

Cross-product evidence should be reconciled when timestamps or entity names differ. Mail, identity, endpoint, and cloud services may record related activity with different identifiers or slight timing offsets. Analysts should normalize the relationship carefully instead of assuming two events are unrelated simply because their labels are not identical.

Answer Defender XDR scenarios with a scope-first mindset

When an SC-200 question asks what to investigate next, identify the unanswered scope question. Do you know which users are affected? Which devices executed the file? Whether the account was compromised before the endpoint event? Whether the incident is still active? The most useful next step is the one that reduces uncertainty about scope or immediate risk.

That mindset also improves response quality. Investigate correlated evidence, establish the attack sequence, contain active threats, remediate root causes, and document what the evidence supports. Defender XDR is valuable because it connects signals, but the analyst turns those signals into an incident narrative and a defensible response decision.