SC-200 Cheat Sheet

Alert notification rules in the Defender portal (Settings > Endpoints > Email notifications) mail named recipients when a Defender for Endpoint alert is generated, scoped by a minimum alert severity and by device group. Set the minimum to high so an on-call list pages only on serious alerts instead of drowning in informational and low events. The rule controls only the outbound email, so a missing notification is a rule problem while a missing alert is a detection or licensing problem.

Vulnerability notification rules fire on vulnerability events and are created on the Vulnerabilities tab of the Defender portal email notifications page (Settings > Endpoints > General > Email notifications > Vulnerabilities); the events themselves come from Microsoft Defender Vulnerability Management. The event types are New vulnerability found (with a severity threshold), Exploit was verified, New public exploit, and Exploit added to an exploit kit, and one rule can select several, scoped by device group. They are configured separately from alert notification rules and never carry endpoint alerts. Reach for one whenever the requirement is to be told when a CVE becomes exploitable or a new exploit appears.

Trap Choosing an alert notification rule to be told about a new public exploit; exploit and exposure events come only from a vulnerability notification rule on the Vulnerabilities tab of the Defender portal email notifications.

Advanced features under Settings > Endpoints in the Defender portal are on/off switches that apply to the whole tenant, so flipping one changes behavior everywhere rather than on a single device or group. When an expected capability such as live response or an integration signal is missing, check these toggles first. A disabled feature silently removes the capability a playbook assumes, which is the common cause of an automatic action that never ran.

Trap Treating Advanced features as a per-device or per-group setting; they are tenant-scoped, so a device-level config change will not enable them.

Automated investigation and response is enabled by default: Microsoft removed the old Automated investigation toggle from Advanced features, so there is no tenant-wide master switch to turn AIR on or off. What you configure instead is each device group's automation level, which decides how far AIR remediates, from No automated response (AIR does not run on that group) up to Full automation. So a group seeing no automated investigation points at its automation level being No automated response, not at a missing feature toggle.

Live response, and the separate Live response for servers toggle, must be enabled in Advanced features before a responder can open a remote investigation shell on a device. A further Live response unsigned script execution toggle controls the riskier ability to run unsigned scripts. Enabling these is a prerequisite for the hands-on response actions an analyst expects during an investigation.

Tamper protection stops attackers, and even local administrators, from turning off Defender for Endpoint protections such as real-time protection or removing the agent. It is the control that keeps an attacker who gains admin on a host from simply switching the EDR off before acting. Treat it as a baseline hardening toggle that should stay on.

EDR in block mode is an Advanced feature that lets Defender for Endpoint block and remediate malicious artifacts even when a third-party antivirus is the primary protection and Microsoft Defender Antivirus is in passive mode. It is the way to add behavioral blocking behind another vendor's AV rather than replacing it. Without it, Defender for Endpoint in passive mode detects but does not block.

Endpoint indicators (file hash, IP, URL/domain, certificate) are built under Settings > Endpoints > Rules with an action of Allow, Audit, Block, or Warn, and they both allow-list known-good artifacts and add custom blocks. Custom network indicators (IP/URL/domain) take effect only when the matching Custom network indicators Advanced feature is on. So a block that is not taking effect is usually the feature toggle, not the indicator itself.

Trap Assuming a newly created network indicator blocks immediately; URL/IP indicators do nothing until the Custom network indicators Advanced feature is enabled.

The automation level that governs how far automated investigation and response remediates is configured per device group, so different groups can run at different levels. There is no single tenant-wide automation level. Raising autonomy for one population means changing that group's automation level, which is why a fix for an unresponsive group targets the group, not a global setting.

Trap Looking for a single tenant-wide automation level; the level is a per-device-group property, so you change it on the group.

Full automation applies AIR remediations automatically with no approval gate and is the recommended setting and the default for newly onboarded tenants, because automatically remediated alerts are handled accurately and it frees analysts for hard incidents. The semi-automation levels (require approval for all folders, for core folders, or for non-temp folders) hold some or all remediations for analyst approval. Older tenants may sit at a semi level and need raising to go hands-off.

Trap Assuming a new tenant starts at semi-automation or no automation; full automation is the default for newly onboarded tenants.

Setting a device group to the No automated response automation level means AIR does not run on that group at all, even with Automated investigation enabled tenant-wide. It is distinct from semi-automation, where AIR runs and proposes actions that wait for approval. A group whose alerts never see any automated investigation is most likely on No automated response.

Under any semi-automation level, AIR's proposed remediations land as Pending actions in the Action center, where an analyst approves or rejects them; nothing is applied until approved. So remediations piling up unactioned mean the group is on a semi level and the approval queue is not being worked, fixed by working the Action center or by raising the group's automation level. The Action center is the single approval queue across automated actions.

Trap Re-tuning detections when remediations are sitting unactioned; the cause is an unworked semi-automation approval queue, not a detection gap.

Approved and fully automated remediations move to the Action center History tab, where an analyst can undo them, for example releasing a file from quarantine or reversing an action that turned out to be a false positive. That reversibility is the safety net that makes full automation acceptable, since a wrong automatic action can be rolled back. The same undo model applies to attack disruption actions recorded in the incident.

Automatic attack disruption correlates high-confidence signals across endpoints, identity, email, and SaaS into one incident and automatically contains the attack while the analyst still investigates, acting at the incident level. AIR, by contrast, investigates and remediates one alert's evidence on covered devices. The tell that a scenario is disruption rather than AIR is incident-wide containment of an attack in motion, not cleanup of a single alert's files.

Trap Calling fast, hands-off incident containment AIR; AIR remediates one alert's artifacts, whereas attack disruption contains an in-progress attack across the whole incident.

Automatic attack disruption only triggers on a narrow set of high-confidence scenarios such as human-operated ransomware, business email compromise, and adversary-in-the-middle, because the cost of a wrong automatic containment is high and these are where speed matters most. It is on by default and is not a detection an analyst hand-tunes. A scenario describing one of these attacks contained within minutes with no human action is describing attack disruption.

