SC-200 cheat sheet — every exam topic on one page

Manage a security operations environment

Defender XDR Automation for SC-200: Email Notifications, Alert Tuning, Correlation, AIR and Attack Disruption

• Pick the setting by its job: notifications tell people, tuning filters alerts, correlation groups them, AIR and attack disruption respond.
• Incident notification rules set severity per service or detection source; 'Send only one notification per incident' stops per-alert emails; RBAC limits rules to the device groups the owner can manage.
• Action notification rules filter by source (Manual/Automated) and status (Completed/Failed) and don't support custom detections with response actions; threat analytics rules track all reports or a type or tag.
• Hide alert (Defender for Endpoint only) keeps data in AlertInfo/AlertEvidence and creates no incident; Resolve alert keeps a closed record; Set as behavior moves data to BehaviorInfo/BehaviorEntities and isn't for Defender for Cloud or Office 365.
• Tuning silences alerts but doesn't stop blocking: add an allow indicator. Built-in tuning rules don't touch custom detection or Custom TI alerts.
• Entra ID Protection alerts default to High-risk detections only; change it in Alert service settings.
• Analytics rules: tenant default plus Enabled/Disabled or #INC_CORR#/#DONT_CORR# at the start of the description; custom detections: included by default, with a per-rule Include/Exclude; only the primary Sentinel workspace correlates with Defender alerts.
• Incidents don't merge when one is closed, assignees or classifications differ, the entity limit is hit, or (if enabled) device groups differ; fix the blocker and merge manually.
• Email remediation always waits for approval and needs Security Administrator plus Search and Purge; since September 2026 Defender for Endpoint AIR can't be triggered manually, while Defender for Office 365 AIR remains.
• Attack disruption needs Standard discovery, Defender for Identity sensors and a capable action account, the full Microsoft 365 connector and five mailbox audit events; Semi doesn't exclude a device group, No automated response does.

SC-200 Configure Microsoft Defender for Endpoint: Advanced Features, ASR Rules, Device Groups and Roles

• Indicators, ASR rules, network protection and allow or block file all need Defender Antivirus in active mode; EDR in block mode helps passive mode but enforces none of them.
• Restrict correlation to within scoped device groups gives each local SOC its own incident, but only for alerts correlated after the change.
• Live response for servers and unsigned script execution are separate toggles; running library scripts needs the Advanced live response permission.
• Certificate indicators allow Allow or Block and remediate only, and cover every file signed with that certificate.
• Outside Microsoft Edge, network indicators and web content filtering need network protection in block mode, and domain blocking needs QUIC and Encrypted Client Hello off.
• With overlapping web content filtering policies the most restrictive wins; an Allow indicator scoped to a device group unblocks one site.
• Custom data collection needs Plan 2 and a connected Sentinel workspace, targets dynamic tags only, and caps each rule at 75,000 events per device per rolling 24 hours.
• Audit ASR rules first (ActionType Asr…Audited in DeviceEvents); the LSASS rule ignores antivirus file and folder exclusions, so use an ASR exclusion.
• Security settings management: Enforcement scope with tagged devices and MDE-Management for a pilot, policies targeted at Entra groups on the Windows platform.
• A device joins only its highest-ranked group (rank 1 wins); a group with no user access assigned is open to everyone; turning on RBAC locks out Security Readers until they get a role.

SC-200 Microsoft Sentinel Automation: Automation Rules and Playbooks

• Use an automation rule's native actions (owner, status, severity, tags, tasks) before reaching for a playbook; playbooks are Logic Apps workflows with run charges.
• The alert trigger offers only Run playbook and is the choice when an analytics rule doesn't create incidents; the rule's trigger must match the playbook's trigger.
• Equals tests the current value; Changed to fires once at the transition. Exclude Updated by Playbook to stop update rules re-triggering themselves.
• Use a Condition group (Or) for either-of-two properties, and Collection of all tags for negative tag conditions.
• Rules run sequentially by order; later rules see earlier changes, update rules wait for create rules, and a rule moves on two minutes after a playbook starts.
• An expiration date ends time-boxed suppression automatically; task order follows creation order, and only playbooks can mark tasks complete.
• After Defender portal onboarding: no Incident provider or Description, avoid titles (use analytic rule name), alert trigger covers Sentinel alerts only, quick changes are batched; use the Enhanced Alert Trigger for Defender alerts.
• Greyed out in the drop-down = Sentinel's service account needs Microsoft Sentinel Automation Contributor on the resource group (granted by Owner or User Access Administrator); not listed = wrong trigger.
• Playbook Operator runs playbooks without editing; a playbook's managed identity needs Responder to write or Reader to read.
• Standard logic apps: no templates, stateful only, and an access restriction policy with private endpoints. Rule runs log to SentinelHealth; playbook outcomes to AzureDiagnostics.

