Sample questions

SC-200 practice questions, with full explanations

75 sample SC-200 (Microsoft Security Operations Analyst) questions, each with the correct answer, a breakdown of why every other option is wrong, a memory hook, and the Microsoft Learn reference. Work the questions by topic; each topic names the field guide behind it.

Exam status

Checked against Microsoft Learn on September 30, 2026.

Microsoft's SC-200 certification page carries this notice: "The English language version of this certification will be updated on October 21, 2026." That date has passed since this was checked. Microsoft's page has the current state. SC-200 on Microsoft Learn

The SC-200 study guide already lists the skills measured as of October 21, 2026. Its change log marks one objective group, Ingest data into the Microsoft Sentinel SIEM and platform, as a minor change. That date has passed since this was checked. Microsoft's page has the current state. SC-200 study guide

The status board for every exam

The books

The SC-200 bookshelf

The SC-200 exam set

Going deeper on one product: four field guides, one product each.

Each has a sample on its Amazon page.

Work the 75 questions, one topic at a time

Each topic opens to its questions with the full explanation, the memory hook and the Microsoft Learn page behind it.

Cover of Microsoft Defender XDR Field Guide
Topic 1 of 4

Microsoft Defender XDR (19 questions)

Go deeper in Microsoft Defender XDR Field Guide. Get it on Amazon · Companion page

Show the 19 questions and explanations

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 was misconfigured; email remediation should have run automatically. Full automation only auto-remediates device threats; email-content actions are pending by design, so nothing is misconfigured.
  • C. The analyst lacks the Manage security settings permission required to auto-run email actions. Manage security settings is unrelated to approving AIR email actions; approval is a SecOps task in the Action center or incident.
  • D. The mailbox is hosted on-premises, so the action cannot complete without approval. 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: 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. The Standard preset is automatically enabled for all recipients until you turn it off. Standard and Strict presets apply to no one until you explicitly enable them and assign users.
  • B. Safe Links protection is on for everyone, but Safe Attachments requires a custom policy. Both Safe Links and Safe Attachments are covered by Built-in protection; Safe Attachments does not require a custom policy for baseline coverage.
  • C. No recipients have Safe Attachments or Safe Links protection until you create a custom policy. 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: 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. Add the scanner binary's file hash to the indicator allow list 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 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 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: Investigate alerts

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. 24-hour lookback; filter for the last 24 hours. The every-3-hours frequency carries a fixed 12-hour lookback; 24 hours isn't the window for this frequency.
  • B. 3-hour lookback; filter for the last 3 hours. 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-hour lookback; filter for the last 48 hours. 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: Custom detection rules

You're reviewing the Secure score recommendations tab in Microsoft Defender for Cloud to decide which security control to prioritize. All listed controls are relevant to your environment. Which security control carries the highest maximum contribution to the classic secure score, and should therefore be prioritized first?

Correct answer: B. Enable MFA

In the classic secure score model, each security control has a fixed maximum point value reflecting its relative significance. Enable MFA is weighted at 10 points, the highest of all controls, because Defender for Cloud places a high value on multifactor authentication for protecting subscription users.

Why the other options are wrong:

  • A. Secure management ports Secure management ports is weighted 8 points - high, but below Enable MFA's 10.
  • C. Remediate vulnerabilities Remediate vulnerabilities is weighted 6 points.
  • D. Apply system updates Apply system updates is weighted 6 points.

Memory hook: MFA tops the chart at 10 - identity first.

Microsoft Learn: Secure score security controls

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 overrides the Strict preset, because Built-in protection is assigned to all recipients by default 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. The custom anti-spam policy wins if it is given priority 0, because custom policies always outrank presets 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. Strict and the custom policy are merged, applying the most protective setting from each on a per-setting basis 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: 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 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 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 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: 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 performs the remediation; no separate account is needed. The DSA only reads AD data; remediation is handled by the action account (LocalSystem by default, or a scoped gMSA), not the DSA.
  • B. Remediation requires upgrading the sensors to v3.x, which then uses a gMSA action account. v2.x sensors on domain controllers already support action accounts; v3.x actually drops gMSA action accounts and always uses LocalSystem.
  • C. Remediation always uses a regular user account you store in the portal; gMSAs are not supported for actions. 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: 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 Move to Deleted Items places messages in the ordinary Deleted Items folder, not Recoverable Items\Deletions.
  • B. Hard delete Hard delete purges the message; only admins can recover it via single-item recovery, not the user from Recoverable Items.
  • D. Quarantine email 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: 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. The asset displays both criticality levels simultaneously, and the SOC must manually resolve the conflict before the asset appears in initiatives. There is no dual-classification state or forced manual resolution. The platform resolves the conflict automatically by applying the highest applicable criticality level.
  • C. Custom classification rules always override predefined classification rules regardless of the criticality level each assigns. Rule origin (custom versus predefined) does not determine precedence. A predefined High rule outranks a custom Medium rule because High outranks Medium.
  • D. The most recently created rule always wins, so the custom Medium rule overrides the predefined High rule from the start. 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: 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 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 of each report 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 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: 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. Owner on the workspace's subscription 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 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 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: 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. A near-real-time (NRT) analytics rule in Microsoft Sentinel 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. A scheduled analytics rule in Microsoft Sentinel 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. A Microsoft security (incident creation) rule in Microsoft Sentinel 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: 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. The Azure portal experience was retired on July 1, 2025, and all remaining workspaces were force-migrated on that date. 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. The Azure portal experience remains supported indefinitely for workspaces that were created before 2025. 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. Support ends on a per-workspace basis, whenever the workspace's Log Analytics retention period next expires. 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: Sentinel: Overview

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 configured with a playbook 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. Automated investigation and response (AIR) completing a manual investigation 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. A custom detection rule configured to isolate devices upon firing 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: 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 automatically close and purge after 30 days of inactivity, so long-running campaigns cannot be tracked in a case. 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. A tenant is limited to 1,000 cases in total, so the SOC must recycle old case IDs. The tenant limit is 100,000 cases, not 1,000, and case IDs are never reused, so there is no ID recycling.
  • D. Incidents can be linked to a case only while the incident status is New, so resolved incidents drop off the case. 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: 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 reassigns all alerts from the related incidents to the current incident's owner. It does not reassign alerts; associated incidents retain their own ownership.
  • C. It changes the correlation rules so future alerts are grouped differently. It does not alter correlation rules or how future alerts are grouped.
  • D. It immediately merges all associated incidents into the current incident. 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: Alerts incidents correlation

A SOC lead worries that Security Copilot incident summaries in the Microsoft Defender portal will drain SCU capacity when several analysts open the same high-severity incident during one shift. According to Microsoft's documentation, what actually happens?

Correct answer: C. Copilot saves generated incident summaries for a week; if the incident hasn't changed significantly, the cached summary is automatically redisplayed at no cost.

Copilot saves generated incident summaries for a week. If the incident you open already has a summary in the cache and the incident didn't change significantly, the summary is automatically redisplayed at no cost, regardless of the generation setting. This caching behavior is what makes auto-generation financially tolerable when multiple analysts work the same incident. For further SCU control, the Copilot incident summary settings (System, then Settings, then Copilot in Defender) let you choose auto-generate always, auto-generate by minimum incident severity (with estimated incident volume and SCU consumption shown), or generate on demand only.

Why the other options are wrong:

  • A. Incident summaries are free; only guided responses and incident reports consume SCU capacity. Incident summaries are a Copilot capability and consume SCUs when generated like other embedded Copilot features. There is no exemption for summaries.
  • B. Closing the Copilot pane cancels the summary generation, so analysts can avoid SCU consumption by closing it immediately. Hiding or closing the Copilot pane doesn't affect SCU consumption; a summary that started generating continues in the background. Cost is controlled through the generation settings and caching, not by closing the panel.
  • D. Every analyst who opens the incident triggers a fresh summary generation, each consuming SCUs. Repeat opens of an unchanged incident within the one-week cache window redisplay the stored summary at no cost; they do not each trigger a billed regeneration.

Memory hook: Summary cache = one week. Unchanged incident reopened = free redisplay; closing the pane doesn't stop the meter.

Microsoft Learn: Security Copilot m365d incident summary

An analyst is investigating a potential insider threat. They need to determine which files a specific user downloaded from SharePoint Online over the past 30 days. Which Microsoft Purview capability should be used first?

Correct answer: B. Audit log search in Microsoft Purview to review the unified audit log for file download events

The unified audit log in Microsoft Purview records user and admin operations across Microsoft 365 services, including file downloads from SharePoint Online. Filter it to the user and the 'Downloaded file' activity type over the relevant window and you have the list of what was pulled. The trap is reaching for Content Search first: it locates content, but it never shows who downloaded what or when.

Why the other options are wrong:

  • A. Content Search in Microsoft Purview to search the user's mailbox Content Search in Microsoft Purview searches the content of mailboxes, SharePoint sites, OneDrive accounts, and Teams chats. It finds where content exists but does not show activity logs of who downloaded what and when.
  • C. Microsoft Graph activity logs to retrieve all authentication events for the user Microsoft Graph activity logs capture authentication and service-level events. They do not provide granular SharePoint file-level activity such as file downloads; that information is in the unified audit log.
  • D. Microsoft Defender for Cloud Apps session policies to block future downloads Session policies in Defender for Cloud Apps are preventive controls that block or limit actions in real time. They do not provide a retrospective view of what was downloaded in the past 30 days.

Memory hook: Audit log = who did what and when. Content Search = find the content. Session policies = block future actions.

Microsoft Learn: Investigate threats using audit in Microsoft 365 Defender Microsoft Purview standard

Cover of Microsoft Defender for Endpoint Field Guide
Topic 2 of 4

Microsoft Defender for Endpoint (19 questions)

Go deeper in Microsoft Defender for Endpoint Field Guide. Get it on Amazon · Companion page

Show the 19 questions and explanations

A device group is set to 'Semi - require approval for all folders'. While the SOC lead was on two weeks of leave, an automated investigation reached a Malicious verdict and generated a file quarantine action. On return, the lead finds the action no longer appears on the Action center Pending tab, no analyst approved or rejected it, and the malicious file is still present on the device. What happened?

Correct answer: C. The pending action timed out after seven days, and a timed-out action is treated the same as a rejected action, so the remediation never ran

Per the automation levels documentation, with semi-automation levels pending remediation actions time out after seven days. When an action times out, the behavior is the same as if the action was rejected: the remediation is not performed, the threat artifact stays on the device, and no one is notified unless alerting on this is built separately. This is the operational risk of semi-automation levels for teams without continuous Action center coverage, and it is why the pending item disappeared without the file being quarantined.

Why the other options are wrong:

  • A. Microsoft Defender XDR escalated the device group to full automation after the timeout and remediated the file silently Automation levels are set per device group and do not escalate automatically. Defender XDR never promotes a group from semi to full automation on its own in response to a timeout.
  • B. The pending action was auto-approved after seven days and moved to the History tab, but the quarantine failed on the device There is no auto-approval mechanism. The seven-day timeout is equivalent to rejection, not approval, so the quarantine was never attempted rather than attempted and failed.
  • D. Pending actions remain in the queue indefinitely, so another analyst must have manually rejected the action Pending actions do not remain indefinitely; they expire after seven days. No manual rejection is needed for a pending action to disappear from the Pending tab.

Memory hook: Pending actions have a 7-day shelf life, and expiry equals rejection: the threat stays and nobody is told.

Microsoft Learn: Automation levels

During an incident, a SOC analyst creates a 'Block and remediate' file indicator for the SHA-256 hash of a malicious utility found on several servers. The utility sits in D:\Tools\, a folder a server administrator added to the Microsoft Defender Antivirus folder exclusion list years ago. The servers are in the indicator's scope, Defender Antivirus is in active mode, and more than a day has passed, yet the utility still executes. According to Microsoft's documented policy conflict handling for file indicators, why?

