Configure Microsoft Defender XDR Settings

Notification rules: alerts vs vulnerabilities

A useful way to picture Defender XDR settings is a pipeline: a signal becomes an alert, the alert may trigger an automated investigation, the investigation may remediate, and a notification rule decides who hears about any of it by email. This section covers the last link, getting the right event to the right inbox, because an alert nobody reads is the most common reason a real incident sits untouched.

There are two separate kinds of email rule, and the exam leans on keeping them straight. An alert notification rule mails recipients when a Microsoft Defender for Endpoint alert is generated. You create it in the Microsoft Defender portal under Settings > Endpoints > General > Email notifications^[1], give it a name, choose the device scope (all devices, or specific device groups), set the alert severity that triggers mail, and list the recipients. Scoping by severity and device group is how you stop a Tier-1 distribution list from drowning in informational noise. Configuring notifications takes the Manage security settings permission (for example the Security Administrator role); under RBAC a recipient only gets alerts for the rule's device groups, and only a Global Administrator can manage a rule scoped to all device groups.

A vulnerability notification rule is a different rule type that fires on vulnerability events, not on alerts. It is created in the same Defender portal area on its own tab, Settings > Endpoints > General > Email notifications > Vulnerabilities^[2]; the events themselves come from Microsoft Defender Vulnerability Management. The event types you can subscribe to 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 of them. The trap the exam sets is to offer an alert notification rule when the scenario asks about being told when a CVE becomes exploitable: that is a vulnerability event, so it needs a vulnerability notification rule. The two never overlap, an alert rule carries no vulnerability events and a vulnerability rule carries no endpoint alerts.

What you can and cannot scope

Both rule families scope by device group, so a regional SOC can be mailed only about its own machines. Severity filtering applies to alert rules; event-type filtering applies to vulnerability rules. Neither rule can change whether an alert or vulnerability is recorded in the portal, they only control the outbound email, which is why a missing email is a notification-rule problem and a missing alert is a detection or licensing problem.

Alert and vulnerability notification rules are configured separately and never carry each other's events; both scope recipients by device group.

Defender for Endpoint advanced features and endpoint rules

Advanced features are tenant-wide on/off switches, set once for the whole tenant under Settings > Endpoints > Advanced features^[3] in the Defender portal. The single most testable fact here is the scope: these toggles are not per device or per group, so flipping one changes behavior everywhere, and an analyst confirming why a capability is missing checks this page first.

The features an SC-200 analyst is expected to recognize include Live response and Live response for servers, which let an authorized responder open a remote investigation shell on a device; Allow unsigned script execution in live response, a riskier sub-toggle; Tamper protection, which blocks attackers and even local admins from disabling Defender for Endpoint; and EDR in block mode, which lets Defender for Endpoint block malicious artifacts behind a non-Microsoft primary antivirus. (Note that Automated investigation is no longer one of these toggles, Microsoft removed it from Advanced features and AIR is now enabled by default; how far AIR goes is governed entirely by the per-device-group automation level covered below.) Several toggles are integration connectors: Microsoft Defender for Cloud Apps, the Microsoft Defender for Identity integration, and the Web content filtering and Custom network indicators switches. A connector left off is a silent gap, the signal simply never flows, so onboarding a new Defender product almost always includes turning its connector on here.

Endpoint rules settings

Beyond the on/off features, Defender for Endpoint carries rule-style settings an analyst tunes to cut false positives and shape automatic response. The main ones are:

Alert suppression / indicators: in the Settings > Endpoints > Rules area you build indicators^[4] (file hash, IP, URL/domain, certificate) with an action of Allow, Audit, Block, or Warn, which both create allow-lists for known-good artifacts and add custom blocks. Custom network indicators only take effect when the matching Advanced feature is enabled.
Web content filtering: policy-based blocking of whole web categories, configured under Rules, dependent on the Advanced feature being on.
Automation uploads and folder exclusions: control what content automated investigation may collect and analyze.
Process memory indicators and alert tuning: suppress or change the severity of specific alerts so recurring benign behavior stops paging the team.

The reconciling point between this section and the last: Advanced features decide whether a capability exists in the tenant, while endpoint rules decide how it behaves for specific artifacts. A custom network indicator (a rule) does nothing until Custom network indicators (the Advanced feature) is on, so a block that is not taking effect is usually the feature toggle, not the indicator.

Advanced features (tenant-wide toggles) sit beside endpoint Rules (behavior tuning) under Settings > Endpoints; a rule does nothing until its enabling feature is on.

Automated investigation and response (AIR) and automation levels

When an alert fires on a device, automated investigation and response (AIR) can launch an automated investigation that imitates the steps an analyst would take: it inspects files, processes, services, registry keys, and other evidence, decides a verdict for each artifact, and then remediates the malicious ones, for example by quarantining a file or killing a process. The point of AIR is volume, it clears the routine alerts so humans spend time on the genuinely hard incidents.