SC-200 Microsoft Sentinel Platform: Roles, Data Tiers, Retention, Workbooks and SOC Optimization

• Sentinel roles are cumulative: Reader views, Responder adds incident management, Contributor adds creating content and installing Content hub solutions.
• Reader or Responder plus Workbook Contributor lets someone save workbooks without other write rights; guests who assign incidents also need Entra Directory Readers.
• Assign Sentinel roles on the workspace's resource group; at resource scope, assign both the workspace and its SecurityInsights solution. Extra assignments never subtract rights.
• Data lake access comes from Entra roles: Security Reader to read across all workspaces, Security Operator to create jobs and write to tables.
• Analytics retention (30 days to 2 years) is the hot window; total retention (up to 12 years) keeps older data cheaply in the lake, still queryable from Sentinel.
• The Data Lake tier stops analytics rules, alerting, advanced hunting and custom detections; search jobs, KQL and Spark jobs and summary rules still work.
• XDR tables: 30 days by default; up to 90 days of analytics retention charges ingestion but not storage; resetting to 30/30 stops Sentinel ingestion.
• Shortening total retention waits 30 days before deleting; analytics retention changes apply immediately.
• Workbook templates come from Content hub solutions; Save creates a JSON-only workbook you edit; print and PDF need Open in Azure.
• SOC optimization: data value flags billable tables unused by detections in 30 days (UEBA and TI matching tables exempt); dismiss what you won't act on.

SC-200 Windows Security Events in Microsoft Sentinel: AMA, DCRs and WEF

• Windows Security Events via AMA writes to SecurityEvent, the table built-in Windows security rules query; Windows Forwarded Events via AMA writes to WindowsEvent.
• The Log Analytics agent (MMA) is retired; the Security Events via Legacy Agent connector is replaced by Windows Security Events via AMA.
• Non-Azure servers must be Azure Arc-enabled before an AMA connector can target them; the wizard installs AMA where it's missing.
• Wizard selections create associations with the machines present at that time; use the built-in Azure Policy initiative plus remediation to cover future and existing VMs.
• Common keeps a full audit trail (sign-in and sign-out); Minimal is a breach-detection subset without sign-outs; no pre-built set reads the System log.
• Custom filters are LogName!XPath, XPath 1.0 subset only (no contains or starts-with); test with Get-WinEvent -FilterXPath; use a DCR transformation for substring filters.
• A generic Azure Monitor DCR sends Security log events to Event; the stream Microsoft-SecurityEvent sends them to SecurityEvent.
• Overlapping DCR associations or MMA and AMA side by side double ingestion: remove the extra association or uninstall MMA after validating AMA.
• WEF sources need the collector URI, WinRM and Network Service in Event Log Readers; only the collector runs AMA.
• Domain WEF is Kerberos-encrypted even over HTTP; use HTTPS with certificates for non-domain machines; plan about 3,000 events per second per collector.

SC-200 Sentinel Data Ingestion: Syslog, CEF, Azure Activity, Threat Intelligence and Custom Logs