Correct answer: D. In the file indicator conflict handling order, a file allowed by a Microsoft Defender Antivirus exclusion is evaluated before block or warn file indicators, so the exclusion wins and the file is allowed

The 'Create indicators for files' documentation defines an explicit conflict handling order: after Windows Defender Application Control/AppLocker enforcement, the next check is 'if the file is allowed by the Microsoft Defender Antivirus exclusions, then Allow', which comes before 'if the file is blocked or warned by a block or warn file IoCs, then Block/Warn'. Microsoft's example table confirms this: antivirus exclusion Allow plus file indicator Block results in Allow. The pre-existing folder exclusion therefore neutralizes the block indicator, and the remediation is to remove or narrow the stale exclusion.

Why the other options are wrong:

  • A. SHA-256 indicators have lower precedence than SHA-1 and MD5 indicators, so an older weaker-hash policy is overriding the block The precedence rule is the opposite: when conflicting file IoC policies target the same file, the more secure (longer) hash wins, so SHA-256 beats SHA-1, which beats MD5. That rule also only arbitrates between conflicting indicators, which is not the issue here.
  • B. File indicator blocks require up to 14 days to fully propagate to previously onboarded servers File indicator blocks are typically enforced within 15 minutes, average around 30 minutes, and can take upwards of two hours, not 14 days. After more than a day, propagation delay is not a plausible cause.
  • C. 'Block and remediate' indicators only apply to copies of the file introduced after the indicator was created, not to files already present on disk Blocking a file via indicator prevents it from being read, written, or executed on devices in the organization, including files already present. There is no restriction limiting enforcement to newly introduced copies.

Memory hook: In the file conflict chain, an AV exclusion outranks your block indicator: exclusion Allow + IoC Block = Allow. Audit old exclusions before trusting a block.

Microsoft Learn: Indicator file

A device group in Microsoft Defender for Endpoint has its remediation (automation) level set to Semi - require approval for non-temp folders. An automated investigation returns a Malicious verdict for an executable found in the signed-in user's Downloads folder. What happens to the remediation?

Correct answer: D. The remediation runs automatically, because the Downloads folder is treated as a temporary folder.

At the Semi - require approval for non-temp folders level, remediation is applied automatically to malicious files/executables located in temporary folders, and Microsoft's temporary-folder list explicitly includes \users\*\downloads\*. Only files outside temporary folders wait for approval on the Pending tab.

Why the other options are wrong:

  • A. The action is placed on the Pending tab of the Action center and waits for analyst approval. Pending approval applies only to files that are NOT in temporary folders; Downloads is a temp folder, so no approval is required.
  • B. No remediation occurs until an analyst raises the group to Full - remediate threats automatically. Automatic remediation of temp-folder files already occurs at the non-temp level; you don't need Full automation to act on Downloads.
  • C. The action is blocked until the analyst is granted the Manage security settings permission. Manage security settings governs configuration tasks (like uploading to the live-response library), not approval of AIR verdicts.

Memory hook: 'Non-temp folders' = approve everything EXCEPT temp/Downloads; temp-folder hits auto-remediate.

Microsoft Learn: Automation levels

During an incident, a SOC analyst with the correct RBAC permissions successfully starts live response sessions on compromised Windows 11 laptops but cannot start a session on a compromised Windows Server 2022 machine, even though the server is onboarded and its sensor is healthy. 'Enable live response' is turned on in Advanced features. What is the most likely cause?

Correct answer: D. 'Enable live response for servers' is a separate toggle in Advanced features that has not been turned on

Live response has two separate enablement toggles under Settings, then Endpoints, then General, then Advanced features: 'Enable live response' and 'Enable live response for servers.' The base toggle does not cover server operating systems - the server toggle must be enabled as well, and it is an easy one to miss because workstation sessions work fine without it. Only admins and users with 'Manage Portal Settings' permissions can enable these toggles. With both toggles on and appropriate RBAC, sessions work on Windows Server 2019, Windows Server 2022 and later, and Server 2012 R2/2016 with the unified agent.

Why the other options are wrong:

  • A. The 'Allow unsigned script execution in live response' setting must be enabled before servers accept sessions Unsigned script execution is an optional third toggle that only governs whether unsigned PowerShell scripts can run inside an established session. It has no effect on whether a session can be initiated.
  • B. The analyst's role includes only basic live response commands, which do not work on servers Basic versus advanced live response permissions determine which commands the analyst can run once connected (for example, run, putfile, and remediate require advanced). They do not control whether sessions can be started on servers.
  • C. Live response is not supported on Windows Server operating systems Live response is fully supported on Windows Server 2019, Windows Server 2022 and later, and on Windows Server 2012 R2 and 2016 when they are onboarded with the modern unified agent. It also supports macOS and Linux.

Memory hook: Live response has two on-switches: one for clients, one for servers. Workstations connecting but servers refusing = the server toggle is off.

Microsoft Learn: Live response

You're enabling Defender for Servers on Amazon EC2 instances through the native AWS connector. Beyond turning on the plan, what must be present on the EC2 instances for full protection?

Correct answer: B. Azure Arc for servers (the Arc agent) plus the AWS Systems Manager (SSM) Agent

Defender for Servers on AWS requires the EC2 instances to be connected via Azure Arc. Arc autoprovisioning depends on the AWS SSM Agent (with the AmazonSSMManagedInstanceCore policy) being present; if the SSM Agent is missing, Arc autoprovisioning can't proceed.

Why the other options are wrong:

  • A. Only the Microsoft Monitoring Agent / Log Analytics agent The Log Analytics agent retired in August 2024; capabilities moved to Defender for Endpoint and agentless scanning.
  • C. A site-to-site VPN tunnel from the AWS VPC to the Azure virtual network No VPN is needed; the connector uses federated authentication plus Arc.
  • D. The instances must first be migrated into Azure as Azure VMs EC2 instances stay in AWS; Arc extends Azure management without migration.

Memory hook: AWS servers = Arc + SSM Agent (no migration, no VPN).

Microsoft Learn: Quickstart onboard AWS

You create a Defender for Endpoint web content filtering policy that blocks only the "Gambling" category. A user reports they can still reach a news site that was never in any blocked category. What is the expected behavior for categories you did not block, and how can you still allow one specific site that falls inside a blocked category?

Correct answer: B. Unblocked categories are automatically audited (access allowed and logged); to allow one site inside a blocked category, create a custom Allow indicator, which supersedes the web content filtering policy.

For any category that is not blocked, URLs are automatically audited: users can access them and access statistics are collected. To permit a single site within a blocked category, a custom Allow indicator (URL/domain) takes precedence over the web content filtering policy.

Why the other options are wrong:

  • A. Unblocked categories are ignored with no logging; allow a site by disabling network protection. Non-blocked categories are audited (logged), not silently ignored, and disabling network protection is not how you allow a single site.
  • C. Unblocked categories are also blocked by default; add the site to an allowed category. Non-blocked categories are not blocked by default; they are audited/allowed, and there is no "add to an allowed category" mechanism.
  • D. Unblocked categories are blocked until explicitly audited; allow a site by adding it to the SmartScreen bypass list. Web content filtering does not block everything that is not audited, and the override mechanism is an Allow indicator, not a SmartScreen bypass list.

Memory hook: Not blocked = audited; one-site exception = Allow indicator (beats web content filtering).

Microsoft Learn: Web content filtering

A desktop technician links a Group Policy Object that turns off Microsoft Defender Antivirus real-time protection on a lab device onboarded to Microsoft Defender for Endpoint. The GPO applies successfully with no errors, but real-time protection remains enabled after multiple policy refreshes. What is the most likely reason?

Correct answer: D. Tamper protection is enabled, so Group Policy changes to tamper-protected settings such as real-time protection are ignored

Real-time protection is one of the tamper-protected settings (along with behavior monitoring, cloud protection, security intelligence updates, IOAV protection, and automatic remediation actions). Microsoft Learn is explicit: when tamper protection is on and you use Group Policy to change Microsoft Defender Antivirus settings, changes to tamper-protected settings are ignored - the change appears to apply but is silently blocked, with no error. If a legitimate change is needed, the documented approach is troubleshooting mode, which temporarily suspends tamper protection on the device; when it ends, tamper-protected settings revert to their configured state. Tamper protection itself cannot be turned off via Group Policy.

Why the other options are wrong:

  • A. The device's sensor is in the Misconfigured (impaired communications) health state Sensor health states describe how well the device reports telemetry to the Defender for Endpoint cloud service. An impaired-communications state would not cause locally applied Group Policy antivirus settings to be ignored.
  • B. The GPO must also stop the WinDefend service before the setting can take effect Microsoft explicitly warns against disabling, stopping, or modifying services like WinDefend or MsMpEng - doing so causes instability. Policy changes never require stopping the antivirus service, and tamper protection would still protect the setting.
  • C. Real-time protection can only be disabled from the Intune admin center on onboarded devices There is no Intune-only restriction on managing real-time protection. Multiple channels can manage antivirus settings; the block here comes from tamper protection ignoring changes to protected settings, regardless of which admin made them via Group Policy.

Memory hook: Tamper protection eats GPO changes silently - no error, no effect. Need a legitimate change? Use troubleshooting mode, and expect a revert when it ends.

Microsoft Learn: Prevent changes to security settings with tamper protection

During a live response session on a compromised Windows device, an analyst who holds the advanced live response commands permission uploads a custom, unsigned PowerShell remediation script to the library and runs it with the run command. The script's syntax is valid, but it fails to execute. What must be enabled?

Correct answer: D. The live response unsigned script execution setting on the Advanced features page

Live response can run PowerShell and Bash scripts from the tenant library, but if a PowerShell script is unsigned you must first enable the unsigned script execution setting on the Advanced features page. Without it, an unsigned library script will not run even for an analyst who holds the advanced live response command permission and has already uploaded the file. Microsoft warns that allowing unsigned scripts increases exposure to threats, so it is an opt-in setting.

Why the other options are wrong:

  • A. Tamper protection troubleshooting mode on the target device Troubleshooting mode temporarily suspends tamper protection to allow local security-setting changes. It is unrelated to running unsigned scripts in a live response session.
  • B. The 'Manage security settings' permission on the analyst's RBAC role 'Manage security settings' is required to upload a file to the library from within the session console (without it the upload button is greyed out), but it does not govern whether an already-uploaded unsigned script is permitted to run. The analyst already got the file into the library.
  • C. EDR in block mode for the device's device group EDR in block mode remediates post-breach EDR detections on passive-mode devices. It has no bearing on whether a live response script is allowed to execute.

Memory hook: Unsigned PowerShell in live response won't run until you flip 'unsigned script execution' in Advanced features. Uploading takes 'Manage security settings'; running unsigned takes the toggle.

Microsoft Learn: Live response

A company onboards its Windows Server 2022 fleet, which runs a non-Microsoft antivirus product that must remain primary, to Microsoft Defender for Endpoint. Soon after onboarding, server admins report severe performance degradation, and both antivirus engines are actively scanning. The Windows 11 workstations onboarded the same week with the same third-party AV show no conflict. What did the deployment team miss on the servers?

Correct answer: B. They should have set the ForceDefenderPassiveMode registry value (REG_DWORD = 1) under HKLM\SOFTWARE\Policies\Microsoft\Windows Advanced Threat Protection before onboarding, because Windows Server does not enter passive mode automatically

