SC-200 cheat sheet

Microsoft Sentinel workspace roles: Sentinel Reader can view incidents and data; Sentinel Responder can also manage incidents; Sentinel Contributor can create and edit analytics rules, workbooks, and automation; Sentinel Automation Contributor lets playbooks run in the resource group.

Data connectors ingest via the Logs Ingestion API, Azure Monitor Agent (AMA) with Data Collection Rules, or service-to-service connectors; AMA replaces the legacy Log Analytics agent and supports Windows and Linux forwarders.

Analytics rule scheduling has three parts: query, query frequency (how often it runs), and lookback/period (how far back each run queries); the lookback must be greater than or equal to the query frequency to avoid gaps.

Alert grouping settings: group all alerts into a single incident, group alerts into multiple incidents by selected entities, or disable grouping; incident creation can be suppressed and alerts left ungrouped.

Entity mappings map query output columns to entity types (Account, Host, IP, URL, FileHash, Process, CloudApplication); mapped entities enable entity pages, entity-based grouping, and investigation graph.

Automation rules run on incident creation, update, or close triggers and can assign owners, change severity or status, add tags, or run a playbook; they run in the order set by their order number.

Playbooks are Azure Logic Apps in the same region as the Sentinel workspace; the Logic Apps connector authenticates as a service principal or managed identity with Sentinel Responder or Automation Contributor permissions.

Workbook and hunting query permissions follow the underlying Log Analytics workspace; data retention defaults to 30 days interactive for Analytics tier, with long-term retention available for search jobs and restore.

Watchlists upload CSV data into a _GetWatchlist() function usable in analytics and hunting queries; watchlist aliases are referenced in KQL as _GetWatchlist('alias').

Incident lifecycle statuses: New, Active, and Closed; closing classification is True Positive, False Positive, Benign, or Undetermined, and only True Positive or False Positive require a close reason field.

Incident tasks are checklist items tracked under an incident; they support status Open, Completed, or Deleted and are used to record response steps rather than to trigger automation.

Investigation (automated investigation) uses the entities mapped in the triggering alert to build an evidence graph and can trigger actions such as isolating a device or marking a user compromised.

Microsoft Defender XDR incident correlation merges related alerts across Defender products into one incident; manual incident creation and alert merging are supported in the Defender portal.

Live response in Defender for Endpoint requires the Live response capability enabled and an appropriate role; basic commands include cd, dir, getfile, putfile, run, and the advanced commands remediate, persist, and undo.

Device response actions: isolate device (full or selective with Outlook and Teams exceptions), restrict app execution, run antivirus scan, collect investigation package, and initiate automated investigation.

User response actions in Defender for Identity and XDR: force password reset, mark user as compromised, disable user, and confirm user as compromised or safe to reset risk state.

Evidence and entity verdicts in automated investigation are Pending action, Remediated, or Not remediated; approvals for pending actions are granted per action in the Action center.

Advanced hunting in Defender XDR uses tables such as DeviceEvents, DeviceProcessEvents, AlertInfo, and IdentityLogonEvents; results can be used to create custom detection rules that generate alerts and incidents.

KQL core operators: where filters rows, project selects columns, extend adds computed columns, summarize aggregates with by grouping, join merges tables, and union combines result sets.

Time filters use ago(), between, and the TimeGenerated column; a hunting query should bound the time range explicitly rather than relying on portal defaults for reproducibility.

summarize with make_set, make_list, dcount, arg_max, and arg_min builds entity profiles; arg_max(TimeGenerated, *) returns the latest row per group.

join kinds: innerunique (default, deduplicates left keys), inner, leftouter, rightouter, fullouter, leftanti, and leftsemi; leftanti returns left rows with no match and is the standard for finding missing coverage.

Sentinel hunting: run built-in or custom queries in the Hunting blade, bookmark interesting rows, and promote a bookmark to an incident or create a livestream query that alerts when results appear.

Microsoft Defender XDR advanced hunting schema prefixes: Device* for endpoint, Email* for email, Identity* for identity, CloudApp* for SaaS, and Alert* for alerts; each table has a documented retention window.

Anomaly and entity behavior analytics: Sentinel UEBA builds behavior profiles from watchlists and logs; anomalies surface in the Entities and UEBA tabs rather than as standalone alerts unless a rule references them.

Threat intelligence matching: the Threat Intelligence solution uploads STIX indicators via TAXII or the upload API, and matching analytics rules join TI indicators to log data by IP, domain, URL, or file hash.

Notebooks in Sentinel use Jupyter with the MSTICPy library; they run on a compute resource such as Azure Machine Learning and authenticate to the workspace through a configured mssparkutils or MSTICPy connection.