Domain 3 of 4 · Chapter 1 of 5

Respond to Incidents in the Microsoft Defender Portal

Work the incident, not the scattered alerts

An adversary-in-the-middle phish lands, the user clicks, a session token is stolen, an inbox rule hides the replies, and within minutes a device is dropping malware while data starts leaving the tenant. That one attack would raise four or five separate alerts in four separate products. The reason SC-200 keeps coming back to the Microsoft Defender portal[1] (security.microsoft.com) is that it correlates those alerts into a single incident[2]: one record, one shared timeline, one entity graph of the users, devices, mailboxes, apps, mailbox rules, and IP addresses involved.

Why correlation is the whole point

Microsoft Defender XDR groups alerts that belong to the same attack into one incident automatically, so you do not have to manually connect a Defender for Endpoint malware alert to the Defender for Identity lateral-movement alert that preceded it. The Incidents queue[3] is the analyst's home page: it lists open incidents with severity, the number of active alerts, the impacted assets, and any tags. The first move on any incident is to open it and read the attack story[4] end to end, because the story tells you the blast radius before you touch a single entity.

What feeds one incident

The correlated incident can carry alerts from Microsoft Defender for Office 365, Microsoft Defender for Endpoint, Microsoft Defender for Identity (formerly Azure Advanced Threat Protection), Microsoft Defender for Cloud Apps (formerly Microsoft Cloud App Security), Microsoft Entra ID Protection (Microsoft Entra ID was Azure Active Directory), Microsoft Defender for Cloud, and Microsoft Purview. Because every source lands in the same queue, the analyst learns ONE place to triage and one navigation model, then applies a source-specific remediation at the end.

Defender for Office 365Defender for EndpointDefender for IdentityDefender for Cloud AppsEntra ID ProtectionDefender for CloudMicrosoft PurviewOne incidentcorrelated alertsin Defender portalShared timelineattack storyEntity graphusers, devices, mailboxes
Seven Microsoft security products feed alerts that XDR correlates into one incident with a shared timeline and entity graph.

The triage-to-response loop, and the per-source action map

Every incident runs the same loop no matter which product raised it: triage, investigate, then respond. Learn the loop once and the only thing that changes per incident is the final remediation verb.

Triage