Automatic attack disruption's automatic actions are a fixed, narrow set: device containment (Defender for Endpoint isolates the device from the network), disable user (a compromised Microsoft Entra ID account is turned off), and contain user (identity actions are blocked on managed devices). These are response actions, not detections, and each is recorded in the incident so it can be reviewed and manually reversed once the situation is confirmed.

Automatic attack disruption's disable-user action is built on Microsoft Defender for Identity's remediation capability. To disable an on-premises Active Directory account, the Defender for Identity sensor must be deployed on a domain controller. Disabling a cloud-only Microsoft Entra ID account, however, is not dependent on Defender for Identity being deployed, Defender for Identity executes it in Entra ID through a Microsoft-managed enterprise application. Device containment relies on Defender for Endpoint instead.

Trap Assuming disable-user can never work without a Defender for Identity sensor; an on-premises AD account does need the sensor on a domain controller, but a cloud-only Entra ID account can be disabled without Defender for Identity deployed.

When a critical identity such as a break-glass or service account must never be auto-disabled, exclude that specific user from automatic attack disruption rather than turning the feature off for the whole tenant. Exclusions scope the protection so high-value automation stays on for everyone else. Disabling disruption tenant-wide to protect one account throws away the containment benefit for every other user.

Trap Turning off automatic attack disruption tenant-wide to protect one service account; exclude that user instead so disruption still covers everyone else.

Several Advanced features are integration connectors rather than capabilities, including Microsoft Defender for Cloud Apps and the Microsoft Defender for Identity integration. A connector left off is a silent gap because the signal simply never flows into Defender XDR, so onboarding a new Defender product almost always includes turning its connector on here. An expected cross-product signal that never appears points at a disabled connector toggle.

When the auto-resolve alerts feature in Defender for Endpoint advanced features closes an alert after an automated investigation finishes, it skips any alert whose status a SecOps analyst already set manually to 'In progress' or 'Resolved'. The manual status takes precedence and is preserved.

Trap It is not re-resolved or reset to a new status by the automated investigation verdict.

On a subscription's Environment settings > Email notifications page, the alert-severity threshold and the attack-path risk-level threshold are configured independently, and each notifies at the chosen level or higher. By default, with no changes, subscription Owners receive high-severity alert and attack-path notifications.

Trap Setting only the alert-severity threshold does not turn on attack-path notifications — the attack-path risk level is a distinct setting.

Microsoft Sentinel (formerly Azure Sentinel) is enabled on top of an Azure Monitor Log Analytics workspace, and that workspace stores all of Sentinel's logs, incidents, and analytics results. There is no separate Sentinel data store, so every workspace design choice about region, access, and retention is really a Log Analytics decision. A single workspace can host only one Sentinel instance.

Trap Treating Sentinel as its own database you can repoint later; the backing Log Analytics workspace and its region are fixed once data flows in.

Microsoft's design guidance is to consolidate into the fewest workspaces you can, because analytics rules, incident correlation, hunting, and the investigation graph all work natively within one workspace and cost less than cross-workspace plumbing. Add a workspace only when a hard boundary forces it: a data-residency region, a separate Microsoft Entra tenant, or an ownership, chargeback, or compliance isolation requirement. Cross-workspace queries handle the rare cases where you must read across more than one.

Trap Spinning up one workspace per region or team by default; it multiplies rules and queries and is only justified by an actual residency, tenant, or isolation boundary.

A Log Analytics workspace lives in a single Azure region and its ingested data is stored in that region, and it is tied to one Microsoft Entra tenant. Choose the region to satisfy data residency and to sit close to your sources, because cross-region transfer adds cost. A single workspace cannot meet two conflicting regional residency rules, which is one of the few legitimate reasons to run more than one.

When one SOC or MSSP must monitor several Microsoft Entra tenants, keep a separate workspace per tenant and grant delegated access with Azure Lighthouse, then run cross-workspace queries for a single view. A workspace cannot span tenants, so merging tenants into one shared workspace is not possible and would break each tenant's isolation boundary.

Trap Collapsing multiple tenants into one shared workspace to simplify access; a workspace is bound to one tenant, so Lighthouse delegation is the supported cross-tenant path.

Permissions for Microsoft Sentinel are Azure role-based access control assigned at the workspace or its resource group, and they combine rather than replace each other. A user typically needs a Sentinel-specific role for incidents and analytics plus a Log Analytics read role for the underlying tables, because the Sentinel roles grant rights on Sentinel constructs while the events live in Log Analytics. Assign roles at the workspace or resource group scope so the grant covers Sentinel and nothing wider.

Trap Assuming a single Sentinel role grants everything; without a Log Analytics read role the analyst cannot read the raw event tables behind the incidents.

The Microsoft Sentinel Reader role lets a user view data, incidents, workbooks, and other Sentinel resources but change nothing. Use it for auditors or stakeholders who need visibility without the ability to act, and pair it with a Log Analytics read role so they can also query the underlying logs.

The Microsoft Sentinel Responder role adds incident management on top of Reader: assigning incidents, changing status and severity, and adding comments. It is the least-privilege answer for a SOC analyst who must triage and resolve incidents but should not edit analytics rules. Grant Responder plus a Log Analytics read role rather than the broader Contributor or subscription Owner.

Trap Granting Sentinel Contributor to an analyst who only triages incidents; Contributor also lets them create and edit analytics rules and content, breaking least privilege.

The Microsoft Sentinel Contributor role adds the ability to create and edit analytics rules, workbooks, and other Sentinel content on top of everything Responder can do. Reserve it for the engineers who build detections, not for analysts who only work incidents. It still does not grant the subscription or resource-group Contributor rights needed to first enable Sentinel.