• CEF via AMA parses CEF into CommonSecurityLog; Syslog via AMA stores plain syslog as text in the Syslog table.
• A forwarder must be an Azure VM or an Azure Arc-enabled server, and you must run Forwarder_AMA_installer.py so it listens on port 514 (UDP and TCP); the daemon hands off to AMA on local TCP 28330.
• The connector page sets a minimum log level per facility (that level and everything more severe); exact severity lists need the DCR API or JSON.
• Fix Syslog/CEF duplication by giving CEF its own facility or by filtering CEF out of the Syslog DCR on both ProcessName and SyslogMessage.
• The Azure Activity connector uses an Azure Policy assignment that creates diagnostic settings; it needs Owner on the assignment scope, and legacy connections must be disconnected first.
• Policy-managed diagnostic settings cover future resources automatically; existing resources need a remediation task.
• Diagnostic settings-based connectors show connected only if data arrived in the past 14 days.
• The upload API pushes any STIX object with an Entra app holding Microsoft Sentinel Contributor; TAXII is pulled by Sentinel from published Microsoft IPs.
• Ingestion rules (Delete, Edit) apply only to data connectors, and indicators now live in ThreatIntelIndicators; the legacy table stopped receiving data after July 31, 2025.
• Custom tables end in _CL and need a datetime TimeGenerated; the Logs Ingestion API needs Monitoring Metrics Publisher on the DCR, and a DCE only for private link.

SC-200 Configure Detections: Defender XDR Custom Detections, Sentinel Analytics Rules, MITRE ATT&CK and Anomalies

• Custom detection queries return Timestamp (or TimeGenerated); on Defender for Endpoint tables also DeviceId and ReportId, kept through aggregations with arg_max.
• Fixed custom detection frequencies have fixed lookbacks: 24 h → 30 days, 12 h → 48 h, 3 h → 12 h, 1 h → 4 h; Custom (run every 5 minutes to 14 days, with a separately configured lookback) is only for Sentinel-only data.
• Continuous (NRT) custom detections need one supported table and no joins, unions, externaldata or comments; they aren't bound by the 50-rule NRT analytics cap.
• Email actions need NetworkMessageId and RecipientEmailAddress; Isolate device cuts networking, Restrict app execution keeps it but runs only Microsoft-signed code.
• Security Operator can manage custom detections only with MDE RBAC off, or with Manage security settings added when it's on; editing needs permission for every device in the rule's scope.
• Custom detections create at most 150 alerts per run; titles take up to three {{Column}} references; custom details are 20 pairs and 4 KB per alert, dropped whole when exceeded.
• Scheduled rules: interval and lookback 5 minutes to 14 days, lookback ≥ interval; suppression up to 24 hours; handle ingestion delay with a longer lookback plus an ingestion_time() filter.
• NRT analytics rules run every minute on ingestion time, 50 per customer, and suit sources with under 12 hours of ingestion delay.
• Matching analytics uses Microsoft's domain, IP and URL indicators and can't be customized; TI map templates (Threat Intelligence solution) match your own indicators and are editable.
• After Defender portal onboarding, Microsoft security and Fusion rules aren't available; anomaly rules write to the Anomalies table and are tuned through a single Flighting copy.

Respond to security incidents

Investigating and Remediating Defender XDR Alerts for SC-200: Office 365, Purview, Defender for Cloud, Cloud Apps, Entra ID and Defender for Identity

• Soft delete hides a message from every folder but stays recoverable by the user; hard delete leaves only admin recovery. Without Search and Purge, add to remediation and approve on the Action center Pending tab.
• AIR in Defender for Office 365 Plan 2 starts from the default alert policies; disabling or replacing one with a custom copy stops its investigations, while built-in tuning rules don't.
• Submission blocks default to 30 days (choose Never expire to keep them); false-positive allows last 45 days after last use; spoofed-sender allows never expire; impersonation false positives need Trusted senders and domains.
• After a password reset, still revoke sessions, replace app passwords and check hidden inbox rules and Forwarding* settings; unblock a 5.1.8 sender on Restricted entities.
• Attack disruption marks its work with the Attack Disruption tag; disabling an AD account needs Defender for Identity sensors on domain controllers, a cloud-only user doesn't.
• DLP signals became behaviors in BehaviorInfo in October 2026 until the built-in DLP tuning rule is disabled; an insider risk alert resolved as True positive shows Confirmed in Purview.
• In Defender for Cloud, dismiss closes one alert and a suppression rule stops similar ones; informational alerts never reach Defender XDR and Defender for Endpoint alerts on cloud resources don't sync status.
• Require user to sign in again ends sessions, Confirm user compromised raises risk to High, and Suspend user blocks access but is reverted for synced users.
• Dismiss user risk needs Security Operator; a temporary password from ID Protection needs Security Operator plus User Administrator; on-premises password changes clear risk only with PHS and the opt-in setting.
• Defender for Identity Active Directory remediation runs only from domain controller sensors using the local system account, while Entra ID actions run through a Microsoft-managed enterprise app; Excluded entities tune classic alerts and alert tuning rules tune Defender-format ones.