On Windows 10 and 11, Microsoft Defender Antivirus automatically enters passive mode when a non-Microsoft antivirus registers with Windows Security Center - which is why the workstations were fine. On Windows Server (2012 R2 and later, including Server 2022), that automatic switch does not happen: you must set ForceDefenderPassiveMode (REG_DWORD, value 1) under HKLM\SOFTWARE\Policies\Microsoft\Windows Advanced Threat Protection, and Learn specifically says to set it before onboarding the device. Without it, both products attempt active protection simultaneously, causing exactly this performance conflict. A further trap: beginning with platform 4.18.2208.0, on an onboarded server with tamper protection enabled, tamper protection allows a switch to active mode but blocks the switch back to passive - so setting the key after the fact may not take effect.

Why the other options are wrong:

  • A. They should have enabled EDR in block mode, which forces Microsoft Defender Antivirus into passive mode on servers EDR in block mode does not set the antivirus mode; it requires Defender Antivirus to already be in passive or active mode and adds a remediation path for EDR detections. It is a complement to passive mode, not the mechanism that creates it.
  • C. They should have uninstalled Microsoft Defender Antivirus from the servers before onboarding them Manually disabling or uninstalling Microsoft Defender Antivirus is the guidance for servers that are NOT onboarded to Defender for Endpoint. On onboarded servers, keeping Defender Antivirus in passive mode is beneficial - it preserves security intelligence updates and enables EDR in block mode.
  • D. They should have set the cloud block level to High Plus so Defender Antivirus defers to the registered primary antivirus Cloud block level (High, High Plus, Zero Tolerance) tunes how aggressively cloud-delivered protection blocks unknown files. It plays no role in active/passive arbitration between antivirus products.

Memory hook: Clients go passive on their own; servers need the ForceDefenderPassiveMode key set BEFORE onboarding - or two AVs fight it out in production.

Microsoft Learn: Microsoft Defender Antivirus compatibility

An administrator creates a web content filtering policy in the Microsoft Defender portal that blocks the 'Gambling' category and scopes it to a device group. What is the behavior for websites in categories the policy does not block?

Correct answer: D. Access is audited: users reach the sites without disruption, and access statistics are collected and shown in the web protection reports

Web content filtering follows a block-or-audit model: for any category that is not blocked in a policy, the URLs are automatically audited. Users can access those sites without disruption while access statistics accumulate, and the data appears under Reports, then Web protection in the Defender portal. Microsoft even documents deploying a policy with no categories selected as a deliberate audit-only pattern to understand user behavior before making blocking decisions. Note also that policy changes can take up to two hours to enforce.

Why the other options are wrong:

  • A. Nothing is recorded for unblocked categories, so no usage data is available until a category is set to block Auditing is precisely what unblocked categories get: access data is collected and reported across 30-day, 3-month, and 6-month ranges, which is what makes audit-first WCF rollouts possible.
  • B. Users see a warn page for uncategorized traffic that they can bypass for 24 hours The 24-hour user bypass behavior belongs to Warn-mode indicators and Warn-mode ASR rules, not to web content filtering auditing. Audited categories load normally with no interstitial page.
  • C. Access is blocked by default: any category not explicitly configured must be added to an allow list Web content filtering is not default-deny. Only the categories explicitly selected in a policy are blocked; everything else is audited, and there is no allow list to maintain.

Memory hook: WCF categories have exactly two states: blocked or audited. Not blocked never means invisible.

Microsoft Learn: Web content filtering

A security administrator enables the ASR rule 'Block credential stealing from the Windows local security authority subsystem' in Block mode through an Intune endpoint security policy. A legacy single sign-on agent used by the finance team is repeatedly blocked when it reads LSASS memory. The administrator adds the agent's folder to the Microsoft Defender Antivirus exclusion list with Set-MpPreference -ExclusionPath, but the blocks continue. What should the administrator do to exclude only this application without weakening other ASR rules?

Correct answer: C. Add a per-ASR-rule exclusion for the agent's full path to this specific rule in the Intune endpoint security ASR policy, because this rule does not honor Microsoft Defender Antivirus file and folder exclusions

The exclusion support matrix in the ASR rules overview shows that 'Block credential stealing from the Windows local security authority subsystem' does not honor Microsoft Defender Antivirus file/folder exclusions; it honors only global ASR exclusions and per-ASR-rule exclusions. A per-rule exclusion is the narrowest option because it applies to this rule alone, while a global ASR exclusion would weaken every rule. Per-ASR-rule exclusions are supported only in Group Policy and Intune endpoint security policies, so adding the agent's path to this rule in the existing Intune policy is the correct fix.

Why the other options are wrong:

  • A. Create an 'allow' file indicator for the agent's SHA-256 hash so the rule permits the process The exclusion matrix shows this rule also does not honor file indicators (IoCs for files) or certificate indicators. An allow file indicator would have no effect on this rule's enforcement.
  • B. Deploy the per-rule exclusion through Microsoft Configuration Manager instead of Intune Microsoft Configuration Manager does not support per-ASR-rule exclusions. Per-rule exclusions can only be configured through Group Policy or Intune endpoint security policies; ConfigMgr supports only global ASR exclusions.
  • D. Switch the rule from Block to Warn mode so finance users can bypass the block for 24 hours The LSASS credential-stealing rule is one of the rules that does not support Warn mode at all; its only active modes are Audit and Block, so there is no user-bypass option.

Memory hook: The LSASS rule ignores AV exclusions and file indicators; only ASR exclusions count (per-rule beats global), and Warn mode isn't on its menu.

Microsoft Learn: Attack surface reduction rules overview

A SOC analyst needs to collect a forensic package from a compromised Windows device in Microsoft Defender for Endpoint without disrupting the user's session. Which response action accomplishes this?

Correct answer: C. Select 'Collect investigation package' from the device response actions

The 'Collect investigation package' action gathers forensic artifacts from the device, including logs, running processes, network connections, and other investigation data, and makes them available for download. This action does not disconnect the user's session or block network access, so it is the least disruptive option for forensic collection.

Why the other options are wrong:

  • A. Initiate a live response session and run the 'isolate' command On a Windows device you would use the 'Isolate device' response action, which disconnects the device from the network while retaining connectivity to the Defender for Endpoint service so analysts can keep investigating (selective isolation can even allow Outlook and Teams). The live response 'isolate' command exists only for macOS. Either way, isolation blocks the user's normal network access, so it is not the right choice when the goal is evidence collection without disruption.
  • B. Select 'Restrict app execution' from the device response actions 'Restrict app execution' prevents applications not signed by Microsoft from running. This can disrupt the user's work and does not collect forensic artifacts.
  • D. Run an antivirus scan from the device response actions Running an antivirus scan initiates a Defender Antivirus scan to identify and remediate malware. It does not collect a forensic package and could modify device state before evidence is preserved.

Memory hook: Investigation package = forensic snapshot you can download. Isolate = cut the network. Restrict = block unsigned apps.

Microsoft Learn: Respond machine alerts

A vulnerability analyst needs Microsoft Defender for Endpoint to discover and run vulnerability assessments against the organization's Cisco switches and Palo Alto firewalls. These network appliances cannot run the Defender sensor. What is the correct approach?

Correct answer: D. Configure an authenticated network scan that designates an onboarded Windows device as a scanner and queries the appliances over SNMP

Network infrastructure devices such as switches, routers, firewalls, WLAN controllers, and VPN gateways cannot run the sensor, so Defender for Endpoint uses authenticated network scans. You designate one or more onboarded Windows devices as scanners, and they periodically query the target appliances using SNMP read-only (SNMPv2 or SNMPv3). Once discovered and classified, the network devices flow into Defender Vulnerability Management so you receive security recommendations and vulnerability findings for them. You configure this under Settings, then Device discovery, then Authenticated scans, and it requires the Manage security settings in Defender permission.

Why the other options are wrong:

  • A. Onboard the appliances using the Linux eBPF sensor package The Linux sensor onboards Linux server operating systems, not vendor network appliances such as Cisco IOS switches or PAN-OS firewalls. Those devices do not support the Defender agent at all.
  • B. Add the appliances to a Microsoft Sentinel watchlist of network devices so they are assessed automatically A Sentinel watchlist is static reference data. It neither discovers devices nor performs any vulnerability assessment against them.
  • C. Enable Standard discovery mode so onboarded devices actively probe and fully classify the switches and firewalls Standard discovery can detect that a network device exists using unauthenticated protocol probing, but it does not authenticate to the appliance to enumerate its configuration and vulnerabilities. Deep classification and vulnerability assessment of switches and firewalls require an authenticated SNMP scan.

Memory hook: Switches/routers/firewalls can't run the sensor, so use an authenticated network scan: an onboarded Windows scanner queries them over SNMP read-only, and the results flow into Defender Vulnerability Management.

Microsoft Learn: Network devices

After an onboarding wave, an administrator filters the Defender portal device inventory by sensor health and finds a Windows device marked 'Misconfigured' with the sub-state 'No sensor data' rather than 'Impaired communications.' What does this distinction tell the administrator, and what should be checked beyond basic connectivity?

Correct answer: C. The device is communicating with the service but reporting only partial sensor data; beyond proxy and service URL checks, verify the Windows diagnostic data service is running and, if a third-party AV is present, that the Defender Antivirus ELAM driver is enabled

The 'Fix unhealthy sensors' article splits Misconfigured into two sub-states with different remediation paths. 'Impaired communications' means limited communication between the device and the service, and the checks are connectivity focused: WinHTTP proxy configuration and access to the Defender for Endpoint service URLs. 'No sensor data' means the device is talking to the service but reporting only partial sensor data, which points past connectivity. On top of the proxy and URL checks, confirm the Windows diagnostic data service is set to start automatically and is running, verify the Early Launch Antimalware (ELAM) driver is enabled when a third-party antimalware client is in use, and check that Defender Antivirus is not disabled by policy.

Why the other options are wrong:

  • A. The two sub-states are interchangeable labels for the same condition, so the same WinHTTP proxy remediation applies to both Microsoft documents distinct causes and suggested actions for each sub-state. Treating them as the same problem misses the diagnostic-data-service and ELAM checks that are specific to 'No sensor data.'
  • B. The onboarding package never applied, so the device is not onboarded at all and only appears in the inventory through device discovery A device that shows a Misconfigured sensor health state is onboarded and has established communication with the service. Devices that are discovered but never onboarded do not carry a sensor health sub-state like 'No sensor data.'
  • D. The device has not reported to the service for more than seven days and must be offboarded and re-onboarded with a fresh package Not reporting for more than seven days describes the 'Inactive' health state, not the Misconfigured sub-states. A 'No sensor data' device is still in contact with the service, and re-onboarding is not the documented first response.

Memory hook: Impaired communications = the line is bad (check proxy/URLs); No sensor data = talking but not telling (check diagnostic data service and ELAM).

Microsoft Learn: Fix unhealthy sensors

A security engineer is rolling out attack surface reduction rules through an Intune endpoint security policy and plans to use Warn mode across the board, so users can temporarily bypass blocks with the Unblock option during the transition period. For which rule will this plan fail, because the rule does not support Warn mode?

Correct answer: C. Block credential stealing from the Windows local security authority subsystem (lsass.exe)

Per the ASR rules overview on Microsoft Learn, two rules do not support Warn mode: 'Block credential stealing from the Windows local security authority subsystem' and 'Block Office applications from injecting code into other processes.' For every other rule, Warn (code 6) behaves like Block but presents a notification with an Unblock option that grants a 24-hour bypass, generating event ID 1129 when a user overrides. Warn mode requires Windows 10 version 1809 or later, antivirus platform 4.18.2008.9+ and engine 1.1.17400.5+, and is not available at all in Microsoft Configuration Manager. The LSASS rule is also one of the three standard protection rules recommended for Block mode from day one.

Why the other options are wrong:

  • A. Block execution of potentially obfuscated scripts 'Block execution of potentially obfuscated scripts' supports Warn mode. Its false-positive risk with legitimate packed or minified scripts is why Warn is a useful transition state for it.
  • B. Block all Office applications from creating child processes 'Block all Office applications from creating child processes' supports Warn mode. It is commonly deployed in Warn during transition periods precisely because line-of-business Office add-ins can trigger it.
  • D. Block executable content from email client and webmail 'Block executable content from email client and webmail' supports Audit, Block, and Warn modes. It is one of the 'other' ASR rules that should be tested in Audit before promotion, but Warn is a valid mode for it.

