Last reviewed: May 2026
A scannable reference of architectural patterns the SC-200 exam tests. Read top-to-bottom, or jump to a section.
Strict data residency requirements across multiple geographic regions.
Deploy multiple Microsoft Sentinel workspaces, one per region. Use Azure Lighthouse for centralized management.
Why: Keeps log data within geographic boundaries for compliance while allowing a central SOC to operate across all workspaces.
Sentinel workspace ingesting over 100 GB of data per day.
Switch the Log Analytics workspace pricing tier from Pay-As-You-Go to Commitment Tiers.
Why: Commitment Tiers provide significant cost savings for high-volume, predictable data ingestion compared to standard pricing.
High-volume logs (e.g., Windows Security Events) are driving up SIEM costs.
1. Use a Data Collection Rule (DCR) to filter events at the source. 2. Configure the destination table for Basic Logs.
Why: DCRs reduce ingestion costs by collecting only necessary events. Basic Logs reduce storage costs for verbose data not requiring full analytics.
Compliance requires data retention for more than 2 years (e.g., 7 years).
Configure the workspace with 90-day interactive retention and a 7-year total retention (archive tier).
Why: Balances immediate searchability (interactive) with low-cost, long-term storage (archive). Access archived data via Search Jobs.
Collect security events from on-premises Windows and Linux servers.
Install the Azure Arc agent for management, then deploy the Azure Monitor Agent (AMA) via Arc.
Why: Arc extends the Azure control plane to on-premises, enabling native management and data collection with the modern AMA agent.
Ingest logs from third-party devices (e.g., firewalls) that support Syslog.
Deploy a dedicated Linux VM as a Log Forwarder with the AMA. Use CEF format for structured security data.
Why: Centralizes collection for devices that cannot host an agent. CEF provides a normalized, queryable schema for security events.
Ingest incidents and alerts from Microsoft Defender XDR into Sentinel.
Enable the Microsoft Defender XDR data connector and its incident creation/bi-directional sync option.
Why: Creates a unified incident queue and ensures status changes are synchronized between Sentinel and the Defender portal.
Filter specific Windows Event IDs at the source to reduce ingestion volume.
Configure a Data Collection Rule (DCR) with an XPath query to specify which Event IDs to collect.
Why: Reduces ingestion volume and cost by filtering data at the source agent, before it is sent to the workspace.
Require the fastest possible detection time for critical events.
Use a Near Real-Time (NRT) analytics rule.
Why: NRT rules run every minute, offering detection latency of ~1-2 minutes, much faster than the 5-minute minimum for scheduled rules.
Detect a threshold of events within a specific time window (e.g., brute force attacks).
Create a Scheduled analytics rule using KQL `summarize ... by bin(TimeGenerated, 5m), ...`.
Why: The `bin()` function is critical for grouping events into discrete, non-overlapping time windows for accurate threshold detection.
Detect complex, multi-stage attacks that individual alerts might miss.
Enable Fusion analytics rules for advanced multistage attack detection.
Why: Fusion uses ML to correlate low-fidelity signals across multiple data sources into high-confidence incidents, reducing alert fatigue.
Detect insider threats or compromised accounts based on anomalous behavior.
Enable User and Entity Behavior Analytics (UEBA).
Why: UEBA establishes behavioral baselines for users and entities, then flags significant deviations that don't match specific rule logic.
Write a single, source-agnostic analytics rule for multiple data sources (e.g., DNS from various vendors).
Use Advanced Security Information Model (ASIM) parsers in the KQL query.
Why: ASIM provides a normalized schema, allowing queries to run against a unified view (e.g., `imDns`) instead of multiple vendor-specific tables.
Manage Sentinel content (analytics rules, workbooks) as code and deploy across environments.
Use Microsoft Sentinel Repositories to connect a GitHub or Azure DevOps repository.
Why: Enables CI/CD workflows, version control, and automated, consistent deployment of security content (Sentinel-as-Code).
Automate basic incident triage tasks like assigning owners, changing status, or adding tags.
Use an Automation Rule triggered on incident creation.
Why: Automation rules are lightweight and synchronous, ideal for simple triage actions without the overhead of a Logic App.
Automate complex incident responses involving external systems (e.g., block user in Entra ID, send Teams message).
Create a Playbook (Azure Logic App) and trigger it from an Automation Rule.
Why: Logic Apps provide the orchestration engine and connectors needed for complex, multi-step responses and integrations.
Understand the scope of an attack by visualizing relationships between entities (users, IPs, hosts).
Use the Investigation Graph on the incident details page.
Why: Provides an interactive map of the attack, making it easy to see connections and pivot between related entities and alerts.
Standardize and accelerate common investigation workflows for the SOC team.
Create and share a Promptbook in Microsoft Security Copilot.
Why: Promptbooks chain together a series of natural language prompts to create a guided, repeatable investigation process for common scenarios.
Manage security permissions centrally for all Microsoft Defender products.
Activate the Microsoft Defender XDR Unified RBAC model.
Why: Replaces individual product-specific roles with a single, granular permission model, simplifying administration.
Automatically isolate devices or remediate files based on alert severity.
Configure Automated investigation settings for device groups, setting the Automation Level to 'Full' or 'Semi'.
Why: Enables hands-off remediation for common threats. Device groups allow different automation levels for workstations vs. critical servers.
Immediately block a known malicious file hash, IP address, or URL across all endpoints.
Create an Indicator of Compromise (IoC) with a "Block and Remediate" action.
Why: Provides a rapid, organization-wide containment mechanism that is faster than waiting for AV signature updates.
Harden endpoints by blocking common attack techniques (e.g., Office creating child processes).
Deploy Attack Surface Reduction (ASR) rules, starting in 'Audit' mode to assess impact before switching to 'Block'.
Why: ASR rules are a key preventative control. Audit mode is critical for preventing disruption to business applications during rollout.
Perform deep forensic investigation or manual remediation on a live endpoint.
Use the Live Response feature to establish a remote shell and collect forensic packages.
Why: Provides direct, real-time access to the device for running commands, collecting files, and running forensic scripts.
Reconstruct an attacker's actions on a specific compromised device.
Analyze the Device Timeline.
Why: Provides a detailed, chronological event log of all process, network, file, and registry activity on the endpoint.
Detect credential theft and lateral movement techniques like Pass-the-Hash/Ticket.
Deploy Microsoft Defender for Identity sensors on all Domain Controllers.
Why: Defender for Identity monitors on-prem AD authentication traffic directly, providing high-fidelity alerts for identity-based attacks.
Protect users from zero-day malware embedded in email attachments.
Configure a Safe Attachments policy with the Dynamic Delivery option.
Why: Detonates attachments in a sandbox to check for malicious behavior while delivering the email body immediately, balancing security and productivity.
Find and remove all instances of a phishing email from user mailboxes.
Use Threat Explorer (or Advanced Hunting) to search for the email and execute a soft or hard delete action.
Why: Threat Explorer is a powerful search and remediation tool to purge active threats from the mail system organization-wide.
Prevent data exfiltration by blocking downloads of sensitive files to unmanaged (non-compliant) devices.
Configure a Defender for Cloud Apps session policy using Conditional Access App Control.
Why: Acts as a reverse proxy to inspect and control user activity in real-time within a cloud app session, enforcing data access policies.
Automatically contain a widespread, active attack like human-operated ransomware.
Enable Automatic Attack Disruption in Microsoft Defender XDR.
Why: Uses cross-domain signals (XDR) to take decisive action at machine speed, such as disabling compromised user accounts and isolating devices.
Proactively search for threats across all XDR data (endpoint, email, identity, cloud apps).
Use Advanced Hunting with Kusto Query Language (KQL).
Why: Provides a powerful, query-based interface to hunt across 30 days of raw telemetry, enabling discovery of threats that evade standard detections.
Quickly understand the full scope of a complex incident involving multiple alerts and entities.
Analyze the incident's Attack Story or Investigation Graph.
Why: Consolidates and visualizes the entire attack chain, showing how an attacker moved from an initial entry point across different assets.
Extend Defender for Cloud workload protections to on-premises and multi-cloud servers.
Onboard the servers using Azure Arc, then enable the Defender for Servers plan.
Why: Azure Arc acts as a control plane bridge, projecting non-Azure resources into Azure so they can be managed and secured by Defender for Cloud.
Quickly understand the purpose and potential maliciousness of a complex script (e.g., PowerShell).
Paste the script into Security Copilot and ask for an analysis of its function and risk.
Why: Leverages generative AI to de-obfuscate and explain code, significantly speeding up artifact analysis without executing the script.
Immediately contain a compromised user account that is synchronized from on-premises AD.
Disable the account in on-premises Active Directory, then trigger an immediate AD Connect sync.
Why: For synchronized identities, on-premises AD is the source of authority. Disabling the account there is the most effective containment action.
Ingest external threat intelligence from a TIP using an industry-standard protocol.
Use the 'Threat Intelligence - TAXII' data connector in Sentinel.
Why: Connects to TAXII 2.x servers to automatically import STIX-formatted indicators, operationalizing threat intelligence.
Correlate known threat indicators (IPs, domains, hashes) against all ingested log sources.
Ingest indicators into the ThreatIntelligenceIndicator table and enable the built-in "TI map..." analytics rules.
Why: These rules efficiently match threat intelligence against normalized entity fields in logs to generate alerts on known malicious activity.
Use a custom list of indicators (e.g., IPs of business partners, terminated employee accounts) for alerting or enrichment.
Create a Watchlist and join it with data in KQL queries.
Why: Watchlists act as a simple key-value store for custom data, easily used in queries for detection logic or to reduce false positives.
A successful KQL hunting query needs to be saved and operationalized for automatic detection.
1. Save the query in the Hunting blade. 2. Promote the hunting query to a scheduled Analytics Rule.
Why: Formalizes the transition from ad-hoc discovery (hunting) to automated, repeatable detection (analytics rule).
Assess detection coverage and identify gaps based on the MITRE ATT&CK framework.
Use the MITRE ATT&CK blade in Sentinel. Tag analytics rules with relevant tactics/techniques.
Why: Provides a visual heat map of detection capabilities mapped against the industry-standard framework, guiding detection engineering.
Preserve interesting results or evidence found during a hunt for later follow-up.
Create a Hunting Bookmark from the KQL query results.
Why: Captures the query, results, and entity context, allowing an analyst to save findings without immediately creating a full incident.