SC-200 Sentinel Incidents, Security Copilot, Multistage Attacks and Case Management

• Onboarded Sentinel incidents are worked in Investigation & response > Incidents & alerts > Incidents; Azure portal support for Sentinel ends after March 31, 2027.
• Microsoft incident creation rules don't work in the Defender portal: use alert tuning or automation rules, and don't key automation on incident titles once Defender XDR names incidents.
• Synced Defender XDR incidents cap at 150 alerts in Sentinel (shown as 150+ with a link); False positive maps to False Positive – Inaccurate data.
• The investigation graph needs entity mappings and handles incidents up to 30 days old; the Entities tab timeline covers seven days, the full entity page any range.
• In the Defender portal you run playbooks on incidents only; Grant permission means an Owner or User Access Administrator must give Sentinel Automation Contributor on the resource group.
• Incident summary = the attack (cached a week, configurable by severity); incident report = the response, best generated after resolving, with reasoning in activity-log comments.
• Triage agents resolve false positives and leave true positives open; use an Entra Agent ID, because a user identity can't use PIM or TAP; feedback teaches only via Use this feedback to teach the agent.
• Fusion needs tactics and entity mappings on scheduled rules and is replaced by the Defender XDR correlation engine after onboarding.
• Lateral movement out of a host: filter DeviceLogonEvents on RemoteDeviceName; PsExec and shares are Network logons. Blast radius needs the data lake, Exposure management (read) and classified critical assets.
• Case management is Defender-portal only; resolved incident cases can't merge, alerts are moved rather than removed, and SLA pause, recalculation and At Risk emails are configured on the policy plus a Case updated automation rule.

SC-200 Defender for Endpoint Response: Device Timelines, Live Response, Isolation and Attack Disruption

• The device timeline shows 30 days by default, but a detailed export covers at most seven days; flag events and use the Flagged events filter to isolate an attack chain.
• Hunt for related events opens advanced hunting around one event on the same device; from a technique entry it returns related events but not the technique itself.
• Isolate cuts an onboarded device off while keeping its Defender connection; Contain makes other devices block an unmanaged one; Restrict app execution allows only Microsoft-signed code and leaves networking alone.
• Plan 1 includes only antivirus scan, isolate, stop and quarantine, and file indicators; packages, live response, app restriction and containment need Plan 2.
• Offline isolation retries for three days, then must be reissued; proxies and full-tunnel VPNs call for selective isolation and split tunnelling.
• Live response runs scripts only from the library, must be enabled in Advanced features, cancels with Ctrl+C only in the portal, and allows one session per device, five per user and 50 per tenant, with getfile capped at 3 GB.
• Stop and quarantine reaches devices that saw the file in 30 days and times out after 3 days; add a block indicator for lasting enforcement.
• Alerts investigation covers file actions on PE files only; Live response advanced covers PE and non-PE files.
• Contain user (attack disruption or predictive shielding) blocks network logons, RPC, SMB and RDP on endpoints but doesn't disable the account; it lifts within five days or with Undo in the Action center (Global Administrator).
• DeviceEvents logs what containment blocked; DisruptionAndResponseEvents lists the disruption actions themselves.

SC-200 Microsoft 365 Investigations: Purview Audit, Content Search and Graph Activity Logs