Memory hook: No Warn for the crown jewels: the LSASS credential-stealing rule and the Office code-injection rule go straight from Audit to Block - there is no click-through middle option.

Microsoft Learn: Attack surface reduction rules overview

While containing an incident, a SOC analyst opens the profile page of a confirmed malicious .exe file and wants to add a block indicator so the file cannot run anywhere in the organization. The capability to block the file is unavailable in the tenant. Which configuration must be in place for file block indicators to work?

Correct answer: C. The 'Allow or block file' advanced feature turned on, which requires Microsoft Defender Antivirus as the active antimalware solution with cloud-delivered protection enabled

Blocking files through indicators is gated by the 'Allow or block file' toggle under Settings, then Endpoints, then General, then Advanced features. Microsoft Learn states blocking is only available if the organization uses Microsoft Defender Antivirus as the active antimalware solution and cloud-delivered protection is enabled (antimalware client 4.18.1901.x or later). Once on, the Add Indicator capability on a file's profile page can block the portable executable from being read, written, or executed on devices across the organization. A related trap: EDR in block mode does not respect Defender for Endpoint indicators, so allow indicators do not exempt files from EDR in block mode's remediation.

Why the other options are wrong:

  • A. EDR in block mode enabled, with Microsoft Defender Antivirus running in passive mode EDR in block mode is a remediation feature for devices running a third-party primary AV; it is not a prerequisite for indicators. File indicators actually require the opposite condition - Defender Antivirus in active mode - and EDR in block mode explicitly does not honor MDE indicators.
  • B. Network protection enabled in block mode on all devices Network protection in block mode is a prerequisite for IP address, URL, and domain indicators, which are enforced at the network layer. File hash indicators are enforced by Defender Antivirus and do not depend on network protection.
  • D. The 'Custom network indicators' advanced feature turned on 'Custom network indicators' is the advanced feature that gates IP and URL/domain indicators. File indicators are gated by the separate 'Allow or block file' feature.

Memory hook: File indicators = 'Allow or block file' ON + Defender AV in active mode + cloud protection. Network indicators ride a different toggle (custom network indicators + network protection).

Microsoft Learn: Advanced features

An analyst uploads a PowerShell script to the live response library and tries to run it during a session, but the run fails because the script is unsigned. Live response is already enabled for the tenant. What must be done so the script can run?

Correct answer: B. Turn on "Live response unsigned script execution" on the Defender for Endpoint Advanced features settings page.

Signature verification applies to PowerShell scripts in live response. To run unsigned PowerShell, you must enable "Live response unsigned script execution" on the Advanced features page. This is separate from enabling live response itself.

Why the other options are wrong:

  • A. Grant the analyst the "Manage portal settings" permission. "Manage portal settings" governs turning live response on, not whether an unsigned script is permitted to run.
  • C. Copy the script to the device manually and run it with the run command, bypassing the library. The run command executes scripts from the library only; you cannot bypass the library, and doing so would not address the unsigned-script block.
  • D. Nothing; re-upload the script and live response will sign it automatically. Live response does not sign scripts for you; unsigned PowerShell stays blocked until you enable the specific advanced feature.

Memory hook: Unsigned PowerShell in live response? Flip the Advanced-features switch first.

Microsoft Learn: Live response

Custom file-hash block indicators created in Microsoft Defender for Endpoint are not being enforced on execution. Microsoft Defender Antivirus is running in passive mode (a third-party AV is primary), cloud-delivered protection is enabled, and the Allow or block file advanced feature is on. Why aren't the files being blocked?

Correct answer: C. File-execution blocking requires Microsoft Defender Antivirus to be in active mode; passive mode and EDR in block mode cannot detect and block based on file execution.

Blocking on file execution requires Microsoft Defender Antivirus in active mode. By design, passive mode and EDR in block mode can't detect and block based on file execution, so even with cloud-delivered protection and Allow or block file enabled, indicators are not enforced while Defender Antivirus is passive.

Why the other options are wrong:

  • A. The analyst needs the Manage security settings permission for the indicators to apply. Manage security settings is not the blocker here; the requirement is Defender Antivirus in active mode.
  • B. File-hash indicators support only script files, not portable executables. File-hash indicators support portable executables (.exe and .dll); the problem is the antivirus mode, not the file type.
  • D. Cloud-delivered protection must be turned off for indicators to take effect. Cloud-delivered protection is a required prerequisite for the block/allow feature, not something to disable.

Memory hook: Block-file indicators need Defender AV in ACTIVE mode; passive and EDR block mode won't stop execution.

Microsoft Learn: Advanced features

A line-of-business app on your finance team's Windows 11 devices is being blocked by the attack surface reduction (ASR) rule "Block all Office applications from creating child processes." Until the vendor ships a fix, the security team wants users to be able to keep working when they acknowledge a prompt, while each trigger is still recorded for review. Which ASR rule mode meets this requirement?

Correct answer: A. Warn mode

Warn mode enforces the rule but presents a bypassable prompt so the user can click through (each override is logged as event 1129), which keeps the app usable while still capturing every trigger. Warn is supported on Windows 10 1809+ and Windows 11.

Why the other options are wrong:

  • B. Audit mode Audit mode only records events (event 1122) and never blocks or prompts the user, so users get no click-through warning and the action is never enforced.
  • C. Not configured Not configured returns the rule to the Windows default (off): the app runs but nothing about the ASR rule is enforced or captured.
  • D. Block mode with a file and folder exclusion A file/folder exclusion silently removes enforcement for that path and generates no block or warn events for it, so the team loses the per-trigger telemetry they want.

Memory hook: Warn = a block you can click through; Audit = watch only, no prompt.

Microsoft Learn: Attack surface reduction rules overview

Cover of Microsoft Sentinel Field Guide
Topic 3 of 4

Microsoft Sentinel (19 questions)

Go deeper in Microsoft Sentinel Field Guide. Get it on Amazon · Companion page

Show the 19 questions and explanations

Your organization onboarded Microsoft Sentinel to the Defender portal and integrated Microsoft Defender XDR incidents, and you are also ingesting Defender for Cloud alerts. You now see duplicate incidents for the same Defender for Cloud alerts. Which set of actions eliminates the duplicates?

Correct answer: B. Configure the Tenant-based Defender for Cloud connector, disconnect the Subscription-based (Legacy) connector, and turn off any analytics/incident-creation rules that create incidents from Defender for Cloud alerts

When Defender for Cloud incidents already flow in through the Defender XDR incident connector, you should use the Tenant-based Defender for Cloud connector to sync alerts, disconnect the Subscription-based (Legacy) connector, and disable any Sentinel analytics/incident-creation rules built on Defender for Cloud alerts. Together these steps prevent the same alert from generating duplicate incidents.

Why the other options are wrong:

  • A. Disconnect the Defender XDR connector and keep only the Subscription-based (Legacy) Defender for Cloud connector Disconnecting the XDR connector abandons XDR incident integration and isn't the recommended fix.
  • C. Disable bi-directional sync on the Subscription-based (Legacy) connector Bi-directional sync isn't the source of duplicate incidents; the legacy connector and incident rules are.
  • D. Enable both the Tenant-based and the Subscription-based (Legacy) connectors so the alerts are correlated automatically Running both connectors is what causes the duplication.

Memory hook: XDR path: go Tenant-based, drop the Legacy connector and its incident rules.

Microsoft Learn: Concept integration 365

You map MITRE ATT&CK tactics and techniques on a custom hunting query, then create bookmarks from that query's results. By default, what MITRE mapping do the new bookmarks have?

Correct answer: B. They inherit the same tactic and technique mappings as the hunting query that produced them, and you can still edit them.

Bookmarks default to using the same entity and MITRE ATT&CK technique mappings as the hunting query that produced the bookmarked results. You can still add or change mappings manually on each bookmark.

Why the other options are wrong:

  • A. They are mapped only to the tactic, never to the technique. They inherit techniques (and sub-techniques) too, not just the tactic.
  • C. They automatically map to every technique that exists under the query's tactic. They inherit the query's specific mapping, not every technique under the tactic.
  • D. They start with no MITRE mapping and must be mapped manually every time. They don't start empty; they inherit the query's mapping (manual mapping is also possible).

Memory hook: Bookmarks inherit the query's MITRE tags by default.

Microsoft Learn: Sentinel: Bookmarks

You need to ingest logs from a third-party SaaS security product that exposes only a REST API. Requirements: fully cloud-based with no VM or agent to install and maintain, built-in connector health monitoring, and the ability to package and deploy the connector as a Content hub solution. Which connector approach best fits?

Correct answer: B. Build the connector with the Codeless Connector Framework (CCF).

The Codeless Connector Framework (CCF) lets you define a connector in a configuration file that pulls from REST APIs, with no service or agent to install or maintain. CCF connectors are fully SaaS, include health monitoring, are fully supported by Microsoft, and can be deployed to your workspace or published as a Content hub solution.

Why the other options are wrong:

  • A. Deploy a Linux log forwarder running the Azure Monitor Agent (AMA) with a Data Collection Rule. The AMA approach requires deploying and maintaining a log-forwarder VM/agent, which violates the 'no agent to maintain' requirement.
  • C. Use the CEF via AMA connector to receive the logs. CEF via AMA is for syslog/CEF appliances routed through a log-forwarder machine running the agent, not for pulling from a SaaS REST API without an agent.
  • D. Write a custom application that pushes events to the Logs Ingestion API using a DCR endpoint. The Logs Ingestion API requires you to build and run custom code that pushes data; it isn't a packaged, health-monitored Content hub connector and adds operational overhead.

Memory hook: Agentless pull from a SaaS REST API, packaged in Content hub = Codeless Connector Framework (CCF).

Microsoft Learn: Create custom connector

A SOC analyst wants to quickly triage the single most unusual events for a user over the last day, using UEBA's near-real-time, event-level score that ranges from 0 (benign) to 10 (highly anomalous). Which table and field should the KQL query target?

Correct answer: B. BehaviorAnalytics, filtering on InvestigationPriority

The InvestigationPriority field in the BehaviorAnalytics table is UEBA's near-real-time, event-level score (0-10) that quantifies how unusual a single event is, combining an entity anomaly score with a time-series score. It is designed for quick triage and drilling into single events.

Why the other options are wrong:

  • A. Anomalies, filtering on AnomalyScore Anomalies.AnomalyScore ranges 0-1 and reflects holistic, batch-processed behavior across multiple events, not single-event triage.
  • C. IdentityInfo, filtering on RiskLevel IdentityInfo holds entity profile data such as Entra ID risk level, not the per-event UEBA priority score.
  • D. UserPeerAnalytics, filtering on Rank UserPeerAnalytics ranks behavioral peers (via TF-IDF) for baselining; it carries no per-event anomaly score.

Memory hook: Priority 0-10 lives in BehaviorAnalytics; Anomaly 0-1 lives in Anomalies.

Microsoft Learn: Identify threats with entity behavior analytics

You create a Microsoft Sentinel summary rule to aggregate verbose logs on a schedule. Which statement about the destination table and scheduling is correct?

Correct answer: D. The destination is a custom table whose name ends in _CL and uses the Analytics plan; the aggregation window is set by binSize, with an optional binDelay for late-arriving data.

Summary rule results are stored in a custom table (name ending in _CL) that uses the Analytics data plan, so results are fully queryable. binSize defines the aggregation interval, and the optional binDelay (default roughly 3.5 minutes up to 10% of binSize, configurable up to 1440 minutes) waits for late-arriving data before running the bin.

