Configure Protections and Detections
Stop the attack you can, then catch the attack you can't
Every control on the SC-200 blueprint does one of two jobs: it either protects (blocks bad activity before it lands) or detects (raises an alert once something slips through). That single split is the map for this whole domain. Protection is preventive and lives inside each Microsoft Defender workload, scoped to the asset it owns: Defender for Office 365 guards email, Defender for Endpoint guards devices with attack surface reduction (ASR) rules, Defender for Cloud Apps guards SaaS sessions, and Defender for Cloud guards Azure, AWS, and GCP workloads. Detection is the safety net that assumes prevention is imperfect, and it runs in two engines: Microsoft Defender XDR (extended detection and response) detects across the Microsoft estate it already protects, while Microsoft Sentinel, the cloud SIEM (security information and event management), detects across every log you feed it. The classic exam trap is reaching for a detection answer when the scenario can be prevented outright, or wiring a custom rule when a built-in preset already covers it; ask "can I block this, and if not, which engine sees the signal?" before you pick.
The domain unfolds in three steps: protect, then detect in XDR, then detect in Sentinel
Read this page as a map, then follow the three subtopics in order. Configure Protections in Microsoft Defender is the preventive layer: you match each Defender workload to the asset it owns and tune its policies, with ASR rules and the Standard or Strict presets the exam favourites. Configure Detections in Microsoft Defender XDR is the first detection engine: custom detection rules built from Kusto Query Language (KQL) advanced-hunting queries, alert tuning to silence the noise, correlation that bundles alerts into one incident, and deception that plants decoys so any touch is a high-confidence signal. Configure Detections in Microsoft Sentinel is the second detection engine and the broadest: analytics rules over your logs, entity mapping that turns query rows into investigatable users and hosts, the Advanced Security Information Model (ASIM) that normalizes many sources so one rule fits all, and behavioral analytics (UEBA, user and entity behavior analytics) for the threat that has no signature. Each subtopic carries the mechanics, the limits, and the traps; this overview just shows how they fit.
When two answers both work, prefer the built-in, lower-noise default
Across protection and detection alike, the exam rewards the same instinct: take the managed, lower-risk path before the hand-built one. Apply a preset security policy before tuning each Office 365 setting by hand, roll an ASR rule out in Audit mode before flipping it to Block, start an analytics rule from a Content hub template before writing KQL from scratch, and reach for alert tuning to suppress known-benign noise rather than deleting telemetry or disabling a rule. The point is signal quality: a detection that floods the queue is as useless as one that never fires, so the correct answer is usually the one that catches the threat while creating the least noise and the least operational risk.
Two jobs, three engines: where each subtopic fits
| Stage | What it does | Engine / where it lives | Drill into |
|---|---|---|---|
| Protect | Block the attack before it lands | Each Microsoft Defender workload (Office 365, Endpoint/ASR, Cloud Apps, Defender for Cloud) | Configure Protections in Microsoft Defender |
| Detect (Microsoft estate) | Alert on what slips through, across protected devices, email, SaaS, and cloud workloads | Microsoft Defender XDR (custom detection rules, alert tuning, correlation, deception) | Configure Detections in Microsoft Defender XDR |
| Detect (all your logs) | Alert across every ingested source, including non-Microsoft data | Microsoft Sentinel SIEM (analytics rules, entity mapping, ASIM, UEBA) | Configure Detections in Microsoft Sentinel |