The Microsoft Sentinel Playbook Operator role lets a user list, view, and manually run playbooks, kept separate so you can let an analyst trigger a playbook without giving them rights to edit detections or content. Because a playbook is a Logic App, creating or editing one also requires Logic App Contributor on the playbook's resource group. The related Microsoft Sentinel Automation Contributor role is assigned to Sentinel's own service identity so automation rules can run playbooks, not to people.

Trap Granting Contributor just so someone can run a playbook; Playbook Operator (plus Logic App Contributor on the playbook resource group to edit it) is the least-privilege answer.

To enable Microsoft Sentinel on a workspace and connect data, you need Contributor on the subscription or the resource group that holds the workspace, and individual data connectors can require extra permissions per their connector docs. These are install-time, configuration rights; once Sentinel is running, scope people down to the narrow Reader, Responder, or Contributor roles for day-to-day work. Specifying which Azure RBAC role enables versus operates Sentinel is a core blueprint task.

Trap Expecting Sentinel Reader or Responder to be able to onboard Sentinel; those are operate-time roles and cannot stand the workspace up.

Each table has a plan, and the Analytics tier is fully indexed and is the only tier that drives standard scheduled analytics rules, the investigation graph, and the full KQL experience, at the highest ingestion cost. Keep security-relevant tables such as sign-ins, Defender alerts, and security events on Analytics so detections and hunting work. Moving such a table to a cheaper tier to save money silently breaks the rules that depend on it.

Trap Putting a table a scheduled analytics rule queries onto the Basic or Auxiliary tier; those tiers do not drive standard scheduled rules, so the detection stops firing.

Basic logs are a lower-cost tier for high-volume data you query occasionally, with queries billed per query and a reduced KQL surface; Auxiliary logs are the lowest-cost tier for verbose, low-value telemetry such as raw network or firewall logs you rarely touch. Both default to a 30-day total retention, but they behave differently when you query: Basic tables have a fixed 30-day query window, while Auxiliary tables can be queried across their whole total retention period. Route noisy, rarely-queried sources here to control ingestion cost while keeping security tables on Analytics.

Trap Leaving verbose firewall or network logs on the Analytics tier with long interactive retention; the right cost move is Basic or Auxiliary plus long-term archive.

Log retention has two consecutive stages. Interactive (analytics) retention keeps data fully and instantly queryable with KQL; Analytics tables can be kept interactively up to 2 years (730 days), while Basic tables have a fixed 30-day query window and Auxiliary tables are queried across their total retention. After the analytics period, long-term (archive) retention keeps the data cheaply for up to 12 years total (the combined analytics-plus-long-term ceiling). Set both per table so a verbose source can have short interactive plus long archive.

Trap Confusing interactive retention with the total ceiling; interactive caps at 2 years for Analytics, while long-term retention extends the combined total to 12 years.

Archived (long-term) data is not interactively queryable. To use it you run a search job against the archive, or restore a table for a time window back into the interactive tier where normal KQL works again. This in-workspace archive plus search job is the native way to meet multi-year audit requirements, rather than exporting logs to a storage account.

Trap Reaching for an export-to-storage-account pattern to retain logs for compliance; in-workspace archive retention with a search job or restore is the built-in answer.

When a workspace has Microsoft Sentinel enabled, the first 90 days of data retention are free for all data ingested into the workspace, on top of the ingestion charge. A 90-day interactive window therefore adds no retention cost, which is why a common requirement of "searchable for 90 days, then retained for years" maps cleanly to free interactive retention plus paid archive.

Retention is configured per table, layered over a workspace-level default you can override table by table. That lets a noisy audit log sit on a cheap tier with a long archive for compliance while alert tables stay on Analytics with months of interactive history. Designing this table-by-table data storage and retention is an explicit SC-200 blueprint task.

When sources fall under different regional data-residency rules, or two business units must not see each other's data, create separate workspaces for that boundary rather than one shared workspace, because a residency or isolation boundary cannot be legally crossed by consolidating. Use cross-workspace KQL queries to investigate across them when needed. Centralization is still the default; only the hard boundary justifies the split.

Trap Using a single shared workspace across a residency or data-isolation boundary to simplify queries; cross-workspace queries are the right tool, not collapsing the boundary.

Microsoft recommends deploying the Sentinel workspace into a dedicated resource group and assigning the built-in Microsoft Sentinel roles at that resource-group scope. Permissions are then assigned once and apply automatically to all dependent resources (the workspace, playbooks, workbooks), minimizing ongoing role-management effort.

Trap Assigning at the workspace scope leaves playbooks/solution resources uncovered and creates more assignments to manage.

If you assign a Sentinel role directly on the workspace instead of on the resource group, some Sentinel features break unless you also assign the same role on the SecurityInsights solution resource in that workspace (and potentially other dependent resources).

Trap This extra assignment is unnecessary when you assign at the resource-group scope, which is why RG-scope is the recommended pattern.

A Microsoft Sentinel scheduled analytics rule runs a KQL query against the workspace tables on a frequency you set, reads a lookback window of data, and raises an alert when the result count crosses a threshold. It is the rule type you reach for whenever you author detection logic yourself, because you control the query, the cadence, the threshold, entity mapping, and the response. Align the lookback to the run frequency so events between runs are neither missed nor double-counted.

Near-real-time rules are a constrained subset of scheduled rules that run once every minute, the lowest latency Sentinel offers for query-based detection. Choose NRT only when the requirement is sub-minute detection, because it carries feature limits a full scheduled rule does not, such as a maximum of 50 NRT rules per workspace and producing up to 30 single-event alerts per run. For ordinary detection where a few minutes is fine, a scheduled rule is the right default.

Trap Setting a scheduled rule to a very short interval to fake real time; NRT is the purpose-built once-a-minute rule type, and a short scheduled interval still incurs scheduled-rule latency.