How aggressively AIR acts is the automation level, and the crucial fact is that the level is set per device group^[5], not globally. The levels, from least to most autonomous, are: No automated response (AIR does not run on the group); Semi-automation, require approval for all folders (every remediation waits in the Action center for analyst approval); Semi-automation, require approval for core folders and non-temp folders variants (approval only for remediations in those locations, others run automatically); and Full automation (remediations are applied automatically with no approval gate). Full automation is Microsoft's recommended level and the default for newly onboarded tenants, because evidence shows automatically remediated alerts are handled accurately and it frees the team. Older tenants may default to a semi level and need raising.

The Action center and approval queue

For any semi-automated group, AIR's proposed actions land as Pending actions in the Action center^[6], where an analyst approves or rejects them; approved or fully-automated actions move to the History tab, where they can be undone (for example, releasing a file from quarantine) if they turn out to be a false positive. The reversibility is the safety net that makes full automation acceptable. The exam pattern: a question that says remediations are sitting unactioned is pointing at a semi-automation group whose approval queue is not being worked, and the fix is either to work the Action center or to raise that group's automation level, not to re-tune detections.

Reconciling AIR with the previous section: AIR is enabled by default (Microsoft removed the old Automated investigation toggle from Advanced features), so what you actually configure is the per-device-group automation level, which alone decides how far AIR goes. A group set to No automated response means no AIR on that group, while a semi or full level governs how much remediation runs automatically.

AIR runs an automated investigation, then the per-device-group automation level routes remediation to automatic action, the Action center approval queue, or off entirely.

Automatic attack disruption in Defender XDR

Automatic attack disruption is the highest-confidence, fastest-acting response Defender XDR offers, and the exam wants you to separate it cleanly from AIR. AIR investigates and remediates one alert's evidence on the devices it covers. Attack disruption works at the incident level: it correlates high-fidelity signals across endpoints, identities, email, and SaaS apps into one incident and, the moment its confidence is high enough, automatically contains the attack^[7] so it cannot spread while the analyst is still investigating. The guiding contrast: AIR cleans up a confirmed-bad artifact, disruption stops a confirmed-bad attack in motion.