Why the other options are wrong:

  • A. Summary rules run only once and can't be scheduled to repeat on an interval. Wrong - summary rules run on a recurring schedule defined by their frequency/binSize.
  • B. The destination table is automatically created on the Basic plan, and its results can't be queried with KQL. Wrong - summary results are stored in an Analytics-plan table and are fully queryable with KQL.
  • C. The destination must be an existing built-in table, and the aggregation window is set by a 'lookback' property. Wrong - the destination is a custom _CL table (new or existing), not a built-in table, and the window is set by binSize, not a 'lookback' property.

Memory hook: Summary rule writes to a _CL Analytics table; binSize sets the window, binDelay waits for stragglers.

Microsoft Learn: Summary rules

In the Entities tab of an incident details page in Microsoft Sentinel (Azure portal), an analyst notices that some entity names appear as clickable links. What is the difference between selecting an entity's name (the link) versus selecting the row the entity is in (but not the name)?

Correct answer: A. Selecting the name opens the full entity page and leaves the incident; selecting the row opens a side panel (Info/Timeline/Insights) without leaving the incident

If the entity name appears as a link, selecting it redirects you to the full Microsoft Sentinel entity page, outside the incident. Selecting the row (without clicking the name) displays the entity's details in a side panel with the Info, Timeline, and Insights cards, letting you stay in the incident context.

Why the other options are wrong:

  • B. Selecting the name filters the incident to that entity; selecting the row removes the entity from the incident Neither action filters the incident nor deletes the entity; the row selection simply opens a side panel.
  • C. There is no difference; both open the full entity page There is a clear difference: the name navigates away, the row stays in the incident.
  • D. Selecting the name adds the entity to threat intelligence; selecting the row runs a playbook Add to TI and Run playbook are separate actions launched from the three-dots menu, not from clicking the name or the row.

Memory hook: Click the name, you leave the incident; click the row, you stay.

Microsoft Learn: Investigate incidents

A threat hunter enables User and Entity Behavior Analytics (UEBA) in Microsoft Sentinel and expects entity profiles for on-premises Active Directory users to appear in the IdentityInfo table for enrichment. Cloud (Microsoft Entra ID) users populate correctly, but on-premises-only AD accounts never show up. What is the most likely cause?

Correct answer: A. On-premises AD user synchronization to UEBA requires Microsoft Defender for Identity with an MDI sensor deployed on the domain controllers; without it, UEBA is cloud-only

When you configure UEBA you choose which directory services to sync user entities from - Microsoft Entra ID and/or on-premises Active Directory. Syncing on-premises AD user entities into UEBA (the IdentityInfo table) requires Microsoft Defender for Identity, standalone or as part of Defender XDR, with the MDI sensor installed on your domain controllers. Without MDI, UEBA remains cloud-only and on-premises-only AD accounts won't populate IdentityInfo, regardless of other configuration.

Why the other options are wrong:

  • B. The BehaviorAnalytics table must be manually joined to IdentityInfo before on-premises users appear Joining BehaviorAnalytics to IdentityInfo is a query technique for enrichment; it does not cause on-premises users to be synced into IdentityInfo. Population depends on the MDI-backed directory sync.
  • C. UEBA only ever profiles cloud identities; on-premises AD accounts are never available to UEBA under any configuration UEBA can profile on-premises AD identities - it just needs the MDI sensor path to source them. The limitation is a missing prerequisite, not an inherent cloud-only design.
  • D. The IdentityInfo table was not enabled; on-premises users require a separate watchlist upload of AD accounts IdentityInfo is created and populated by enabling UEBA, not by a manual table toggle, and on-premises users are sourced through MDI sync, not through a hand-built watchlist of AD accounts.

Memory hook: No MDI sensor on the DCs = UEBA is cloud-only. On-prem AD identities reach IdentityInfo through Defender for Identity.

Microsoft Learn: Enable entity behavior analytics

A detection engineer wants to alert on a specific sign-in pattern within one minute of events arriving in Microsoft Sentinel. Which analytics rule type should be used?

Correct answer: D. Near-real-time (NRT) analytics rule

NRT analytics rules are designed to run once every minute and capture events ingested in the preceding minute, with only a two-minute delay to account for ingestion time. They provide the fastest possible detection response within Microsoft Sentinel, making them the right choice when near-instantaneous alerting is required.

Why the other options are wrong:

  • A. Anomaly analytics rule Anomaly rules use machine learning to detect deviations from baseline behavior; they are not designed for near-real-time alerting on specific rule-based patterns.
  • B. Scheduled analytics rule Scheduled rules run at configurable intervals (minimum five minutes by default) and include an additional built-in delay for ingestion lag, making them unsuitable for sub-minute detection requirements.
  • C. Microsoft security rule Microsoft security rules convert alerts from other Microsoft security products (such as Defender for Office 365) into Sentinel incidents. They do not execute custom KQL queries.

Memory hook: NRT = Nearly Right This-minute. One-minute cadence, two-minute lag.

Microsoft Learn: Near real time rules

A security engineer needs to allow a SOC analyst to manage incidents in Microsoft Sentinel but must prevent that analyst from creating or editing analytics rules. Which built-in Microsoft Sentinel role should be assigned?

Correct answer: A. Microsoft Sentinel Responder

Microsoft Sentinel Responder grants all Reader permissions plus the ability to manage incidents (triage, assign, close). It does not permit creating or editing analytics rules, workbooks, or other configuration resources. Microsoft Sentinel Contributor adds those configuration rights, which would exceed the required scope.

Why the other options are wrong:

  • B. Microsoft Sentinel Contributor Contributor includes all Responder rights and additionally allows creating and editing analytics rules, workbooks, and other configuration resources, which exceeds the stated requirement.
  • C. Microsoft Sentinel Reader Reader can only view data and incidents. The analyst would not be able to update incident status, assign owners, or add comments.
  • D. Microsoft Sentinel Playbook Operator Playbook Operator can list and manually run playbooks but cannot manage incidents. It does not address the core requirement.

Memory hook: Responder = respond to incidents, nothing more. Reader reads, Contributor configures, Playbook Operator pulls the trigger on playbooks.

Microsoft Learn: Sentinel: Roles

An analyst wants to run one of Microsoft Sentinel's Jupyter notebooks (which use the MSTICPy library) to perform custom machine-learning analysis and visualizations on Sentinel data during an investigation. Within Microsoft Sentinel, what compute platform do these notebooks run on, and what access is required?

Correct answer: A. They run on Azure Machine Learning compute; the analyst needs access to both the Sentinel workspace and an Azure Machine Learning workspace

In Microsoft Sentinel, notebooks run on the Azure Machine Learning platform. To run them you must have appropriate access to both the Microsoft Sentinel workspace and an Azure Machine Learning workspace. The notebooks rely on the MSTICPy Python library.

Why the other options are wrong:

  • B. They run directly on the Log Analytics workspace; only the Microsoft Sentinel Reader role is required Notebooks query Log Analytics but execute on Azure ML compute, and the Reader role alone is not sufficient to run them.
  • C. They run on an Azure Automation account using a Logic Apps runtime Azure Automation and the Logic Apps runtime are used for playbooks, not for running Sentinel notebooks.
  • D. They run in Azure Cloud Shell; only Contributor on the subscription is required Notebooks do not run in Cloud Shell; they require an Azure Machine Learning workspace, not just subscription Contributor.

Memory hook: Sentinel notebooks live on Azure ML - need Sentinel + ML workspace access.

Microsoft Learn: Sentinel: Notebooks

While hunting in a Microsoft Sentinel Jupyter notebook running on Azure Machine Learning, the notebook hangs and you restart the kernel to recover. What must you do afterward for the notebook to work correctly?

Correct answer: B. Rerun the initialization and authentication cells, because restarting the kernel clears all variables and state

Restarting the kernel deletes all in-memory variables and state. You must rerun the initialization and authentication cells (for example, the MSTICPy setup and sign-in) before continuing, otherwise later cells fail because their prerequisites are gone.

Why the other options are wrong:

  • A. Recreate the Azure Machine Learning workspace from scratch The AML workspace and compute are unaffected by a kernel restart; recreating them is unnecessary.
  • C. Nothing; variables and authentication tokens persist across a kernel restart State does not persist across a kernel restart; discarding in-memory state is the purpose of a restart.
  • D. Re-import the notebook template from the Microsoft Sentinel Notebooks blade The notebook file itself is intact after a kernel restart; only in-memory state is lost, so re-importing is not required.

Memory hook: Restart kernel = clean slate; rerun init + auth cells.

Microsoft Learn: Notebooks hunt

During a UEBA investigation you want to know which other users Microsoft Sentinel considers behavioral "peers" of a suspected compromised user, so you can judge whether an action is unusual relative to that peer group. Sentinel ranks the top peers using a TF-IDF weighting in which smaller groups carry higher weight. Which UEBA table holds this dynamically calculated peer ranking?

Correct answer: D. UserPeerAnalytics

UserPeerAnalytics contains dynamically calculated peer groups, ranking the top 20 peers based on security group membership, mailing lists, and other associations. It uses the TF-IDF algorithm to normalize weights, so smaller groups carry higher weight.

Why the other options are wrong:

  • A. BehaviorAnalytics BehaviorAnalytics stores enriched behavioral events with the InvestigationPriority score, not peer rankings.
  • B. UserAccessAnalytics UserAccessAnalytics is not a Microsoft Sentinel UEBA table; it is a distractor.
  • C. IdentityInfo IdentityInfo stores entity profile attributes (roles, blast radius, group membership), not the ranked peer list.

Memory hook: Peers? UserPeerAnalytics: top 20, ranked by TF-IDF.

Microsoft Learn: UEBA reference

An analyst wants an interactive dashboard visualizing sign-in trends in Microsoft Sentinel and starts from a workbook template that shipped with an installed Content hub solution. After selecting Save on the template, what has actually been created, and where does the data live?

Correct answer: C. An Azure resource (the workbook) saved in the workspace's resource group containing only the workbook's JSON definition - no data - that queries the underlying tables live each time it loads

Microsoft Sentinel workbooks are built on Azure Monitor Workbooks. Saving a template creates an Azure resource based on that template in the location you choose; only the workbook's JSON definition is saved there - no data is copied. The workbook runs its queries against the underlying Log Analytics tables each time it is opened or refreshed, so it always reflects current data. You then select View saved workbook and Edit to customize it.

Why the other options are wrong:

  • A. A scheduled export that writes the workbook's query results to Azure Storage every time the dashboard refreshes Workbooks query live at load and refresh time and do not export results to storage on refresh. Auto-refresh simply re-runs the queries against the source tables.
  • B. A new Log Analytics table containing a materialized copy of the sign-in data the workbook displays Saving a workbook does not create a data table or materialize any results; it stores only the visualization definition. The data stays in its source tables and is queried at render time.
  • D. A read-only snapshot image of the template that cannot be edited without reinstalling the solution The saved workbook is fully editable - that is the point of saving your own copy from a template. The original template also remains available and is separate from your editable copy.

Memory hook: Save a workbook = a JSON resource in the resource group, not a data copy. It re-queries the tables live every time it loads.

Microsoft Learn: Monitor your data

You have imported threat indicators into Microsoft Sentinel and want them to automatically generate alerts and incidents when they match events flowing in from your connected data sources (for example, matching a malicious IP against firewall logs). Which type of analytics rule is designed to correlate your imported indicators with ingested events?

Correct answer: D. A "TI map..." analytics rule

TI map analytics rules, which use the "TI map..." naming format, map your imported threat indicators against events from connected data sources to automatically generate alerts and incidents when a match occurs.

