Design security operations, identity, and compliance capabilities
Two platforms, one operations model
Microsoft Sentinel is the cloud-native SIEM and SOAR layer: it ingests logs via data connectors, detects with analytics rules, groups alerts into incidents, and responds. Microsoft Defender XDR is the native correlation layer across Defender for Endpoint, Identity, Office 365, Cloud Apps, and Vulnerability Management - it produces high-fidelity incidents from first-party signals and can auto-remediate. Design questions ask you to choose: if the requirement is "correlate signals from Microsoft workloads with automatic disruption," XDR; if it is "centralize third-party and custom logs with custom detection and orchestration," Sentinel.
In Sentinel, separate automation rules from playbooks. An automation rule is the trigger and lightweight logic (assign, tag, close, suppress) evaluated on incident creation or update. A playbook is an Azure Logic App that does the actual work - enrich, post to Teams, isolate a device, open a ticket. A trap answer will use an automation rule to perform remediation, or a playbook as the trigger.
For identity, Microsoft Entra ID Protection supplies risk signals, Conditional Access enforces the decision, Privileged Identity Management provides just-in-time role activation with approval, and access reviews provide periodic attestation. Microsoft Purview covers the compliance half: classification, sensitivity labels, DLP, retention, insider risk, eDiscovery, and audit.
Rule of thumb: risk signal → policy decision → enforcement point → evidence. If a scenario names an evidence requirement (audit, retention, attestation), the answer lives in Purview or access reviews, not in Defender.
Worked example: an auditor wants proof nobody holds permanent Global Administrator. Answer: PIM eligible assignments with approval required, plus recurring access reviews - the review produces the evidence.