Open the incident and set three things. Classification[5] marks it true positive, informational expected activity, or false positive (and a true positive carries a determination such as malware, phishing, or compromised account, which feeds Microsoft's detection tuning). Severity tells you and your team how hard to push. Assignment gives the incident an owner. Tagging and adding a comment keep the queue readable for the rest of the SOC.

Investigate

Walk the attack story and timeline[4], then pivot through the entity graph: from a user to the devices they signed in to, from a device to the mailbox and the apps, from an IP to every entity that touched it. Read the evidence and response tab to see what alerts fired and what automated investigation already did.

Respond, with the action that matches the entity

The testable detail is which remediation belongs to which entity type. A compromised device is isolated from the network[6] while you work it. A compromised identity has its sessions revoked and is forced to re-register MFA[7]. A malicious email is hunted across mailboxes and soft-deleted. A risky OAuth app or SaaS user is suspended in Defender for Cloud Apps. A cloud workload alert is fixed through the linked Defender for Cloud remediation. The loop is constant; the verb follows the entity.

Triageclassify, severity, assignInvestigatetimeline, entity graphRespondaction per entityDeviceisolateIdentityrevoke sessions, resetEmailsoft-delete across boxesApp / workloaddisable / remediate
The same triage to investigate to respond loop runs on every incident; only the respond action changes with the entity type.

Email threats: investigate and remediate with Defender for Office 365

When the incident's threat is email, the investigation tool is Threat Explorer (Explorer)[8] in Defender for Office 365, and the remediation is a tenant-wide cleanup, not a one-mailbox fix.

Find every copy, then act

Threat Explorer (Plan 2) and the lighter Real-time detections (Plan 1) let you search delivered mail by sender, subject, URL, file hash, or detection technology, so you can locate every copy of a phishing or malware message across all mailboxes. From the results you take remediation actions[9] directly: the common one is Soft delete, which moves the message to Deleted Items / Recoverable Items so it can still be restored, versus Hard delete which purges it. Remediation runs as a tracked action you can approve and review, not an irreversible bulk purge.

ZAP runs automatically after delivery

Zero-hour auto purge (ZAP)[10] retroactively moves mail to junk or quarantine when a verdict changes after delivery, for example a link that was clean at delivery and later flagged as malware. ZAP is the automatic backstop; Threat Explorer remediation is the analyst's manual, targeted cleanup. Knowing that ZAP acts post-delivery is a frequent exam point.

Do not stop at the message

A real BEC or phishing compromise almost always leaves persistence in the mailbox. After removing the mail, check for attacker-created inbox rules and forwarding[11] (a rule that auto-deletes replies or forwards mail externally), reset the user's credentials, and revoke sessions. Removing the email alone leaves the foothold in place.

Threat Explorerfind all copiesSoft deleterecoverable, not purgeRemove inbox ruleskill forwardingReset and revokeaccount securedZAP (automatic backstop)purges post-delivery on new verdict
Email cleanup: Threat Explorer finds every copy, soft-delete, remove inbox rules, reset the account; ZAP is the automatic post-delivery backstop.

Automatic attack disruption: ransomware, BEC, and AiTM

For a small set of high-confidence attacks, Microsoft Defender XDR does not wait for an analyst. Automatic attack disruption[12] contains an attack in progress by itself, then hands you a half-finished incident to verify and close out.

When it fires and what it does

Disruption triggers only on high-confidence, correlated signals for specific playbooks: human-operated ransomware[12], business email compromise (BEC), and adversary-in-the-middle (AiTM). When the confidence bar is crossed it takes automatic response actions[12] such as disabling a compromised user account[13] in Microsoft Entra ID, isolating a device[6], or containing a device with a built-in containment action, to break the attacker's chain before damage spreads. The incident is tagged so you can see disruption acted.

Your job after disruption

The analyst role shifts from racing the attacker to confirming the automatic action and finishing remediation. Read the disruption tag and the action it took, confirm the blast radius, then complete the cleanup the automation did not do. Because it acts on accounts and devices automatically, you must also know how to undo a disruption action[14] (re-enable an account, release a device from containment) when triage shows a false positive. Disruption needs the prerequisite signal sources connected and the right roles, but as the analyst you respond to it rather than configure it.

Disruption vs ordinary AIR

Disruption is not the same as automated investigation and response (AIR)[15]: AIR investigates an alert and proposes or runs remediation on the affected assets, while attack disruption is the narrower, higher-confidence capability that takes immediate containment at the account or device level mid-attack.

High-confidence signalransomware, BEC, AiTMAuto containmentdisable account, isolateAnalyst verifiesread disruption tagTrue positivecomplete remediationFalse positiveundo actionConfirmedWrong
Attack disruption auto-contains a high-confidence attack; the analyst then verifies and either completes remediation or undoes a false positive.

Compromised identities: Entra ID Protection and Defender for Identity

Identity incidents come from two complementary sources that the portal correlates into the same incident, and SC-200 expects you to respond to the alert, not to build the Conditional Access that gates it.

Cloud identity risk: Microsoft Entra ID Protection

Microsoft Entra ID Protection[16] scores sign-in risk[17] (this sign-in looks anomalous, for example impossible travel or anonymous IP) and user risk[17] (this account is probably compromised, for example leaked credentials). The analyst response to a confirmed risky user is to remediate and unblock[7]: require a secure password reset (which remediates user risk once completed), revoke the user's active sessions/refresh tokens so a stolen token stops working, and have them re-register MFA. You can also explicitly confirm a user as compromised or dismiss the risk as a false positive, which feeds the model.

On-premises and lateral movement: Microsoft Defender for Identity

Microsoft Defender for Identity[18] watches the Active Directory side using sensors on domain controllers, detecting reconnaissance, credential theft (Pass-the-Hash, Pass-the-Ticket), and lateral movement[19] toward sensitive accounts. Its alerts surface in the Defender portal and correlate with the Entra and Endpoint alerts for the same user, so one compromised identity shows both its cloud sign-in risk and its on-premises lateral-movement path in a single incident.

Respond, do not redesign

Revoking sessions, forcing a reset, and confirming the user compromised is response work in scope for SC-200. Building Conditional Access policies, configuring risk-based sign-in policies, or setting up PIM is identity-governance design owned by SC-300. The exam line is respond to the risk versus author the policy that enforces it.

Entra ID Protectionsign-in risk, user riskDefender for Identitylateral movement, ADOne identitycorrelated incidentRevoke sessionsstolen token diesSecure resetremediates user riskRe-register MFAconfirm compromised
Cloud risk and on-premises lateral movement correlate into one identity incident; respond by revoking sessions, secure reset, and MFA re-registration.

Cloud Apps, Defender for Cloud, and Purview signal sources

The remaining three sources round out the seven investigation surfaces a portal incident can carry. Each has its own remediation, and for the policy-driven ones (Purview) the boundary between respond and author matters for the exam.

Defender for Cloud Apps: risky SaaS and OAuth

Microsoft Defender for Cloud Apps[20] raises alerts on risky SaaS usage and on malicious or overprivileged OAuth apps[21]. Investigate the alert in the activity log, then remediate: suspend the user, require a sign-in, or for a malicious OAuth app disable or revoke the app[22] so its consented access is cut. App governance flags the OAuth-app threats specifically.

Defender for Cloud: workload protection alerts

Microsoft Defender for Cloud[23] raises security alerts[24] from its paid Defender plans (Servers, Storage, SQL, Containers) on runtime threats against your cloud workloads, and these alerts now flow into the unified Defender portal incidents. Investigate the alert, then respond[24] by following its remediation steps or applying the linked security recommendation on the affected resource (for example, restrict a publicly exposed management port). Remember that only an enabled Defender plan produces alerts; free CSPM produces recommendations, not alerts.

Microsoft Purview DLP and insider risk: respond, do not author

The Defender portal surfaces alerts from Microsoft Purview Data Loss Prevention (DLP)[25] (a policy match where sensitive data was about to leave) and insider risk management[26] (risky user behaviour such as mass download before resignation). Your job is to investigate the alert, scope the user and the data, and remediate (revoke access, escalate an insider risk alert to a case[27]). Authoring the DLP policy or configuring insider risk policies is Purview administration owned by SC-401, not SC-200; the exam tests the response, not the policy build.

Defender for Cloud Appsrisky SaaS, OAuth appSuspend user / disable apprevoke OAuth consentDefender for Cloudworkload alert (paid plan)Apply remediationlinked recommendationPurview DLP / insider riskpolicy match, risky userRespond, not authorscope, escalate to case
Three more incident sources and their remediation; for Purview DLP and insider risk SC-200 tests the response, not authoring the policy.

Exam-pattern recognition

SC-200 incident questions almost always give you a scenario and ask for the single best response action. The pattern that wins is: identify the entity under attack, then pick the remediation verb that matches it.

Read the entity, pick the verb

  • The stem names a device dropping malware and asks how to stop spread while you investigate: isolate the device, not reimage and not block at the firewall.
  • The stem names a user with a risky sign-in or leaked credentials: revoke the user's sessions and require a secure password reset (and MFA re-registration). Resetting the password alone without revoking sessions leaves a stolen refresh token working, which is a classic distractor.
  • The stem describes a phishing email already delivered to many mailboxes: use Threat Explorer to find all copies and soft-delete them, then remove attacker inbox rules. Asking the user to delete it themselves, or fixing one mailbox, is the wrong-scale answer.
  • The stem describes in-progress ransomware or BEC that was already contained automatically: the right action is to verify the automatic attack disruption and complete remediation, recognizing disruption acted on its own.
  • The stem describes a risky OAuth app: disable/revoke the app in Defender for Cloud Apps; suspending only the user does not cut the app's consented access.

Respond vs author is a recurring trap

Whenever a question mentions Purview DLP, insider risk, Conditional Access, or Azure infrastructure hardening, check whether it asks you to respond to an alert (in scope, you act in the Defender portal) or to create/tune the policy (out of scope, owned by SC-401 / SC-300 / AZ-500). The in-scope answer is always the investigate-and-remediate option, never the build-the-policy option.

Portal vs portal

If the scenario is a correlated cross-product incident, the answer lives in the Microsoft Defender portal. If it is specifically about Sentinel analytics rules, automation rules, or playbooks, that is the Sentinel incident-response subtopic. The two are converging in the unified SecOps platform, but the exam still distinguishes which portal owns the action.

Which signal source, and the remediation action it calls for

Signal sourceWhat it detectsPrimary remediation action in the Defender portal
Defender for Office 365Phishing, malware, and BEC email already deliveredFind all copies with Threat Explorer and soft-delete; remove attacker inbox rules and forwarding
Automatic attack disruption (Defender XDR)High-confidence ransomware, BEC, AiTM in progressVerify the automatic containment (account disabled, device isolated); finish cleanup or undo if false positive
Microsoft Entra ID ProtectionRisky sign-ins and risky users (compromised identities)Confirm compromised, revoke sessions, require secure password reset and MFA re-registration
Defender for IdentityOn-premises identity attacks and lateral movementInvestigate the lateral-movement path; disable/reset the account, coordinate with the Entra response
Defender for Cloud AppsRisky SaaS usage and malicious OAuth appsSuspend the user or disable/revoke the OAuth app; govern the risky activity
Defender for Cloud (workload protection)Runtime threats on VMs, storage, SQL, containersInvestigate the alert; apply the linked remediation steps or security recommendation on the resource
Microsoft Purview DLP / insider riskCompromised or risky data handling by a userScope the user and data, remediate access, escalate to an insider risk case where warranted

Decision tree

Already auto-contained?attack disruption tagVerify disruptionfinish or undoYesWhich entity under attack?read the incident graphNoIdentityrisky user / lateral moveEmailphish deliveredApp / device / workloadSaaS, endpoint, cloudRevoke sessions, resetre-register MFAThreat Explorersoft-delete all copiesIsolate deviceendpoint threatDisable app / remediateCloud Apps / Defender for CloudAlways: classify, set severity, assign the incidentrespond to the alert, never author the policy

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.

Work the correlated incident, not the individual alerts

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

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

The triage-investigate-respond loop is the same for every source

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

Classify an incident to mark it true positive, false positive, or informational

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

1 question tests this
Isolate a compromised device to stop spread while you investigate

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

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

Revoke sessions and reset, do not just reset the password

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

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

Entra ID Protection scores sign-in risk and user risk separately

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

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

3 questions test this
Defender for Identity covers the on-premises and lateral-movement side

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

3 questions test this
Use Threat Explorer to find and soft-delete every copy of a malicious email

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

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

1 question tests this
Soft delete is recoverable; hard delete purges

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

3 questions test this
Zero-hour auto purge acts automatically after delivery on a new verdict

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

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

After removing the mail, kill attacker inbox rules and forwarding

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

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

1 question tests this
Automatic attack disruption contains ransomware, BEC, and AiTM on its own

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

2 questions test this
After disruption fires, verify the action and finish or undo it

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

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

4 questions test this
Attack disruption is narrower and faster than automated investigation and response

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

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

Disable or revoke a malicious OAuth app, not just the user

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

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

3 questions test this
Defender for Cloud workload alerts need an enabled paid plan

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

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

Respond to Purview DLP and insider risk alerts, do not author the policy

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

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

2 questions test this
Read the entity, then pick the matching remediation verb

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

Correlated cross-product incidents are handled in the Defender portal

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

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

Insider Risk content needs the Investigators role group, even after a case opens

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

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

3 questions test this
View blast radius needs the Sentinel data lake and defined critical assets

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

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

3 questions test this
Silence a recurring false-positive Defender for Cloud alert with a suppression rule

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

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

4 questions test this

Also tested in

References

  1. https://learn.microsoft.com/en-us/defender-xdr/microsoft-365-defender-portal
  2. https://learn.microsoft.com/en-us/defender-xdr/incidents-overview
  3. https://learn.microsoft.com/en-us/defender-xdr/incident-queue
  4. https://learn.microsoft.com/en-us/defender-xdr/investigate-incidents
  5. https://learn.microsoft.com/en-us/defender-xdr/manage-incidents
  6. https://learn.microsoft.com/en-us/defender-endpoint/respond-machine-alerts
  7. https://learn.microsoft.com/en-us/entra/id-protection/howto-identity-protection-remediate-unblock
  8. https://learn.microsoft.com/en-us/defender-office-365/threat-explorer-about
  9. https://learn.microsoft.com/en-us/defender-office-365/remediate-malicious-email-delivered-office-365
  10. https://learn.microsoft.com/en-us/defender-office-365/zero-hour-auto-purge
  11. https://learn.microsoft.com/en-us/defender-office-365/responding-to-a-compromised-email-account
  12. https://learn.microsoft.com/en-us/defender-xdr/automatic-attack-disruption
  13. https://learn.microsoft.com/en-us/defender-xdr/configure-attack-disruption
  14. https://learn.microsoft.com/en-us/defender-xdr/autoad-results
  15. https://learn.microsoft.com/en-us/defender-xdr/m365d-autoir
  16. https://learn.microsoft.com/en-us/entra/id-protection/overview-identity-protection
  17. https://learn.microsoft.com/en-us/entra/id-protection/concept-identity-protection-risks
  18. https://learn.microsoft.com/en-us/defender-for-identity/what-is
  19. https://learn.microsoft.com/en-us/defender-for-identity/understand-lateral-movement-paths
  20. https://learn.microsoft.com/en-us/defender-cloud-apps/what-is-defender-for-cloud-apps
  21. https://learn.microsoft.com/en-us/defender-cloud-apps/investigate-risky-oauth
  22. https://learn.microsoft.com/en-us/defender-cloud-apps/manage-app-permissions
  23. https://learn.microsoft.com/en-us/azure/defender-for-cloud/alerts-overview
  24. https://learn.microsoft.com/en-us/azure/defender-for-cloud/managing-and-responding-alerts
  25. https://learn.microsoft.com/en-us/purview/dlp-alerts-dashboard-learn
  26. https://learn.microsoft.com/en-us/purview/insider-risk-management-activities
  27. https://learn.microsoft.com/en-us/purview/insider-risk-management-cases