Why the other options are wrong:

  • A. The built-in Microsoft Threat Intelligence Analytics matching-analytics rule The Microsoft Threat Intelligence Analytics rule matches Microsoft's own indicators against CEF/Syslog/DNS data; matching your imported indicators across sources is the job of the TI map rules.
  • B. An ML Behavior Analytics anomaly rule ML Behavior Analytics rules detect anomalous SSH/RDP login behavior, not indicator-to-event matches.
  • C. A Fusion (Advanced Multistage Attack Detection) rule Fusion correlates multistage alerts and anomalies into high-fidelity incidents; it does not match your indicator lists against raw events.

Memory hook: Your indicators + your logs: use the 'TI map' rules.

Microsoft Learn: Use threat indicators in analytics rules

An analyst needs to create a Microsoft Sentinel analytics rule that detects a specific event pattern within one minute of its occurrence and generates an alert for every matching event up to 30 events. Which rule type should the analyst use, and what happens when more than 30 matching events occur in a single run?

Correct answer: A. Use a Near-Real-Time (NRT) analytics rule; when more than 30 matching events occur, single-event alerts are generated for the first 29 events, and a 30th alert summarizes all remaining events.

NRT (near-real-time) analytics rules are designed for up-to-the-minute detection and run their queries at one-minute intervals. When the event grouping option is set to generate an alert per event, NRT rules support up to 30 events. If more than 30 events match, single-event alerts are generated for the first 29 events, and a 30th summary alert covers all events in the result set. This is a specific NRT behavior not shared by scheduled rules.

Why the other options are wrong:

  • B. Use a Scheduled analytics rule with a 1-minute run interval; when more than 30 events match, Sentinel creates 30 individual alerts and drops the remainder. Scheduled analytics rules do not run at exactly 1-minute intervals for all configurations, and the drop-the-remainder behavior described is not how scheduled rules handle event grouping. NRT rules are the correct tool here.
  • C. Use a Near-Real-Time (NRT) analytics rule; when more than 30 matching events occur, only the first alert is generated and the rest are silently discarded. NRT rules do not silently discard events beyond the first. The 30-event grouping logic produces 29 individual alerts plus one summary alert for the rest of the events.
  • D. Use a Machine Learning analytics rule; it automatically groups events into a single alert regardless of event count. Machine Learning analytics rules use built-in ML models to detect anomalies based on behavioral baselines; they are not designed for specific-pattern, near-real-time per-event alerting.

Memory hook: NRT = 1-minute cadence. Per-event grouping = max 30: events 1-29 get solo alerts, event 30 becomes a summary of all the rest.

Microsoft Learn: Create NRT rules

A playbook in Microsoft Sentinel is created to run automatically when an incident is created. A junior analyst holds only the Microsoft Sentinel Responder role. They want to manually run this playbook against an open incident. Which additional role must be granted?

Correct answer: A. Microsoft Sentinel Playbook Operator on the playbook resource group

The Microsoft Sentinel Responder role can access and manage incidents, including running a playbook manually from within an incident. However, actually running the playbook manually requires the Microsoft Sentinel Playbook Operator role assigned to the resource group where the playbook resides. Responder provides incident access; Playbook Operator provides the run permission.

Why the other options are wrong:

  • B. Microsoft Sentinel Contributor on the Microsoft Sentinel workspace Microsoft Sentinel Contributor includes all Responder permissions plus the ability to create and edit analytics rules, workbooks, and other configuration resources. This exceeds the requirement and violates the principle of least privilege.
  • C. Logic App Contributor on the playbook resource group Logic App Contributor allows editing and managing logic apps and running playbooks, but it is broader than necessary for an analyst who only needs to manually trigger an existing playbook. Microsoft Sentinel Playbook Operator is the purpose-built minimum role.
  • D. Microsoft Sentinel Automation Contributor on the playbook resource group Microsoft Sentinel Automation Contributor is a service account role used by the Sentinel service itself to run playbooks via automation rules. It is not used for user accounts and would not resolve the analyst's manual run requirement.

Memory hook: Playbook Operator = permission to pull the trigger on an existing playbook. Responder can see the gun; Playbook Operator can fire it.

Microsoft Learn: Automate responses with playbooks

An automation rule must automatically run a playbook (built on a Consumption logic app) when an incident is created. Beyond your own permissions, which role must the Microsoft Sentinel service account hold on the resource group that contains the playbook so that automation rules can execute it?

Correct answer: A. Microsoft Sentinel Automation Contributor

Sentinel uses a dedicated service account to run incident-triggered (or manually run) playbooks. That account must be granted the Microsoft Sentinel Automation Contributor role on the playbook's resource group; once granted, automation rules can run any playbook in that resource group. Learn notes this role isn't used for any other purpose.

Why the other options are wrong:

  • B. Microsoft Sentinel Playbook Operator Playbook Operator lets a user manually run a playbook; it isn't the service-account role for automation rules.
  • C. Microsoft Sentinel Responder Responder lets a user access an incident to run a playbook manually; it doesn't authorize automation rules to run them.
  • D. Logic App Contributor Logic App Contributor is a role a user needs to edit/run logic apps, not the service-account grant that lets automation rules run playbooks.

Memory hook: Automation rules run playbooks only when Sentinel holds Automation Contributor on that resource group.

Microsoft Learn: Automate responses with playbooks

A central SOC uses Microsoft Sentinel workspace manager (preview) to publish standardized content from a central workspace to its member workspaces. Which content type is NOT supported by workspace manager and must therefore be deployed through another method?

Correct answer: C. Playbooks

Workspace manager supports publishing analytics rules, automation rules (excluding playbooks), parsers/saved searches/functions, hunting queries, and workbooks. Playbooks are explicitly not supported, including playbooks attached to analytics or automation rules, so they must be deployed by other means such as ARM/CI-CD. (Workspace manager also requires the Microsoft Sentinel Contributor role on both the central and member workspaces.)

Why the other options are wrong:

  • A. Hunting queries Hunting queries are a supported workspace manager content type.
  • B. Workbooks Workbooks are a supported workspace manager content type.
  • D. Analytics rules Analytics rules are a supported workspace manager content type.

Memory hook: Workspace manager pushes rules, functions, hunts, workbooks. It does NOT push playbooks.

Microsoft Learn: Workspace manager

Your team relied on Microsoft Sentinel livestream to run a query continuously and push notifications when new matches appeared. Per current Microsoft guidance, livestream is being retired. Which alternatives does Microsoft now recommend for persistent query results and notifications to messaging platforms?

Correct answer: B. KQL jobs, analytics rules, or playbooks.

Current Learn guidance states Sentinel livestreams are no longer available and directs you to use KQL jobs, analytics rules, or playbooks instead. These alternatives offer persistent query results and support notifications to various messaging platforms.

Why the other options are wrong:

  • A. Guided hunting (query builder) and sample queries. Guided hunting and sample queries help you author queries; they don't automate persistent results or alerts.
  • C. Bookmarks and the investigation graph. Bookmarks and the investigation graph preserve and visualize findings; they don't provide continuous querying or notifications.
  • D. Restore historical data and search jobs. Restore historical data and search jobs retrieve archived/historical data; they aren't continuous notification mechanisms.

Memory hook: Livestream retired; use KQL jobs, analytics rules, or playbooks.

Microsoft Learn: Sentinel: Hunting

Cover of KQL Threat Hunting Field Guide
Topic 4 of 4

Threat Hunting with KQL (18 questions)

Go deeper in KQL Threat Hunting Field Guide. Get it on Amazon · Companion page

Show the 18 questions and explanations

A threat hunter writes an advanced hunting query that joins DeviceLogonEvents (left side) to DeviceProcessEvents (right side) on DeviceId without specifying a join kind. The left table contains dozens of failed logon rows for the same device, but the results include only one failed logon row per device. What explains this behavior?

Correct answer: A. When kind is omitted, KQL uses innerunique, which deduplicates the left table on the join key before matching, keeping a single arbitrary row per unique DeviceId

innerunique is the default join flavor when the kind parameter is not specified. Learn documents that it removes duplicate keys from the left side before matching, leaving a single (arbitrary) row for each unique join-key value, then matches that deduplicated left side against the right table. The advanced hunting best practices page calls out this exact trap and recommends specifying kind=inner when you need every matching row combination, such as one row per failed logon.

Why the other options are wrong:

  • B. DeviceId is not unique in DeviceProcessEvents, so the engine collapses left-side rows to prevent fan-out The engine never collapses rows based on right-side cardinality to prevent fan-out. The deduplication is the documented left-side behavior of the innerunique flavor, independent of the right table's contents.
  • C. join defaults to leftsemi, which returns only distinct left-side rows The default flavor is innerunique, not leftsemi. leftsemi returns left-table rows (with only left-table columns) that have a match on the right, and it is never applied implicitly.
  • D. The 100,000-row result limit in advanced hunting truncated the result set The result cap truncates large result sets and surfaces a warning; it does not selectively deduplicate left-side rows by join key.

Memory hook: No kind = innerunique = left side quietly deduped. Want every combination? Say kind=inner out loud.

Microsoft Learn: Join innerunique

Your cross-table hunting query joins a small table of suspicious IPs (a few hundred rows) with a huge network-flow table (billions of rows). Following KQL best practices, how should you structure the join for best performance?

Correct answer: B. Put the small suspicious-IP table on the left (first) side of the join operator

KQL best practice for join is to place the table with the fewest rows on the left (first) side, because the left side is loaded into memory to build the join. Putting the small suspicious-IP set on the left minimizes memory pressure. (For single-column filtering, in is also often preferable to a left semi-join.)

Why the other options are wrong:

  • A. Replace the join with a union of both tables union stacks rows from both tables without correlating them, so it cannot answer 'which flows match a suspicious IP.'
  • C. Put the huge network-flow table on the left (first) side of the join operator Placing the huge table on the left forces the larger dataset into the join's in-memory side, degrading performance.
  • D. Add hint.remote=left so both sides execute on the same node hint.remote controls which cluster executes a cross-cluster join; it does not fix left/right sizing and is irrelevant to a single-workspace query.

Memory hook: Join: small table on the left (the left side goes into memory).

Microsoft Learn: Best practices

A string column in your hunting results contains repeating key=value entries such as: Action=BlockedByPolicy; RuleId=4471; User=contoso\jdoe. In a single step you want to break this into three separate columns (Action, RuleId, User) using the repeating pattern. Which KQL operator is purpose-built for extracting multiple values from one string into new columns?

Correct answer: B. parse

The parse operator evaluates a string expression and extracts multiple substrings into new calculated columns based on a pattern, effectively running multiple extract() applications on the same string in one statement. It's the standard tool for structuring key=value or printf-style strings.

Why the other options are wrong:

  • A. summarize with make_set() make_set() aggregates distinct values into a dynamic array during summarize; it doesn't split a string into columns.
  • C. extend with tostring() extend adds calculated columns but can't pattern-extract several fields from one string in a single step; you'd need a separate extract() per field.
  • D. project-rename project-rename only renames existing columns; it cannot pull values out of the middle of a string.

Memory hook: parse = pattern-slice one string into many columns.

Microsoft Learn: Parse operator

In DeviceProcessEvents you filter on FileName == "powershell.exe" to find suspicious PowerShell executions. You now need the PARENT process that spawned each PowerShell instance, to spot an Office-app-to-PowerShell chain. Which column holds the name of the process that launched the recorded process?

Correct answer: B. InitiatingProcessFileName

In DeviceProcessEvents the recorded (created) process is described by the FileName and Process* columns, while the process that started it is the 'initiating process.' So InitiatingProcessFileName is the immediate parent (e.g., winword.exe launching powershell.exe). InitiatingProcessParentFileName is one level higher: the grandparent.

Why the other options are wrong:

  • A. ProcessCommandLine ProcessCommandLine is the command line of the recorded process, not the parent's name.
  • C. FileName FileName is the recorded/created process itself (powershell.exe), not its parent.
  • D. InitiatingProcessParentFileName InitiatingProcessParentFileName is the grandparent (the parent of the initiating process), one level too high in the tree.

