Microsoft Defender XDR (16 questions)
Go deeper on this topic in Microsoft Defender XDR Field Guide.
All Microsoft Defender for Endpoint device groups are set to Full - remediate threats automatically. An automated investigation in Microsoft Defender for Office 365 determines that a delivered message contains a malicious URL, yet the recommended soft-delete action shows as Pending approval in the Action center. What best explains this?
Correct answer: A. Malicious email-content remediations are recommended actions that always await SecOps approval; device-group automation levels govern endpoint remediation, not email.
In the AIR verdict model, a Malicious verdict on email content (URLs or attachments) produces recommended remediation actions that are pending approval, regardless of device automation. The Full - remediate threats automatically setting applies to device (endpoint) remediation, so email actions still require a SecOps member to approve them.
Why the other options are wrong:
- B. Full automation only auto-remediates device threats; email-content actions are pending by design, so nothing is misconfigured.
- C. Manage security settings is unrelated to approving AIR email actions; approval is a SecOps task in the Action center or incident.
- D. Recommended email actions are generated when the latest delivery location is a cloud mailbox; the pending state is by design, not an on-prem limitation.
Memory hook: Device verdicts can auto-fire; email verdicts always wait for a human to approve.
Microsoft Learn: https://learn.microsoft.com/defender-xdr/m365d-remediation-actions
Your tenant has Microsoft Defender for Office 365 but no custom Safe Attachments or Safe Links policies, and you have not enabled the Standard or Strict preset security policies. Which statement about the protection your recipients receive is correct?
Correct answer: D. The Built-in protection preset security policy already provides Safe Links and Safe Attachments protection to all recipients by default.
Built-in protection is assigned to all recipients by default and effectively provides default Safe Links and Safe Attachments policies (you can configure exceptions). The Standard and Strict presets are assigned to no one until you enable them and add users.
Why the other options are wrong:
- A. Standard and Strict presets apply to no one until you explicitly enable them and assign users.
- B. Both Safe Links and Safe Attachments are covered by Built-in protection; Safe Attachments does not require a custom policy for baseline coverage.
- C. Even without a custom policy, Built-in protection gives all recipients Safe Links and Safe Attachments protection by default.
Memory hook: Built-in protection = Safe Links + Safe Attachments for everyone, on by default.
Microsoft Learn: https://learn.microsoft.com/defender-office-365/preset-security-policies
An authorized vulnerability scanner triggers dozens of Microsoft Defender for Endpoint alerts every night. The SOC manager wants these alerts to stop appearing in the alert queue and stop creating incidents, but the threat hunting team requires that the records remain queryable in the AlertInfo and AlertEvidence tables in advanced hunting. Which alert tuning action, configured under Settings, then Microsoft Defender XDR, then Alert tuning, meets all of the requirements?
Correct answer: D. Hide alert
Hide alert is the only action that satisfies every requirement: per Microsoft Learn, it suppresses the alert and prevents incident creation, while hidden alerts remain in the AlertInfo and AlertEvidence tables so hunters can still query them. Hide alert is only applicable to Defender for Endpoint alerts, which matches this scenario's source. The rule conditions should be scoped tightly, for example the scanner process name AND its service account, rather than a broad wildcard.
Why the other options are wrong:
- A. The indicator allow list governs blocking and remediation behavior for files, not alert queue hygiene. Allow-listing the scanner binary changes how Defender treats the file but is not the mechanism for suppressing alerts while preserving AlertInfo records, and it carries side effects beyond tuning.
- B. Resolve alert does not suppress anything: matching alerts and their related incidents are still created, just automatically set to resolved status. The resolved records still land in the queue and incidents are still generated, so it fails both the 'stop appearing' and 'stop creating incidents' requirements.
- C. Set as behavior converts matching signals into behaviors: they no longer appear in the alert queue or trigger incidents, but the data lands in the BehaviorInfo and BehaviorEntities tables, not AlertInfo and AlertEvidence, which violates the hunting team's requirement. It is also unsupported for Defender for Cloud and Defender for Office 365 alerts.
Memory hook: Hide = out of the queue, no incident, but still in AlertInfo (MDE only). Resolve = closes it everywhere. Behavior = moves the data to BehaviorInfo.
Microsoft Learn: https://learn.microsoft.com/defender-xdr/investigate-alerts#tune-an-alert
You configure a Microsoft Defender XDR custom detection rule against Defender XDR data with a frequency of "Every 3 hours." To avoid missing or double-counting events, what lookback period does the rule apply, and how should your query's time filter relate to it?
Correct answer: C. 12-hour lookback; align your query's time filter with the lookback window.
A rule that runs every 3 hours looks back 12 hours, not 3. The fixed mapping for custom detections on Defender XDR data: hourly checks the last 4 hours, every 3 hours checks 12 hours, every 12 hours checks 48 hours, and every 24 hours checks 30 days. Match your query's time filter to that lookback window so relevant results aren't ignored.
Why the other options are wrong:
- A. The every-3-hours frequency carries a fixed 12-hour lookback; 24 hours isn't the window for this frequency.
- B. The lookback for a 3-hour frequency is 12 hours, not 3; a 3-hour filter would miss data inside the lookback window.
- D. 48 hours is the lookback for the every-12-hours frequency, not every 3 hours.
Memory hook: Lookback: 3h gets 12h, 12h gets 48h, 24h gets 30d, hourly gets 4h.
Microsoft Learn: https://learn.microsoft.com/defender-xdr/custom-detection-rules
Executive and support staff need Microsoft's most aggressive email protection, with the admin releasing any blocked messages the users request. A custom anti-spam policy already targets some of these same users. The team assigns the Strict preset security policy to the executives. For those users, how are the anti-spam settings resolved, and how does Built-in protection relate?
Correct answer: A. The Strict preset security policy's settings are applied to those users before the custom anti-spam policy or the default policy; Built-in protection provides only Safe Links and Safe Attachments to recipients not covered by Standard/Strict or custom policies
Preset security policies sit at the top of the threat-policy order of precedence: Strict is applied first, then Standard, then Defender for Office 365 evaluation policies, then custom threat policies by priority, and finally the Built-in protection preset (Safe Links/Safe Attachments) and the default policies. So for a user in the Strict preset, the Strict anti-spam settings are applied instead of the custom or default anti-spam policy; no merging occurs. Built-in protection is assigned to all recipients by default but only provides Safe Links and Safe Attachments, and it is the lowest-precedence preset, so it never overrides Strict. Strict is the right choice because it quarantines more aggressively and is designed for high-value targets whose admins review and release messages.
Why the other options are wrong:
- B. Built-in protection is assigned to all recipients by default, but it only supplies Safe Links and Safe Attachments and is the lowest-precedence preset. It does not override the Strict preset's settings.
- C. Custom policy priority determines ordering only among custom policies. Preset security policies (Strict, then Standard) are always applied before any custom or default threat policy, so a custom anti-spam policy cannot outrank the Strict preset even at priority 0.
- D. Threat policies are not merged per setting. The first applicable policy in the precedence order wins for a given recipient, and preset policies are evaluated before custom and default policies.
Memory hook: Order: Strict then Standard then eval then custom (by priority) then Built-in protection and defaults. Presets always beat custom; Built-in protection is just Safe Links/Attachments at the bottom.
Microsoft Learn: https://learn.microsoft.com/defender-office-365/preset-security-policies
After Microsoft Entra flags a risky sign-in for a user, a threat hunter wants to determine whether that user then performed unusual bulk file downloads from SharePoint Online and OneDrive, using data surfaced by Microsoft Defender for Cloud Apps in advanced hunting. Which table holds these cloud app file-activity events (for example, ActionType 'FileDownloaded') to correlate with the sign-in?
Correct answer: B. CloudAppEvents
CloudAppEvents contains events involving accounts and objects in Office 365 and other cloud apps and services, populated by Microsoft Defender for Cloud Apps. It records SaaS activities such as FileDownloaded for SharePoint Online and OneDrive, with columns like ActionType, Application, AccountObjectId, and RawEventData that a hunter can pivot on and correlate with the risky sign-in by account. The table requires Defender for Cloud Apps to be deployed and the Microsoft 365 activities connector enabled.
Why the other options are wrong:
- A. EmailEvents covers email messages processed by Defender for Office 365 (delivery, sender, recipients). It does not capture SharePoint or OneDrive file-download activity.
- C. IdentityInfo is a reference and enrichment table describing user account attributes. It provides context about the identity but contains no file-download activity events.
- D. DeviceFileEvents records file create, modify, and delete activity on managed endpoints from Defender for Endpoint. It captures local file operations on a device, not cloud service downloads surfaced by Defender for Cloud Apps.
Memory hook: SaaS/Office 365 activity (FileDownloaded, MailItemsAccessed) = CloudAppEvents (from Defender for Cloud Apps). Not EmailEvents, not DeviceFileEvents.
Microsoft Learn: https://learn.microsoft.com/defender-xdr/advanced-hunting-cloudappevents-table
You want Microsoft Defender for Identity to disable a compromised on-premises Active Directory account and reset its password from the Microsoft Defender portal. All of your sensors are v2.x running on domain controllers. Which account performs these remediation actions, and how does it differ from the Directory Service Account (DSA)?
Correct answer: D. A dedicated action account (a gMSA you scope with the needed permissions) performs remediation, while the DSA is used only to read Active Directory data; by default the v2.x sensor uses the domain controller's LocalSystem account for actions.
Remediation actions such as disabling a user or resetting a password are performed by the action account. By default the v2.x sensor impersonates the domain controller's LocalSystem account; if you want scoped permissions you configure a dedicated gMSA as the action account. This is separate from the DSA, which only reads AD data.
Why the other options are wrong:
- A. The DSA only reads AD data; remediation is handled by the action account (LocalSystem by default, or a scoped gMSA), not the DSA.
- B. v2.x sensors on domain controllers already support action accounts; v3.x actually drops gMSA action accounts and always uses LocalSystem.
- C. A gMSA is the recommended scoped option for the action account; you do not have to use a stored regular user account.
Memory hook: DSA reads; the action account acts (LocalSystem by default, gMSA if you scope it).
Microsoft Learn: https://learn.microsoft.com/defender-for-identity/deploy/manage-action-accounts
During email remediation in Microsoft Defender, which action moves the messages to the user's Recoverable Items\Deletions folder, leaving them recoverable by the user?
Correct answer: C. Soft delete
Soft delete moves messages to the Recoverable Items\Deletions folder, where they remain recoverable by the user (and admins). Hard delete purges the message (recoverable only by an admin via single-item recovery), and Move to Deleted Items only places it in the visible Deleted Items folder.
Why the other options are wrong:
- A. Move to Deleted Items places messages in the ordinary Deleted Items folder, not Recoverable Items\Deletions.
- B. Hard delete purges the message; only admins can recover it via single-item recovery, not the user from Recoverable Items.
- D. Quarantine email holds the message in quarantine for admin review; it is not a move to Recoverable Items.
Memory hook: Soft delete = Recoverable Items (user can get it back); Hard delete = purged (admin-only recovery).
Microsoft Learn: https://learn.microsoft.com/defender-office-365/remediate-malicious-email-delivered-office-365
In Microsoft Security Exposure Management, a database server matches two critical asset classification rules at the same time: a predefined rule that assigns High criticality and a custom rule that assigns Medium criticality. Months later, the server is rebuilt and no longer matches the High-criticality rule's criteria. How does Exposure Management handle the asset's criticality level across these events?
Correct answer: B. The rule with the highest criticality level takes precedence, so the asset is High; when it no longer meets that rule's criteria, it automatically reverts to the next applicable classification level (Medium).
Microsoft Security Exposure Management categorizes assets into four criticality levels: Very High, High, Medium, and Low. When multiple classification rules apply to the same asset, the rule with the highest criticality level takes precedence. That classification remains in effect until the asset no longer meets the criteria for that rule, at which point it automatically reverts to the next applicable classification level. So the server is treated as High while it matches the predefined rule, then automatically drops to Medium after the rebuild. Getting criticality right matters operationally: criticality feeds prioritization surfaces such as device inventory sorting, security recommendations (exposed critical assets), and incident prioritization in the Defender portal.
Why the other options are wrong:
- A. There is no dual-classification state or forced manual resolution. The platform resolves the conflict automatically by applying the highest applicable criticality level.
- C. Rule origin (custom versus predefined) does not determine precedence. A predefined High rule outranks a custom Medium rule because High outranks Medium.
- D. Rule recency is not the tiebreaker. Precedence is determined by the criticality level each rule assigns, with the highest level winning.
Memory hook: Criticality conflicts: highest level wins, and the asset auto-demotes to the next applicable level when that rule stops matching.
Microsoft Learn: https://learn.microsoft.com/security-exposure-management/classify-critical-assets
A vulnerability management lead opens Threat analytics in the Microsoft Defender portal (Threat intelligence, then Threat analytics). They want to prioritize patching against tracked threats the organization has not yet generated any alerts for, ranked by how severe the exploited vulnerabilities are and how many onboarded devices carry those weaknesses. Which dashboard section provides this ranking?
Correct answer: D. Highest exposure threats
The threat analytics dashboard (https://security.microsoft.com/threatanalytics3) summarizes threats in three sections: Latest threats (most recently published or updated reports), High-impact threats (ranked by the number of active and resolved alerts in your organization), and Highest exposure threats. Per Microsoft Learn, the exposure level is calculated using two pieces of information: how severe the vulnerabilities associated with the threat are, and how many devices in your organization could be exploited by those vulnerabilities. Because exposure is driven by device posture rather than alerts, this section can surface threats the tenant has never seen an alert for, which is exactly what proactive patch prioritization needs.
Why the other options are wrong:
- A. High-impact threats ranks by the number of active and resolved alerts in your own tenant, so it answers 'what is already hitting us,' not 'what could hit us.' A threat with zero alerts sits low there regardless of your vulnerability posture.
- B. The Related incidents tab lists incidents in your tenant already correlated to the threat; by definition it requires alerts to exist and offers no vulnerability-based ranking across threats.
- C. Latest threats orders reports by publication or update recency. It tells you what is new, not how exposed your devices are to it.
Memory hook: High impact = already burning you (alert counts). Highest exposure = could burn you (vuln severity x vulnerable devices). Patch off the exposure list.
Microsoft Learn: https://learn.microsoft.com/defender-xdr/threat-analytics
A SOC lead wants to add custom case status values such as 'Pending vendor response' and 'Detection tuning' to case management in the Microsoft Defender portal. The lead currently holds Microsoft Sentinel Responder, which already lets them create cases and link incidents. Using Microsoft Sentinel roles, what is the minimum role required to customize the case status options?
Correct answer: A. Microsoft Sentinel Contributor
Customizing case status options requires the Microsoft Sentinel Contributor role, or Core Security settings (manage) under Authorization and settings in unified RBAC. That is the top tier of case management RBAC in the Defender portal: viewing the case queue, details, tasks, comments, and audits needs only Security data basics (read) or Microsoft Sentinel Reader, while creating and managing cases and case tasks, assigning, updating status, and linking or unlinking incidents needs Alerts (manage) or Microsoft Sentinel Responder. The trap is assuming Responder covers everything case-related; changing the status menu is a configuration change, one tier above day-to-day case work and typically a SOC lead or admin function.
Why the other options are wrong:
- B. Subscription Owner is far beyond the minimum. The documented minimum Sentinel role for customizing case status options is Microsoft Sentinel Contributor (or Core Security settings (manage) in Defender unified RBAC).
- C. Microsoft Sentinel Reader maps to view-only case access: queue, details, tasks, comments, and audits. It cannot create cases, let alone customize status values.
- D. Microsoft Sentinel Responder covers working cases (create, manage, assign, update status, link/unlink incidents) but not customizing the available status options, which is a settings-level change.
Memory hook: Cases RBAC ladder: Reader views, Responder works the case, Contributor changes the status menu.
Microsoft Learn: https://learn.microsoft.com/unified-secops/cases-overview
A SOC has onboarded Microsoft Sentinel to the Microsoft Defender portal. A detection engineer is writing a brand-new detection over DeviceEvents and EmailEvents data and wants native Defender XDR remediation actions with automatic entity mapping, while minimizing ingestion costs. Which detection mechanism does Microsoft currently recommend for this rule?
Correct answer: D. A custom detection rule in the Microsoft Defender portal
Microsoft's feature-comparison guidance states that custom detections are now the best way to create new rules across Microsoft Sentinel and Microsoft Defender XDR. Custom detections reduce ingestion costs by running directly against already-available Defender data, provide real-time detections, and integrate directly with Defender XDR data, functions, and native remediation actions with automatic entity mapping. Since this detection targets Defender XDR tables (DeviceEvents, EmailEvents), a custom detection rule is exactly the recommended vehicle. Existing analytics rules keep running, and analytics rules still lead in a few areas (such as full MITRE technique coverage), but new detections on Defender data should be custom detections.
Why the other options are wrong:
- A. Sentinel NRT analytics rules test events only after they're ingested and are limited to Sentinel data. Custom detections offer NRT streaming evaluation and are the recommended path for new rules on Defender data.
- B. Scheduled analytics rules cannot query Defender XDR data natively (that data would first have to be ingested into the workspace, incurring ingestion cost) and do not provide native Defender XDR remediation actions.
- C. Microsoft security rules only create Sentinel incidents from alerts generated by other Microsoft security products. They cannot express a custom KQL detection over DeviceEvents and EmailEvents.
Memory hook: New detection on Defender data in the unified portal = custom detection: cheaper (no re-ingestion), real-time, native XDR response actions.
Microsoft Learn: https://learn.microsoft.com/azure/sentinel/compare-analytics-rules-custom-detections
A security operations manager still runs Microsoft Sentinel exclusively in the Azure portal and asks how long that experience remains supported before the team must operate from the Microsoft Defender portal. What should you tell them?
Correct answer: B. After March 31, 2027, Microsoft Sentinel will no longer be supported in the Azure portal and will be available only in the Microsoft Defender portal.
Microsoft's published retirement timeline states that after March 31, 2027, Microsoft Sentinel will no longer be supported in the Azure portal and will be available only in the Microsoft Defender portal. Microsoft Sentinel is generally available in the Defender portal, including for customers without Defender XDR or an E5 license, and Microsoft recommends that Azure-portal customers start planning their transition now. Teams still operating from the Azure portal should treat this as a hard deadline for moving their SOC workflows.
Why the other options are wrong:
- A. July 2025 is when new customers onboarding their first Sentinel workspace (with subscription Owner or User Access Administrator permissions, and not Lighthouse-delegated) began being automatically onboarded to the Defender portal. It was not a retirement or forced migration of existing Azure-portal workspaces.
- C. There is no indefinite grandfathering for older workspaces. All customers using Sentinel in the Azure portal will be redirected to the Defender portal after the retirement date.
- D. Log Analytics retention governs how long data is kept, not portal support. The retirement is a fixed calendar date for the whole service, unrelated to any workspace's retention settings.
Memory hook: March 31, 2027: Azure portal Sentinel goes dark. The Defender portal is the only home after that.
Microsoft Learn: https://learn.microsoft.com/azure/sentinel/overview#microsoft-sentinel-in-the-azure-portal-retirement-timeline
During an incident investigation, Microsoft Defender XDR automatically contained several user accounts and isolated two devices without analyst intervention. The incident carries the 'Attack Disruption' tag. Which feature triggered these containment actions?
Correct answer: D. Automatic attack disruption in Microsoft Defender XDR
Automatic attack disruption in Microsoft Defender XDR correlates signals from endpoints, identities, email, and SaaS applications to identify active human-operated attacks (such as ransomware and business email compromise) with high confidence and automatically contains compromised assets. Disrupted incidents are tagged with 'Attack Disruption' and the specific threat type. Actions include containing devices and disabling user accounts.
Why the other options are wrong:
- A. Microsoft Sentinel automation rules can trigger playbooks, but they do not produce the 'Attack Disruption' incident tag. Sentinel automation operates at the SIEM layer and calls Logic Apps, rather than performing XDR-native containment actions directly.
- B. AIR (Automated Investigation and Response) is triggered by specific alerts and applies remediation actions based on investigation results. It does not tag incidents with 'Attack Disruption' and operates differently from the cross-workload automatic attack disruption capability.
- C. Custom detection rules can trigger alerts and response actions but operate per-rule based on a specific query match. They do not produce the 'Attack Disruption' tag and do not correlate signals across the entire XDR suite to disrupt multi-stage attacks.
Memory hook: Attack Disruption tag = XDR's AI-driven automatic containment. No human needed, no playbook required.
Microsoft Learn: https://learn.microsoft.com/defender-xdr/automatic-attack-disruption
A threat hunting team uses case management in the Microsoft Defender portal to track a long-running phishing campaign that has generated roughly 250 related incidents. The team wants to link every incident to a single case so the whole campaign has one durable record. Which documented service limit forces a different design?
Correct answer: A. Each case supports a maximum of 100 linked incidents, so the campaign's 250 incidents must be split across multiple cases.
The Microsoft Sentinel service limits page documents the case management limits: 100,000 cases per tenant, 500 GB of attachments per tenant, and 100 linked incidents per case. Linking 250 incidents to one case exceeds the per-case incident cap, so the team must split the campaign across multiple cases (for example, by wave or by month) and use the case descriptions, tasks, or naming conventions to tie them together. Cases themselves are durable: they do not expire or auto-delete, and case IDs (starting at 1000) are never recycled, which is why archival is handled with custom statuses and filters rather than deletion.
Why the other options are wrong:
- B. Cases do not auto-close or auto-purge. They persist until manually deleted (which requires typing 'delete' in a confirmation dialog); archival is managed with statuses and filters.
- C. The tenant limit is 100,000 cases, not 1,000, and case IDs are never reused, so there is no ID recycling.
- D. There is no status-based restriction on linking. The constraint on this scenario is the documented cap of 100 linked incidents per case.
Memory hook: Case limits: 100 incidents per case, 100,000 cases per tenant, 500 GB of attachments. The '100 per case' is the one that bites campaign tracking.
Microsoft Learn: https://learn.microsoft.com/azure/sentinel/sentinel-service-limits
While investigating in the incident graph, an analyst switches the associated-incidents view from This incident only to All associated incidents. What is the effect of this change?
Correct answer: A. It expands the graph to show related incidents and alerts for context only; it does not change grouping, correlation rules, merge logic, or the other incidents' separate ownership and lifecycle.
The All associated incidents view helps analysts see additional related incidents and alerts in the investigation graph for added context. It does not change incident grouping, correlation rules, or merge logic, and the associated incidents keep their own owner, status, and lifecycle until an actual merge occurs.
Why the other options are wrong:
- B. It does not reassign alerts; associated incidents retain their own ownership.
- C. It does not alter correlation rules or how future alerts are grouped.
- D. The view is contextual only; it does not perform a merge.
Memory hook: 'All associated incidents' = look wider, change nothing (no merge, no reassignment).
Microsoft Learn: https://learn.microsoft.com/defender-xdr/alerts-incidents-correlation