An anomaly analytics rule uses machine learning to learn a baseline over an observation period, then flags behavior outside that baseline, but it does not generate its own alerts; it records findings in the Anomalies table for you to query and join into detections. You cannot edit a built-in anomaly rule directly, so to tune one you duplicate it, run the copy in Flighting mode alongside the original in Production, then promote the copy if you like the results.

Trap Expecting an anomaly rule to drop alerts into the incident queue; it populates the Anomalies table, and you bring that context into other rules or hunts.

A Microsoft security analytics rule creates Microsoft Sentinel incidents in real time from alerts that other Microsoft solutions generate, since externally generated alerts do not create their own incidents. The decisive caveat: this rule type is unavailable, and existing ones auto-disable, once you enable Defender XDR incident integration or onboard Sentinel to the Defender portal, because Defender XDR then creates the incidents itself.

Trap Choosing a Microsoft security rule to create incidents when Defender XDR incident integration is already on; that rule type is disabled in that state and XDR makes the incidents.

Advanced multistage attack detection, the Fusion engine, uses scalable machine learning to correlate low-fidelity alerts and events across multiple products into a small number of high-fidelity, actionable incidents. It is enabled by default, runs as a single non-editable instance because its logic is hidden, and like the Microsoft security rule it is unavailable once Defender XDR incident integration is enabled.

Trap Reaching for a scheduled rule to tie together alerts from several products into one incident; cross-product multistage correlation is exactly what Fusion does automatically.

An entity is a data element Sentinel recognizes as a known type, such as Account, Host, IP, URL, File, File hash, Process, or Mailbox, which lets it correlate that element across every alert and surface it in the investigation graph and entity pages. In the Defender portal entities split into assets (internal protected objects like accounts and hosts) and other entities or evidence (external indicators like IPs, files, and URLs).

A strong identifier names an entity uniquely on its own, such as an Entra account's GUID or its User Principal Name (UPN); a weak identifier like a bare username or NTDomain is reliable only in context, though several weak identifiers can combine into a strong one. This matters because Sentinel merges two alerts that share a strong identifier into one entity, so the user correlates across data sources; identify a user by a weak identifier alone and the same person fragments into separate, uncorrelated entities.

Trap Mapping a user by username only when a UPN or GUID column is available; the bare username is a weak identifier and Sentinel cannot reliably merge it across sources.

Entity mapping in a scheduled rule binds query columns to entity types via identifiers. The testable limits: up to 10 entity mappings per rule, up to 3 identifiers per mapping with at least one required, and at most 500 entities collectively per alert, divided across the mappings, inside a 64 KB entities field that truncates beyond that. You can map several entities of the same type, for example a source IP and a destination IP as two IP mappings, and each counts separately toward the 500.

Entity mapping can bind an identifier only to a field that the rule's KQL query returns, so a column you want to map must be projected by the query or it will not appear in the value list. This is the common reason an alert arrives without expected user or host context: the field was never returned, so it could not be mapped to an entity.

Trap Assuming an entity will populate from a field the query filters on but does not return; mapping needs the column in the result set, not just in the where clause.

The Advanced Security Information Model (ASIM) is a query-time layer of KQL parser functions that map disparate source tables onto normalized schemas, so detection written against schema fields works on any current or future source that supports that schema. That is why one ASIM-based rule can catch brute force or impossible travel across Okta, AWS, and Azure at once, and why built-in ASIM content automatically expands to new sources without a rewrite.

ASIM has two parser levels. The unifying parser, named _Im_<schema> (for example _Im_Dns or _Im_Authentication), is the one you normally query: it calls every source-specific parser underneath so your query covers all sources for that schema. Source-specific parsers follow _Im_<schema>_<source>V<version> and can be used alone when you want a single source. You query by parser name in place of the raw table name.

Trap Querying a raw source table directly when the goal is cross-source coverage; only the unifying Im parser pulls in every source for that schema.

The _Im_ ASIM parsers are parameterized, meaning they accept filtering parameters such as a time range or field value that push the filter down to the source for performance on large data sets. A parallel set named _ASim_<schema> does not support filtering parameters and exists only for backward compatibility, so it is slower. For new detection work, prefer the filtering _Im_ parsers.

Trap Using an ASim parser for new work; it has no filtering parameters and is kept only for backward compatibility, so it scans more than the parameterized Im parser.

ASIM parsers are KQL user-defined functions that transform existing tables into a normalized view at query time, without modifying the stored source data. Because nothing is rewritten on ingest, a parser can be developed and tested against existing data, and a fix to a parser applies retroactively to data already collected. When query-time parsing is too slow on very large data, Sentinel offers ingest-time normalization into native tables like ASimDnsActivityLogs for faster queries.

ASIM defines normalized schemas for predictable event categories including Authentication, DNS Activity, Network Session, Process Event, Web Session, File Activity, DHCP, Registry, and Audit. Writing a detection against one of these schemas (through its parser) is what makes the rule source-agnostic, because every schema defines the same field names regardless of which product produced the event.

User and Entity Behavior Analytics (UEBA) builds dynamic ML behavioral profiles for users, hosts, IP addresses, and other entities, then flags activity that deviates from the entity's own history, its peer group, and the organization. That three-ring context is how it surfaces compromised accounts, insider attacks, and lateral movement that a static threshold rule cannot express. You enable UEBA and connect its feeding sources: Entra ID sign-in and audit logs, Security events, Defender for Identity, and Office 365.

Unlike scheduled and NRT rules, UEBA does not generate alerts in the incident queue. It writes enrichment into tables you query and join into detections and hunts: BehaviorAnalytics for per-event behavioral data, Anomalies for ML-flagged anomalous events, IdentityInfo for entity profiles, and UserPeerAnalytics for computed peer groups. The way to act on UEBA is to query these tables, often joining the Anomalies table into a hunting or detection query.

Trap Waiting for a UEBA alert to appear in the queue; UEBA surfaces signal through its tables, so you query BehaviorAnalytics and Anomalies rather than triaging UEBA alerts.