Memory hook: FileName = the child; InitiatingProcess* = the parent; add 'Parent' and you jump up to the grandparent.

Microsoft Learn: Advanced hunting DeviceProcessEvents table

A SOC manager builds a custom workbook from the SecurityIncident table to compute mean time to triage. They notice incident counts are inflated because the table appends a new row every time an incident is created or updated. Which KQL pattern correctly returns only the latest state of each incident before computing metrics?

Correct answer: D. | summarize arg_max(TimeGenerated, *) by IncidentNumber

SecurityIncident appends a new row on every incident create and update, so the current state lives in the newest record. summarize arg_max(TimeGenerated, *) by IncidentNumber (or by LastModifiedTime) keeps that latest row with all its columns for each incident, giving you one clean row per incident before computing metrics like mean time to triage. The classic trap is arg_min, which hands back the creation-time snapshot instead.

Why the other options are wrong:

  • A. | distinct IncidentNumber distinct IncidentNumber returns only the ID column, losing the fields needed to compute metrics.
  • B. | summarize arg_min(TimeGenerated, *) by IncidentNumber arg_min returns the earliest (creation) record rather than the current state, which skews "mean time to" metrics.
  • C. | summarize count() by IncidentNumber count() by IncidentNumber counts the update rows; it does not return the latest incident state with its columns.

Memory hook: Dedup SecurityIncident with arg_max(TimeGenerated,*) by IncidentNumber.

Microsoft Learn: Manage SOC with incident metrics

You want to hunt for hosts whose outbound connection counts spike abnormally versus their own seasonal baseline over the past 14 days, using KQL's built-in time-series anomaly detection. Which approach produces input in the correct shape for series_decompose_anomalies()?

Correct answer: D. make-series Count=count() default=0 on TimeGenerated from ago(14d) to now() step 1h by DeviceName, then pipe to series_decompose_anomalies(Count)

series_decompose_anomalies() operates on a dynamic numeric array (a series). make-series produces exactly that: one evenly-spaced, gap-filled (default=0) numeric array per DeviceName over the time axis, which is the required input. The function decomposes each series into seasonal/trend/residual components and scores outliers on the residual.

Why the other options are wrong:

  • A. evaluate autocluster() over the DeviceNetworkEvents table autocluster() finds common attribute-value patterns; it is not time-series decomposition and does not score seasonal anomalies.
  • B. summarize Count=count() by DeviceName, bin(TimeGenerated, 1h), then pipe directly to series_decompose_anomalies(Count) summarize ... by bin() returns individual scalar rows, not a dynamic array; it also leaves time gaps, so the decomposition function cannot consume it directly.
  • C. make-list(TimeGenerated) per device, then pipe to series_decompose_anomalies() make-list(TimeGenerated) builds an array of timestamps, not the per-bin numeric metric the decomposition needs.

Memory hook: Anomaly hunt = make-series (evenly-spaced array) then series_decompose_anomalies; bin() gives rows, not a series.

Microsoft Learn: Anomaly detection

A hunting query returns a column named Ips that is a dynamic array holding multiple IP addresses per row, for example ["10.0.0.5","203.0.113.9"]. You need one row per individual IP so you can join each address against a watchlist. Which operator do you use?

Correct answer: C. mv-expand Ips

mv-expand expands a multi-value dynamic array into multiple records, generating one row per element and duplicating all other columns onto each row. It is the inverse of the aggregation operators (make-list/make_set) that pack values into an array, and it is the standard way to fan out an array for per-element joins.

Why the other options are wrong:

  • A. mv-apply Ips on (summarize count()) mv-apply runs a subquery per expanded element; the shown form aggregates rather than simply expanding, and it is more than is needed here.
  • B. summarize make-list(Ips) make-list does the opposite: it packs multiple values into a single dynamic array.
  • D. evaluate bag_unpack(Ips) bag_unpack expands the keys of a property bag (dictionary) into columns, not array elements into rows.

Memory hook: Array to rows = mv-expand (the opposite of make-list).

Microsoft Learn: Mv expand operator

During an investigation, an analyst wants a single result set containing every row from both DeviceFileEvents and DeviceImageLoadEvents that references a suspicious SHA1 hash, stacked vertically, with an extra column showing which table each row came from. Which KQL construct does this?

Correct answer: B. DeviceFileEvents | union withsource=SourceTable DeviceImageLoadEvents

union takes two or more tables and returns all their rows stacked vertically. The withsource parameter adds a new column whose value in each row is the name of the table the row came from, which is exactly what is needed to trace each hit back to its origin when combining multiple event tables in a hunt.

Why the other options are wrong:

  • A. DeviceFileEvents | lookup DeviceImageLoadEvents on SHA1 lookup extends a fact table with columns looked up in a dimension table. It widens rows horizontally rather than stacking all rows from both tables, and it does not label row origin.
  • C. DeviceFileEvents | join kind=fullouter DeviceImageLoadEvents on SHA1 fullouter join still merges rows horizontally into combined wide rows keyed on the hash. It neither stacks the rows vertically nor produces a column identifying the source table.
  • D. DeviceFileEvents | join kind=inner DeviceImageLoadEvents on SHA1 join kind=inner correlates rows horizontally on matching key values and returns only combined rows where the hash appears in both tables; rows present in just one table are dropped entirely.

Memory hook: union stacks rows; join matches rows. withsource is the return-address label on each stacked row.

Microsoft Learn: Union operator

An analyst's advanced hunting query completes successfully but the portal displays a message indicating the displayed results are partial due to size constraints. Which service limit was reached, and what is the most effective fix?

Correct answer: C. The 64-MB results size limit; use project to return only the columns the hunt actually needs, or aggregate before returning results

Advanced hunting enforces a 64-MB limit on the overall size of the results data. The limit is not just about record count: the number of columns, data types, and field lengths all contribute. When a query result exceeds 64 MB, the portal returns the maximum number of records it can fit within the limit and displays a message that the displayed results are partial due to size constraints. Because width drives the size, the effective fix is narrowing the payload: project only the needed columns, drop large dynamic fields, or summarize before returning.

Why the other options are wrong:

  • A. The 10-minute query timeout; add join hints such as hint.strategy=broadcast to speed up execution A query that exceeds the 10-minute timeout is terminated with an error and returns no results at all, not a partial result set with a size message.
  • B. The tenant CPU quota; wait 15 minutes for the allocation cycle to reset and run the query again Reaching 100 percent of the tenant CPU allocation blocks queries with an 'exceeded processing resources' error. It does not return partial results.
  • D. The 100,000-row result cap; split the query into multiple smaller time windows and merge the results manually Hitting the 100,000-row cap simply returns up to 100,000 records; it is a different limit from the size constraint that generates this specific partial-results message. Wide rows can trip the 64-MB limit well below 100,000 rows.

Memory hook: Partial-results message = the 64-MB size cap. Cut columns with project; fewer columns beats fewer rows.

Microsoft Learn: Advanced hunting overview

A threat hunter promotes an advanced hunting query on DeviceProcessEvents (Defender XDR data) to a custom detection rule with the frequency set to every hour. The query filters Timestamp > ago(24h). Analysts notice the scheduled rule catches far fewer events than the same query run interactively. What is the cause?

Correct answer: B. Custom detections on Defender XDR data set to run hourly have a fixed four-hour lookback, so most of the query's 24-hour window falls outside what the rule evaluates

For custom detections that include Defender XDR data, the lookback period is fixed by the chosen frequency: every 24 hours looks back 30 days, every 12 hours looks back 48 hours, every 3 hours looks back 12 hours, and hourly rules look back four hours. Microsoft Learn explicitly warns to match the time filters in your query with the lookback period, because results outside of the lookback period are ignored. An hourly rule therefore only ever evaluates four hours of data, no matter what the query's ago() filter says. Only rules targeting Microsoft Sentinel data exclusively get a configurable lookback.

Why the other options are wrong:

  • A. The lookback slider in the rule wizard must be manually extended to 24 hours to match the query filter There is no configurable lookback for rules that include Defender XDR data; the lookback is fixed by frequency. The customizable lookback (up to 30 days depending on frequency) applies only when the rule targets Microsoft Sentinel data exclusively.
  • C. Hourly rules look back exactly one hour, so 23 hours of the query window are never evaluated The lookback is not equal to the frequency. Hourly rules use a fixed four-hour lookback, not one hour; the frequency-to-lookback mapping is a documented fixed table for Defender XDR data.
  • D. Scheduled rules require TimeGenerated instead of Timestamp, so the time filter is being ignored entirely Either Timestamp or TimeGenerated can set alert timestamps, and neither is ignored. The problem is the window mismatch between the query's 24-hour filter and the rule's fixed four-hour lookback.

Memory hook: XDR custom detections have fixed lookbacks: hourly=4h, 3-hourly=12h, 12-hourly=48h, daily=30d. Match your time filter to the lookback or lose events quietly.

Microsoft Learn: Custom detection rules

An analyst investigating a potential business email compromise (BEC) attack needs to find all logon events made by email recipients within 30 minutes after they received emails that were identified as malware and where Zero-hour Auto Purge (ZAP) failed. Which pair of Advanced Hunting tables provides the data needed to correlate these events in a single KQL query?

Correct answer: B. EmailPostDeliveryEvents and IdentityLogonEvents

EmailPostDeliveryEvents captures security events that occur after email delivery, including ZAP actions and their results (ActionType contains 'ZAP' and ActionResult can be 'Error' for failures). IdentityLogonEvents captures authentication events on Active Directory and Microsoft online services, enabling correlation with RecipientEmailAddress matching AccountUpn. This is the canonical table pair for ZAP-failure + subsequent logon correlation shown in Microsoft's own hunting scenario examples.

Why the other options are wrong:

  • A. EmailEvents and DeviceLogonEvents EmailEvents captures email delivery and blocking events at delivery time but does not contain post-delivery ZAP action results. DeviceLogonEvents captures device sign-ins from endpoints, not cloud identity logon events.
  • C. AlertInfo and IdentityQueryEvents AlertInfo contains alert metadata not raw ZAP events. IdentityQueryEvents captures Active Directory object queries (e.g., LDAP queries), not user logon events.
  • D. EmailAttachmentInfo and DeviceProcessEvents EmailAttachmentInfo contains file attachment metadata. DeviceProcessEvents captures process creation. Neither table provides ZAP failure events or post-delivery identity logon correlation.

Memory hook: ZAP fail + logon after = EmailPostDeliveryEvents (for ZAP result) + IdentityLogonEvents (for who logged in). Post-delivery = the key word.

Microsoft Learn: Advanced hunting query emails devices

An analyst is writing an Advanced Hunting query in Microsoft Defender XDR to find all devices where a potentially compromised user account (username: 'jsmith') has logged on, and then list all active alerts triggered on those devices. Which table should be the starting point, and what join strategy correctly avoids duplicating device records?

Correct answer: B. Start from DeviceInfo filtered for LoggedOnUsers containing 'jsmith', get distinct DeviceIds, then join kind=inner to AlertEvidence on DeviceId, project AlertId, then join AlertInfo on AlertId.

The documented Microsoft example for this exact scenario starts with DeviceInfo filtered for LoggedOnUsers containing the account name, then takes distinct DeviceIds to avoid duplication, then performs a kind=inner join to AlertEvidence on DeviceId (inner join prevents deduplication of left-side DeviceId values that could cause fan-out), projects AlertId, and then joins AlertInfo to retrieve alert details. This is the canonical multi-table hunting pattern shown in the Microsoft Advanced Hunting documentation.

