3.3. Respond to Cloud Workload and Sentinel Incidents
💡 First Principle: Not every incident starts in Microsoft 365. Attackers target virtual machines, storage accounts, databases, Kubernetes clusters, and third-party systems, and they appear in the same queue as Defender XDR signals because Defender for Cloud and Sentinel feed it. Responding means applying the same triage discipline to resources that don't have a Defender XDR "isolate" button, and using Sentinel's investigation tools for data Defender XDR never sees.
Why care: the unified queue means one analyst may handle a phishing incident, then a suspicious Azure Storage access pattern, then an alert from a firewall rule. The exam expects you to know where each one's detail lives and which tools respond to it.
Think of the Defender portal as a hospital's single admissions desk. Patients arrive from different ambulances (Defender XDR products, Defender for Cloud, Sentinel rules), but they're triaged in one queue and records follow them. Specialists still work in their own departments: cloud workload alerts are remediated in Azure (or AWS and Google Cloud), while Sentinel incidents draw on entity pages, UEBA, and workspace data.
⚠️ Common Misconception: "Defender for Cloud alerts cover only Azure." Defender for Cloud protects workloads in Azure, AWS, and Google Cloud through connectors, and servers anywhere through Azure Arc. A second trap: assuming Sentinel incident changes don't affect the Defender view. In the unified platform, incident status, owner, classification, and comments are shared.