UEBA exposes two scores for different jobs. InvestigationPriority, in the BehaviorAnalytics table, runs 0 to 10 and is near-real-time and event-level, combining how rare the entities are with abnormal time-series patterns, so it suits quick triage of a single event. AnomalyScore, in the Anomalies table, runs 0 to 1 and is batch and behavior-level, a holistic ML anomaly across many events. A first-ever Azure action scores high investigation priority yet low anomaly score, which shows why both exist.

UEBA is the always-on profiling engine that populates BehaviorAnalytics, Anomalies, IdentityInfo, and UserPeerAnalytics and enriches investigations org-wide. Anomaly analytics rules are individual customizable templates you enable per behavior, which also write to the Anomalies table and can be duplicated to tune in Flighting mode. The blueprint's behavioral-analytics requirement is met by enabling UEBA, installing the UEBA Essentials hunting solution, and joining these tables into detections.

Trap Treating enabling a single anomaly rule template as the same as enabling UEBA; UEBA is the broader profiling engine, separately enabled, that feeds the entity-behavior tables.

The IdentityInfo table holds detailed profiles of entities (users, devices, groups), built from Microsoft Entra ID and, optionally, on-premises Active Directory synchronized through Microsoft Defender for Identity. It is the table you join to enrich an alert's account with role, group membership, and manager context during investigation, which is why connecting Entra ID and Defender for Identity is part of getting full value from UEBA.

A scheduled rule's event-grouping setting controls how query rows become alerts: group all matching events into a single alert, or trigger a separate alert for each row returned, up to 150 alerts per rule run. Choose one alert per row when each row is an independently investigatable event whose entities you want mapped individually; group into a single alert when the rows are facets of one finding.

Trap Leaving event grouping at single alert when each returned row is a distinct incident to investigate; you then lose per-row entities and per-event triage.

A rule's incident settings decide whether its alerts create incidents and how they group. You can fold alerts produced within a chosen time window into a single incident, and optionally group only when entities or details match, so a chatty rule produces one incident per campaign rather than hundreds of near-duplicates. This is distinct from event grouping, which is about rows-to-alerts; incident grouping is about alerts-to-incidents.

Trap Confusing event grouping (rows into alerts) with alert grouping (alerts into incidents); they are separate settings that solve different noise problems.

Query scheduling suppression stops a scheduled rule from re-running for a set period after it triggers, useful when a benign pattern would otherwise re-alert every interval. Tag rules with MITRE ATT&CK tactics and techniques so the MITRE coverage view shows where detection is thin, and attach automation rules or playbooks to act on alert or incident creation, for example to assign an owner or change severity.

Rather than writing every detection from scratch, activate analytics rule templates from solutions in the Content hub; these carry expert-written KQL designed around known threats, and you can customize the query, schedule, and threshold after activating. Export a finished rule to an Azure Resource Manager (ARM) template to manage and deploy detections as code across workspaces, and import rules from template files to edit them in the UI.

In a Sentinel scheduled analytics rule, 'Run query every' (interval) cannot exceed 'Lookup data from the last' (lookback); the lookback must be longer than or equal to the interval, otherwise validation fails because gaps would be left where events are never examined.

Trap Both 'Run query every' and 'Lookup data from the last' accept the same range, 5 minutes to 14 days; the lookback just can't be set shorter than the interval.

For each schema, a workspace-deployed source-specific ASIM parser comes in two versions: the filtering (parameterized) parser named vim (for example vimDnsInfobloxNIOS) and the parameter-less parser named ASim (for example ASimDnsInfobloxNIOS).

Trap Confusing these source-specific names with the unifying parsers a query normally calls: workspace-deployed unifying parsers are im, and the built-in unifying parsers are Im (filtering) and ASim (parameter-less).

For private, non-globally-routable IP addresses (RFC 1918), the Address identifier alone is a weak identifier, so the same address is not reliably correlated across alerts. Map both Address and AddressScope on the IP entity to make it a strong identifier.

Trap AddressScope is only needed for private IPs; public/global addresses are strongly identified by Address alone.

On the MITRE ATT&CK page under Threat management, select items in the Simulated rules menu to project your possible coverage if you configured all available-but-not-yet-enabled detections, so you can find gaps before turning rules on.

Trap By default the matrix shows only currently active scheduled-query and NRT rules; Simulated is what models the prospective coverage from available detections.

The Microsoft Defender portal automatically groups related alerts from across Defender for Office 365, Endpoint, Identity, Cloud Apps, Entra ID Protection, Defender for Cloud, and Purview into one incident with a shared timeline and entity graph. Because a single attack raises alerts in several products, the analyst responds to the incident as one attack story rather than chasing each alert in isolation, so the first move is always to open the incident and read the correlated timeline before touching any entity.

Trap Triaging each product's alert separately in its own console; that loses the cross-product correlation the incident already did for you.

Whatever product raised it, an incident runs one loop: triage (classify, set severity, assign), investigate (timeline plus entity-graph pivots), then respond. Only the final remediation verb changes with the entity, so internalising the loop once lets you handle any source. The exam rewards mapping the named entity to its matching action rather than learning a different process per product.

Classification records the analyst's verdict on an incident or alert as true positive, false positive, or informational expected activity, and a true positive carries a determination such as malware, phishing, or compromised account. That verdict is not just bookkeeping: it feeds Microsoft's detection tuning, so accurate classification improves future signal quality. Severity and assignment are set in the same triage step to drive urgency and ownership.

When the entity under attack is a device dropping malware, the containment action is to isolate it from the network so it can still talk to the Defender service for investigation but cannot reach anything else. Isolation is reversible and buys time without destroying evidence, which is why it beats reimaging or blocking at the firewall as the immediate response. Reimaging discards the forensic state and a firewall block does not stop east-west movement from the host.

Trap Reimaging the device immediately; that wipes the evidence you need and is not the contain-while-you-investigate action.