Why the other options are wrong:

  • A. Start from IdentityLogonEvents filtered on AccountName == 'jsmith', join kind=leftouter to DeviceInfo to get device details, then join AlertInfo to get active alerts. IdentityLogonEvents captures authentication events but does not contain the DeviceId column directly in a way that maps to AlertEvidence. The documented pattern uses DeviceInfo (which tracks LoggedOnUsers) as the starting point for device-centric correlation.
  • C. Start from DeviceLogonEvents filtered for AccountName == 'jsmith', join kind=fullouter to AlertInfo on DeviceId to get all associated alerts. DeviceLogonEvents captures device-level sign-in events. A fullouter join to AlertInfo would produce a cross-product of unmatched rows and would not correctly constrain alerts to the specific compromised user's devices.
  • D. Start from AlertInfo, left outer join to DeviceInfo on DeviceId, then filter for LoggedOnUsers containing 'jsmith'. Starting from AlertInfo and joining to DeviceInfo would not efficiently filter to the specific compromised user's devices first. A left outer join would also include devices with no matching alerts, which is the opposite of what is needed. This approach is less efficient and not the documented pattern.

Memory hook: Compromised user hunting: DeviceInfo (LoggedOnUsers filter), then distinct DeviceId, then inner join AlertEvidence, then AlertInfo. Inner join = no DeviceId fan-out duplication.

Microsoft Learn: Advanced hunting query emails devices

A threat hunter suspects malware established persistence by adding a value under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run on managed endpoints. Which advanced hunting table should the query target to find the creation or modification of that value, along with the process that made the change?

Correct answer: C. DeviceRegistryEvents

DeviceRegistryEvents contains information about the creation and modification of registry entries, exposing RegistryKey, RegistryValueName, and RegistryValueData columns to filter for the Run key, plus PreviousRegistryValueData for modifications and the InitiatingProcess* columns identifying which process (and account) made the change. The table is populated by Microsoft Defender for Endpoint, so it only returns rows on devices onboarded to MDE.

Why the other options are wrong:

  • A. DeviceProcessEvents DeviceProcessEvents records process creation events. It could show the malware launching, but it does not capture the registry value the process wrote.
  • B. DeviceFileEvents DeviceFileEvents records file create, modify, rename, and delete activity. Run-key persistence is registry-based, not file-based, so the write never appears there.
  • D. DeviceEvents DeviceEvents is the catch-all table for miscellaneous event types such as antivirus detections and ASR rule triggers. Registry create/modify telemetry has its own dedicated table with purpose-built registry columns.

Memory hook: Registry persistence hunts live in DeviceRegistryEvents: key, value name, value data, and the initiating process in one table.

Microsoft Learn: Advanced hunting DeviceRegistryEvents table

A threat hunter wants to write a Microsoft Defender XDR Advanced Hunting query to find all devices where a file from a known malicious sender (MaliciousSender@example.com) was delivered as an email attachment and is now present on the device. Which table join correctly maps email attachment file hashes to device file events?

Correct answer: B. Join EmailAttachmentInfo (filtered by SenderFromAddress) to DeviceFileEvents on SHA256 to find devices where the attachment exists.

The canonical Microsoft hunting scenario for 'check if files from a known malicious sender are on your devices' filters EmailAttachmentInfo by SenderFromAddress, then joins to DeviceFileEvents on SHA256. The hash is what makes the correlation trustworthy: file names get renamed, but the SHA256 stays consistent from email attachment to file on disk.

Why the other options are wrong:

  • A. Join AlertEvidence (filtered for file entities) to EmailEvents on NetworkMessageId, then join DeviceFileEvents on FileName. AlertEvidence contains alert-related artifacts (files, IPs, etc. associated with triggered alerts), not comprehensive file delivery data from email. Joining on FileName is unreliable due to file renaming and is not the documented approach.
  • C. Join EmailPostDeliveryEvents to DeviceLogonEvents on RecipientEmailAddress to find users who received the file and then logged on. EmailPostDeliveryEvents tracks post-delivery security actions (like ZAP) and DeviceLogonEvents tracks device sign-ins. This join would identify users who logged on after receiving emails, not devices where the attachment file is present.
  • D. Join EmailEvents to DeviceFileEvents on NetworkMessageId to correlate the email to device file activity. EmailEvents does not contain file hashes for attachments. Joining on NetworkMessageId to DeviceFileEvents would not work because DeviceFileEvents does not have a NetworkMessageId column. File hash correlation requires EmailAttachmentInfo.

Memory hook: Malicious attachment on device = EmailAttachmentInfo (filter sender) JOIN DeviceFileEvents ON SHA256. Hash is the reliable link between email and endpoint.

Microsoft Learn: Advanced hunting query emails devices

A SOC manager wants threat hunters to document each proactive investigation with a stated hypothesis, work from cloned copies of hunting queries scoped to that investigation, collect bookmarks and their entities in one place, and report program metrics such as validated hypotheses and new analytics rules created. Which Microsoft Sentinel capability should the team use?

Correct answer: D. The Hunts feature under Microsoft Sentinel, then Threat management, then Hunting

The Hunts feature is Microsoft Sentinel's end-to-end proactive hunting workflow. A hunt is a named investigation container with a hypothesis state you update as evidence accumulates, queries that are cloned into the hunt so they can be edited without affecting the workspace query library, hunt-specific bookmarks with an Entities tab that deduplicates mapped entities, a comment thread for collaboration, and direct actions to create analytics rules and incidents. The metrics bar on the Hunts tab tracks validated hypotheses, new incidents created, and new analytics rules created. Using the feature requires the Microsoft Sentinel Contributor role or a custom Azure RBAC role with Microsoft.SecurityInsights/hunts permissions.

Why the other options are wrong:

  • A. Shared queries in advanced hunting in the Microsoft Defender portal Shared queries in advanced hunting make saved KQL visible to the whole organization, but they have no hypothesis tracking, no bookmark collection, no entity aggregation, and no outcome metrics. They are a query library, not an investigation workflow.
  • B. Threat analytics reports in the Microsoft Defender portal Threat analytics reports are Microsoft-authored intelligence about specific threats and campaigns. They inform hypotheses but are not a container for tracking your own hypothesis-driven hunts, bookmarks, and outcomes.
  • C. A Microsoft Sentinel workbook built on the HuntingBookmark table A workbook could visualize bookmark data from the HuntingBookmark table, but it cannot manage hypothesis state, clone queries into a scoped investigation, or produce the built-in metrics for validated hypotheses and rules created. That capability is native to the Hunts feature.

Memory hook: A Hunt = hypothesis + cloned queries + bookmarks + entities + metrics, all in one named container.

Microsoft Learn: Sentinel: Hunts

During a Microsoft Sentinel hunt, an analyst bookmarks several interesting query result rows, carefully adding names, notes, and MITRE ATT&CK technique mappings, but skips the entity mapping section to save time. Later, the analyst selects a bookmark and chooses Investigate to visualize the finding. What happens, and what is required to fix it?

Correct answer: B. The bookmark cannot be usefully investigated in the graph; every bookmark you investigate must have at least one mapped entity, so the analyst must edit the bookmark and map an entity first

The investigation graph will not usefully render a bookmark without entities: each bookmark you want to investigate must have at least one mapped entity, and if it does not, you must edit the bookmark to add one before you begin. Entity mapping happens in the Add bookmark pane by mapping entity types and identifiers to columns in the query results, with account, host, IP, and URL types supported. Skipping the step at creation time is the classic time-waster because the fix is a manual edit of every affected bookmark afterward. Map entities when you create the bookmark, not after.

Why the other options are wrong:

  • A. The investigation graph renders normally, because Sentinel automatically extracts entities from the raw bookmarked rows Entities are not auto-extracted from arbitrary bookmarked rows. The analyst must explicitly map entity types and identifiers to result columns in the Entity mapping section of the bookmark pane.
  • C. Selecting Investigate automatically creates an incident, and the graph populates from that incident's alert entities instead Investigate opens the investigation graph directly; it does not create an incident. Escalating a bookmark to an incident is a separate, deliberate action: Incident actions, then Create new incident or Add to existing incident.
  • D. The MITRE technique mappings substitute for entity mappings, so the graph renders technique nodes in place of entity nodes MITRE tactic and technique mappings classify the finding for coverage and correlation purposes; they do not create graph nodes. The investigation graph is built on mapped entities, and no technique mapping can substitute for them.

Memory hook: No mapped entity, no investigation graph. Map at least one entity at bookmark creation, not after.

Microsoft Learn: Sentinel: Bookmarks

A threat hunter maintains a 5-MB CSV of known-bad IP addresses in Azure Blob Storage, refreshed daily by an external feed. They want their KQL hunting queries to check DeviceNetworkEvents against the current list at query time, keeping the blob as the single source of truth without importing the list into the workspace. Which KQL construct achieves this?

Correct answer: C. The externaldata operator, with the column schema defined in the query and the blob's storage connection string as the source

The externaldata operator returns a table whose schema is defined in the query itself and whose data is read from an external storage artifact, such as a blob in Azure Blob Storage or a file in Azure Data Lake Storage. In Azure Monitor and Microsoft Sentinel contexts, Microsoft Learn recommends it for small reference tables of up to 100 MB, which comfortably covers a 5-MB IOC list. Because the data is read from the blob at query time, the query always sees the latest daily refresh and nothing is ingested into the workspace. The documented pattern is exactly this: filter a table where a column is in the set returned by externaldata.

Why the other options are wrong:

  • A. A Microsoft Sentinel watchlist created from the CSV, referenced with _GetWatchlist() Watchlists would work functionally, but they require uploading the CSV into Microsoft Sentinel, where it is stored in the workspace. That contradicts the requirement to keep the blob as the single source of truth without importing, and daily feed updates would require re-upload machinery.
  • B. The lookup operator pointed directly at the blob's URL The lookup operator correlates two tabular expressions that the query engine can already resolve, such as workspace tables or let-defined expressions. It cannot read data from a storage URL.
  • D. A summary rule that aggregates the CSV into an Analytics-tier custom table on a 20-minute bin Summary rules aggregate data that already exists in Log Analytics tables on a scheduled bin. They cannot read a CSV from Blob Storage, and they produce ingested custom tables, the opposite of the no-import requirement.

Memory hook: externaldata = schema in the query, data stays in the blob. Small reference lists (up to 100 MB), zero ingestion.

Microsoft Learn: Externaldata operator

You hunt for suspicious Microsoft Entra authentication in the IdentityLogonEvents table. Your query returns interactive sign-ins but misses the attacker's non-interactive, token-based sign-ins entirely. Why?

Correct answer: B. IdentityLogonEvents captures interactive sign-ins and legacy-protocol authentications to Microsoft online services (via Defender for Cloud Apps); non-interactive Entra sign-ins aren't in this table and are found in the Microsoft Entra sign-in/audit logs instead.

IdentityLogonEvents covers Entra logon activity tracked by Defender for Cloud Apps: interactive sign-ins and authentications using ActiveSync and other legacy protocols. Non-interactive logons are not populated here; review them in the Microsoft Entra logs (for example, AADNonInteractiveUserSignInLogs).

Why the other options are wrong:

  • A. Non-interactive sign-ins require the DeviceLogonEvents table, which merges into IdentityLogonEvents automatically. DeviceLogonEvents covers endpoint logons and does not auto-merge to supply Entra non-interactive sign-ins.
  • C. IdentityLogonEvents stores only on-premises Active Directory logons, so no Microsoft Entra sign-ins of any kind appear. The table does include Microsoft online services (Entra) authentications, not only on-premises AD events; the gap is limited to non-interactive sign-ins.
  • D. Non-interactive sign-ins are present but retained for only 7 days; extend the time filter to reveal them. The gap isn't a retention/time-window issue; non-interactive events simply aren't ingested into this table.

Memory hook: IdentityLogonEvents = interactive + legacy only; non-interactive lives in the Entra logs.

Microsoft Learn: Advanced hunting IdentityLogonEvents table