It is deliberately narrow. Microsoft limits it to a small set of high-confidence attack scenarios such as human-operated ransomware, business email compromise (BEC), and adversary-in-the-middle (AiTM), because the cost of a wrong automatic containment is high and these are the cases where speed matters most. Its automatic actions are also a fixed, narrow set: device containment (the device is isolated from the network by Defender for Endpoint), disable user (a compromised Microsoft Entra ID account is turned off so the attacker loses it), and contain user (Defender for Endpoint blocks a suspicious identity's actions on its onboarded devices, without disabling the account in the identity provider). The disable-user action is built on Microsoft Defender for Identity's remediation capability; for an on-premises Active Directory account the Defender for Identity sensor must be deployed on a domain controller, though disabling a cloud-only Entra ID account 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.

What the analyst actually configures

Attack disruption is on by default and is not a detection you hand-tune; the analyst's settings work is keeping its prerequisites met and reviewing its actions. Practically that means: ensure the contributing Defender workloads are onboarded (Defender for Endpoint for device actions, Defender for Identity for the user actions), keep automated response from being globally suppressed, and optionally exclude specific user accounts^[8] from automatic actions for break-glass or service identities so a critical account is never auto-disabled. Every disruption action is recorded in the incident and in the Action center and can be manually undone (release the device, re-enable the user) once the analyst confirms the situation, which is the same reversibility model as AIR. The exam pattern: a scenario describing a ransomware or BEC attack that was contained within minutes without anyone clicking is describing automatic attack disruption, and the right follow-up is to review and, if warranted, reverse the action in the incident, not to disable the feature.

Attack disruption correlates cross-workload signals into one high-confidence incident, then auto-applies device containment, disable user, or contain user.

Exam-pattern recognition

Questions in this subtopic almost always present an operational symptom and ask which Defender XDR setting fixes it. Map the stem to the setting:

Notification stems

If the stem says the team is not being emailed about high-severity alerts, the answer is an alert notification rule^[1] scoped to that severity and device group, not a new analytics rule. If the stem mentions being told when a CVE gets a public exploit or a new vulnerability is found, the answer is a vulnerability notification rule^[2] (Defender portal email notifications, Vulnerabilities tab); an alert notification rule is the planted distractor because both involve email.

Capability-missing stems

If an expected response such as live response, AIR, or a Defender for Cloud Apps signal never happened, the first suspect is a tenant-wide Advanced feature^[3] being off, since these are tenant-scoped switches. A common distractor is per-device configuration, but Advanced features are not per device.

Automation stems

If remediations are piling up unapproved, the group is on a semi-automation level and the fix is to work the Action center or raise the group's automation level^[5]; the level is per device group, so a global setting is the wrong answer. If a question asks for hands-off remediation, the answer is Full automation, Microsoft's recommended and default level for new tenants.

Disruption stems

If an attack such as ransomware or BEC was contained in minutes with no human action, that is automatic attack disruption^[7], not AIR; the tell is incident-level containment of an in-progress attack rather than cleanup of one alert's files. If the scenario needs the disable-user action to work against on-premises Active Directory accounts, the requirement is the Microsoft Defender for Identity integration (the sensor on a domain controller), the usual distractor being to onboard another product; note that disabling a cloud-only Entra ID account does not itself depend on Defender for Identity being deployed. When a legitimate account such as a service or break-glass identity must never be auto-disabled, the answer is to exclude that user^[8] from attack disruption, not to turn the feature off for everyone.

The through-line for the whole subtopic: SC-200 configures the response and notification behavior around alerts (who is told, what runs automatically, how far it goes, what is contained), and it does not author the detection logic that raises the alerts or the identity and platform policies those alerts come from.

Defender XDR response settings: who acts, where, and at what scope

Setting	What it does	Where you configure it	Scope of action
Alert notification rule	Emails named recipients when an alert fires	Defender portal > Settings	Filtered by severity and device group
Vulnerability notification rule	Emails on vulnerability events (new vulnerability, verified/public exploit)	Defender portal email notifications (Vulnerabilities tab)	Filtered by event type and device group
Advanced features	Tenant-wide on/off for live response, AIR, connectors	Settings > Endpoints	Whole tenant
Automated investigation and response	Investigates one alert and remediates its evidence	Per device group automation level	Devices in the group, after the set approval level
Automatic attack disruption	Contains an in-progress attack across the incident	Defender XDR (auto, prerequisite-gated)	Incident-wide: device containment, user disable

Decision tree

Cheat sheet

Sharp facts the exam loves — give these one last read before exam day.

Cheat sheet

Sharp facts the exam loves — scan these before test day.

Alert notification rules email recipients, filtered by severity and device group

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 are a separate rule type for exploit and exposure events

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.

1 question tests this

Your company uses Microsoft Defender for Endpoint Plan 2. You need to configure email notifications to alert your security team when a new…

Defender for Endpoint Advanced features are tenant-wide toggles, not per device

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.

1 question tests this

Your company uses Microsoft Defender for Endpoint Plan 2 and Microsoft Intune. A security administrator opens a vulnerability management…

AIR is enabled by default; the per-group automation level alone controls how far it goes

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 is gated behind its own Advanced 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 blocks even local admins from disabling Defender for Endpoint

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 lets Defender block when a non-Microsoft AV is primary

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.

2 questions test this

Custom indicators only act when their Advanced feature is enabled

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.

AIR automation level is set per device group, not globally

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.

2 questions test this

Full automation is Microsoft's recommended and default AIR level for new tenants

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.

No automated response is the level that turns AIR off for a group

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.

6 questions test this

Semi-automation parks remediations in the Action center as pending approvals

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.

2 questions test this

Action center History lets you undo a remediation

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.

1 question tests this

Your company uses Microsoft Defender for Endpoint Plan 2. A device group is configured with Full - remediate threats automatically. An…

Attack disruption contains an in-progress attack at the incident level, unlike AIR

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.

Attack disruption is limited to a few high-confidence attack types

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.

Attack disruption acts via device containment, disable user, or contain user

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.

1 question tests this

Your company uses Microsoft Defender for Endpoint Plan 2. You configure three device groups with the following automation levels:…

Disable-user is built on Defender for Identity; on-prem AD accounts need the MDI sensor on a DC

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.

2 questions test this

Exclude break-glass accounts from attack disruption instead of disabling the feature

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.

Integration connectors in Advanced features carry signals from other Defender products

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.

1 question tests this

Your company uses Microsoft Defender for Endpoint and Microsoft Purview Insider Risk Management. You need to ensure that Defender for…

Auto-resolve never overwrites an alert status an analyst set by hand

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.

4 questions test this

Defender for Cloud email notifications have separate alert-severity and attack-path thresholds

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.

5 questions test this

Notification rules: alerts vs vulnerabilities

What you can and cannot scope

Defender for Endpoint advanced features and endpoint rules

Endpoint rules settings

Automated investigation and response (AIR) and automation levels

The Action center and approval queue

Automatic attack disruption in Defender XDR

What the analyst actually configures

Exam-pattern recognition

Notification stems

Capability-missing stems

Automation stems

Disruption stems

Defender XDR response settings: who acts, where, and at what scope

Decision tree

Cheat sheet

References