For a compromised identity the complete response is to revoke the user's active sessions and refresh tokens, require a secure password reset, and have them re-register MFA. Revoking sessions is the part most answers omit: a password reset alone leaves an already-stolen refresh token valid, so the attacker keeps access until that token is killed. Revoking sessions invalidates the issued tokens so the attacker is forced back to a sign-in that now fails.

Trap Resetting the password without revoking sessions; the stolen refresh token keeps working until the sessions are revoked.

Microsoft Entra ID Protection (Entra ID was Azure Active Directory) produces two risk signals the analyst responds to: sign-in risk says this particular authentication looks anomalous (impossible travel, anonymous IP), while user risk says the account itself is probably compromised (for example leaked credentials). Completing a secure password reset remediates user risk, and you can explicitly confirm a user as compromised or dismiss it as a false positive, which trains the model.

Trap Treating sign-in risk and user risk as the same signal; one rates the authentication event, the other rates the account, and a secure reset is what clears user risk.

Microsoft Defender for Identity (formerly Azure Advanced Threat Protection) uses sensors on domain controllers to detect Active Directory attacks such as reconnaissance, credential theft like Pass-the-Hash and Pass-the-Ticket, and lateral-movement paths toward sensitive accounts. Its alerts correlate in the same incident as the user's cloud sign-in risk, so one compromised identity shows both its cloud and on-premises picture. Reach for Defender for Identity when the scenario is domain-controller or AD lateral movement rather than a cloud sign-in.

When a phishing or malware message has reached mailboxes, the investigation tool is Threat Explorer (Explorer) in Defender for Office 365, which searches delivered mail by sender, subject, URL, file hash, or detection technology so you can locate every copy tenant-wide. From the results you take a tracked remediation action, most commonly Soft delete, which moves the message to Recoverable Items so it can be restored, rather than asking each user to delete it. Plan 1 exposes the lighter Real-time detections; Plan 2 has full Threat Explorer.

Trap Asking the user to delete the email or cleaning just one mailbox; the threat is tenant-wide, so you remediate every copy from Threat Explorer.

When remediating malicious mail, Soft delete moves messages to Deleted Items or Recoverable Items so they can still be restored if the verdict was wrong, while Hard delete purges them irreversibly. Soft delete is the default safe choice for analyst remediation because it contains the threat without destroying mail you might need, and you can escalate to hard delete once the verdict is certain.

Zero-hour auto purge (ZAP) is the automatic backstop in Defender for Office 365 that retroactively moves already-delivered mail to junk or quarantine when its verdict changes after delivery, for example a link clean at delivery that is later flagged. ZAP runs on its own, post-delivery, whereas Threat Explorer remediation is the analyst's manual targeted cleanup. The testable point is that ZAP is a post-delivery, automatic action, not something you trigger per message.

Trap Assuming ZAP only scans at delivery time; its whole purpose is the retroactive purge after delivery when a verdict changes.

Remediating a compromised mailbox does not stop at deleting the malicious message: BEC and account takeover almost always leave persistence such as an inbox rule that auto-deletes replies or forwards mail to an external address. The complete response removes those attacker-created inbox rules and forwarding, then resets credentials and revokes sessions, because deleting the email while leaving the rule in place keeps the attacker's foothold and exfiltration channel.

Trap Stopping after the malicious email is deleted; the attacker's inbox rule and forwarding remain and keep leaking mail.

Automatic attack disruption in Microsoft Defender XDR fires on high-confidence, correlated signals for a few playbooks (human-operated ransomware, business email compromise, adversary-in-the-middle) and takes immediate containment such as disabling a compromised account in Entra ID or isolating a device, without waiting for an analyst. It does this only when the confidence bar is crossed, so it is a narrow, high-precision capability rather than a general automation. The incident is tagged so you can see disruption acted.

When attack disruption has already contained an incident, the analyst role shifts to verifying that the automatic action was correct and completing the remaining cleanup the automation did not do. Because disruption acts on accounts and devices by itself, you must also know how to undo the action (re-enable an account, release a device from containment) when triage shows a false positive. The right answer to an already-contained scenario is verify-and-complete, not start the response from scratch.

Trap Re-running the full manual containment after disruption already acted, instead of verifying its action and completing the cleanup.

Automated investigation and response (AIR) investigates an alert and proposes or runs remediation across the affected assets, while automatic attack disruption is the narrower, higher-confidence capability that takes immediate account- or device-level containment mid-attack. Both are automation, but disruption is about breaking an in-progress high-confidence attack fast, whereas AIR is the broader investigate-and-remediate workflow. Match disruption to in-progress ransomware/BEC and AIR to general alert remediation.

Trap Conflating attack disruption with AIR; disruption is the immediate high-confidence containment, AIR is the broader automated investigation workflow.

For a risky or malicious OAuth app surfaced by Microsoft Defender for Cloud Apps (formerly Microsoft Cloud App Security), the remediation is to disable or revoke the app so its consented access to the tenant is cut. Suspending the affected user alone does not help, because the OAuth app holds its own delegated or application permissions independent of any single user's session. App governance is the feature that flags overprivileged or malicious OAuth apps for this action.

Trap Suspending only the user when an OAuth app is malicious; the app keeps its consented access until the app itself is disabled or revoked.

Microsoft Defender for Cloud raises the runtime security alerts an analyst investigates only when a paid Defender plan (Servers, Storage, SQL, Containers) is enabled on the resource; free foundational CSPM produces recommendations, not alerts. To respond, investigate the alert and apply its linked remediation steps or the associated security recommendation on the affected resource, such as closing a publicly exposed management port. The key fact is alerts equal an enabled plan, recommendations equal CSPM.

Trap Expecting workload alerts from free CSPM; CSPM only gives recommendations, while alerts require an enabled Defender plan.