• Audit records activity, Content search finds content, Graph activity logs record Graph API calls: match the tool to the question.
• View-Only Audit Logs is least privilege for audit search; assign it in the Exchange admin center too for Search-UnifiedAuditLog.
• UnifiedAuditLogIngestionEnabled is reliable only in Exchange Online PowerShell; Security & Compliance PowerShell always shows False.
• Audit (Standard) keeps 180 days; the one-year default needs an E5 user and an Entra ID, Exchange, OneDrive or SharePoint record.
• Custom retention policies beat the default even when shorter, lower priority numbers win, and changes are never retroactive.
• Audit search jobs run on after the browser closes, last 30 days, allow one unfiltered job, and usually lag 60 to 90 minutes.
• MailItemsAccessed is in Audit (Standard); a Sync record means assume the whole folder was taken, and SessionId plus ClientIPAddress separate attacker from owner.
• SIEM feed = Office 365 Management Activity API (7-day content window); REST search = Graph auditLogQuery; scripts = Search-UnifiedAuditLog in Exchange Online PowerShell.
• KeyQL: space is OR, operators uppercase, quote multi-word values, prefix-only wildcards, trailing slash for site-only paths.
• Search and purge needs Search And Purge in Purview, removes 10 items per mailbox per run (100 via Graph in premium cases), and fails over 50,000 searched mailboxes.

Perform threat hunting

Detecting Threats with Microsoft Defender XDR for SC-200: Advanced Hunting Tables, KQL, Threat Analytics, Hunting Graphs and Sentinel Graph

• Pick the table by the event: DeviceProcessEvents for launches, DeviceRegistryEvents for registry writes, DeviceLogonEvents for device sign-ins (including local accounts), IdentityLogonEvents for AD authentication on domain controllers.
• IdentityQueryEvents is reading AD objects; IdentityDirectoryEvents is changing them; IdentityInfo holds account attributes such as Department.
• Prefer has over contains for whole terms, and =~ / in~ for file names whose case varies; _cs operators are case-sensitive.
• A join without kind is innerunique and drops duplicate left rows; use kind=inner to keep them, leftanti for 'never seen before' baselines, smaller table left and time filters on both sides.
• FileName and ProcessCommandLine are the new process; InitiatingProcess* is its parent; identify an instance by ProcessUniqueId, or by device + process ID + creation time.
• Advanced hunting covers 30 days of native data (longer via onboarded Sentinel analytics-tier retention, never the data lake tier), works in UTC, and caps results by rows, 64 MB and a tenant CPU cycle.
• Take actions needs identifier columns: DeviceId for devices, a hash plus DeviceId for quarantine, a SID and/or AccountObjectId for users, the message and recipient identifiers for email actions, plus EmailDirection and SenderFromAddress for Delete email.
• In threat analytics, Impacted assets is driven by alerts, Endpoints exposure by vulnerabilities and misconfigurations (with update deployment status), and Recommended actions lists only Secure Score-tracked items.
• Hunting graph and blast radius need the Sentinel data lake and Exposure Management read access; custom graphs live for a session, 30 days (on-demand job) or on a refresh schedule, and are queried with GQL.

Detecting Threats on the Microsoft Sentinel Platform for SC-200: Hunting Queries, Bookmarks, Hunts, KQL Jobs, Summary Rules, Notebooks and the MCP Server

• N/A on the Hunting page means the query's data source isn't connected; 0 means it ran and found nothing.
• Results delta and delta percentage always compare the last 24 hours with the 24 to 48 hours before; sort by percentage to surface small queries that suddenly multiplied.
• Only custom-source hunting queries are editable: clone Content hub queries, and edit repository queries in the repository.
• Bookmarks inherit the query's entity and MITRE mappings, land in the HuntingBookmark table, and exist only in the Sentinel hunting experience, not in advanced hunting.
• Hunt queries are independent clones; create analytics rules from a hunt's Queries tab and TI indicators from its Entities tab.
• Livestream is gone: KQL jobs persist results, analytics rules alert, automation rules with playbooks notify.
• KQL job output: _KQL_CL in a Sentinel workspace (analytics), _KQL in System tables (lake); appends need a matching schema.
• KQL jobs: start at least 30 minutes out, editing a one-time job reruns it, five concurrent per tenant (extra jobs rejected), no externaldata(), arg(), adx(), ingestion_time() or UDFs.
• Summary rules aggregate only recent data (bins up to 1,440 minutes), cost a data scan on low-cost sources plus Analytics ingestion, and are monitored through LASummaryLogs.
• Notebooks: _SPRK lake / _SPRK_CL analytics (append only), Synapse and Sentinel provider libraries only; the MCP server needs Security Reader, plus Security Copilot Contributor for entity analyzers.