Configure automation for Microsoft Defender XDR and Microsoft Sentinel
Automation settings in the Defender portal and Microsoft Sentinel
An attack surface reduction (ASR) rule[1] can block Office applications from creating child processes, such as a macro in a document a user opens that tries to start one. Whether a rule blocks it, whether an alert and an email reach your team, whether Microsoft Defender XDR contains the attack on its own[2], and whether a Sentinel playbook opens a ServiceNow ticket[3] are each decided by different settings, configured in advance in the Microsoft Defender portal and Microsoft Sentinel. Detection rules are a separate kind of setting: Defender XDR custom detection rules[4] and Sentinel scheduled analytics rules[5] generate alerts when their queries find matches.
Defender for Endpoint, Defender XDR, and Sentinel settings
The settings belong to three products: Defender for Endpoint enforces settings on the device, Defender XDR raises alerts and incidents, and Sentinel automation rules run when an incident is created or updated, or when an alert is created[6]. By the question each setting answers, the settings form these stages:
- Prevent and collect (Defender for Endpoint): what the device blocks and what telemetry it records. Defender for Endpoint advanced features, indicators, ASR rules delivered by endpoint security policies, and custom data collection.
- Tune and notify (Defender XDR[7] and Defender for Endpoint[8]): which alerts surface and who is told. Alert tuning rules and email notification rules.
- Built-in response (Defender XDR[2] and Defender for Endpoint[9]): what Defender does on its own. Automated investigation and remediation (AIR), Action center approvals, and automatic attack disruption.
- Custom orchestration (Microsoft Sentinel): what a workflow your team wrote does. Sentinel automation rules and playbooks[6], the SOAR (security orchestration, automation, and response) part of Sentinel.
The Prevent and collect, Tune and notify, Built-in response, and Custom orchestration stages are not one pipeline that every signal passes through: each setting is configured and triggered separately. The two response stages differ in who writes the decision logic: Microsoft describes automatic attack disruption as built in, unlike the response actions you create yourself in a SOAR platform. In built-in response you only set boundaries, such as which devices get automatic remediation and which assets are excluded; in custom orchestration you write the logic yourself.
Device-group scope and policy assignments
Selected Defender settings, including automated remediation, are scoped by a device group[10], a named set of Defender for Endpoint devices. Keep one consequence in mind from the start: a device belongs to one group only, so that group's access, notification, and remediation settings apply to it as a package. Endpoint security policies, one way to deliver ASR rules, are assigned to Microsoft Entra groups instead. Device groups or Microsoft Entra groups scope selected Defender settings, as the figure shows.
Takeaway: name the stage first: blocking a device behavior is an ASR rule, quieting an alert is alert tuning, and opening an external ticket is a Sentinel playbook. A real feature from a different stage still fails: alert tuning hides an alert but never lets its file run.
Device groups: the scope Defender settings share
Membership in a Defender for Endpoint device group decides which Microsoft Entra user groups can access a device's alerts and data, and which remediation level applies[10] during automated investigations.
A device group[10] is a named set of onboarded devices defined by a matching rule over four properties: device name, domain, tags, and OS platform. You create groups under Settings > Endpoints > Permissions > Device groups, up to 2,000 per tenant, with Defender for Endpoint Plan 1 or Plan 2.
How a device finds its group
- Conditions combine with AND, values with OR. A device must match every property the rule specifies. Within one property, such as several tag values or several name patterns, the values are alternatives, and each of those properties accepts up to 10 values[10].
- The highest rank wins. If a device matches more than one group, it joins only the highest-ranked group, and rank 1 is the highest. Settings never merge across matching groups.
- No match means the default group. A device that matches no group lands in Ungrouped devices (default). You cannot delete it or change its rank, but you can set its remediation level and its user access, which is why it deserves a review: new or mistagged devices inherit whatever it says.
A device therefore joins exactly one group[10]: its highest-ranked match, or Ungrouped devices (default) when nothing matches, as the figure shows.
What the group decides
- Who sees the device. Access comes from assigning Microsoft Entra user groups that already hold RBAC (role-based access control) roles. Defender for Endpoint has three permission models: basic permissions management[11] (full or read-only access only), Defender for Endpoint RBAC, and Microsoft Defender unified RBAC[12], the only model for new customers since February 16, 2025; device-group access needs an RBAC model. Assign none, and the group stays visible to every user with portal access[10], so an empty list is the open default, not a lockout.
- Its remediation level. Each group carries a remediation level (Microsoft also calls it the automation level) that decides whether automated remediation acts at once or waits for approval. Microsoft documents five remediation levels[9], from Full - remediate threats automatically to No automated response.
- Which notification rules cover it. Email notification rules filter by device group. Deleting a group removes it from those rules, and if it was a rule's only group, the notification rule is deleted too[10] instead of falling back to all devices.
- How incidents correlate, if you opt in. The advanced feature Restrict correlation to within scoped device groups[13] stops Defender from merging alerts from different groups into one incident, so a local SOC can act on incidents confined to the groups it can access. The global SOC then sees several incidents instead of one, and the change affects future correlations only.
One name collision to settle now: a Defender for Endpoint device group is not a Microsoft Entra device group. Endpoint security policies are assigned to Entra groups, while indicators, notification rules, and remediation levels use Defender device groups.
Takeaway: rank and the ungrouped default decide membership, and membership decides access, notification coverage, and automation in one package.
Defender for Endpoint advanced features
Blocking files by hash, running live response sessions on servers, sharing endpoint signals with Intune and Microsoft Purview, and stopping apps from changing antivirus settings each depend on a switch under Settings > Endpoints > Advanced features[13], set to On or Off and then saved with Save preferences. The same settings page carries other switches too, such as preview features and unsigned script execution in live response.
Protection switches
| Switch | What it does | Prerequisite or boundary |
|---|---|---|
| EDR in block mode | Blocks and remediates malicious artifacts that endpoint detection and response (EDR) finds after a breach | Works while Defender Antivirus runs in passive mode beside another primary antivirus; it does not make Defender the primary scanner |
| Allow or block file | Lets file indicators stop devices from reading, writing, or running a file | Defender Antivirus must be the active antimalware solution, with cloud-based protection on |
| Custom network indicators | Enables IP address, domain, and URL indicators | Windows 10 version 1709 or later, or Windows 11 |
| Tamper protection | Stops apps and other methods from changing protected Defender Antivirus settings | Locks configuration; it does not block an app behavior the way an ASR rule does |
| Web content filtering | Turns on category-based web blocking | Needs a separate policy that names the categories |
EDR in block mode[14] is built for devices where Defender Antivirus runs in passive mode, while Microsoft lists ASR rules among the features available only in active mode, so one never substitutes for the other.
Web content filtering needs more than the switch. Create a web content filtering policy[15] that selects the blocked categories and the device groups. Outside Edge on Windows, enforcement comes from network protection[16], the Defender for Endpoint component that blocks outbound HTTP(S) connections to poor-reputation sites and extends Edge's web protection, including custom indicators, to other browsers and applications. On Windows, Microsoft Edge is enforced through SmartScreen, while supported non-Microsoft browsers need network protection in block mode; on macOS and Linux, network protection in block mode is required for every supported browser, Edge included. A policy with no categories selected audits web activity instead of blocking anything.
Investigation and response switches
- Live response and Live response for servers are separate switches[13]. For a responder who can open sessions on workstations but not on servers, check the server switch and the other live response prerequisites; both switches only make sessions available to users who already hold the right permissions.
- Automatically resolve alerts closes alerts when no threat was found or the detected threat was remediated, without overwriting an analyst's manual In progress or Resolved status. Because active alerts feed a device's risk level, auto-resolution can lower that level.
- Download quarantined files (on by default) backs up quarantined files to a secure, compliant location so responders can download them from quarantine later.
- Show user details displays Microsoft Entra ID profile data (picture, name, title, department) on account entities in views such as the alert queue and the device details page. It adds context, not access.
- Restrict correlation to within scoped device groups stops Defender from merging alerts from different device groups into one incident.
Integration switches
- Microsoft Defender for Cloud Apps forwards endpoint signals for visibility into cloud app usage; the forwarded data is stored and processed in the Defender for Cloud Apps data location.
- Microsoft Intune connection shares device risk for risk-based compliance and Conditional Access. It must be enabled in both Defender for Endpoint and Intune, needs an active Intune environment and the matching licenses, and does not write the Conditional Access policies that consume the risk.
- Share endpoint alerts with Microsoft Compliance Center sends endpoint alerts and their triage status to Microsoft Purview, where insider risk management uses them once its policy indicators are configured. The Cloud Apps switch does not feed insider risk.
Inventory and telemetry switches
- Device discovery uses onboarded devices to find unmanaged devices on the network. Device discovery can find unmanaged devices, but it can also find devices already onboarded or recently offboarded.
- Authenticated telemetry prevents spoofed telemetry from reaching the dashboard.
- Hide potential duplicate device records (on by default, tenant-wide) matches records by hostname and last seen time and hides duplicates from the device inventory, vulnerability management pages, and machine-data APIs. The hidden records still appear in global search, advanced hunting, alerts, and incidents.
- Default to streamlined connectivity makes the streamlined onboarding package the default for supported operating systems; the standard package stays selectable on the onboarding page.
Takeaway: read every advanced-features question for its prerequisite. Check more than the switch: confirm the antivirus mode, the connected product, and any separate policy the feature needs.
Indicators: type, action, and scope
Defender for Endpoint lets you create indicators[17] for objects that threat intelligence names, such as a file hash, a phishing domain, or a signing certificate. An indicator[18], short for indicator of compromise (IoC), records your own decision about one such object, and Defender for Endpoint applies it wherever its scope reaches. Every indicator has the same four parts:
- Type: file (by hash), certificate, IP address, or URL and domain.
- Action: what happens on a match.
- Scope: the device groups it applies to.
- Expiration: when it stops applying, so a temporary decision does not become permanent.
An indicator is a detection or enforcement rule, not a saved hunting query. Adding an IoC to a Sentinel watchlist[19], a list of reference data that Sentinel queries and detection rules correlate with, creates no indicator and configures no prevention on endpoints.
Actions and which types support them
| Action | Effect on a match |
|---|---|
| Allow | Lets the object run, and by design generates no alert |
| Audit | Raises an alert without blocking |
| Warn | Shows a warning the user can bypass |
| Block execution | Prevents execution, with no bypass |
| Block and remediate | Prevents execution and applies a remediation action |
Not every type offers every action (actions per indicator type[18]):
| Indicator type | Supported actions |
|---|---|
| File | Allow, Audit, Warn, Block execution, Block and remediate |
| IP address | Allow, Audit, Warn, Block execution |
| URL or domain | Allow, Audit, Warn, Block execution |
| Certificate | Allow, Block and remediate |
So a certificate cannot be staged in Audit first, and Block and remediate exists only for files and certificates.
What each type matches
- IP address: individual addresses only. Ranges, CIDR notation, and wildcards are not supported[18]; IPv4 uses dotted-quad form and IPv6 all eight segments.
- Domain:
contoso.commatches the domain and every subdomain, such assub.contoso.com. - URL path: targets resources under that path. HTTPS path matching works only in Microsoft Edge, while HTTP paths match across browsers.
- Certificate: follows the signing certificate (a CER or PEM file) to match files signed with it; Microsoft apps cannot be blocked, and antivirus exclusions still apply. A file hash covers one exact file content, and a new application version has a new hash.
Network indicators need the Custom network indicators switch, and file blocking needs the Allow or block file switch with active antivirus, both under Settings > Endpoints > Advanced features[13].
Scoped exceptions
A scoped Allow indicator can carve an exception out of a broader control. When one team needs a business site that sits in a blocked web content category, an Allow domain indicator scoped to that team's device group exempts the site while the category stays blocked for everyone else. The same Allow mechanism is how a file is exempted after alert tuning.
Takeaway: choose the type from what must be matched (one file, a publisher, an address, a domain), choose the action from the outcome, and check that the type supports that action.
When an indicator seems not to work
Several documented conditions[18] make an indicator that saved correctly still produce an unexpected result.
- An antivirus exclusion wins. File and certificate indicators do not block files covered by a Microsoft Defender Antivirus exclusion[18]. Adding the same block hash again, or blocking the signing certificate instead, does not override the exclusion; correct the unintended exclusion.
- The handshake is not the verdict. Network protection decides whether to allow or block a site after the TCP three-way handshake completes, so a
ConnectionSuccessnetwork event (the TCP connection was established) can sit beside a successful block. Look for the block event or alert before recreating the indicator. - Block and Warn alerts look generic. Block and Warn matches create generic informational alerts[17] that ignore the custom title and severity you configured; only Audit alerts carry your severity. An informational-severity block alert is not by itself evidence of a failed save.
- Warn needs the Windows notification. The bypass prompt appears only when Files or activities are blocked is enabled under Virus & threat protection notifications in Windows Security, with the registry value
FilesBlockedNotificationDisabledset to 0. Changing Warn to Allow removes the warning instead of repairing it. - Trusted-application hashes need hash computation. Enforcing indicators against hashes of trusted applications needs
EnableFileHashComputation, a Group Policy setting that is off by default and separate from the portal's Allow or block file switch. - Cloud Apps synchronization overwrites local edits. Indicators synchronized from Defender for Cloud Apps follow the app's sanctioned or unsanctioned status there. Clearing Generate Alert on an unsanctioned app's indicator is reversed by the next synchronization, so change the Cloud Apps policy, not the generated indicator.
- Capacity is counted per tenant. A tenant can hold 15,000 indicators[17], and Microsoft does not support raising that limit. Splitting a feed across device groups creates no extra capacity, so an oversized feed needs selection and expiry management.
- One hash is not an application ban. An application consists of many files, so a hash indicator suits immediate containment of one known file. Durable application blocking belongs in App Control for Business or AppLocker.
Takeaway: when a block seems to fail, check antivirus exclusions, the network verdict, and the alert presentation before touching the indicator itself.
ASR rules: block the behavior, not the file
Attackers can abuse what is already installed: an Office macro that starts a script, a PDF reader that launches a process, a copied system tool run from a temporary folder. Attack surface reduction (ASR) rules[20] target those risky behaviors within each rule's scope and supported exclusions. That separates them from indicators, which act on one named object, and from controlled folder access, which protects designated folders against unauthorized changes.
Prerequisites and modes
ASR rules require Microsoft Defender Antivirus as the primary antivirus, in active mode with real-time protection on. Passive mode does not qualify, even with EDR in block mode turned on, and several rules also depend on cloud-delivered protection. Each rule runs in one mode:
| Mode | Behavior |
|---|---|
| Audit | Records what the rule would have blocked, without blocking |
| Block | Enforces the rule |
| Warn | Blocks, but the user can select Unblock for a 24-hour bypass |
| Disabled or Not configured | The rule is off |
Warn has two documented boundaries: starting with Defender Antivirus platform version 4.18.26060, using Unblock requires administrator approval, and some rules, including the LSASS credential-theft rule and the Office process-injection rule, do not support Warn at all.
Rolling out safely
Microsoft splits the rules into two categories. Standard protection rules (Block abuse of exploited vulnerable signed drivers, Block credential stealing from the Windows local security authority subsystem, and Block persistence through WMI event subscription) are recommended in Block mode without extensive testing. Other ASR rules should run in Audit mode first: review the audit events, add narrow exclusions where a verified application needs one, then switch to Block or Warn. The Configuration Manager client relies heavily on WMI, which creates the documented exceptions on devices it manages: test the WMI persistence rule extensively in Audit before you enforce it through another deployment method such as Group Policy or PowerShell, and do not enable the PSExec and WMI process-creation rule there through any deployment method other than Configuration Manager itself. On those devices, the WMI persistence rule[20] therefore joins the other rules on the Audit-first path, as the figure shows.
Choosing the rule from the attack mechanism
The rule names are long, but each targets one mechanism, so match the mechanism the scenario describes (ASR rules reference[1]). Selected ASR rules, not the full set, by the mechanism they target:
| Attack mechanism in the scenario | ASR rule |
|---|---|
| An executable arrives through email or webmail | Block executable content from email client and webmail |
| A macro writes an executable to disk | Block Office applications from creating executable content |
| An Office application injects code into another process | Block Office applications from injecting code into other processes (restart Office afterward) |
| A VBA macro calls native Windows APIs without writing a file | Block Win32 API calls from Office macros |
| Word, Excel, or PowerPoint launches a process | Block all Office applications from creating child processes |
| Outlook launches a process | Block Office communication application from creating child processes |
| A PDF opened in Adobe Reader launches a process | Block Adobe Reader from creating child processes |
| An untrusted or unsigned program runs from USB | Block untrusted and unsigned processes that run from USB |
| A concealed (obfuscated) script runs | Block execution of potentially obfuscated scripts |
| A readable script downloads and starts a payload | Block JavaScript or VBScript from launching downloaded executable content |
| Malware persists through WMI event subscriptions | Block persistence through WMI event subscription |
| A process is started remotely through PsExec or WMI | Block process creations originating from PSExec and WMI commands |
| An app reads LSASS memory to steal credentials | Block credential stealing from the Windows local security authority subsystem |
| A vulnerable signed driver is written to disk | Block abuse of exploited vulnerable signed drivers |
| An executable with little reputation runs | Block executable files from running unless they meet a prevalence, age, or trusted list criterion |
| A copy of a System32 tool runs from another folder | Block use of copied or impersonated system tools |
| Commands try to reboot into Safe Mode | Block rebooting machine in Safe Mode |
| A web shell is written on an Exchange server | Block Webshell creation for Servers |
Boundaries that change the answer
- LSASS (the Local Security Authority Subsystem Service, which holds credentials in memory): the rule denies memory access, not the process. An updater whose LSASS access was blocked keeps running, and the event alone does not justify an exception. With LSA protection[21] enabled (the Windows setting that stops nonprotected processes from reading LSASS memory or injecting code into it), the rule is redundant.
- Vulnerable drivers: the rule stops a driver from being saved to disk, not a driver already present from loading; add application control or the vulnerable driver blocklist for that.
- Copied tools: the rule judges location, so a valid Microsoft signature does not exempt a copied tool.
- Safe Mode: the rule stops abused commands such as
bcdeditandbootcfg; manual Safe Mode entry through Windows Recovery Environment still works. - Reputation: the prevalence rule and Use advanced protection against ransomware can block a new business executable that simply lacks a positive reputation, and both need cloud-delivered protection.
- Script rules: the obfuscated-script rule needs AMSI (the Antimalware Scan Interface) and cloud-delivered protection; the downloaded-content rule needs AMSI.
- WMI persistence: the rule depends on RPC (Remote Procedure Call) as well as Defender Antivirus (rule dependencies[1]).
- Silent enforcement: an enforced block is not always visible. The LSASS rule produces neither EDR alerts nor user notifications, and for the Adobe Reader rule, EDR alerts need cloud protection at High plus or Zero tolerance. An empty alert queue is not proof that a rule is off.
Takeaway: pick the rule by the mechanism the attacker uses, confirm active antivirus, and audit before enforcing anything outside the standard protection set.
Endpoint security policies: delivering ASR rules
One way to configure ASR rules on a device is through an endpoint security policy[22]: a template-based policy for one platform, created on the Endpoint security policies page of the Defender portal or in Intune, and assigned to groups of devices. Creating one means choosing a platform and template and assigning groups, managing it needs a dedicated permission, and its policy page shows status and the devices it applies to (manage endpoint security policies[22]).
Pick the template for the platform
- Antivirus, antivirus exclusions, and EDR templates exist for supported Windows, macOS, and Linux devices.
- Defender Firewall and Firewall rules templates are Windows-only. The firewall profile holds firewall settings, the firewall-rules profile holds individual traffic rules, and neither is an ASR profile.
- For ASR, choose platform Windows and the Attack Surface Reduction Rules profile (configure ASR rules in endpoint security policies[23]). The same policy also holds ASR exclusions.
Onboarding does not make every template available on every operating system: an onboarded Linux server cannot receive the Windows firewall template.
Target Microsoft Entra device groups
After the Intune connection and Defender for Endpoint security settings management are configured, supported policies also reach devices that are onboarded to Defender for Endpoint but not enrolled in Intune. For devices managed this way, assign policies to Microsoft Entra device groups, meaning Entra groups whose members are devices: this management path supports device objects, not user targeting.
Permission to manage policies
Under Defender unified RBAC, Core security settings (manage) under Authorization and settings > Security settings lets an administrator create and manage endpoint security policies; Core security settings (read) gives read-only access. The permission must apply to all devices: a role scoped to particular device groups cannot open the Endpoint security policies page. Whatever role grants access, the list of policies shown is also filtered by Intune RBAC assignments.
Verify delivery, not just creation
A policy in the list proves it was created, not that each device applied it. A policy reaches a device through creation, assignment, and the device's next check-in, and the device page confirms the result:
- Create the policy for one platform and template; its own page later shows status, applicable devices, and assigned groups.
- Assign it to Entra device groups.
- Let the device check in: devices under Defender security settings management check in with Intune every 90 minutes[22]. To speed this up, choose More actions > Policy sync on the device page, and the policy should apply in about 10 minutes.
- Confirm on the device's Configuration management > Security policies tab which policies applied.
An assigned policy reaches a device at its next check-in with Intune[22], or sooner after a Policy sync, as the figure shows. Creating a duplicate policy before checking assignments and sync adds configuration without fixing delivery.
Takeaway: match the template to the platform, assign to Entra device groups, and verify on the device itself.
Which ASR setting wins on a device
When two management tools configure the same ASR rule differently, the device does not pick the stricter value. A fixed precedence decides, and some conflicts leave the rule unapplied. That precedence ranks Group Policy, mobile device management (MDM) tools such as Intune, and local PowerShell commands (ASR rule precedence[23]).
Precedence between authorities
- Group Policy over MDM by default. When Group Policy and an MDM tool such as Intune configure the same rule, Group Policy takes precedence[23]. Setting the Policy CSP (configuration service provider) value
ControlPolicyConflict/MDMWinsOverGPto 1 makes MDM win instead; its default is 0. The most recently edited policy does not automatically win. - Any policy over local PowerShell. Local configuration with
Set-MpPreferencehas the lowest precedence, and policy-based configuration overwrites conflicting local settings at startup. A local change that keeps disappearing points at the managing policy, not at a need to rerun the command. - Several Intune policies merge. Non-conflicting ASR settings from multiple Intune policies combine into one superset[20] on the device. Settings that conflict, such as the same rule in two different modes, are held back and not applied; there is no automatic rule that Block wins.
Group Policy outranks MDM by default, and any policy-based method overwrites local settings[23], as the figure shows.
Commands and action values
The PowerShell cmdlets come in three forms: Add-MpPreference adds rules without touching existing ones, Set-MpPreference replaces the configured list with exactly what you pass, and Remove-MpPreference removes the specified entries. Add-MpPreference can put one rule into Audit mode while every rule already configured keeps its mode:
PowerShell: add the Adobe Reader child-process rule in Audit mode
# Add-MpPreference appends; Set-MpPreference here would replace the whole rule list
Add-MpPreference -AttackSurfaceReductionRules_Ids 7674ba52-37eb-4a4f-a9a1-f0f9a1619a2c -AttackSurfaceReductionRules_Actions AuditMode
In that command, -AttackSurfaceReductionRules_Ids takes the rule's GUID, and -AttackSurfaceReductionRules_Actions takes the mode for that GUID, position by position when you pass several. Group Policy and the Policy CSP express the same modes as numbers (action values[23]):
| Value | Mode |
|---|---|
| 0 | Disabled |
| 1 | Enabled (Block) |
| 2 | Audit |
| 5 | Not configured |
| 6 | Warn |
So a nonzero value does not always mean blocking: 2 audits and 6 warns.
Leave competing settings Not configured
When Defender for Endpoint centrally manages Block Webshell creation for Servers, leave that rule Not configured[1] in Group Policy and other local settings. An explicit Disabled is still a competing value, not a hand-off to central management.
Takeaway: give each rule one authority. Group Policy wins by default unless MDMWinsOverGP changes precedence; managed policies override conflicting local PowerShell settings, and conflicting Intune values are not applied.
ASR exclusions: keep the exception narrow
A verified compatibility problem sometimes needs an exception, and ASR offers two scopes for it. The scope decides which rules skip the path, and the exclusion type, an ASR exclusion or a Microsoft Defender Antivirus exclusion, decides whether a given rule reads it at all (exclusions for ASR rules[20]).
- ASR only per rule exclusions let an approved path bypass one supported rule.
- Attack surface reduction only exclusions (global ASR exclusions) apply across every ASR rule that honors exclusions.
Prefer the per-rule form. A global exclusion for a one-rule problem[20] exempts the path from rules that had nothing to do with the conflict. Both scopes sit in the same endpoint security policy that delivers the rules.
Antivirus exclusions are a different mechanism, and not every ASR rule reads them. The LSASS credential-theft rule ignores Microsoft Defender Antivirus file and folder exclusions but honors ASR exclusions, so a password-sync agent that legitimately needs LSASS access gets an ASR exclusion, not an antivirus folder exclusion. Check a rule's exclusion support before reusing an antivirus exception for it.
Warn mode is not an exclusion: it gives one user a 24-hour bypass of one block, and rules that do not support Warn cannot offer even that.
Takeaway: make an exception as narrow as the verified problem, per rule rather than global, and of the exclusion type the rule actually reads.
Custom data collection into Sentinel
Default Defender for Endpoint telemetry does not record every event an investigation might want, such as every load of one DLL across a set of servers. Custom data collection[24] lets you define rules that capture additional endpoint events and send them to a Microsoft Sentinel workspace. It adds events that default collection never captured, which is why extending XDR retention cannot replace it: retention keeps collected data longer, it does not collect more. Its rules are created in the Defender portal and support the DeviceCustomProcessEvents, DeviceCustomImageLoadEvents, DeviceCustomFileEvents, DeviceCustomNetworkEvents, and DeviceCustomScriptEvents tables. Despite the similar name, such a custom data collection rule[24] is not an Azure Monitor data collection rule (DCR)[25]: a DCR is an Azure resource that tells Azure Monitor how to process the data it receives.
Prerequisites
- Defender for Endpoint Plan 2 and a Microsoft Sentinel workspace. The feature currently supports one Sentinel workspace per tenant.
- Windows 10 or Windows 11 with client version 10.8805 or later (Windows 10 also needs Extended Security Updates (ESU)[26] enrollment), or Windows Server 2019 or later.
- A budget for ingestion: collection is included in Plan 2, but the data is billed as Sentinel ingestion.
Building a rule
Rules live under Settings > Endpoints > Rules > Custom Data Collection, and setup proceeds in this order:
- Select the Sentinel workspace at the top of the page, even if a workspace is already connected.
- Create a rule and choose the table, the action (the event type), and conditions that narrow the events.
- Define the scope: all applicable devices, or devices that carry a dynamic tag from Asset Rule Management. Manual (static) tags are not supported, and the tag rule must have run at least once; check that evaluation first when expected devices send nothing.
- Verify the events in the matching DeviceCustom* table:
DeviceCustomFileEvents,DeviceCustomScriptEvents,DeviceCustomNetworkEvents,DeviceCustomProcessEvents, orDeviceCustomImageLoadEvents. Output from a custom process rule lands inDeviceCustomProcessEvents, notDeviceProcessEvents, and theRuleNameandRuleLastModificationTimecolumns show which rule revision produced an event.
Setup runs from the workspace through the rule and its scope to the DeviceCustom* tables, and each rule runs under a per-device event cap and a deployment delay[24], as the figure shows.
Limits and lifecycle
- Event cap. Each rule captures up to 75,000 events per device in a rolling 24-hour window[24]. At the cap, that rule pauses on that device until the window resets. Narrow the table, action, and conditions; raising workspace retention changes storage time only.
- Deployment latency. Creating or editing a rule typically takes 20 minutes to one hour to reach the targeted devices.
- Delete versus disable. Deleting a rule removes it permanently and stops new collection, but data already in Sentinel stays under its retention settings. Disable the rule when you want a reversible pause.
Takeaway: custom collection adds data only going forward, within the rule's scope of all applicable devices or selected dynamic tags, and only up to its per-rule, per-device cap.
Alert tuning: hide, resolve, or set as behavior
Alert tuning[7] (formerly alert suppression) is meant for scenarios where known internal business applications, such as a backup agent, or security tests trigger expected activity: a rule matches the alert's evidence and applies one action automatically. Rules live under Settings > Microsoft Defender XDR > Alert tuning, or you can start one from an alert with Tune alert.
Two Microsoft Sentinel features also use the word suppression, so separate them now. Alert tuning acts on Defender XDR alerts. A Sentinel scheduled analytics rule's suppression setting pauses the rule's query for a set time after it generates an alert[27]. Incident suppression in Sentinel closes matching incidents through an automation rule[6].
The three actions
| Action | What happens | Where the data stays | Boundary |
|---|---|---|---|
| Hide alert | Suppresses the alert and prevents incident creation | AlertInfo and AlertEvidence tables | Defender for Endpoint alerts only |
| Resolve alert | Creates the matching alerts and their incidents in resolved status | The alert and incident records themselves | Leaves a record of the expected activity |
| Set as behavior | Converts matching signals into behaviors, outside the alert queue and incidents | BehaviorInfo and BehaviorEntities tables | Not supported for Defender for Cloud or Defender for Office 365 alerts |
Resolve alert keeps resolved alert and incident records, Hide alert keeps Defender for Endpoint alerts in the alert tables, and Set as behavior[7] keeps behaviors but is not supported for Defender for Cloud or Microsoft Defender for Office 365 alerts, as the figure shows.
Conditions and scope
- Evidence, not titles. Conditions use evidence such as files, processes, and scheduled tasks, up to 200 conditions per rule[7], combined with AND, OR, and grouping. Values are case-insensitive and some properties accept wildcards. An alert's type is its
IoaDefinitionId, so a changed display title does not mean a new alert type. - Alert type scope. Starting from an alert, choose either the selected alert type or Any alert type based on certain conditions. The second option also needs service sources, and only services you have permission to manage are offered. Broadening both the type and the services can quiet unrelated detections that happen to share the same evidence.
Built-in tuning rules
Microsoft ships built-in tuning rules for common benign activity. They suppress alerts without disabling AIR investigations or email notifications, and if an automated investigation then finds malicious or suspicious activity, the suppressed alert is reactivated. They do not apply to alerts from custom detection rules or Custom TI[17] alerts (alerts raised by your own threat-intelligence indicators), so a noisy custom detection needs your own tuning rule or a better query.
Tuning does not allow the file
Hiding or resolving alerts changes alert handling only. If the triggering file must also stop being blocked, the Successful rule creation page that follows rule creation offers to add selected evidence as Allow indicators, a separate decision with its own scope. An antivirus exclusion is not a tuning tool either: it changes what is protected, not what is shown.
Takeaway: tune by evidence, pick the action by which record you still need, and add an Allow indicator only when the activity must also run unblocked.
Email notifications: pick the subscription by event
An incident email, a failed-remediation email, and a new threat analytics report are three different subscriptions configured separately on their respective tabs. Endpoint alert and vulnerability notifications are configured under Settings > Endpoints, not on the Defender XDR Email notifications page:
| Subscription | Where | Fires on | Filters |
|---|---|---|---|
| Incidents | Settings > Microsoft Defender XDR > Email notifications, Incidents tab | New incidents and updates to existing ones | Alert severity, service or detection source, device group; optionally one email per incident |
| Actions | Same page, Actions tab | Response actions | Manual or automated source, action type, device groups, completed or failed status |
| Threat analytics | Same page, Threat analytics tab | Reports published or updated | All reports, or by report type or tag |
| Endpoint alerts | Settings > Endpoints > General > Email notifications | New Defender for Endpoint alerts | Alert severity, devices or device groups |
| Vulnerabilities | Settings > Endpoints > General > Email notifications > Vulnerabilities | Vulnerability events | Event type, such as a new vulnerability above a severity threshold or a verified exploit |
Each subscription adds its own options and limits:
- Incident notifications[28] can set different severities per service or detection source, so different SOC teams receive only the incidents relevant to them.
- Action notifications[29] distinguish completed from failed actions, so filter on failed status; incident severity describes risk, not whether a remediation ran. Selecting All device groups covers groups created later too, and response actions inside custom detections are not supported.
- Threat analytics notifications[30] follow report publication, not your tenant's incidents: a matching report need not describe anything in your environment. Add at least one recipient and use Send test email to check delivery.
- Endpoint alert notifications[8] are their own rule under Endpoints settings, built with Add item; editing an XDR incident rule never repairs missing endpoint-alert emails.
- Vulnerability notifications[31] select event types: New vulnerability found, Exploit was verified, New public exploit, and Exploit added to an exploit kit. Newly vulnerable device is not among the documented notification event types.
Permissions and scope
Managing incident notification rules needs the Manage security settings permission, or Security Administrator or a higher role when the tenant uses basic permissions management. Under RBAC, as opposed to basic permissions management, an administrator can create, edit, delete, and receive notifications only for the device groups they are allowed to manage, and only a Global Administrator can manage endpoint alert rules that cover all devices. Adding someone as a recipient does not widen anyone's device scope.
When emails do not arrive
For endpoint alert notifications, new recipients are notified about alerts triggered after they were added. When matching emails are missing, check the Junk Email folder, the mail security product, and mailbox rules that move messages. Deleting a device group can remove or delete rules that referenced it[10].
Takeaway: choose the tab by event type (incident, action, report, endpoint alert, vulnerability), then use the filters that subscription supports, such as report type or tag for threat analytics.
Automated investigation and remediation (AIR)
For example, Defender detects a malicious file on a laptop and runs the Stop and quarantine action with no analyst involved. That is automated investigation and remediation (AIR)[9]: Defender examines the evidence, reaches a verdict, and remediates, while the device group's remediation level decides whether each remediation happens at once or waits for approval.
What changed for Defender for Endpoint
As of September 1, 2026, AIR no longer runs as a separate investigation experience[32] in Defender for Endpoint, and you can no longer trigger an endpoint investigation manually. Its detection and response capabilities run automatically in the default antivirus protection stack; for an on-demand check of a device, run a full antivirus scan. AIR for Defender for Office 365 is unaffected and still investigates email threats. There is also no tenant-wide AIR switch in advanced features: the remediation level per device group[33] is the control. Microsoft still documents the remediation levels[9]: they decide whether a remediation action runs at once and appears on the Action center History tab, or waits on the Pending tab for approval.
Verdicts decide whether remediation is needed
An investigation classifies evidence as Malicious, Suspicious, or No threats found, and only then decides whether remediation is needed. A Defender for Office 365 investigation[34] can legitimately close without any action when no threats were found or the messages were already remediated, so a finished investigation without a quarantine step is not, by itself, a failed automation.
Remediation levels
| Remediation level | What happens |
|---|---|
| Full - remediate threats automatically | Remediates malicious artifacts automatically; recommended, and the default for tenants created on or after August 16, 2020 with no device groups yet |
| Semi - require approval for all folders | Every file remediation waits for approval |
| Semi - require approval for core folders | Approval for operating-system folders such as \windows\*; automatic everywhere else |
| Semi - require approval for non-temp folders | Automatic in temporary folders such as \users\*\appdata\local\temp\*; approval everywhere else |
| No automated response | Automated investigation does not run, so it takes no remediation actions and leaves none pending; other antivirus protections can still apply; not recommended |
These levels set approval boundaries for remediation; choosing one does not bring back the retired manual endpoint investigation. A malicious file is remediated at once under Full automation and shows on the History tab, while under a Semi level a remediation that needs approval waits on the Pending tab (automation levels[9]), as the figure shows; No automated response produces no performed or pending AIR actions.
The Action center
The Action center[32] lists remediation actions for devices, email and collaboration content, and identities in one place:
- Pending holds actions waiting for a decision. Approve or reject them one at a time, or in bulk when the selected actions share the same action type. A pending endpoint action that nobody answers times out after seven days[9] and is treated as rejected, never as approved. Closing an incident does not approve its pending actions.
- History is the audit log of completed actions: automated remediation, manual actions, live response commands, and antivirus remediation. Some actions can be undone from here.
- Action source shows how each action started: a manual device or email action, an automated device or email action, advanced hunting, Explorer, or live response. Check it before changing automation settings, because an entry in History is not necessarily the result of AIR.
Who can approve
Approving endpoint remediation under Defender unified RBAC needs Security operations > Security data > Response (manage). Email remediation needs the email and collaboration advanced-actions permission when that workload's unified RBAC is active, or, under Microsoft Entra or Email & collaboration permissions, Security Administrator combined with the Search and Purge role. Read-only access to security data lets someone inspect pending actions, not approve them.
Takeaway: the remediation level decides automatic versus pending, the Action center holds the queue, and seven days of silence means rejection.
How automatic attack disruption acts
Microsoft Defender correlates signals to identify active ransomware campaigns and other sophisticated attacks while they are in progress. Automatic attack disruption[2] is Defender XDR's built-in answer: it contains the compromised assets the attacker is using and limits lateral movement early. Microsoft describes three stages of its own inside this one feature:
- It correlates signals from endpoints, identities, email and collaboration tools, and SaaS apps into a single high-confidence incident.
- It identifies the assets the attacker controls and uses to spread the attack.
- It takes response actions in the relevant Defender products to contain those assets while the attack is in progress.
Containment acts on the assets identified within that one correlated incident, as the figure shows. Because disruption evaluates the whole attack, it differs from blocking on a single indicator of compromise: a file-hash block stops one file, while disruption contains the accounts and devices behind the attack. It is also not a playbook you author; a Sentinel playbook is the tool when you need your own response workflow. Supported scenarios include human-operated ransomware, business email compromise (BEC), and adversary-in-the-middle (AiTM) phishing.
Actions
| Action | Product | What it does |
|---|---|---|
| Contain device | Defender for Endpoint | Applies a policy on all onboarded devices that blocks communication from the suspicious device, so the contained device needs no sensor of its own |
| Contain IP | Defender for Endpoint | Blocks communication from an IP address of an undiscovered or non-onboarded device |
| Isolate device (preview) | Defender for Endpoint | Isolates a compromised end-user workstation that Defender for Endpoint onboards and manages; undone automatically after a defined time window |
| Contain user | Defender for Endpoint | Blocks the identity's authentication-based access, file system access, and network communication at onboarded devices; the account stays enabled |
| Disable user | Defender for Identity | Disables the account in its identity service |
Microsoft also documents other actions, such as revoking a user's sessions or suspending a user in Microsoft Entra ID, and OAuth app actions in Defender for Cloud Apps. Every action is recorded in the incident and the Action center, the incident shows an Attack Disruption tag and a yellow banner, and your team can undo any action.
Contain user and Disable user act in different places, and so do Contain device and Isolate device (automatic isolation). Contain user restricts the identity at endpoints, so it is not evidence that the directory account is disabled; that is Disable user. And an unmanaged workstation can be covered by Contain device, which the other onboarded devices enforce, but it is not eligible for automatic isolation, which needs a managed workstation (isolation eligibility[35]).
How Disable user reaches the account
The route depends on where the account lives:
- Active Directory only: disabled through domain controllers running the Defender for Identity sensor.
- Synced from Active Directory to Microsoft Entra ID: disabled in Active Directory through the sensor-equipped domain controllers, and in Entra ID as well.
- Cloud-only Entra ID account: disabled in Entra ID through a Microsoft-managed enterprise application, which does not require Defender for Identity to be deployed.
Exclusions: protect an asset, or only its traffic
Attack disruption exclusions[36] stop automatic response for selected assets. Under Settings > Microsoft Defender XDR > Automated response, use Identities > Add user exclusion for an approved critical account, or Devices > Policy application > Exclude IP for an address, range, or subnet. These exclusions exempt only the chosen assets or actions from selected automated responses, without turning off automated response for a whole device group. If an isolated workstation merely needs to keep one management connection or process, use selective isolation exclusions instead: they keep specific traffic flowing during isolation, whereas an attack disruption exclusion prevents the automatic response altogether.
Takeaway: disruption is incident-wide, automatic, reversible, and Microsoft-authored; you shape it through deployment and exclusions, not workflow logic.
Attack disruption prerequisites by product
Defender for Identity can act on an on-premises account only when it has the required permissions[35], so disruption can identify a compromised account yet fail to disable it. Disruption acts only through products that are deployed and configured, and each product has its own attack disruption prerequisites[35]. Check the deployment requirements for each signal and action; disabling a user account in Microsoft Entra ID does not require Defender for Identity deployment. A detection that relies on Defender for Cloud Apps signals needs that product, and containing a device needs Defender for Endpoint; the license alone executes nothing.
Defender for Endpoint
- Device-group remediation level. Full is recommended. A Semi level still lets disruption act without manual approval, so Semi is not a way to hold disruption for review. No automated response excludes the group from automated containment and is meant for a small number of devices only.
- Active, Passive, or EDR Block Mode. Disruption acts whether Defender Antivirus is active, passive, or in EDR block mode, unlike ASR rules, which need active mode.
- Sense Agent version. Contain user needs version 10.8470 or later of the Sense Agent, the Defender for Endpoint sensor component on each device. Read
MsSenseDllVersionunderHKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Advanced Threat Protection\Statusto check; successful onboarding alone does not prove a compatible version. - Device discovery. Automatic Contain device also requires device discovery set to Standard discovery.
Defender for Identity
- Configure the required audit events on the domain controllers that run the sensor.
- Validate the action accounts. By default the sensor impersonates the domain controller's LocalSystem account; if that configuration was changed, the replacement account still needs the rights to disable users. Detecting a compromised identity does not prove the sensor can disable it.
- Check that other automation will not re-enable accounts that disruption disabled, such as a script that keeps every active employee's account enabled.
Defender for Office 365
- Mailboxes hosted in Exchange Online.
- Mailbox auditing for at least MailItemsAccessed, UpdateInboxRules, MoveToDeletedItems, SoftDelete, and HardDelete.
Defender for Cloud Apps
- The Microsoft 365 connector with every option selected, including Microsoft Entra ID apps. A connector that exists but omits options, such as one collecting only Exchange activity, can degrade disruption or make critical actions fail, such as app governance[37] actions on OAuth-enabled apps.
Who can configure it
The roles that can configure automatic attack disruption include Security Operator, Security Administrator, Global Administrator, User Administrator, Authentication Administrator, Privileged Authentication Administrator, Directory Writers, and Helpdesk Administrator. Changing a device group's remediation level is a different procedure that requires Global Administrator or Security Administrator, so Security Operator alone cannot change it.
Takeaway: deploy every product whose signals or actions you expect, keep each product's prerequisites in place, and never use Semi to slow disruption down.
Sentinel automation rules
For example, your team wants every new phishing incident tagged, assigned to the email team, and set to Active. A Microsoft Sentinel automation rule[6] does that without any workflow code. Each rule has three parts, a trigger, conditions, and actions, and rules run one after another in an order you set. Sentinel is moving fully into the Microsoft Defender portal: after March 31, 2027, the Azure portal no longer supports it.
Triggers
| Trigger | Runs when |
|---|---|
| When incident is created | A new incident is created (for workspaces onboarded to the Defender portal, any new incident there) |
| When incident is updated | Status, owner, or severity changes; alerts are added; comments, tags, or tactics are added |
| When alert is created | A Sentinel Scheduled or NRT (near-real-time) analytics rule creates an alert, including an alert with no incident |
Use the created trigger for first triage and the updated trigger for anything that happens later, such as escalation when severity rises; a creation rule never reruns because an existing incident changed. Alert-triggered automation exists mainly for analytics rules that do not create incidents. Its only condition is the set of analytics rules it applies to, so it cannot filter on incident owner or entity properties.
Conditions
Conditions test incident properties, entity properties, and the analytics rule that produced the incident, and all of them must be true for the actions to run.
- Current state. Properties are evaluated at the moment the rule runs, so a later rule sees the changes an earlier rule made.
- State changes (update trigger only). The operators changed, changed from, changed to, and added fire on a specific transition. Severity equals High on an update trigger matches every later update of an incident that is already High; Severity changed to High matches the escalation itself.
- Updated by. Shows who made the change: a user, an application, a playbook, an automation rule, AIR, an alert grouping, or other sources. Excluding updates made by automation rules stops a rule from reacting to its own changes.
- Tags, individual versus collection. Any individual tag with does not contain
Protectedis true when any one tag passes, so an incident taggedProtectedandRoutinestill matches throughRoutine. To exclude every incident that carries the tag, use Collection of all tags with does not containProtected.
Actions
The built-in actions are adding a task, changing status (with a closing reason and comment when closing), changing severity, assigning an owner, adding tags, and running a playbook. One rule can serve many analytics rules, and its actions run in the order listed. A run-playbook action can call only a playbook whose trigger matches the rule's: incident-trigger playbooks from incident rules, alert-trigger playbooks from alert rules.
Order and timing
- Separate queues. Each trigger type has its own order queue, and rules run sequentially, never in parallel. Equal order numbers in one queue run in random order, so use distinct numbers when sequence matters, and place a rule that adds a tag before a rule that routes on it.
- Creation before update. When creation rules change a new incident, all applicable creation rules finish before the resulting update rules start.
- Two-minute playbook boundary. For a playbook running longer than two minutes, the rule moves to its next action two minutes after the playbook started[6], finished or not, so a closing action listed after a long enrichment playbook can run before the enrichment ends.
- Consolidated updates. After onboarding to the Defender portal, several changes to one incident within 5 to 10 minutes reach Sentinel as one update carrying only the latest change. Intermediate transitions are lost, so do not build workflows that depend on seeing every transient status.
An event fires a trigger, the rules in that trigger's queue run by order number, and each checks its conditions against the current state before running its actions in listed order (automation rules[6]), as the figure shows.
Suppression and reuse
To silence noise from a planned activity such as a penetration test, create an automation rule from one of its incidents: the analytics rule and entity conditions are prefilled and a closing action is proposed. Set an expiration date so the rule disables itself afterward, and keep the conditions narrow so unrelated incidents from the same detection still surface; disabling the analytics rule would stop detection entirely. To deploy rules as code, export them to Azure Resource Manager (ARM) template JSON. The file is workspace-independent and imports into other workspaces and tenants, unlike a Logic Apps workflow export, which carries none of the rule's trigger conditions or order.
Takeaway: pick the trigger for the lifecycle moment, write conditions against the state the rule will actually see, and sequence rules with distinct order numbers.
How a playbook receives and updates an incident
When the built-in actions run out, for example enriching an IP address from a threat feed, syncing a ServiceNow ticket, or posting to a Teams channel, the automation rule hands the incident to a playbook[3]: an Azure Logic Apps workflow that Sentinel runs. Because a playbook is a Logic Apps resource, it can add Logic Apps charges on top of Sentinel ingestion costs. A playbook receives incident, alert, or entity data through its Sentinel connector trigger, and connector actions such as Update Incident write changes back to the incident (Sentinel connector[38]).
Consumption or Standard
Playbooks run on either Logic Apps hosting model: Consumption (multitenant) or Standard (single-tenant, able to host multiple workflows). A Standard playbook for Sentinel must use a stateful workflow[39].
Triggers and their payloads
The Sentinel connector's triggers[38] are the playbook's own Logic Apps triggers, not the automation rule triggers; they decide what data the playbook receives, and an automation rule can run only a playbook that starts with its own trigger type[40] (incident with incident, alert with alert).
| Trigger | Payload | Typical use |
|---|---|---|
| Microsoft Sentinel incident | Incident properties, an Alerts array, an Entities array, and workspace information | Most scenarios, including automation rules on incident creation or update and manual runs on an incident |
| Microsoft Sentinel alert (preview) | One alert | Manual runs on alerts, and Sentinel Scheduled or NRT analytics rules that do not create incidents |
| Microsoft Sentinel entity | One entity | Manual runs from an investigation or a hunt |
The schemas differ, so a workflow built on one trigger is not interchangeable with another just because its actions look suitable. Selecting an alert property in an incident-trigger playbook creates a For each loop automatically, because one incident can hold several alerts.
Working with incidents and entities
- Update Incident and Add comments to incident identify their target by the Incident ARM ID, the incident's Azure Resource Manager resource identifier, not an alert ID. In a playbook that starts from an alert, call Alert - Get Incident first to retrieve the incident and its ARM ID.
- The Entities field is an array of mixed JSON entities, not a single object. Entities - Get IPs, Hosts, Accounts, URLs, or FileHashes filter it by type and expose that type's fields, still as an array to loop over. For other entity types, combine the Logic Apps Filter array and Parse JSON actions.
Templates
Playbook templates (preview) come from the templates tab of the Automation page, from Content hub solutions, and from the Sentinel GitHub repository. A template is not a running workflow: deploy it, then configure its connections. When a newer template version is published, playbooks created from it show an update-available label[41] on the Active playbooks tab; the label means a review is due, not that the deployed workflow has changed.
Takeaway: use the incident trigger unless you have a reason not to, address incidents by their ARM ID, and treat entities as arrays.
Playbook permissions: separate authorization boundaries
A playbook can fail even when the analyst who built it is an Owner, because the analyst's role does not grant Sentinel's service account or the playbook's connections their permissions. Treat the requirements as three separate permission checks, not three identities a single run passes through: two apply while the playbook runs (the Sentinel service account that starts it and the API connections its steps use), and the third, the Logic Apps and Sentinel roles people hold, decides who can edit, run, or attach the playbook.
- Sentinel service account. When an automation rule runs a playbook, or someone runs one manually on an incident, Sentinel uses its own service account. That account needs Microsoft Sentinel Automation Contributor[3] on the resource group that contains the playbook; after that, any automation rule can run any playbook in the group. Playbooks without the grant appear grayed out in the rule's playbook list. The role exists only for this purpose and is not a role for people who author playbooks.
- API connection identity. Connector steps use their configured API connections, and steps can share a connection. A Sentinel connection authenticated as Microsoft Sentinel Reader can use triggers and read actions, but Update Incident and Add comments to incident need Microsoft Sentinel Responder or Contributor on the target workspace (connector permissions[38]). Giving the workflow's author more Logic Apps rights does not change what the connection identity can do.
- Workflow authors and operators. For Consumption logic apps, Logic App Contributor edits, manages, and runs playbooks but cannot grant access, and Logic App Operator reads, enables, and disables them. For Standard, Logic Apps Standard Operator enables, disables, and resubmits workflows, Logic Apps Standard Developer creates and edits them, and Logic Apps Standard Contributor manages everything. On the Sentinel side, Microsoft Sentinel Playbook Operator runs playbooks manually[42], and Microsoft Sentinel Contributor attaches playbooks to rules.
A run depends first on the service account's grant[3] to start the playbook and then on the connection's role to update the incident, while people's roles are a separate check, not a run step, as the figure shows.
Granting the first permission is itself privileged: the person assigning Microsoft Sentinel Automation Contributor needs role-assignment authority at that scope, such as Microsoft.Authorization/roleAssignments/write. A Logic App Contributor who cannot make the assignment needs an access administrator to do it, not broader workflow permissions or extra connections.
Across tenants
With cross-workspace or Azure Lighthouse automation, Sentinel's execution permission is defined where the playbook lives[40], not where the automation rule is stored. When a managed security service provider (MSSP), signed in to its own tenant, configures a rule in a customer workspace that runs a playbook in the customer tenant, Sentinel needs execution permissions in both tenants: the usual grant in the customer tenant, plus a Lighthouse delegation that gives Azure Security Insights, the Microsoft application in the managing tenant's Microsoft Entra ID through which Sentinel receives this permission, Microsoft Sentinel Automation Contributor on the playbook's resource group. Delegated analyst access to the customer workspace does not cover this.
Takeaway: when access is denied, check the Sentinel service account's grant, the API connection's role, or the person's Logic Apps and Sentinel roles; when a playbook is missing from the rule's list, check trigger compatibility, and when a run fails, inspect its run history rather than assuming a permission failure.
Practice: matching each requirement to its Defender or Sentinel setting
A requirement is met by the Defender or Sentinel setting built for that job, and a related real feature fails it for a specific reason: an indicator[17], for example, acts on one named object, so it cannot stand in for an ASR rule[20], which blocks a behavior.
- Stop Office apps from launching child processes: an ASR rule. Controlled folder access protects folders, and an indicator matches named objects, not a behavior.
- ASR rules have no effect on devices running another antivirus product: ASR needs Defender Antivirus active with real-time protection, and EDR in block mode does not satisfy that requirement.
- Block a whole subnet with one indicator: not possible, because IP indicators accept single addresses only, without ranges or CIDR notation.
- Quiet a benign alert but keep resolved alert and incident records: Resolve alert. Hide alert prevents the incident, and Set as behavior leaves no alert record.
- Hide an alert and let its file run: two steps, a tuning rule plus an Allow indicator, because tuning alone allows nothing.
- Email the team when a remediation fails: an Actions notification rule filtered on failed status, since incident severity says nothing about whether an action ran.
- A pending remediation was never approved and nothing happened: the seven-day timeout counts as a rejection.
- Require approval before attack disruption contains anything: Semi automation does not provide an approval gate, and an exclusion prevents the selected automatic response rather than queuing it for approval.
- Disable a cloud-only account without a Defender for Identity sensor: no sensor is needed, because cloud-only accounts are disabled in Entra ID through Microsoft's enterprise application.
- Assign an owner, add a tag, and set new incidents to Active: an automation rule; a playbook adds nothing here.
- Escalate when severity later rises to High: the When incident is updated trigger with a changed to condition, not the creation trigger.
- A playbook is grayed out when you add it to an automation rule: the Sentinel service account lacks Microsoft Sentinel Automation Contributor on the playbook's resource group, and a user with role-assignment authority at that scope can grant it.
- The playbook runs but cannot update the incident: the API connection identity needs Responder or Contributor; the author's Logic Apps roles are irrelevant.
- A device matches two device groups with different remediation levels: only the highest-ranked group applies, and levels never combine.
Takeaway: identify the stage first, then the exact mechanism, for example an ASR rule for a behavior on the device, an indicator for a named object, alert tuning for what analysts see, and an automation rule or playbook for Sentinel incident handling. A genuine feature doing a different job still fails, such as Semi automation offered as an approval gate for attack disruption.
The four automation stages at a glance
| Aspect | Prevent and collect | Tune and notify | Built-in response | Custom orchestration |
|---|---|---|---|---|
| Question it answers | What does the device block or record? | Which alerts surface, and who hears about them? | What does Defender do on its own? | What does your own workflow do? |
| Main settings | Advanced features, indicators, ASR rules in endpoint security policies, custom data collection | Alert tuning rules, email notification rules | AIR remediation levels, Action center approvals, automatic attack disruption | Sentinel automation rules, playbooks |
| Who writes the decision logic | Microsoft engines enforce the policies you choose | You, through rule conditions | Microsoft; you set levels, prerequisites, and exclusions | You, through rule conditions and workflow steps |
| What scopes it | Device groups (indicators); Microsoft Entra groups (endpoint security policies) | Evidence conditions, service sources, device groups | Device groups (remediation level); per-asset exclusions | Analytics rules plus incident and entity conditions |
| Where you configure it | Defender portal: Settings > Endpoints, Endpoint security policies | Defender portal: Settings > Microsoft Defender XDR, Settings > Endpoints | Defender portal: Device groups, Action center, Automated response settings | Sentinel automation page; Azure Logic Apps |
| Common mix-up | Assuming EDR in block mode satisfies the ASR active-antivirus requirement | Expecting a hidden alert to also allow the file | Expecting Semi automation to hold back attack disruption | Calling a playbook whose trigger does not match the rule's trigger |
Decision tree
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.
- Incident email rules select notifications by alert source, severity, and device group
Configure incident notification rules under Settings > Microsoft Defender XDR > Email notifications > Incidents. Rules can filter by alert severity, service or detection source, and device group, allowing different SOC teams to receive relevant incidents rather than every alert.
Trap Using an Actions notification rule, which filters response operations rather than incident alerts.
2 questions test this
- You are creating one incident email notification rule in Microsoft Defender XDR for your SOC managers. They want Medium and High severity alerts from Microsoft Defender for Endpoint EDR and every seve
- Your identity security team wants an email whenever a Microsoft Defender XDR incident includes High severity alerts from Microsoft Defender for Identity on devices in the Tier0 device group. Other tea
- Response action notifications can distinguish failures from completed actions
Use the Actions tab of Defender XDR email notifications to select manual or automated action sources, action types, device groups, and completed or failed status. Selecting All device groups covers current and future groups. Response action email notifications currently do not support response actions contained in custom detections.
Trap Using incident severity as a proxy for remediation failure, which describes alert risk rather than action execution status.
2 questions test this
- A custom detection rule in Microsoft Defender XDR automatically isolates devices when it matches. You created a notification rule on the Actions tab that covers automated and manual sources, the Isola
- The SOC lead wants an email only when an automated response action, such as device isolation by automatic attack disruption or automated investigation, fails to complete on any current or future devic
- Threat analytics notifications follow report publication and updates
Create a notification rule on the Threat analytics tab to receive emails when reports are published or updated. Select all reports or filter by report type or tag; a matching report need not represent an incident in your tenant. Add at least one recipient and use Send test email to verify delivery.
Trap Creating an alert notification rule, which subscribes to tenant detections rather than threat report updates.
2 questions test this
- Your threat intelligence team wants an email whenever Microsoft publishes a new threat analytics report about ransomware or updates an existing one, even when no related alerts or incidents exist in y
- You are creating a threat analytics notification rule in Microsoft Defender XDR for the intelligence team, filtered to reports with a specific tag. Before you finish, you must confirm that the team's
- Notification management requires security-settings permission and respects device scope
Managing incident and action email rules requires Manage security settings permission, or Security Administrator under basic permissions management. With RBAC, administrators can create, edit, delete, and receive notifications only for device groups they are permitted to manage. Adding an email recipient does not expand the administrator's device scope.
Trap Assigning Security Reader to a notification administrator, which supplies visibility without security-settings management.
2 questions test this
- Your organization uses Microsoft Defender for Endpoint role-based access control. AdminEU has the Manage security settings permission and manages only the EU device groups. AdminEU tries to create an
- Your organization uses basic permissions management in Microsoft Defender for Endpoint. NotifyAdmin1 must create and edit incident and response action email notification rules in Microsoft Defender XD
- Endpoint alert emails require their own severity and device-scoped notification rule
Configure endpoint alert subscriptions under Settings > Endpoints > General > Email notifications, separately from the XDR incident, action, and threat analytics subscriptions. Use Add item to select alert severity, devices or device groups, and recipient email addresses, then send a test email and save the rule. If matching alerts do not arrive, inspect Junk Email, the mail security product, and mailbox rules that move messages. New recipients receive notifications for alerts triggered after they were added rather than a replay of earlier alerts.
Trap Editing an XDR incident subscription to repair missing endpoint-alert emails, leaving the separate endpoint notification rule unchanged.
2 questions test this
- Yesterday you added Analyst5 as a recipient to an endpoint alert notification rule under Settings > Endpoints > General > Email notifications. Analyst5 expected to receive emails for the High severity
- Device administrators receive email for new Microsoft Defender for Endpoint alerts on the Kiosks device group. After a cleanup, those alert emails stopped. An engineer edited the incident rule under S
- Hide alert suppresses endpoint incidents without deleting hunting evidence
Use the Hide alert action in an alert tuning rule for known benign Defender for Endpoint activity that should not create incidents. Hidden alerts remain in AlertInfo and AlertEvidence for hunting. This action is available for Defender for Endpoint alerts, not every Defender workload.
Trap Creating an antivirus exclusion, which changes protection coverage rather than only alert visibility.
2 questions test this
- A Microsoft Defender for Identity alert fires repeatedly for an approved directory synchronization service account used by the identity team. An analyst creates an alert tuning rule for it in Microsof
- A nightly IT maintenance script triggers the same Microsoft Defender for Endpoint alert on 300 devices, and the change board approved the activity as expected behavior. You need to stop these alerts f
- Resolve alert tuning creates matching records in resolved status
Choose Resolve alert when matching alerts and associated incidents should be automatically resolved rather than hidden. The alert and incident records still exist with resolved status, providing a record of expected activity. Scope the rule to evidence that reliably identifies the approved activity.
Trap Choosing Hide alert when resolved incident records are required, because hiding prevents incident creation.
2 questions test this
- Your quarterly penetration test triggers known Microsoft Defender for Endpoint alerts on the testing team's devices. Auditors require a record of each alert and its incident, but analysts must not hav
- An approved backup agent, C:\Program Files\Bkp\bkagent.exe, which the service BkpSvc starts, triggers Microsoft Defender for Endpoint alerts on file servers. You create a Resolve alert tuning rule in
- Set as behavior retains signals as behavior data instead of alerts
Set as behavior converts matching signals into behaviors that do not appear in the alert queue or trigger incidents. Query BehaviorInfo and BehaviorEntities to retain investigative visibility. This tuning action is not supported for Defender for Cloud or Defender for Office 365 alerts.
Trap Selecting Resolve alert, which retains alert records rather than converting signals into behavior records.
2 questions test this
- A Microsoft Defender for Endpoint detection for an approved remote management tool floods the alert queue with hundreds of alerts every day. The SOC wants the matching signals removed from the alert q
- An analyst wants to tune a recurring Microsoft Defender for Office 365 alert for an approved mail-flow test by using the Set as behavior action, so that hunters keep the data in behavior tables withou
- Alert tuning conditions combine evidence properties rather than just display titles
Alert tuning supports evidence such as files, processes, and scheduled tasks, with up to 200 conditions per rule. Combine conditions with AND, OR, and grouping; condition values are case-insensitive and some properties support wildcards. An alert type is identified by IoaDefinitionId, so a display-title change does not necessarily identify a new type.
Trap Matching only an incident's display title, which is not the evidence-based alert type used by tuning.
2 questions test this
- In Microsoft Defender XDR, you need one alert tuning rule that resolves Microsoft Defender for Endpoint alerts only when agent.exe runs and its parent process is either svc1.exe or svc2.exe. Alerts in
- You created an alert tuning rule in Microsoft Defender XDR that uses the Resolve alert action and a single File condition. The file name value, copied from a change ticket, is UPDATER.EXE. On devices,
- Scoped device-group correlation trades global incident context for local SOC access
Enable Restrict correlation to within scoped device groups when local SOC teams must act on incidents confined to their accessible groups. Cross-group alerts no longer form one incident, so the global SOC sees separate incidents by device group. The setting affects future correlations only.
Trap Using an email device-group filter to separate incidents, which changes notification recipients without changing correlation.
2 questions test this
- You turned on Restrict correlation to within scoped device groups in Microsoft Defender for Endpoint advanced features so that regional SOC teams can act on incidents for their own device groups. The
- Your company uses Microsoft Defender for Endpoint with regional device groups, and each regional SOC can access only its own device group. Several open incidents contain alerts from devices in more th
- Built-in alert tuning preserves investigation and can reactivate suppressed alerts
Microsoft's built-in tuning rules reduce noise from common benign activity without disabling associated automated investigations or email notifications. If an automated investigation finds malicious or suspicious activity, Defender reactivates the suppressed alert. These built-in rules do not apply to custom detection alerts or Custom TI alerts. Use custom tuning when an organization-specific condition needs its own suppression policy.
Trap Relying on built-in benign-activity suppression to quiet a custom detection, which lies outside the built-in rules' scope.
2 questions test this
- Your company uses Microsoft Defender XDR with Microsoft Defender for Office 365 Plan 2. A built-in alert tuning rule suppresses an alert for common benign email activity. A manager worries that the su
- A custom detection rule in Microsoft Defender XDR generates many alerts for a benign backup job that your organization runs every hour. A manager expects Microsoft's built-in alert tuning rules for co
- Custom tuning can target one alert type or matching alerts across selected services
When creating a tuning rule from an alert, choose either the selected alert type or Any alert type based on certain conditions. For the latter, select the service sources to which the rule should apply; only services you have permission to manage are offered. Use the selected-type option when the approved exception concerns one detection rather than every detection involving the same evidence. Broadening both type and service scope can suppress unrelated alerts that happen to satisfy those evidence conditions.
Trap Selecting any alert type across all services for one benign detection, extending the exception to unrelated detections sharing its evidence.
2 questions test this
- To silence one benign Microsoft Defender for Endpoint detection caused by the approved file C:\Tools\agent7.exe, Analyst2 created a tuning rule from the alert page with the Resolve alert action. Analy
- Alert3 is a Microsoft Defender for Endpoint detection triggered by the approved inventory script inv.ps1. Security approved resolving this detection automatically, but other detections that involve in
- Alert suppression does not itself authorize the triggering file to run
Hiding or resolving alerts changes alert handling, not the allow decision for a file that triggered them. After creating a tuning rule from an alert, the Successful rule creation page can separately add selected evidence as Allow indicators. Select the approved file and its intended scope, then save that allowance when preventing future blocking is also required.
Trap Using Resolve alert tuning as an application-unblocking exception, although changing alert status does not create the file's scoped Allow indicator.
2 questions test this
- You create an alert tuning rule from an alert raised when Defender for Endpoint blocked UpdateHelper.exe, an approved tool. The Successful rule creation page appears after you save the rule. Future bl
- Defender for Endpoint blocks an approved finance tool, FinCalc.exe, and raises an alert. An analyst created a Resolve alert tuning rule from the alert, so the alerts now resolve automatically, but Fin
- EDR in block mode remediates post-breach artifacts with passive Defender Antivirus
Enable EDR in block mode to remediate malicious artifacts detected by endpoint detection and response even when Microsoft Defender Antivirus runs in passive mode. This complements another primary antivirus product rather than making Defender Antivirus the primary real-time scanner. Configure the feature under Settings > Endpoints > Advanced features.
2 questions test this
- Your company uses a non-Microsoft antivirus product as the primary antivirus on all Windows devices, and Microsoft Defender Antivirus runs in passive mode. The devices are onboarded to Microsoft Defen
- Your company plans to turn on EDR in block mode in Microsoft Defender for Endpoint for devices that run a non-Microsoft antivirus with Microsoft Defender Antivirus in passive mode. A manager believes
- Custom network indicators enable explicit IP, domain, and URL decisions
Turn on Custom network indicators before using an organization-specific list of IP addresses, domains, or URLs to allow or block destinations. Use web content filtering instead when the requirement is to block categories of websites rather than named destinations. These are separate controls in Endpoint advanced features.
Trap Selecting web content filtering for a specific IP block, because its policy model selects content categories.
2 questions test this
- Compliance requires that users on corporate Windows devices can't reach any gambling website, including new gambling sites that appear after the policy is created. The SOC doesn't maintain or buy any
- Your SOC must block devices from reaching five named URLs that a partner reported as malicious, and compliance also requires blocking every site in the Adult content category, including new sites that
- Allow or block file requires active Defender Antivirus and cloud protection
Enable Allow or block file when file indicators must prevent devices from reading, writing, or running identified files. Microsoft Defender Antivirus must be the active antimalware solution and cloud-based protection must be enabled. Merely onboarding a device does not establish these prerequisites.
Trap Relying on passive antivirus plus EDR block mode as the stated prerequisite for Allow or block file, which requires active antivirus.
2 questions test this
- You turned on Allow or block file in Microsoft Defender for Endpoint and created a file hash indicator to block a tool. Devices run a non-Microsoft antivirus, so Microsoft Defender Antivirus is in pas
- Microsoft Defender Antivirus is the active antimalware solution on all Windows devices onboarded to Microsoft Defender for Endpoint. You turned on Allow or block file and created a file indicator, but
- Tamper protection prevents unauthorized changes to protected antivirus settings
Enable tamper protection to stop applications and other unauthorized methods from changing protected Microsoft Defender Antivirus settings. Its purpose is to preserve security configuration during attacks. It is distinct from a rule that blocks a particular application behavior.
Trap Using an ASR rule as a substitute for locking antivirus configuration, because ASR targets risky software behaviors.
2 questions test this
- Your company runs a non-Microsoft antivirus product on some Windows devices, so Microsoft Defender Antivirus is in passive mode on them. Before turning on tamper protection for all devices in Microsof
- During a recent attack, malware ran a script that turned off real-time protection in Microsoft Defender Antivirus on several devices before it encrypted files. You need to stop apps, scripts, and othe
- Automatic alert resolution preserves analyst-set statuses
Automatically resolve alerts closes alerts when no threats are found or detected threats are remediated. It does not overwrite a status that an analyst manually set to In progress or Resolved. Since active alerts contribute to device risk, automatic resolution can also affect the device's risk level.
Trap Creating broad benign-activity suppression to close remediated threats, which ignores the remediation-based eligibility of automatic resolution.
2 questions test this
- Analysts spend time closing Microsoft Defender for Endpoint alerts after automated investigations already remediated the threats or found no threats. A colleague proposes a broad alert tuning rule tha
- Automatically resolve alerts is turned on in Microsoft Defender for Endpoint advanced features. An analyst manually set Alert1 to In progress while investigating Device7. An hour later, the threat det
- The Cloud Apps integration exposes cloud application use seen by endpoints
Enable Microsoft Defender for Cloud Apps integration to forward Defender for Endpoint signals for cloud application visibility. The forwarded information is stored and processed in the Defender for Cloud Apps data location. Use this integration for application-use insight, not as an alternative to endpoint onboarding.
2 questions test this
- Before you turn on the Microsoft Defender for Cloud Apps integration in Microsoft Defender for Endpoint advanced features, your privacy officer asks where the Defender for Endpoint signals forwarded f
- Your security team wants to discover which cloud applications employees use from corporate Windows devices, including apps accessed outside the corporate network, by using signals that Microsoft Defen
- Device discovery uses protected endpoints to reveal unmanaged network devices
Enable Device discovery in Endpoint advanced features to find unmanaged devices through endpoints already onboarded to Defender for Endpoint. Discovery adds visibility to the device inventory and helps assess risks without deploying a separate discovery appliance. Review onboarding status and onboard eligible discovered endpoints separately when they need endpoint protection. An inventory entry produced by discovery is not evidence that the discovered device has a Defender sensor.
Trap Treating a discovered workstation's inventory entry as completed onboarding, although discovery can list devices with no installed sensor.
2 questions test this
- Your company has thousands of onboarded Windows devices, but the network team suspects that many unmanaged laptops, printers, and IoT devices are connected to the corporate network. You need to find t
- After you turn on device discovery in Microsoft Defender for Endpoint, Workstation9 appears in the device inventory. A manager concludes that Workstation9 is now protected by Defender for Endpoint and
- Live response session availability requires feature enablement as well as analyst permissions
Under Settings > Endpoints > Advanced features, enable Live response for device sessions and configure the separate Live response for servers switch for server sessions. Save preferences after changing the relevant switch. These controls make sessions available to appropriately authorized users; assigning a response role alone does not turn the feature on. When an authorized responder cannot open a server session, check the server-specific enablement rather than increasing the responder's privileges.
Trap Granting a broader administrator role to overcome disabled server live response, although role assignment does not enable the server capability.
2 questions test this
- Responder1's Microsoft Defender for Endpoint custom role includes advanced live response capabilities and is assigned to the Entra group that has access to both the Workstations and Servers device gro
- Your company uses Microsoft Defender for Endpoint Plan 2 with Defender for Endpoint RBAC custom roles, and Live response is turned on in Advanced features. Analyst5's custom role includes View data an
- The Intune connection must be enabled in both products to share endpoint risk
Enable the Microsoft Intune connection in Defender for Endpoint and complete the corresponding integration in Intune. This connection shares device data for risk-based compliance and Conditional Access enforcement. It requires an active Intune environment and appropriate licenses rather than being supplied by the Endpoint switch alone. Configuring this integration establishes the risk-sharing path; it does not itself author the access policies that consume that risk.
Trap Turning on only the Defender-side Intune switch, leaving the required Intune-side connection incomplete.
2 questions test this
- You turned on Microsoft Intune connection in Microsoft Defender for Endpoint advanced features so that Defender device risk can be used in Intune device compliance policies. Intune-enrolled, Microsoft
- The Microsoft Intune connection is now enabled in both Microsoft Defender for Endpoint and Intune. The security lead expects devices with a high device risk level to lose access to Microsoft 365 apps
- Web category blocking requires both a filtering policy and browser-appropriate enforcement
Turn on Web content filtering, then create a policy specifying blocked categories and the intended device groups. On Windows, enable SmartScreen for Microsoft Edge and network protection in block mode for supported non-Microsoft browsers. On macOS and Linux, network protection in block mode is required for all supported browsers, including Edge. A policy with no categories selected audits web activity rather than blocking categories.
Trap Leaving network protection in audit mode while expecting Chrome category blocks, although its enforcement path requires block mode.
2 questions test this
- An administrator turned on web content filtering in Microsoft Defender for Endpoint advanced features and created a policy for the Contractors device group but didn't select any categories, planning t
- A web content filtering policy in Microsoft Defender for Endpoint blocks the Gambling category for the Sales device group. On Windows 11 devices, gambling sites are blocked in Microsoft Edge but still
- Authenticated telemetry protects the dashboard from spoofed telemetry
Turn on Authenticated telemetry under Endpoint advanced features when protecting dashboard telemetry integrity. This setting prevents spoofing telemetry into the dashboard. It addresses the trustworthiness of incoming telemetry rather than which web destinations an endpoint may access.
- Hiding potential duplicate devices changes inventory visibility rather than deleting evidence
Hide potential duplicate device records matches records by hostname and last seen time and keeps the most accurate record visible. It hides duplicates from Device inventory, vulnerability management pages, and public machine-data APIs. The records remain available in global search, advanced hunting, alerts, and incidents. The setting is enabled tenant-wide by default and can be turned off to show those duplicate records again.
Trap Using duplicate-record hiding as an evidence-deletion mechanism, although investigative surfaces retain the hidden records.
- Endpoint alert sharing supplies Purview insider risk with alerts and triage status
Enable Share endpoint alerts with Microsoft Compliance Center to send endpoint security alerts and their triage status to the Microsoft Purview portal. With the relevant insider-risk policy indicators configured, the integration shares alerts for applicable users with insider risk management. Forwarded data is stored in the same location as Office 365 data. Choose this sharing control for insider-risk consumption rather than the Cloud Apps integration used for cloud-application visibility.
Trap Enabling Cloud Apps integration to supply Purview insider-risk alerts, routing endpoint signals to the wrong consuming service.
- Download quarantined files preserves a secure copy for later retrieval
The Download quarantined files advanced feature backs up quarantined files in a secure, compliant location so responders can download them directly from quarantine. The setting is enabled by default. Check this evidence-preservation setting when planning later retrieval rather than treating file blocking or live response enablement as the backup mechanism.
Trap Using live response enablement as assurance that quarantine has a downloadable backup, although interactive session access does not configure the quarantine backup feature.
- Show user details adds Entra profile context to account investigations
Enable Show user details in Endpoint advanced features to expose profile information stored in Microsoft Entra ID while investigating user account entities. Available details include the user's picture, name, title, and department in views such as the alert queue and device details page. This switch supplies identity context rather than changing an account's access permissions.
Trap Reaching for the Defender for Cloud Apps integration to display an account's department, although that integration forwards endpoint signals for application-use visibility.
- Default to streamlined connectivity changes the onboarding package default without removing standard connectivity
Enable Default to streamlined connectivity when onboarding devices in the Defender portal to make the streamlined package the default for supported operating systems. The standard package remains available through an explicit selection on the onboarding page. This setting controls the default package choice rather than forcing every onboarding operation to use streamlined connectivity.
Trap Turning off the tenant's streamlined default merely to obtain one standard onboarding package, although the onboarding page still offers that package explicitly.
- Endpoint indicators specify an action, duration, and device-group scope
Configure an endpoint indicator's action, expiration, and device-group scope to apply a threat decision only where and while it is needed. Indicators can represent files, certificates, IP addresses, domains, or URLs. An indicator is a detection or enforcement rule, not merely a saved hunting search.
Trap Adding an IOC only to a Sentinel watchlist, which does not configure endpoint prevention actions.
2 questions test this
- You have Microsoft Defender for Endpoint Plan 2. The incident team identified a malicious executable hash that must be blocked only on the Servers device group, and only until the end of the current m
- Your company uses Microsoft Defender for Endpoint Plan 2 and Microsoft Sentinel. Threat intelligence reports that the domain malware-cdn.example is distributing payloads to finance users. You need to
- IP indicators do not accept address ranges or wildcards
Specify individual IP addresses for endpoint IP indicators; wildcards and ranges are not supported. IPv4 uses dotted-quad notation, while the documented IPv6 format includes all eight segments. A subnet-level network requirement therefore cannot be represented by entering a CIDR range as one indicator.
Trap Entering a firewall-style CIDR network into the indicator field, which does not support ranges.
2 questions test this
- You have Microsoft Defender for Endpoint Plan 2 with custom network indicators turned on and network protection in block mode. Users browse only with Microsoft Edge. A phishing site, login.fabrikam.ex
- You have Microsoft Defender for Endpoint Plan 2 with custom network indicators turned on. A threat report lists every host in the external network 203.0.113.0/24 as attacker infrastructure. You need t
- Domain indicators cover subdomains while HTTPS path matching depends on Edge
A domain indicator such as example.com covers that domain and its subdomains. A URL-path indicator targets resources under the specified path instead. HTTPS URL-path matching is supported in Microsoft Edge, while HTTP URL paths can be matched across browsers.
Trap Choosing an HTTPS path indicator for browser-independent path blocking, because encrypted path matching is Edge-specific.
2 questions test this
- You have Microsoft Defender for Endpoint Plan 2 with custom network indicators turned on and network protection in block mode, and users browse only with Microsoft Edge. You create a domain indicator
- You have Microsoft Defender for Endpoint Plan 2 with custom network indicators and network protection in block mode. Users browse with Microsoft Edge and Google Chrome, which has QUIC and Encrypted Cl
- Certificate indicators apply decisions to files signed by a certificate
Use a certificate indicator when the allow or block decision should follow a signing certificate rather than one file version. Certificate indicators accept CER or PEM files. File-hash indicators identify individual file content, so changed application versions can require different hashes.
Trap Blocking one executable hash to cover every future release from its publisher, because changed file content changes the hash.
2 questions test this
- You have Microsoft Defender for Endpoint Plan 2 with Defender Antivirus active and cloud-based protection enabled. A prohibited remote-access tool ships a new build every two weeks, and every build is
- You have Microsoft Defender for Endpoint Plan 2. To block an internally banned application, you are creating a certificate indicator from the application's leaf signing certificate. The certificate te
- A scoped Allow indicator can exempt a business site from category filtering
When a team needs one site in an otherwise blocked web category, create an Allow domain indicator scoped to that team's device group. This preserves category-based blocking for other users and sites. Allow indicators do not generate alerts by design.
Trap Disabling the entire web content filtering category, which removes the restriction beyond the required business exception.
2 questions test this
- You have Microsoft Defender for Endpoint Plan 2 with web content filtering blocking the Social networking category for all device groups. The marketing team, whose devices are in the Marketing device
- You have Microsoft Defender for Endpoint Plan 2. You created a domain indicator with the Allow action, scoped to the Marketing device group, so that the team can reach one site in a category that web
- Indicator actions distinguish observation, bypassable warnings, and enforced remediation
Select Audit to alert on an indicator match without blocking, Warn to offer a user-bypassable warning, or Block execution to prevent execution without that bypass. Block and remediate also applies remediation and is supported for files and certificates, not IP addresses, URLs, or domains. File indicators support all these actions, while certificates support only Allow or Block and remediate. Choose both the indicator type and action from the required outcome rather than assuming every object supports an audit or warning stage.
Trap Selecting Audit for a certificate indicator to stage a publisher policy, although certificates offer only Allow or Block and remediate.
2 questions test this
- You have Microsoft Defender for Endpoint Plan 2. Threat intelligence flags a file hash as suspicious but unconfirmed, and the file belongs to an approved line-of-business tool. You need an alert each
- During an incident, you create three Microsoft Defender for Endpoint indicators: a file hash for a dropper, a URL for the dropper's download page, and the dropper's leaf signing certificate. Defender
- ConnectionSuccess can coexist with a successfully enforced network indicator
Network protection determines whether to allow or block website access after the TCP three-way handshake completes. A ConnectionSuccess record describes success at the TCP layer, not a final decision to permit the website. Inspect the associated block or alert evidence before declaring that the network indicator failed. Recreating the indicator solely because the handshake succeeded addresses the wrong layer of the connection.
Trap Treating ConnectionSuccess as proof that a blocked site was usable, confusing transport establishment with the later network-protection verdict.
2 questions test this
- You have Microsoft Defender for Endpoint Plan 2 with network protection in block mode. A junior analyst sees ConnectionSuccess events in DeviceNetworkEvents for a domain blocked by an indicator and wa
- You have Microsoft Defender for Endpoint Plan 2 with network protection in block mode and an IP indicator that blocks 198.51.100.20. A user's device shows an alert that the connection was blocked, but
- Antivirus exclusions can defeat file and certificate indicator blocking
File and certificate indicators do not block exclusions defined for Microsoft Defender Antivirus. When an apparently valid blocking indicator does not stop a matching file, inspect the effective antivirus exclusions and correct an unintended exception. Adding the same blocking hash again does not override the exclusion. Preserve an exception only when its security tradeoff is intentional and approved.
Trap Adding a certificate block to overcome an antivirus file exclusion, although certificate indicators honor that exclusion boundary too.
2 questions test this
- You have Microsoft Defender for Endpoint Plan 2 with Defender Antivirus active. An approved Defender Antivirus folder exclusion covers C:\Vendor\Agent. A malicious signed executable placed in that fol
- You have Microsoft Defender for Endpoint Plan 2 with Defender Antivirus active. You created a file indicator with Block execution for the hash of tool.exe, yet tool.exe still runs on Device1 from C:\T
- Cloud Apps synchronization can overwrite local indicator alert settings
For indicators synchronized from Defender for Cloud Apps, the sanctioned or unsanctioned application policy is authoritative over locally edited indicator settings. Unsanctioned applications enable Generate Alert, and clearing it in Defender for Endpoint can be reversed by the next synchronization. Diagnose repeated reversions at the originating Cloud Apps policy rather than repeatedly editing the generated indicator. Sanctioned or allowed applications use the no-alert setting, but changing an application's sanction status also changes the underlying access decision.
Trap Repeatedly clearing Generate Alert on a synchronized unsanctioned-app indicator, although the source Cloud Apps policy restores its setting.
2 questions test this
- You have Microsoft Defender for Endpoint Plan 2 integrated with Microsoft Defender for Cloud Apps. App1 was tagged Unsanctioned with a scoped profile that blocks it only for the Sales device group. Po
- You have Microsoft Defender for Endpoint Plan 2 integrated with Microsoft Defender for Cloud Apps. An app marked Unsanctioned in Defender for Cloud Apps produced a synced indicator in Defender for End
- Application control is preferable to a succession of hashes for durable application blocking
Use App Control for Business or AppLocker when the goal is to prevent an application persistently rather than stop one identified malicious file. Applications commonly contain multiple files, so a hash indicator for one component does not express the complete application restriction. A file indicator is appropriate as an immediate containment measure for a known file, not as the primary long-term application-control policy.
Trap Blocking only the main executable's hash as a durable application ban, leaving other application components outside the indicator's identity match.
- Block and Warn indicator alerts can ignore custom severity and title
Microsoft documents an indicator alert limitation in which Block and Warn produce generic informational alerts rather than alerts with the configured custom title and severity. Audit alerts use the customer-provided severity. Validate alert presentation against the selected action before diagnosing an informational block alert as a failure to save a high-severity configuration.
Trap Repeatedly raising a Block indicator's custom severity to force a high-severity alert, although its documented alert path produces generic informational output.
2 questions test this
- You have Microsoft Defender for Endpoint Plan 2. During a two-week evaluation of a suspicious domain, you need every device connection to it to raise an alert that uses your custom title and High seve
- You have Microsoft Defender for Endpoint Plan 2. You created a URL indicator with the Block execution action, the custom alert title Contoso Ransomware C2, and severity High. When devices are blocked,
- Warn indicator bypass depends on Windows Security notification settings
For an indicator configured with Warn, enable Files or activities are blocked under Windows Security's Virus & Threat Protection notifications so the user receives the bypass prompt. The corresponding FilesBlockedNotificationDisabled registry value must be 0. When the intended warning interaction is missing, inspect notification delivery rather than changing the indicator into a permanent Allow exception.
Trap Replacing Warn with Allow to repair a missing bypass prompt, removing the warning decision instead of enabling its blocked-activity notification.
2 questions test this
- You have Microsoft Defender for Endpoint Plan 2. A URL indicator set to Warn is supposed to let field staff continue to a partner site after a warning, but on several devices users are simply blocked
- You have Microsoft Defender for Endpoint Plan 2 with Defender Antivirus active. A file indicator with the Warn action covers App1.exe so that users can continue after acknowledging a risk message. Use
- EnableFileHashComputation supports indicator enforcement against trusted application hashes
EnableFileHashComputation calculates file hashes during scans and supports IoC enforcement against hashes belonging to trusted applications. It is disabled by default and is enabled manually through Group Policy alongside the Allow or block file configuration. Evaluate this setting when validating trusted-application hash enforcement rather than assuming the portal's file-control switch establishes hash computation.
Trap Using successful file-indicator creation as proof that trusted application hashes are being computed during scans, although that computation has a separate disabled-by-default setting.
- Endpoint indicator capacity stops at 15,000 per tenant
Defender for Endpoint limits the tenant to 15,000 indicators, and Microsoft does not support increasing that limit. Size feed imports against the tenant-wide allowance rather than treating each device group as a separate capacity pool. A feed exceeding the allowance needs selection and lifecycle management instead of a quota-increase dependency.
Trap Splitting an oversized indicator feed across device groups to obtain extra capacity, although the limit is counted at tenant scope.
- Custom endpoint collection stores additional telemetry in a selected Sentinel workspace
Custom data collection captures endpoint events beyond default telemetry and requires Defender for Endpoint Plan 2 plus a connected Microsoft Sentinel workspace. Select that workspace explicitly in Custom Data Collection even if it is already connected. The current feature supports one Sentinel workspace per tenant, and Sentinel ingestion charges apply.
Trap Extending XDR retention to collect missing event types, which preserves collected telemetry without configuring additional collection.
2 questions test this
- Your company uses Microsoft Defender for Endpoint Plan 2 in a single tenant. The EU and US security teams each have their own Microsoft Sentinel workspace, WS-EU and WS-US. You plan custom data collec
- You have a Microsoft 365 E5 subscription that uses Microsoft Defender for Endpoint Plan 2 and a connected Microsoft Sentinel workspace. For threat hunting, you need every PowerShell script execution o
- Selective custom collection uses dynamic tags rather than manual tags
Scope a custom data collection rule to all applicable devices or to devices with dynamic tags from Asset Rule Management. The dynamic tag rule must have run at least once; manual static tags are not supported. If expected devices produce no events, verify tag evaluation as well as the collection rule.
Trap Applying a manual device tag for collection targeting, which is not supported by custom collection scope.
2 questions test this
- You have Microsoft Defender for Endpoint Plan 2. Ten minutes ago you created a dynamic tag rule named Tier0 in Asset rule management, and then a custom data collection rule scoped to devices tagged Ti
- You have Microsoft Defender for Endpoint Plan 2 with custom data collection enabled. You need a custom collection rule that gathers file events only from the 120 finance devices, and the targeting mus
- Custom collection pauses a rule at its per-device rolling event cap
Each custom collection rule can capture up to 75,000 events per device in a rolling 24-hour window. Collection for that rule pauses on a device that reaches the limit until the window resets. Refine table, action, and event conditions when overly broad collection exhausts the allowance.
Trap Increasing workspace retention to fix stopped collection, which changes storage duration rather than the device collection cap.
2 questions test this
- You have Microsoft Defender for Endpoint Plan 2. A custom data collection rule named NetRule collects all network connections from Device1. During a busy morning, NetRule's events from Device1 stopped
- You have Microsoft Defender for Endpoint Plan 2 with custom data collection. RuleNet collects network events and RuleProc collects process events from the same 200 devices. At 09:00, RuleNet reached 7
- Custom collection requires supported Windows versions and a sufficiently recent client
Custom endpoint collection supports Windows 10 and Windows 11 with a minimum client version of 10.8805, and Windows Server 2019 or later. Windows 10 requires ESU enrollment. Check these prerequisites before investigating missing rule deployment on an otherwise onboarded endpoint.
2 questions test this
- You have Microsoft Defender for Endpoint Plan 2 with custom data collection. RuleSrv targets devices that have the dynamic tag CustomNet, and Asset Rule Management shows that the tag rule ran 30 minut
- You have Microsoft Defender for Endpoint Plan 2 with custom data collection. RuleScr targets all applicable client devices. Windows 11 devices send custom script events, but Windows 10 22H2 devices th
- Custom collection changes can take an hour to reach targeted devices
Creating or editing a custom collection rule typically takes 20 minutes to one hour to deploy. Verify events in DeviceCustomFileEvents, DeviceCustomScriptEvents, DeviceCustomNetworkEvents, DeviceCustomProcessEvents, or DeviceCustomImageLoadEvents as appropriate. RuleName and RuleLastModificationTime help distinguish a deployed revision from older output.
Trap Checking only DeviceProcessEvents for custom rule output, because custom process telemetry has its own table.
2 questions test this
- You have Microsoft Defender for Endpoint Plan 2 with custom data collection. Two hours ago, you created RuleDns, which collects outbound network connection events on port 53 from devices tagged DnsWat
- You have Microsoft Defender for Endpoint Plan 2. Fifteen minutes ago you edited the custom data collection rule ScriptRule to add a condition on the script file path. Analysts querying the custom scri
- Deleting a collection rule does not remove previously ingested Sentinel data
Deleting a custom data collection rule permanently removes that rule and stops new collection. Historical data already in Sentinel remains available under its retention settings. Disable a rule instead when a reversible pause is required.
Trap Deleting the rule as a way to purge historical telemetry, which does not delete data already stored in Sentinel.
2 questions test this
- You have Microsoft Defender for Endpoint Plan 2 with custom data collection. RuleFile collects file modification events from devices tagged FinanceFS. It must stop collecting during a two-week change
- You have Microsoft Defender for Endpoint Plan 2 with custom data collection. RuleCmd has sent process command-line events to Microsoft Sentinel for 60 days. The privacy officer wants that collection t
- ASR rules target risky application behavior rather than protecting a folder list
Use ASR rules for requirements such as blocking executable content from email, Office child-process creation, or untrusted and unsigned processes running from USB. These rules target behaviors commonly abused by attackers. Controlled folder access is the alternative for protecting designated folders against unauthorized changes.
Trap Choosing controlled folder access to block Office child processes, because it protects folder writes rather than that process behavior.
2 questions test this
- You have Windows 11 devices onboarded to Microsoft Defender for Endpoint. During a recent incident, ransomware running under an unfamiliar process name encrypted the files in C:\Finance. You need to e
- You have Windows 11 devices onboarded to Microsoft Defender for Endpoint. Field engineers regularly connect USB drives and SD cards that sometimes carry unsigned tools. You need to prevent unsigned or
- ASR requires active Defender Antivirus with real-time protection
ASR rules require Microsoft Defender Antivirus as the primary antivirus in Active mode with real-time protection enabled. Passive mode, including passive mode with EDR in block mode, does not satisfy this requirement. Cloud-delivered protection is also important, and some rules have explicit cloud dependencies.
Trap Using EDR in block mode to satisfy the ASR antivirus prerequisite, because ASR requires active real-time antivirus.
2 questions test this
- You have four Windows 11 devices onboarded to Microsoft Defender for Endpoint and an ASR policy that sets several rules to Block. The devices are configured as follows: - Device1: Defender Antivirus a
- You have Windows 11 devices onboarded to Microsoft Defender for Endpoint. The devices run a non-Microsoft antivirus product, and Microsoft Defender Antivirus runs in passive mode. You assign an Attack
- Audit mode measures ASR impact before enforcement
Deploy ASR rules in Audit mode to observe affected applications without enforcing the block, then use the results to refine policy before switching to Block or Warn. Microsoft distinguishes standard protection rules, which normally need less testing, from other ASR rules that should be tested first. Environments using Configuration Manager need particular care with the WMI persistence rule because that client relies on WMI.
Trap Using Block mode as an observation-only pilot, which enforces the behavior restriction during the test.
2 questions test this
- You have Windows 11 devices onboarded to Microsoft Defender for Endpoint Plan 2. You plan to enable the Block Office applications from creating executable content rule. A colleague proposes enabling t
- You have Windows 11 devices onboarded to Microsoft Defender for Endpoint Plan 2. You're starting the testing phase of an ASR rules deployment. A legacy policy already sets the Block execution of poten
- Endpoint security ASR policies use the Windows ASR rules profile
In Intune Endpoint security, create an Attack surface reduction policy with platform Windows and profile Attack Surface Reduction Rules. For devices managed through Defender for Endpoint security settings management, assign policies to Microsoft Entra device groups. That management path supports device objects rather than user targeting.
Trap Assigning the policy to an Entra user group for Defender for Endpoint management, which supports device targeting only.
2 questions test this
- You have Windows 11 devices onboarded to Microsoft Defender for Endpoint and managed through Defender for Endpoint security settings management. The devices aren't enrolled in Intune. You create an At
- You have Windows 11 devices enrolled in Microsoft Intune and onboarded to Microsoft Defender for Endpoint. You need to deploy ASR rules by using the recommended Intune method. The solution must let yo
- The LSASS ASR rule blocks credential-memory access rather than the calling process
Choose Block credential stealing from the Windows local security authority subsystem when applications must be prevented from accessing LSASS memory to extract credentials. A block event for an updater means its LSASS access was denied, not that the updater was prevented from running. Unnecessary LSASS enumeration can generate events without a functional failure, so an event alone does not justify an application exception. When LSA protection is enabled, Microsoft documents this ASR rule as redundant and not applicable in the management settings.
Trap Exempting a functioning updater merely because its LSASS access was blocked, restoring unnecessary access to credential-bearing memory.
2 questions test this
- You have Windows 11 devices onboarded to Microsoft Defender for Endpoint. A custom smartcard driver prevents you from enabling Credential Guard or LSA protection on the finance devices. You need to pr
- You have Windows 11 devices onboarded to Microsoft Defender for Endpoint with Block credential stealing from the Windows local security authority subsystem in Block mode. The ASR rules report shows da
- The vulnerable-driver ASR rule prevents driver writes but does not stop existing driver loads
Enable Block abuse of exploited vulnerable signed drivers to prevent applications from saving vulnerable signed drivers on the computer. A valid signature does not make a vulnerable driver safe, because privileged applications can exploit it to gain kernel access. The rule does not prevent loading a vulnerable driver already present on disk. Add an appropriate application-control or vulnerable-driver blocklist control when existing driver loading must also be prevented.
Trap Relying only on vulnerable-driver ASR after the driver is already installed, although its enforcement boundary is saving drivers rather than loading existing ones.
2 questions test this
- Your company enabled the Block abuse of exploited vulnerable signed drivers rule in Block mode on all Windows 11 devices. A threat report names a vulnerable signed driver that a hardware vendor's util
- Device9 runs Windows 11, and the Block abuse of exploited vulnerable signed drivers rule is in Block mode. A vulnerable signed driver already exists on Device9's disk, and the security team requires t
- Office ASR selection depends on whether the payload reaches disk, another process, or a Win32 API
When an allowed Office macro drops an untrusted executable, select Block Office applications from creating executable content to prevent access to or execution of that payload. If the attack instead moves code into an existing process, select Block Office applications from injecting code into other processes; restart Office applications after configuring it. For a VBA macro that invokes native APIs without writing a payload, select Block Win32 API calls from Office macros, which depends on AMSI. Blocking executable creation alone does not address an attack whose relevant operation is memory injection or an API call.
Trap Choosing Office executable-content blocking for a fileless VBA Win32 API attack, although the malicious operation does not depend on a dropped executable.
2 questions test this
- An allowed finance macro in Excel was abused to write an untrusted executable to the user's Downloads folder; the macro itself never starts the file at any point. Later, the user double-clicked the fi
- A malicious Word document uses a VBA macro that calls Win32 APIs to run shellcode in memory without writing any payload file to disk. The company still relies on other VBA macros in Word and Excel tha
- Suspicious script obfuscation and downloaded executable launches require different ASR rules
Choose Block execution of potentially obfuscated scripts when suspicious properties inside concealed script content are the behavior to stop; the rule supports PowerShell and requires AMSI and cloud-delivered protection. Choose Block JavaScript or VBScript from launching downloaded executable content when the behavior is a script fetching and starting a payload, even if the script is readable. The downloaded-content rule depends on AMSI but does not list cloud protection as an enforcement dependency. Test legitimate obfuscated applications and scripted installers because each can exhibit the behavior its respective rule targets.
Trap Using only obfuscated-script protection against a readable VBScript downloader, mistaking concealment detection for downloaded-payload launch control.
2 questions test this
- You are documenting dependencies before deploying the Block JavaScript or VBScript from launching downloaded executable content rule alongside the Block execution of potentially obfuscated scripts rul
- Your devices already block obfuscated PowerShell with the Block execution of potentially obfuscated scripts rule. A new campaign uses a plainly readable VBScript file that fetches an executable from t
- WMI persistence protection is distinct from PSExec and WMI process-creation blocking
Use Block persistence through WMI event subscription to prevent malware from abusing the WMI repository and event model for persistent execution; this rule depends on RPC. Use Block process creations originating from PSExec and WMI commands when the requirement is to stop processes launched through those remote execution mechanisms. Microsoft advises against enabling the process-creation rule through alternative deployment methods on Configuration Manager-managed devices because its client relies heavily on WMI. An event-subscription persistence control is not a general replacement for remote process-creation blocking.
Trap Selecting WMI event-subscription blocking to stop a PSExec-launched process, although that process does not require WMI persistence.
2 questions test this
- You have Windows 11 devices onboarded to Microsoft Defender for Endpoint, and no device is managed by Microsoft Configuration Manager. A threat report describes fileless malware that registers WMI eve
- You have Windows Server devices onboarded to Microsoft Defender for Endpoint, and no device is managed by Microsoft Configuration Manager. During an incident, an attacker used stolen credentials and P
- Reputation-based ASR protections can block files without a known malicious verdict
For execution restricted by file trust, select Block executable files from running unless they meet a prevalence, age, or trusted list criterion. For additional ransomware-focused protection, select Use advanced protection against ransomware, which combines client and cloud heuristics and can block files that lack a positive reputation. Both rules require cloud-delivered protection. An unknown business executable can therefore need compatibility evaluation even when no known-malware signature identifies it.
Trap Assuming a new unsigned business executable is exempt because it has no known malware verdict, overlooking the absence of sufficient positive reputation.
2 questions test this
- You have Windows 11 devices onboarded to Microsoft Defender for Endpoint. You need an extra layer of ransomware defense that uses client and cloud heuristics to decide whether a file resembles ransomw
- You have Windows 11 devices onboarded to Microsoft Defender for Endpoint, with Defender Antivirus active and real-time protection on. You assign Block executable files from running unless they meet a
- Endpoint security policy templates must match the target operating system and management path
Choose antivirus, antivirus-exclusion, and EDR templates for supported Windows, macOS, or Linux devices; Defender Firewall and Firewall rules templates are Windows-specific. Use the firewall profile for firewall settings and the firewall-rules profile for individual traffic rules rather than an ASR profile. After configuring the Intune connection and security settings management, supported policies can also reach devices onboarded to Defender for Endpoint but not enrolled in Intune. Onboarding does not make every policy template available on every operating system.
Trap Assigning a Windows Defender Firewall template to Linux endpoints merely because they are onboarded, ignoring platform-specific template support.
3 questions test this
- Your company uses Microsoft Defender for Endpoint and Microsoft Intune. You connected Intune to Defender for Endpoint and enabled security settings management. You have macOS devices that are onboarde
- Your company uses Microsoft Defender for Endpoint with security settings management. You have Windows 11, macOS, and Linux devices that are onboarded to Defender for Endpoint but aren't enrolled in In
- You have Windows Server devices onboarded to Microsoft Defender for Endpoint and managed through security settings management. You need to create individual rules that block inbound TCP port 445 traff
- Endpoint policy administration requires management permission that applies to all devices
With Defender unified RBAC, grant Core security settings (manage) under Authorization and settings > Security settings to create and manage endpoint security policies. The permission must apply to all devices: a role limited to specific device groups cannot open the Endpoint security policies page. Core security settings (read) is the alternative for read-only access. Regardless of the access-granting role, the displayed policy list is also scoped by Intune RBAC assignments.
Trap Granting policy-management permission only on one device group, leaving the administrator unable to open the all-device policy-management surface.
2 questions test this
- PolicyAdmin2 has a Microsoft Defender unified RBAC role with Core security settings (manage) that applies to all devices and can open the Endpoint security policies page. However, PolicyAdmin2 sees on
- PolicyAdmin1 has a Microsoft Defender unified RBAC custom role with Core security settings (manage), assigned with a data source scope limited to the EU device groups. PolicyAdmin1 must create and man
- Policy delivery must be verified separately from successful policy creation
Open the saved endpoint policy to inspect its status, applicable devices, and assigned groups, then use the device's Configuration management > Security policies tab to check applied policies. Devices managed through Defender security settings management check with Intune every 90 minutes. To request an earlier refresh, choose More actions > Policy sync on the device entity page; application should occur in about 10 minutes. A policy listed in inventory proves creation, not that each target has applied it.
Trap Creating another copy of a policy before checking assignments and synchronizing the device, adding configuration without resolving delivery latency.
3 questions test this
- After saving a new endpoint security policy in the Microsoft Defender portal, a manager sees it on the Endpoint security policies page and reports to leadership that all 400 targeted devices, which ar
- You assigned a new Antivirus policy from the Microsoft Defender portal to a device group that contains Device11, which is managed through Defender for Endpoint security settings management. Thirty min
- You created an Attack Surface Reduction policy on the Endpoint security policies page in the Microsoft Defender portal and assigned it to a Microsoft Entra device group that contains Device10. Device1
- Adobe Reader and Outlook child execution require their application-specific ASR rules
Choose Block Adobe Reader from creating child processes when a PDF attack uses Reader to launch another process. Choose Block Office communication application from creating child processes when Outlook is the parent application. The general Office child-process rule targets applications such as Word, Excel, and PowerPoint, so its name should not be treated as coverage for every application in these scenarios.
Trap Using Block all Office applications from creating child processes for an Outlook-launched payload, overlooking the distinct Office communication application control.
2 questions test this
- Your Intune ASR policy already sets Block all Office applications from creating child processes to Block. A colleague says no further rules are needed to stop Outlook-launched payloads and PDF-based a
- Users open PDF attachments in Adobe Reader on Windows devices. In a recent incident, a malicious PDF caused Adobe Reader to start PowerShell, which then downloaded a payload from the internet. You nee
- Safe Mode ASR protection stops abused reboot commands while retaining manual recovery access
Select Block rebooting machine in Safe Mode to stop commonly abused commands such as bcdedit and bootcfg from restarting Windows into Safe Mode. Attackers use this transition because security products can be disabled or run with reduced functionality there. Manual Safe Mode access through Windows Recovery Environment remains available, so this rule is not a prohibition on all recovery entry paths.
Trap Using this ASR rule to enforce a requirement that nobody can enter Safe Mode through Windows Recovery Environment, a manual route that remains accessible.
2 questions test this
- A retail kiosk project requires that nobody can start the kiosk devices in Safe Mode by any method, including manually through the Windows Recovery Environment or by using startup commands. A colleagu
- Ransomware operators in a recent incident ran bcdedit to force compromised Windows devices to restart in Safe Mode, where security products are disabled or limited, before encrypting files on the devi
- A trusted signature does not exempt relocated system tools from the copied-tool ASR rule
Block use of copied or impersonated system tools treats executables in the Windows System32 and SysWOW64 directories as system tools. It blocks copies or same-named files running elsewhere even when Microsoft or another trusted vendor signed them. Select this rule for relocated or impersonated tool execution rather than relying on a signature or prevalence-based trust decision.
Trap Using a valid Microsoft signature to dismiss a copied-tool ASR block as impossible, although the rule evaluates execution outside the system tool's expected location.
2 questions test this
- A legitimate third-party inventory agent that was installed in a custom, nondefault path is blocked on 40 devices by the Block use of copied or impersonated system tools rule. The security team confir
- Attackers on your network copy built-in Windows utilities from System32 into user-writable folders, and sometimes rename their own tools to match Windows utility names, to blend in. Some copies are ge
- Webshell creation protection is an Exchange-server ASR control
Choose Block Webshell creation for Servers to prevent web-shell script creation on Windows servers running Microsoft Exchange. Such scripts can give an attacker remote command execution, payload download, or credential theft capabilities on the compromised server. Match the policy to this supported server workload rather than interpreting the rule as a general Office or script-execution restriction.
Trap Using Block Office applications from creating executable content to stop an Exchange web-shell drop, although that rule depends on Office applications writing the payload.
2 questions test this
- You are scoping a Microsoft Intune ASR policy that sets Block Webshell creation for Servers to Block. The infrastructure team wants to assign it broadly to every server and workstation group so that n
- To stop web shell drops on Exchange servers, a colleague proposes enabling Block Office applications from creating executable content on those servers, because web shells are written to disk. No Offic
- Policy-managed ASR settings override conflicting local PowerShell settings
Local ASR configuration through Set-MpPreference has the lowest precedence. Policy-based configuration overwrites conflicting local settings on startup. Correct the authoritative management policy when a local change repeatedly disappears.
Trap Repeating Set-MpPreference at each restart, which leaves the higher-precedence policy conflict unresolved.
2 questions test this
- Device2 is managed by Microsoft Intune. An Intune attack surface reduction policy sets the Block executable files from running unless they meet a prevalence, age, or trusted list criterion rule to Aud
- Device1 is managed by a Microsoft Intune attack surface reduction policy that sets the Block Office applications from creating executable content rule to Block. To troubleshoot a macro, a technician r
- Group Policy wins an ASR conflict unless MDMWinsOverGP changes precedence
When Group Policy and MDM configure the same ASR rule, Group Policy takes precedence by default. Setting the ControlPolicyConflict Policy CSP value MDMWinsOverGP to 1 makes MDM win instead; its default value is 0. Avoid configuring the same rule through competing authorities when possible.
Trap Assuming the most recently edited Intune policy always wins, because default conflict precedence favors Group Policy.
2 questions test this
- Device3 is domain-joined and enrolled in Microsoft Intune. A Group Policy object sets an attack surface reduction rule to Block, and an Intune policy that was edited yesterday sets the same rule to Au
- Pilot devices receive the same attack surface reduction rules from a GPO and from an MDM solution that configures them through Policy CSP, and the values conflict. The GPO must stay linked to the devi
- Add-MpPreference preserves existing ASR assignments while Set-MpPreference replaces them
Use Add-MpPreference to add ASR rule IDs and corresponding actions without replacing existing assignments. Set-MpPreference overwrites the specified ASR configuration, while Remove-MpPreference removes selected entries. Pair AttackSurfaceReductionRules_Ids with the intended AttackSurfaceReductionRules_Actions values.
Trap Using Set-MpPreference to append a single rule, which can replace the previously configured rule list.
2 questions test this
- Device4 isn't managed by Intune, Group Policy, or any other policy, and five attack surface reduction rules were configured on it locally with PowerShell. You need to add the Block JavaScript or VBScr
- Device6 isn't managed by Intune, Group Policy, or any other policy, and three attack surface reduction rules are already configured on it locally. In an elevated PowerShell session, you run Add-MpPref
- ASR action values distinguish Block, Audit, Warn, and disabled states
ASR action values include 0 for Disabled, 1 for Enabled or Block, 2 for Audit, 5 for NotConfigured, and 6 for Warn. Select the value for the intended rollout behavior rather than treating every nonzero value as blocking. Configuration methods that identify rules by GUID still require the correct action for each rule.
2 questions test this
- An attack surface reduction (ASR) rule ran in Audit mode on Windows 11 pilot devices, and the ASR rules report showed no line-of-business impact. You now update the rule's entry in the AttackSurfaceRe
- A deployment script passes the value 2 in AttackSurfaceReductionRules_Actions for the Block executable content from email client and webmail rule. The security manager assumes that any nonzero value b
- Per-rule ASR exclusions are narrower than global ASR exclusions
Use ASR only per rule exclusions when an approved path should bypass just one supported rule. Attack surface reduction only exclusions apply across ASR rules that honor those exclusions. Prefer the narrow exception that resolves the verified application conflict instead of exempting the path from every applicable ASR rule.
Trap Using a global ASR exclusion for a single-rule compatibility issue, which broadens the exemption to other rules.
2 questions test this
- Device6 receives two Microsoft Intune attack surface reduction policies. To fix a conflict with one rule, an administrator added C:\Tools to the Attack Surface Reduction Only Exclusions setting in pol
- In Microsoft Intune, an attack surface reduction rules policy sets several rules to Block. A verified line-of-business app in C:\Apps\Ledger conflicts only with the Block executable files from running
- ASR Warn permits a temporary bypass only for supported rules
Warn initially blocks the activity but offers Unblock for a 24-hour bypass, unlike Audit, which records without blocking, or Block, which provides no such bypass. Starting with Defender Antivirus platform version 4.18.26060, using Unblock requires administrator approval. The LSASS credential-theft and Office process-injection rules do not support Warn. Use a supported enforcement mode for those rules rather than promising users a warning-based exception.
Trap Using Warn for Office process-injection compatibility, although that rule does not implement the bypass mode.
2 questions test this
- Devices run Microsoft Defender Antivirus platform version 4.18.26070 on Windows 11. The Block executable content from email client and webmail rule is in Warn mode, and users were told that they could
- An Office add-in used by the legal team conflicts with the Block Office applications from injecting code into other processes rule. A manager asks you to set the rule to Warn so that legal users can b
- Antivirus file exclusions do not exempt applications from the LSASS ASR rule
Check an ASR rule's exclusion compatibility before reusing an antivirus file or folder exception. Block credential stealing from the Windows local security authority subsystem ignores Microsoft Defender Antivirus file and folder exclusions but honors ASR exclusions. For a verified compatibility problem requiring an exception to this rule, configure an ASR exclusion rather than assuming the antivirus path exclusion applies.
Trap Using an antivirus folder exclusion for a password-sync application's LSASS access, even though this rule does not consult that exclusion type.
2 questions test this
- Server2 already has a Microsoft Defender Antivirus folder exclusion for C:\SyncAgent, which was added for scanning performance. The Block credential stealing from the Windows local security authority
- On Server1, a verified password synchronization agent must read LSASS memory, but the Block credential stealing from the Windows local security authority subsystem rule blocks it. An administrator add
- An ASR block can succeed without an EDR alert or user pop-up
ASR enforcement and notification support are separate capabilities: the LSASS credential-theft rule lists neither EDR alerts nor user notifications. For Block Adobe Reader from creating child processes, EDR alerts require High plus or Zero tolerance cloud protection, while user pop-ups require High, High plus, or Zero tolerance. Check the specific rule's notification support and cloud protection level before treating a silent block as failed protection.
Trap Using an empty EDR alert queue as the deployment acceptance test for every ASR rule, although some enforced rules have no EDR alert output.
2 questions test this
- You deploy the Block credential stealing from the Windows local security authority subsystem rule in Block mode. Advanced hunting shows AsrLsassCredentialTheftBlocked events on several devices, but no
- On Finance laptops, the Block Adobe Reader from creating child processes rule is in Block mode, and Microsoft Defender Antivirus cloud protection is set to the High level. When the rule blocks Adobe R
- Centrally managed webshell protection requires competing settings to remain Not Configured
When managing Block Webshell creation for Servers in Microsoft Defender for Endpoint, leave that rule Not Configured in Group Policy and other local settings. Explicit Enabled or Disabled values can conflict with central management and prevent the rule from applying correctly. Resolve this deployment conflict by removing the competing configuration rather than setting a local value to reinforce the central policy.
Trap Using Disabled in Group Policy to hand control to Defender for Endpoint, because Disabled remains an explicit competing configuration rather than relinquishing configuration of the rule.
2 questions test this
- Exchange servers receive the Block Webshell creation for Servers rule from Microsoft Defender for Endpoint central management, and the related GPO setting is Not Configured. As extra reinforcement, an
- You manage the Block Webshell creation for Servers rule for Exchange servers through Microsoft Defender for Endpoint. To hand control of the rule to Defender for Endpoint, a domain administrator set t
- Endpoint AIR no longer runs as a separate manually triggered investigation experience
From September 1, 2026, Defender for Endpoint AIR no longer operates as a separate investigation experience or supports manual triggering. Its detection and response capabilities run automatically in the default antivirus protection stack; use a full antivirus scan for an on-demand endpoint investigation. This change does not remove Defender for Office 365 AIR.
Trap Launching a separate endpoint AIR investigation from an older procedure, because that experience is no longer available.
2 questions test this
- Your company uses Microsoft Defender for Endpoint and Microsoft Defender for Office 365 Plan 2. After reading about the September 1, 2026 change to automated investigation and response (AIR), a collea
- Your company uses Microsoft Defender for Endpoint Plan 2. An older SOC runbook tells analysts to start a separate automated investigation manually from the device page whenever they need an on-demand
- Action center separates approvals from completed action history
Use the Pending tab in Action center to review and approve or reject actions that still need a decision. Use History to audit completed actions, including automated responses, manual operations, live response activity, and antivirus remediation. Bulk approval or rejection requires selected actions to have the same action type.
Trap Closing an incident to approve pending remediation, which changes case status rather than authorizing an action.
2 questions test this
- On the Pending tab of the Action center, you select 20 pending actions to approve at once. Twelve are Quarantine file actions from automated investigations, and eight are Isolate device actions. The p
- Automated investigations in Microsoft Defender XDR produced 15 pending remediation actions to quarantine files on devices whose device group uses Semi - require approval for all folders. Your manager
- Action source identifies how a remediation operation was initiated
Inspect Action source in Action center to distinguish manual device or email actions, automated actions, advanced hunting actions, Explorer actions, and live response operations. This lets the SOC identify the responsible workflow before changing automation settings. An action in History is not necessarily the result of AIR.
Trap Changing the device automation level for every recorded action, because manually initiated actions have a different source.
2 questions test this
- In the Microsoft Defender XDR Action center History tab, you see several soft-deleted email messages and isolated devices from last night. An analyst reports running a query and then taking actions on
- In the Action center History tab, you see that Device2 was isolated from the network yesterday afternoon during an incident. Your manager assumes that an automated investigation isolated the device an
- Response permissions must cover the affected workload
Under Defender unified RBAC, endpoint remediation uses Security operations > Security data > Response (manage). Email remediation uses the relevant email and collaboration advanced-actions permission when that workload's unified RBAC is active. In the documented legacy email permissions path, Security Administrator must be combined with Search and Purge for remediation.
Trap Granting read-only security data access to an approver, which allows inspection without the required response permission.
2 questions test this
- Your company uses Microsoft Defender XDR Unified role-based access control (RBAC) for Microsoft Defender for Endpoint. Approver1's custom role grants Security data basics (read) and File collection (m
- Your company uses Microsoft Defender XDR Unified RBAC for Microsoft Defender for Endpoint, and the Email & collaboration > Defender for Office 365 permissions workload is active in Unified RBAC. Appro
- An automated investigation can legitimately finish without a remediation action
The Defender XDR investigation process assesses evidence as Malicious, Suspicious, or No threats found, then identifies whether remediation is needed. Alert eligibility and workload configuration determine whether an investigation starts; its evidence findings determine whether response work follows. For Defender for Office 365 Plan 2, an investigation can close when no threats are found or the affected messages were already remediated. Therefore, a completed investigation with no new action is not by itself evidence of failed automation.
Trap Treating every completed investigation without a quarantine operation as an automation failure, despite clean evidence or messages already remediated.
- Unanswered endpoint remediation approvals time out as rejected after seven days
For Defender for Endpoint's Semi - require approval for all folders level, pending remediation actions time out after seven days. A timed-out action behaves as though it was rejected, not approved. Arrange review within that window when remediation needs authorization; leaving the request unanswered does not provide eventual automatic execution.
Trap Assuming an unattended approval queue provides delayed automatic remediation, because expiration takes the rejection path rather than granting authorization.
2 questions test this
- Devices in the Finance device group use the Semi - require approval for all folders remediation level. The SOC was offline for a 10-day shutdown, and pending file remediation actions accumulated in th
- Devices in the Finance device group use the Semi - require approval for all folders remediation level in Microsoft Defender for Endpoint. During a two-week holiday, nobody reviews the Action center, a
- Attack disruption coverage depends on both available signals and deployed action providers
Deploy the Defender products needed for the attack scenarios and response actions you expect to use. A detection that relies on Cloud Apps signals needs that product, while endpoint containment requires Defender for Endpoint. Automatic Contain device also requires device discovery to use Standard discovery.
Trap Treating the XDR license alone as sufficient to execute every response action, because the corresponding products must be deployed.
2 questions test this
- Your company has Microsoft 365 E5 and has deployed Microsoft Defender for Endpoint to all devices. Microsoft Defender for Cloud Apps hasn't been set up. Automatic attack disruption contains devices du
- Your company has Microsoft 365 E5. Microsoft Defender for Office 365 and Microsoft Defender for Identity are deployed, but no devices are onboarded to Microsoft Defender for Endpoint. You need automat
- Semi automation does not require manual approval for attack disruption
Automatic attack disruption can trigger without manual approval when a device group's remediation setting is Semi automation. Full remediation is recommended; No automated response excludes the group from automated containment. Do not interpret the approval behavior of conventional remediation as an approval gate for disruption.
Trap Selecting Semi automation to require approval before containment, because attack disruption can still act immediately.
2 questions test this
- Your company uses automatic attack disruption in Microsoft Defender XDR. The Lab device group contains 12 test devices that run fragile instrumentation. Management approved excluding only this device
- Your company uses automatic attack disruption in Microsoft Defender XDR. The Servers device group has its remediation level set to Semi - require approval for all folders. Your manager believes this s
- Attack disruption can act with active, passive, or EDR block-mode antivirus
Attack disruption can operate independently of the device's Defender Antivirus operating state. Active, Passive, and EDR Block Mode are supported states for this capability. Other controls such as ASR have different antivirus prerequisites and must be evaluated separately.
Trap Applying ASR's active-antivirus requirement to attack disruption, because their prerequisites differ.
2 questions test this
- Your company has Microsoft 365 E5 and onboards all Windows devices to Microsoft Defender for Endpoint. Devices in the Retail device group run a non-Microsoft antivirus product, so Microsoft Defender A
- Your company uses automatic attack disruption in Microsoft Defender XDR. All Windows devices are onboarded to Microsoft Defender for Endpoint, and the device groups are configured as follows: - Plants
- Identity disruption requires sensor coverage, auditing, and authorized action accounts
Configure required domain-controller audit events and validate Defender for Identity action-account permissions before relying on on-premises account disablement. By default, the sensor impersonates the domain controller's LocalSystem account; changed action-account configuration must retain the needed rights. Check that other account-enablement automation will not undo disruption during an attack.
Trap Assuming a detected identity compromise proves the sensor can disable the account, because detection and remediation permissions are separate.
2 questions test this
- Your company is preparing on-premises Active Directory for automatic attack disruption, which can disable compromised accounts. Microsoft Defender for Identity sensors run on all domain controllers wi
- Your company uses Microsoft Defender for Identity with automatic attack disruption. During an attack, disruption disabled the compromised Active Directory account User1, but less than an hour later Us
- Email attack disruption requires Exchange Online mailboxes and specific audited events
For Defender for Office 365 attack disruption, mailboxes must be hosted in Exchange Online. At minimum, audit MailItemsAccessed, UpdateInboxRules, MoveToDeletedItems, SoftDelete, and HardDelete. These signals support visibility into mailbox access and attacker-driven changes.
2 questions test this
- Your company is in an Exchange hybrid deployment. Half of the mailboxes have moved to Exchange Online, and the rest are still hosted on Exchange Server on-premises. All users are synchronized to Micro
- Your company is preparing Microsoft Defender for Office 365 for automatic attack disruption. All mailboxes are hosted in Exchange Online. You need to configure mailbox audit logging so that, at minimu
- Cloud Apps disruption depends on a fully configured Microsoft 365 connector
Connect Defender for Cloud Apps to Microsoft 365 and select all required connector options, including Microsoft Entra ID apps. Partial selection can degrade disruption and app governance functionality or cause operations to fail. A connector that exists but omits required data is not equivalent to complete integration.
Trap Enabling only Exchange activity collection, which omits other required Microsoft 365 connector options.
2 questions test this
- Your company relies on automatic attack disruption scenarios that use Microsoft Defender for Cloud Apps. The Microsoft 365 app connector was created months ago with only the Exchange and SharePoint ac
- Your company plans to rely on automatic attack disruption scenarios that use Microsoft Defender for Cloud Apps signals and actions, such as app governance and disruption flows. Defender for Cloud Apps
- Automatic attack disruption contains active attacks using high-confidence incident context
Automatic attack disruption correlates signals across Defender workloads into a high-confidence incident, identifies attacker-controlled assets, and automatically contains them while the attack is progressing. Its decision evaluates the attack as a whole rather than matching a single indicator of compromise. Choose this built-in capability for coordinated containment without authoring a Sentinel playbook; a playbook is appropriate when you need to define your own response workflow.
Trap Reaching for a single file-hash block to obtain incident-wide containment, although the hash decision addresses only matching file content.
2 questions test this
- Your company has Microsoft 365 E5 with Microsoft Defender XDR and Microsoft Sentinel. Leadership wants coordinated, built-in containment of compromised users and devices while a human-operated ransomw
- Your company has Microsoft 365 E5. During a ransomware incident, Defender correlates alerts from endpoints, identities, and email into one incident with a compromised user and three devices. An analys
- Asset exclusions and selective isolation exclusions protect different operational requirements
For an approved critical-account exception, use Settings > Microsoft Defender XDR > Automated response > Identities > Add user exclusion; use Devices > Policy application > Exclude IP for an address, range, or subnet containment exception. These targeted exclusions reduce protection for the selected assets without disabling automated response for an entire device group. If an isolated workstation merely needs access to a particular process or destination, configure selective isolation exclusions instead. A traffic exception preserves the permitted communication during isolation, whereas an attack-disruption exclusion prevents the selected automatic response.
Trap Using an attack-disruption asset exclusion to preserve one management connection, thereby removing automatic response protection instead of only permitting the necessary traffic.
2 questions test this
- Your company uses automatic attack disruption, which can isolate compromised workstations. If Workstation1 is isolated during an incident, the help desk's remote remediation tool on Workstation1 must
- Your company uses Microsoft Defender XDR with automatic attack disruption. Management approved an exception for BreakGlass1, an emergency administrator account that must remain usable during any incid
- Contain user requires Sense Agent version 10.8470 or later
Validate the endpoint Sense Agent version before relying on Contain user: the minimum supported version is 10.8470. Read MsSenseDllVersion under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Advanced Threat Protection\Status to confirm the installed sensor version. Successful onboarding alone does not establish compatibility with this response action.
Trap Checking only the antivirus operating mode when Contain user fails, although the action also requires a compatible Sense sensor.
2 questions test this
- Your company plans to rely on the Contain user action of automatic attack disruption. All four devices below are onboarded to Microsoft Defender for Endpoint, and you read their MsSenseDllVersion regi
- Your company plans to rely on the Contain user action of automatic attack disruption. A device team confirms that Device1 is onboarded to Microsoft Defender for Endpoint. Before the rollout, you must
- Automatic isolation requires a managed workstation rather than merely a containable asset
Automatic device isolation in attack disruption is limited to end-user workstations onboarded to and managed by Defender for Endpoint. An unmanaged asset is not eligible for this isolation action, even when attack disruption can contain it. Contain device instead enforces restrictions through onboarded endpoints that block communication from the suspicious asset, so its coverage does not require installing a sensor on that asset.
Trap Assuming a discovered unmanaged workstation can receive automatic isolation because Contain device covers it, confusing peer-enforced restrictions with management of the target workstation.
2 questions test this
- Your company uses automatic attack disruption with Microsoft Defender for Endpoint. A colleague argues that because Contain device covers unmanaged devices, automatic device isolation will also apply
- Your company has Microsoft 365 E5, with Microsoft Defender for Endpoint device discovery set to Standard discovery. Device discovery found Kiosk1, an end-user workstation that isn't onboarded to Defen
- Contain user restricts identity activity at endpoints rather than disabling the directory account
Contain user applies a Defender for Endpoint containment policy across onboarded devices to block communication from the compromised identity. Its enforcement limits authentication-based access, file system access, and network communication at those endpoints. Disable user instead acts on the account in its identity service, so endpoint containment is not evidence that the directory account has been disabled.
Trap Assuming a Contain user action proves directory-wide account disablement, because the action enforces restrictions through endpoint policies rather than changing the account's enabled state.
2 questions test this
- Your company uses automatic attack disruption. During an incident, disruption applied Contain user to User1, a synchronized identity. The incident graph shows User1 as contained, and Action center rec
- Your company uses automatic attack disruption. User2 is contained by the Contain user action after a credential theft incident. The identity team requires that User2 be prevented from signing in anywh
- Cloud account disablement does not inherit the on-premises sensor requirement
For a cloud-native account, attack disruption executes disablement in Microsoft Entra ID through a Microsoft-managed enterprise application. Disabling an Entra account does not depend on deploying Defender for Identity. For a synchronized identity, disruption can disable both the Active Directory account through sensor-equipped domain controllers and its Entra counterpart; a purely on-premises account uses the domain-controller path.
Trap Requiring a domain-controller sensor before protecting cloud-native accounts, incorrectly extending the Active Directory execution dependency to the enterprise-application path.
2 questions test this
- User3 is hosted in Active Directory and synchronized to Microsoft Entra ID. Microsoft Defender for Identity sensors run on all domain controllers. During an incident, automatic attack disruption runs
- Your company has only cloud-native user accounts in Microsoft Entra ID and no on-premises Active Directory. Microsoft Defender for Identity isn't deployed. A consultant says that attack disruption can
- General disruption configuration and device automation changes have different role requirements
The eligible roles for configuring automatic attack disruption include Security Operator, Security Administrator, Global Administrator, User Administrator, Authentication Administrator, Privileged Authentication Administrator, Directory Writers, and Helpdesk Administrator. The documented device-group automation procedure instead requires Global Administrator or Security Administrator. Select authorization for the specific configuration operation rather than treating eligibility for general disruption setup as permission to change device remediation levels.
Trap Using Security Operator alone to change device-group automation settings, confusing general disruption eligibility with the administrator requirement for that procedure.
2 questions test this
- Your company uses Microsoft Defender XDR and is preparing to configure automatic attack disruption. The following users each hold only the listed Microsoft Entra role: - User1: Authentication Administ
- Your company uses Microsoft Defender XDR. Neither Defender for Endpoint role-based access control nor Unified RBAC is turned on. For an attack disruption rollout, UserA must only configure automatic a
- A device belongs to only its highest-ranked matching group
Device groups match on device name, domain, tags, and OS platform. When several groups match, only the highest-ranked group applies; rank 1 has the highest priority. Use ranking deliberately because the selected group determines scoped access and its remediation setting.
Trap Combining remediation levels from every matching device group, because membership resolves to a single highest-ranked group.
2 questions test this
- You create device group LabFull with Full remediation for 20 lab devices tagged Lab. The existing device group AllWindows, ranked 1, matches every Windows device and uses Semi - require approval for a
- In Microsoft Defender for Endpoint, device group HR-Laptops (rank 1) matches devices tagged HR and is assigned to the Entra group HR-SOC. Device group EU-Devices (rank 2) matches the domain eu.contoso
- Device-group properties combine with AND while alternative values use OR
A device must match all specified property conditions in a group definition. Within a property such as tag, device name, or domain, multiple values are alternatives joined with OR. Each of those properties supports up to 10 values, allowing a group to cover several naming patterns without relaxing its other conditions.
Trap Treating an OS condition and a tag condition as alternatives, which admits devices that fail one of the required properties.
2 questions test this
- You create a Microsoft Defender for Endpoint device group whose matching rule specifies the OS platform Windows Server 2022 and the tag PCI. An engineer expects the group to contain every Windows Serv
- You need one Microsoft Defender for Endpoint device group for branch gateways. A device must be in the contoso.com domain, and its name must be NYC-GW01, BOS-GW01, or CHI-GW01. Devices in other domain
- Device-group access assignments use Entra groups that already have RBAC roles
Assign Microsoft Entra user groups with RBAC roles to control which analysts can access a device group. If no Entra groups are assigned, the device group remains accessible to all users with portal access. Device grouping and analyst role assignment therefore need to be configured together.
Trap Leaving the user-access list empty to deny access, because the default exposes the group to portal users.
2 questions test this
- You are creating a device group in Microsoft Defender for Endpoint. On the User access page, you need to give the Microsoft Entra security group SOC-Tier2 access to the group's devices and alerts, but
- Your company uses Microsoft Defender for Endpoint with role-based access control. You create a device group named HR-Devices for sensitive HR laptops and skip the User access page because you plan to
- Unmatched devices enter a permanent default group
Devices that match no custom device group enter Ungrouped devices (default). You cannot delete or rerank this fallback group, but you can change its remediation level and assigned Entra user groups. Review it so that new or incorrectly tagged devices do not inherit unintended access or automation settings.
Trap Deleting the default group to enforce explicit grouping, because the fallback group cannot be removed.
2 questions test this
- New laptops onboarded to Microsoft Defender for Endpoint sometimes get a mistyped tag, so they match no custom device group. Those laptops then use Full remediation and are visible to every analyst. U
- Your organization wants every Microsoft Defender for Endpoint device to be in an explicitly defined device group. An administrator proposes deleting the Ungrouped devices (default) group so that devic
- Deleting a device group can remove its notification rule
Deleting a device group removes that group from email notification rules that reference it. If it is the only group in a notification rule, the notification rule is deleted as well. Review notification dependencies before reorganizing group membership or retiring a group.
Trap Assuming a notification rule automatically falls back to all devices after its sole group is deleted, because the rule itself is removed.
2 questions test this
- You plan to retire the Kiosks device group in Microsoft Defender for Endpoint and move its devices into a broader Retail group. The security lead wants the change to avoid any silent loss of the alert
- In Microsoft Defender for Endpoint, an email notification rule sends alerts for the FinanceLaptops device group to the finance security team, and FinanceLaptops is the only device group configured in
- Semi remediation levels place approval boundaries on different file locations
For remediation governed by the device-group automation level, Full remediates malicious artifacts automatically, whereas Semi - require approval for all folders requires approval for every file remediation. Semi - require approval for core folders gates operating-system locations such as the Windows directory but allows automatic remediation elsewhere. Semi - require approval for non-temp folders allows automatic remediation in temporary locations and requires approval outside them. These are remediation approval settings, not a way to restore the separate manually triggered endpoint AIR experience that Microsoft discontinued on September 1, 2026.
Trap Selecting the core-folders approval level when every file remediation needs approval, leaving noncore files eligible for automatic remediation.
2 questions test this
- On a developer device group in Microsoft Defender for Endpoint, remediation of malicious files in temporary folders such as Downloads must happen automatically. Remediation of files in every other fol
- A regulated device group in Microsoft Defender for Endpoint must still get automated investigations. Compliance requires analyst approval before any remediation action is applied to any file on those
- Automation rules perform basic incident handling without a playbook
Use an automation rule to assign incident owners, change status or severity, add tags or tasks, and close expected incidents. Use a playbook when richer branching or interactions with external systems exceed the available built-in actions. One automation rule can apply to multiple analytics rules.
Trap Building a Logic App solely to assign an incident owner, which adds a workflow where an automation-rule action suffices.
2 questions test this
- You have a Microsoft Sentinel workspace. Each new incident generated by the scheduled analytics rule Rule1 must be assigned to User1 and have its status changed from New to Active as soon as it's crea
- You have a Microsoft Sentinel workspace with 12 scheduled analytics rules that detect identity threats. For every new incident from these rules, the status must change from New to Active, the owner mu
- Automation triggers distinguish incident creation, incident updates, and alert creation
Choose When incident is created for initial triage and When incident is updated for changes such as ownership, severity, tags, or added alerts. When alert is created can respond to supported Sentinel analytics alerts even if they have no incident. A creation trigger does not rerun merely because an existing incident receives an update.
Trap Using only an incident-created trigger for escalation on a later severity change, which is an update event.
2 questions test this
- You have a Microsoft Sentinel workspace. AutoRule2 uses the When incident is created trigger and runs Playbook2, an incident-trigger playbook that posts a Teams message about the incident. Analysts al
- You have a Microsoft Sentinel workspace that isn't onboarded to the Microsoft Defender portal. AutoRule9 uses the When incident is created trigger, has no conditions, and assigns a Tier1 owner. Schedu
- Later automation rules evaluate the incident state left by earlier rules
Automation rule ordering matters because conditions are evaluated when each rule runs. If an earlier rule changes status or tags, a later rule sees those updated values. Sequence dependent rules deliberately rather than assuming every rule evaluates the original incident snapshot.
Trap Placing a tag-dependent routing rule before the rule that adds the tag, which evaluates the condition before the tag exists.
3 questions test this
- You have a Microsoft Sentinel workspace. Two automation rules use the When incident is created trigger. RuleT (order 1) changes every new incident's status from New to Active and assigns an owner, and
- You have a Microsoft Sentinel workspace with two automation rules that use the When incident is created trigger: - RuleA (order 1): if the analytics rule is PenTestRule, change the status to Closed wi
- You have a Microsoft Sentinel workspace with two automation rules that use the When incident is created trigger. RuleS (order 1) raises the severity to High when the incident contains the account enti
- Updated by conditions can exclude automation-generated changes
Use Updated by on incident-update automation to distinguish user, application, playbook, automation-rule, and other supported update sources. Combine it with changed, changed from, changed to, or added conditions when a specific transition should trigger work. Excluding automation-generated updates helps prevent repeated reactions to the workflow's own changes.
Trap Testing only that severity equals High for every update, which also matches unrelated updates while severity remains High.
2 questions test this
- You have a Microsoft Sentinel workspace that isn't onboarded to the Microsoft Defender portal. RuleN uses the When incident is updated trigger and runs Playbook3, which sends a notification about each
- You have a Microsoft Sentinel workspace. Closed incidents are sometimes reopened by analysts, and the SOC manager must be assigned as the owner of every reopened incident so that the reopening can be
- Incident suppression rules can expire after a known benign activity window
Create an automation rule from a recurring incident to prepopulate its analytics rule and entity conditions and propose a closing action. Set an expiration date for temporary suppression, such as a scheduled security test. Narrow conditions retain coverage for unrelated incidents generated by the same detection.
Trap Disabling the analytics rule for a narrow maintenance exception, which stops detection for all activity covered by that rule.
2 questions test this
- You have a Microsoft Sentinel workspace. A suppression automation rule closes every incident from Rule3 because a nightly backup job on Server1 triggers it. Security discovers that Rule3 also detected
- You have a Microsoft Sentinel workspace. A red team will run a penetration test from 10.1.1.50 next week, and analytics rule Rule3 will generate incidents for it. You need those incidents closed autom
- An automation rule can invoke only playbooks with a compatible trigger
Pair incident-created or incident-updated automation rules with incident-trigger playbooks, and alert-created automation rules with alert-trigger playbooks. The trigger determines the input schema, so an available workflow is not interchangeable merely because its actions are suitable. Alert-created automation conditions select the analytics rules to which automation applies; they do not offer the incident and entity property conditions available for incident-triggered rules.
Trap Reaching for an alert-created rule to filter directly on incident ownership, which is outside that trigger's analytics-rule-only condition set.
2 questions test this
- You have a Microsoft Sentinel workspace. Microsoft Sentinel already has the Microsoft Sentinel Automation Contributor role on the resource group that contains Playbook1. Playbook1 starts with the Micr
- You have a Microsoft Sentinel workspace. You plan an automation rule that uses the When alert is created trigger to run an alert-trigger playbook for alerts from the NRT analytics rules NRT7 and NRT8.
- Automation ordering sequences dispatch without guaranteeing long-running playbook completion
Each automation trigger type has its own order queue, and equal order numbers within a trigger type are resolved randomly. When creation automation causes incident updates, applicable creation rules finish before the resulting update-trigger rules run. A playbook lasting more than two minutes does not block the next action beyond two minutes after its start. Use distinct order numbers for deterministic rule sequencing, but do not treat those numbers as a completion dependency for a long-running workflow.
Trap Assuming a later closing action waits for a lengthy enrichment playbook because it appears second, despite the two-minute advancement boundary.
- A negative individual-tag condition can pass despite an exclusion tag elsewhere on the incident
Any individual tag evaluates true when at least one tag satisfies the condition, including a negative condition. For an incident tagged Protected and Routine, Any individual tag does not contain Protected succeeds because Routine satisfies it. Use Collection of all tags does not contain Protected when the presence of that tag anywhere must exclude the incident from automation.
Trap Using Any individual tag does not contain Protected to safeguard protected incidents, allowing another ordinary tag to satisfy the condition and run the action.
2 questions test this
- You have a Microsoft Sentinel workspace. An automation rule closes incidents from the analytics rule Phish1 as Benign Positive when the condition Any individual tag does not contain Hold is true. Inci
- You have a Microsoft Sentinel workspace. An automation rule that uses the When incident is updated trigger assigns the Tier1 queue owner when the condition Collection of all tags does not contain Exem
- Defender incident update consolidation can omit intermediate transitions from Sentinel automation
After a workspace is onboarded to the Defender portal, multiple changes to an incident within a 5-to-10-minute period can be sent to Sentinel as one update containing only the most recent change. Intermediate updates are lost rather than delivered later as separate triggers. Design update-driven workflows without assuming that every transient status or ownership transition will reach the Sentinel rule.
Trap Using a transient incident status as a guaranteed handoff trigger after Defender onboarding, although consolidation can discard that transition before Sentinel receives an update.
2 questions test this
- Your Microsoft Sentinel workspace is onboarded to the Microsoft Defender portal. RuleH uses the When incident is updated trigger with the condition Status changed to Active and starts an SLA timer pla
- Your Microsoft Sentinel workspace is onboarded to the Microsoft Defender portal. A metrics playbook, run by an incident-updated automation rule, records every owner reassignment so that the SOC can me
- Automation rule ARM exports support repeatable deployment across workspaces and tenants
Export Sentinel automation rules as Azure Resource Manager template JSON to preserve their configured parameters as deployable code. The exported file is workspace-independent and can be imported into another workspace or tenant. Version-control and review this definition for repeatable deployments instead of manually recreating the same conditions and actions in each workspace.
Trap Using a Logic Apps workflow export to replicate the surrounding automation rule, although that workflow definition does not supply the Sentinel rule's trigger conditions and ordering.
- Sentinel playbooks are Logic Apps workflows for response and integration
Use a playbook for multi-step enrichment, external ticket synchronization, notifications, or response across services. A playbook is an Azure Logic Apps resource and can incur Logic Apps charges beyond Sentinel ingestion costs. A template must be deployed and configured before it becomes an active workflow.
Trap Treating a Content hub playbook template as an already running response workflow, because it still needs deployment and configuration.
2 questions test this
- You have a Microsoft Sentinel workspace. You install a solution from the Content hub that includes a playbook template that posts new incidents to a Microsoft Teams channel. An analyst expects the tem
- Your SOC deployed a Microsoft Sentinel playbook that enriches every new incident with threat intelligence from an external service and posts a summary to Microsoft Teams. The finance team asks whether
- The incident trigger supplies the incident together with alerts and entities
Use the Microsoft Sentinel incident trigger for workflows invoked on incident creation or updates and for incident-level manual response. Its payload includes incident properties, an alerts array, entities, and workspace information. Selecting an alert property can create a For each loop because an incident can contain several alerts.
Trap Using an entity-only trigger for a workflow that requires the complete incident and all its alerts, because its payload is scoped differently.
2 questions test this
- You are building a Microsoft Sentinel playbook that analysts will run manually from incidents and that an automation rule will also run whenever incidents are updated. The workflow must read the incid
- You are editing a Microsoft Sentinel playbook that starts with the Microsoft Sentinel incident trigger. You add a Send an email action that notifies the SOC mailbox and insert the dynamic field Alert:
- Playbook incident updates require the Incident ARM ID
Update Incident and Add comments to incident use the Incident ARM ID to identify the target. In a workflow starting with an alert, use Alert - Get Incident to retrieve the incident and its ARM ID first. An alert ID is not interchangeable with the incident resource identifier.
Trap Passing the alert ID into Update Incident, which expects an incident resource identifier.
2 questions test this
- A ServiceNow webhook starts a Logic Apps playbook through an HTTP request trigger, not a Microsoft Sentinel trigger. The webhook payload includes the Incident ARM ID of the related Microsoft Sentinel
- You have a Microsoft Sentinel playbook that starts with the Microsoft Sentinel alert trigger. Its Update Incident action, which should assign an owner to the related incident, fails because the action
- Entity actions extract typed entities from the incident's mixed array
Use Entities - Get IPs, Hosts, Accounts, URLs, or FileHashes to filter the Entities array and expose type-specific fields. The result is still an array, so process each entity as needed. For other entity types, combine Filter array with Parse JSON.
Trap Treating the incident Entities value as a single IP object, because it contains multiple heterogeneous JSON entities.
2 questions test this
- You are building a Microsoft Sentinel playbook that starts with the incident trigger. Incidents contain several entity types, including accounts, hosts, and IP addresses. For every IP address in the i
- Your Microsoft Sentinel incidents include mailbox entities, and a playbook must read each mailbox entity's properties. The Microsoft Sentinel connector provides Entities - Get actions for IPs, account
- Sentinel needs its own permission to invoke incident playbooks
Grant the Microsoft Sentinel service account Microsoft Sentinel Automation Contributor on the resource group containing the playbooks. This authorizes Sentinel to invoke workflows in that group independently of the analyst's own roles. The role is intended for the Sentinel service, not as a general user-authoring role.
Trap Granting Logic App Contributor only to the analyst, which does not give the Sentinel service permission to invoke the playbook.
2 questions test this
- Your Microsoft Sentinel workspace is in RG-SOC. Yesterday you granted Microsoft Sentinel the Microsoft Sentinel Automation Contributor role on RG2 so that automation rules could run Playbook7, an inci
- A Microsoft Sentinel administrator plans to assign the Microsoft Sentinel Automation Contributor role to the SOC analysts group on the playbooks resource group so that analysts can build, test, and ma
- Playbook hosting and connection identities determine separate authorization requirements
Consumption uses multitenant Logic Apps, whereas Standard supports single-tenant hosting and multiple workflows; Sentinel Standard playbooks must use stateful workflows. For Standard, choose Logic Apps Standard Operator to enable, disable, or resubmit workflows, Standard Developer to create and edit them, or Standard Contributor for full management. These hosting roles do not replace Sentinel invocation authorization or the independent authorization of each API connection inside the workflow. For example, a Sentinel connection authenticated as Reader can use triggers and read actions, but updating an incident requires Responder or Contributor on the target workspace.
Trap Assigning Standard Developer to the workflow author to fix a Reader-authenticated connection's failed incident update, which executes under the connection identity instead.
- Cross-tenant playbook authorization follows the workflow's location
For cross-workspace or Azure Lighthouse multitenant automation, define Sentinel's execution permissions where the playbook resides, not merely where the automation rule is stored. If an MSSP signed into its managing tenant configures a customer-workspace rule to run a customer-tenant playbook, Sentinel needs execution permissions in both tenants. In addition to the customer-side grant, add Lighthouse delegation for the managing tenant's Azure Security Insights application with Microsoft Sentinel Automation Contributor on the playbook resource group.
Trap Assuming delegated analyst access to a customer workspace also delegates the managing tenant's Sentinel service invocation rights, leaving the Azure Security Insights application unauthorized.
- Granting Sentinel playbook access requires role-assignment authority beyond workflow authoring
The person granting Sentinel its playbook execution permission needs Owner or User Access Administrator authority at the relevant scope. Logic App Contributor can edit and manage a Consumption workflow but cannot grant that access. When an author cannot authorize Sentinel to invoke the workflow, have an authorized access administrator perform the role assignment rather than expanding the workflow's actions or connections.
Trap Assigning Logic App Contributor to solve a failed Sentinel execution-role grant, although workflow management permission does not include role-assignment authority.
2 questions test this
- An engineer who holds Logic App Contributor on resource group RG1 builds Playbook1 there. When the engineer tries to grant Microsoft Sentinel permissions to run the playbooks in RG1, the role assignme
- An engineer holds only Logic App Contributor on resource group RG1, which contains Playbook1, a Consumption logic app that Microsoft Sentinel uses as a playbook. The engineer is assigned several Playb
- A new playbook template version marks deployed playbooks as having an update available
When a newer version of a playbook template is published, active playbooks created from it receive an additional label in the Active playbooks tab indicating an available update. Treat the label as a maintenance signal to review the deployed workflow against the new template. Publication of the template revision is not evidence that the running playbook has adopted its changes.
Trap Closing a playbook maintenance task solely because its template was updated in the content catalog, mistaking an update-available label for an applied workflow revision.
Also tested in
References
- https://learn.microsoft.com/en-us/defender-endpoint/attack-surface-reduction-rules-reference
- https://learn.microsoft.com/en-us/defender-xdr/automatic-attack-disruption
- https://learn.microsoft.com/en-us/azure/sentinel/automation/automate-responses-with-playbooks
- https://learn.microsoft.com/en-us/defender-xdr/custom-detection-rules
- https://learn.microsoft.com/en-us/azure/sentinel/threat-detection
- https://learn.microsoft.com/en-us/azure/sentinel/automate-incident-handling-with-automation-rules
- https://learn.microsoft.com/en-us/defender-xdr/investigate-alerts
- https://learn.microsoft.com/en-us/defender-xdr/configure-email-notifications
- https://learn.microsoft.com/en-us/defender-endpoint/automation-levels
- https://learn.microsoft.com/en-us/defender-endpoint/machine-groups
- https://learn.microsoft.com/en-us/defender-endpoint/basic-permissions
- https://learn.microsoft.com/en-us/defender-xdr/manage-rbac
- https://learn.microsoft.com/en-us/defender-endpoint/advanced-features
- https://learn.microsoft.com/en-us/defender-endpoint/edr-in-block-mode
- https://learn.microsoft.com/en-us/defender-endpoint/web-content-filtering
- https://learn.microsoft.com/en-us/defender-endpoint/network-protection
- https://learn.microsoft.com/en-us/defender-endpoint/indicators-overview
- https://learn.microsoft.com/en-us/defender-endpoint/manage-indicators
- https://learn.microsoft.com/en-us/azure/sentinel/watchlists
- https://learn.microsoft.com/en-us/defender-endpoint/attack-surface-reduction-rules-overview
- https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection
- https://learn.microsoft.com/en-us/defender-endpoint/manage-security-policies
- https://learn.microsoft.com/en-us/defender-endpoint/enable-attack-surface-reduction
- https://learn.microsoft.com/en-us/defender-endpoint/create-custom-data-collection-rules
- https://learn.microsoft.com/en-us/azure/azure-monitor/data-collection/data-collection-rule-overview
- https://learn.microsoft.com/en-us/windows/whats-new/extended-security-updates
- https://learn.microsoft.com/en-us/azure/sentinel/scheduled-rules-overview
- https://learn.microsoft.com/en-us/defender-xdr/m365d-notifications-incidents
- https://learn.microsoft.com/en-us/defender-xdr/m365d-response-actions-notifications
- https://learn.microsoft.com/en-us/defender-xdr/m365d-threat-analytics-notifications
- https://learn.microsoft.com/en-us/defender-endpoint/configure-vulnerability-email-notifications
- https://learn.microsoft.com/en-us/defender-xdr/m365d-action-center
- https://learn.microsoft.com/en-us/defender-endpoint/configure-automated-investigations-remediation
- https://learn.microsoft.com/en-us/defender-office-365/air-about
- https://learn.microsoft.com/en-us/defender-xdr/configure-attack-disruption
- https://learn.microsoft.com/en-us/defender-xdr/automatic-attack-disruption-exclusions
- https://learn.microsoft.com/en-us/defender-cloud-apps/app-governance-manage-app-governance
- https://learn.microsoft.com/en-us/azure/sentinel/automation/playbook-triggers-actions
- https://learn.microsoft.com/en-us/azure/sentinel/automation/logic-apps-playbooks
- https://learn.microsoft.com/en-us/azure/sentinel/automation/run-playbooks
- https://learn.microsoft.com/en-us/azure/sentinel/use-playbook-templates
- https://learn.microsoft.com/en-us/azure/sentinel/roles