The Defender portal surfaces Microsoft Purview Data Loss Prevention (DLP) matches and insider risk alerts, and the SC-200 task is to investigate them, scope the affected user and data, and remediate, for example revoking access or escalating an insider risk alert to a case. Creating the DLP policy or configuring insider risk policies is Purview administration owned by SC-401, not the analyst. The exam line is respond to the alert versus build the policy.

Trap Choosing the build-or-tune-the-DLP-policy answer; SC-200 investigates and remediates the alert, while authoring the policy is SC-401 work.

SC-200 incident questions describe a scenario and ask for the single best response, and the reliable method is to name the entity under attack, then choose its remediation: device to isolate, identity to revoke-and-reset, delivered email to Threat-Explorer-soft-delete, OAuth app to disable, cloud workload to apply-the-recommendation. The wrong answers usually offer a different entity's verb or the wrong scale, so matching verb to entity filters them out.

When a scenario is a correlated, cross-product incident spanning email, identity, devices, and cloud, the action lives in the Microsoft Defender portal (security.microsoft.com), which is the unified XDR queue. If the scenario is specifically Sentinel analytics rules, automation rules, or playbooks, that belongs to the Sentinel incident-response surface instead. The two are converging under the unified SecOps platform, but the exam still asks which portal owns the action.

Trap Reaching for Microsoft Sentinel to handle a correlated Defender XDR incident; the unified XDR incident is worked in the Defender portal.

Viewing a case's Content explorer requires membership in the Insider Risk Management Investigators (or the broader Insider Risk Management) role group. After you confirm an alert to a case, Content explorer shows no details for that case unless someone is assigned one of those role groups, and Investigators also need the file's Information Rights Management permissions to open IRM-protected items.

Trap Being able to triage or confirm the alert does not grant Content explorer access; that needs the Investigators (or Insider Risk Management) role group specifically.

Blast radius analysis is an incident-graph context-menu action (select the node, then View blast radius) that maps propagation paths from a compromised entity to predefined critical targets. It requires onboarding to the Microsoft Sentinel data lake (plus Exposure Management read permission), path length is bounded up to seven hops from the source node, and the graph is only as complete as the critical assets you define and the workloads you enable.

Trap A sparse blast-radius graph usually means critical assets are undefined or workloads are off, not that there are few attack paths.

For a confirmed false-positive Defender for Cloud alert, open the alert, select Take action, expand Suppress similar alerts, and create a suppression rule scoped to that alert type plus entity conditions that limit it to specific resources such as one VM. Matched alerts change to Dismissed status but still appear in the security alerts list, and detection continues for every other resource.

Trap Disabling the plan or the detection kills coverage everywhere; a scoped suppression rule keeps detection on for all other VMs.

Advanced hunting in the Microsoft Defender portal lets you query the raw event tables Defender XDR collects from endpoints, identities, email, apps, and cloud, going back about 30 days, using Kusto Query Language (KQL). It is proactive: you run a query and pivot from the result table rather than waiting for an alert. The query is read-only against telemetry, so a hunt never changes a device or mailbox; any containment is a separate response action. When you need data older than ~30 days, that is a Microsoft Sentinel job, not advanced hunting.

Every advanced hunting query starts at a table name and flows left to right through operators joined by the pipe character, each one taking the previous step's rows as input, just like a Unix pipe. Read it top to bottom and each line is one transformation of the table above it. The core operators are where (filter), project and extend (choose or compute columns), summarize (aggregate), join and union (combine tables), and order/take (sort and limit). Internalizing the pipeline shape is what lets you compose and debug a hunt rather than memorize snippets.

The performance rule SC-200 leans on is filter early. Place your time filter (where Timestamp > ago(...)) and your most selective where conditions immediately after the table, before summarize, join, or project, so every later operator works on fewer rows. Microsoft's query best practices say to filter before aggregating or joining and to project the columns you want last. A query that aggregates or projects before filtering is the slow, wrong answer on the exam.

Trap Filtering after a summarize or join; the aggregation already processed the full row set, so the late where saves nothing and the query stays slow.

In KQL == is case-sensitive equality and =~ is case-insensitive equality. When you match a file name or account that an attacker can re-case, use =~ so a query for powershell.exe still catches PowerShell.exe. The classic distractor is == , which silently misses the re-cased value and returns nothing. The same idea extends to string search: prefer the case-insensitive, term-based operators when the value's casing is not guaranteed.

Trap Using == to match a file name; it is case-sensitive, so a re-cased value like PowerShell.exe slips past a query written for powershell.exe.

KQL has matches a whole indexed term and is fast because it uses the term index; contains matches any substring and is slower because it cannot. For hunting on command lines, file names, or URLs, reach for has or has_any first and fall back to contains only when you genuinely need a partial-token match. On a large estate the operator choice is the difference between a query that returns and one that times out.

Trap Defaulting to contains for every text match; it skips the term index and runs far slower than has on large tables.

There is no single events table. Defender XDR groups telemetry by emitting product: Device* tables (DeviceProcessEvents, DeviceNetworkEvents, DeviceFileEvents, DeviceLogonEvents) from Defender for Endpoint, Email* and Url tables (EmailEvents, EmailAttachmentInfo, EmailUrlInfo, UrlClickEvents) from Defender for Office 365, Identity* tables (IdentityLogonEvents, IdentityDirectoryEvents) from Defender for Identity, and CloudAppEvents plus AAD sign-in tables from Defender for Cloud Apps and Microsoft Entra ID. The first decision in any hunt is which table owns the entity you care about, because its columns and data depend on it.

Trap Querying DeviceLogonEvents for a directory or identity sign-in; Device* tables come from Defender for Endpoint, while domain logon and directory activity live in the Identity* tables from Defender for Identity.

You do not have to know every column from memory. The portal's schema reference lists each table and column, and running TableName | take 10 returns a quick sample so you can see the real column names and shapes before you commit to a query. take returns arbitrary rows for sampling, not a ranked top-N; use top when you want the highest values. Inspecting first prevents the dead-end of joining or projecting a column that does not exist on that table.

Trap Treating take 10 as a top-10 ranking; take returns arbitrary rows, so for the highest counts or latest events you need top or order by.

Advanced hunting exists to follow an attacker across products that a single-product view cannot show: from a phished mailbox (EmailEvents) to the click (UrlClickEvents) to a process on a device (DeviceProcessEvents) to a sign-in (IdentityLogonEvents). You stitch the story with join on a shared key like AccountUpn or DeviceId, or union when several tables share the same entity column. This cross-domain query surface is what distinguishes advanced hunting from running each product's own search.

Unlike SQL, KQL join defaults to the innerunique flavor, which de-duplicates rows on the left table before matching. If a hunt needs every left-right pair (for example, all logons that match all of several suspicious devices), an unqualified join can silently drop rows. State join kind=inner explicitly when you want full inner-join semantics, and pick the kind (leftouter, rightsemi, anti, and so on) deliberately rather than relying on the default.

Trap Assuming an unqualified join behaves like a SQL inner join; KQL defaults to innerunique and de-duplicates the left side, so it can quietly drop matching rows.

The lifecycle is hunt, then operationalize: refine a KQL query interactively until it reliably finds the threat with low noise, then choose Create detection rule to save it as a custom detection that re-runs on a schedule and alerts. A bare advanced hunting query is a one-time manual lookup, so a recurring need (alert whenever, continuously detect) means promote to a rule. Authoring the KQL is the hunting task; the rule's frequency, tuning, and response actions are the detections topic.

Trap Re-running an advanced hunting query by hand on a cadence for something that should be a standing custom detection rule; promotion is what makes it alert automatically.

For a query to promote into a usable custom detection it must return the columns Defender XDR uses to build the alert: a timestamp, an entity that maps the alert to a real asset, plus ReportId for non-endpoint tables or DeviceId for Defender for Endpoint tables so the alert ties back to the originating event. A hunt that summarizes everything away and drops these columns cannot map its alerts to an asset; project them (use take_any or arg_max to carry ReportId through an aggregation) so the alert can build.

Trap Omitting ReportId on a non-endpoint table; without it Defender XDR cannot identify the originating event, so the alert is not tied back to its source even though the rule itself still creates and runs.

Advanced hunting ships helpers so you do not compose every hunt from scratch. Functions like FileProfile() enrich a file hash with prevalence and reputation in one call, Microsoft and the community publish a library of sample queries on GitHub, and guided hunting lets an analyst build a query with dropdowns instead of writing KQL. Reaching for a sample query or a function before hand-rolling a complex join is faster and less error-prone, and guided mode keeps non-KQL analysts able to hunt.

Threat analytics is a feed of expert reports written by Microsoft security researchers that describe active campaigns, actors, and techniques, then overlay them onto your tenant's own data. So it tells you whether a named campaign is affecting you right now, with your impacted assets and your exposure, rather than giving generic malware background. The SC-200 task here is interpretation and response: read the report and act, not authoring intelligence. When a question asks which mitigations reduce exposure to a specific actor, the answer is threat analytics, not a KQL hunt.

Trap Reaching for advanced hunting to judge whether a named campaign affects you; threat analytics already overlays Microsoft intel on your tenant and shows impacted assets and exposure.

Each threat analytics report turns intel into action through its tabs: an Overview and analyst report with the narrative and MITRE ATT&CK techniques, an Impacted assets view of the exact devices, users, and mailboxes with related activity, Related incidents and alerts already in your queue for that threat, and an Endpoints exposure plus Recommended actions view ranking the missing secure-configuration settings the campaign exploits. Mitigation status updates as you remediate, so the report doubles as a checklist for closing the gaps that leave you exposed.

The threat analytics dashboard summarizes the feed three ways: Latest threats (most recently published or updated), High-impact threats (greatest effect on your organization by active and resolved alert count), and Highest-exposure threats (where your configuration leaves you most exposed). Use High-impact and Highest-exposure to decide which campaign to hunt or harden first, because they are scored against your own telemetry and configuration rather than a one-size severity label. Reports also surface ready hunting queries that pivot you straight into advanced hunting.

Trap Prioritizing by a report's generic severity rating; that ignores your tenant, whereas High-impact and Highest-exposure are scored against your own affected assets and configuration gaps.

Advanced hunting queries about the last 30 days of Defender XDR data, so an investigation reaching months back belongs in Microsoft Sentinel, where long-term retention, archived log restore, and search jobs live. Keep each hunt's lookback as tight as it allows (ago(7d) returns faster than ago(30d) and is usually enough to confirm or rule out an indicator). A stem mentioning data older than 30 days, archived logs, or search jobs is pointing at Sentinel, not Defender XDR advanced hunting.

Trap Trying to hunt months-old data in Defender XDR advanced hunting; its window is about 30 days, so older investigations need Microsoft Sentinel retention and search jobs.

A KQL query surfaces evidence but never changes anything: it cannot isolate a device, disable a user, or delete an email. Those containment actions are taken from the incident, device, or user page in the response workflow, or are wired into a custom detection rule's automatic actions, not into the hunt itself. Knowing the read-versus-act split keeps you from expecting a hunting query to remediate and points you to the incident-response surface when the question asks how to contain.

For network indicators in Microsoft Defender for Endpoint, only Allow, Audit, Block, and Warn actions are supported. A CSV import in which network indicators use BlockAndRemediate fails to import those entries; use Block instead.

Trap BlockAndRemediate is valid only for file indicators, not for IP/URL/domain network indicators.

When several Defender for Endpoint URL, domain, or IP indicators target the same value, the precedence order is Allow over Warn over Block, so an Allow indicator overrides both Warn and Block.

Trap This precedence differs from file-hash indicator conflict handling, where the more secure/longer hash (SHA-256 over MD5) wins instead.