Free practice questions

SC-200 practice questions, with full explanations

75 free 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. Prefer to be quizzed? Take the interactive SC-200 quiz, which scores you by topic and points you to the guide that fits your weak spots.

Microsoft Defender XDR (16 questions)

Go deeper on this topic in Microsoft Defender XDR Field Guide.

All Microsoft Defender for Endpoint device groups are set to Full - remediate threats automatically. An automated investigation in Microsoft Defender for Office 365 determines that a delivered message contains a malicious URL, yet the recommended soft-delete action shows as Pending approval in the Action center. What best explains this?

Correct answer: A. Malicious email-content remediations are recommended actions that always await SecOps approval; device-group automation levels govern endpoint remediation, not email.

In the AIR verdict model, a Malicious verdict on email content (URLs or attachments) produces recommended remediation actions that are pending approval, regardless of device automation. The Full - remediate threats automatically setting applies to device (endpoint) remediation, so email actions still require a SecOps member to approve them.

Why the other options are wrong:

  • B. Full automation only auto-remediates device threats; email-content actions are pending by design, so nothing is misconfigured.
  • C. Manage security settings is unrelated to approving AIR email actions; approval is a SecOps task in the Action center or incident.
  • D. Recommended email actions are generated when the latest delivery location is a cloud mailbox; the pending state is by design, not an on-prem limitation.

Memory hook: Device verdicts can auto-fire; email verdicts always wait for a human to approve.

Microsoft Learn: https://learn.microsoft.com/defender-xdr/m365d-remediation-actions

Your tenant has Microsoft Defender for Office 365 but no custom Safe Attachments or Safe Links policies, and you have not enabled the Standard or Strict preset security policies. Which statement about the protection your recipients receive is correct?

Correct answer: D. The Built-in protection preset security policy already provides Safe Links and Safe Attachments protection to all recipients by default.

Built-in protection is assigned to all recipients by default and effectively provides default Safe Links and Safe Attachments policies (you can configure exceptions). The Standard and Strict presets are assigned to no one until you enable them and add users.

Why the other options are wrong:

  • A. Standard and Strict presets apply to no one until you explicitly enable them and assign users.
  • B. Both Safe Links and Safe Attachments are covered by Built-in protection; Safe Attachments does not require a custom policy for baseline coverage.
  • C. Even without a custom policy, Built-in protection gives all recipients Safe Links and Safe Attachments protection by default.

Memory hook: Built-in protection = Safe Links + Safe Attachments for everyone, on by default.

Microsoft Learn: https://learn.microsoft.com/defender-office-365/preset-security-policies

An authorized vulnerability scanner triggers dozens of Microsoft Defender for Endpoint alerts every night. The SOC manager wants these alerts to stop appearing in the alert queue and stop creating incidents, but the threat hunting team requires that the records remain queryable in the AlertInfo and AlertEvidence tables in advanced hunting. Which alert tuning action, configured under Settings, then Microsoft Defender XDR, then Alert tuning, meets all of the requirements?

Correct answer: D. Hide alert

Hide alert is the only action that satisfies every requirement: per Microsoft Learn, it suppresses the alert and prevents incident creation, while hidden alerts remain in the AlertInfo and AlertEvidence tables so hunters can still query them. Hide alert is only applicable to Defender for Endpoint alerts, which matches this scenario's source. The rule conditions should be scoped tightly, for example the scanner process name AND its service account, rather than a broad wildcard.

Why the other options are wrong:

  • A. The indicator allow list governs blocking and remediation behavior for files, not alert queue hygiene. Allow-listing the scanner binary changes how Defender treats the file but is not the mechanism for suppressing alerts while preserving AlertInfo records, and it carries side effects beyond tuning.
  • B. Resolve alert does not suppress anything: matching alerts and their related incidents are still created, just automatically set to resolved status. The resolved records still land in the queue and incidents are still generated, so it fails both the 'stop appearing' and 'stop creating incidents' requirements.
  • C. Set as behavior converts matching signals into behaviors: they no longer appear in the alert queue or trigger incidents, but the data lands in the BehaviorInfo and BehaviorEntities tables, not AlertInfo and AlertEvidence, which violates the hunting team's requirement. It is also unsupported for Defender for Cloud and Defender for Office 365 alerts.

Memory hook: Hide = out of the queue, no incident, but still in AlertInfo (MDE only). Resolve = closes it everywhere. Behavior = moves the data to BehaviorInfo.

Microsoft Learn: https://learn.microsoft.com/defender-xdr/investigate-alerts#tune-an-alert

You configure a Microsoft Defender XDR custom detection rule against Defender XDR data with a frequency of "Every 3 hours." To avoid missing or double-counting events, what lookback period does the rule apply, and how should your query's time filter relate to it?

Correct answer: C. 12-hour lookback; align your query's time filter with the lookback window.

A rule that runs every 3 hours looks back 12 hours, not 3. The fixed mapping for custom detections on Defender XDR data: hourly checks the last 4 hours, every 3 hours checks 12 hours, every 12 hours checks 48 hours, and every 24 hours checks 30 days. Match your query's time filter to that lookback window so relevant results aren't ignored.

Why the other options are wrong:

  • A. The every-3-hours frequency carries a fixed 12-hour lookback; 24 hours isn't the window for this frequency.
  • B. The lookback for a 3-hour frequency is 12 hours, not 3; a 3-hour filter would miss data inside the lookback window.
  • D. 48 hours is the lookback for the every-12-hours frequency, not every 3 hours.

Memory hook: Lookback: 3h gets 12h, 12h gets 48h, 24h gets 30d, hourly gets 4h.

Microsoft Learn: https://learn.microsoft.com/defender-xdr/custom-detection-rules

Executive and support staff need Microsoft's most aggressive email protection, with the admin releasing any blocked messages the users request. A custom anti-spam policy already targets some of these same users. The team assigns the Strict preset security policy to the executives. For those users, how are the anti-spam settings resolved, and how does Built-in protection relate?

Correct answer: A. The Strict preset security policy's settings are applied to those users before the custom anti-spam policy or the default policy; Built-in protection provides only Safe Links and Safe Attachments to recipients not covered by Standard/Strict or custom policies

Preset security policies sit at the top of the threat-policy order of precedence: Strict is applied first, then Standard, then Defender for Office 365 evaluation policies, then custom threat policies by priority, and finally the Built-in protection preset (Safe Links/Safe Attachments) and the default policies. So for a user in the Strict preset, the Strict anti-spam settings are applied instead of the custom or default anti-spam policy; no merging occurs. Built-in protection is assigned to all recipients by default but only provides Safe Links and Safe Attachments, and it is the lowest-precedence preset, so it never overrides Strict. Strict is the right choice because it quarantines more aggressively and is designed for high-value targets whose admins review and release messages.

Why the other options are wrong:

  • B. Built-in protection is assigned to all recipients by default, but it only supplies Safe Links and Safe Attachments and is the lowest-precedence preset. It does not override the Strict preset's settings.
  • C. Custom policy priority determines ordering only among custom policies. Preset security policies (Strict, then Standard) are always applied before any custom or default threat policy, so a custom anti-spam policy cannot outrank the Strict preset even at priority 0.
  • D. Threat policies are not merged per setting. The first applicable policy in the precedence order wins for a given recipient, and preset policies are evaluated before custom and default policies.

Memory hook: Order: Strict then Standard then eval then custom (by priority) then Built-in protection and defaults. Presets always beat custom; Built-in protection is just Safe Links/Attachments at the bottom.

Microsoft Learn: https://learn.microsoft.com/defender-office-365/preset-security-policies

After Microsoft Entra flags a risky sign-in for a user, a threat hunter wants to determine whether that user then performed unusual bulk file downloads from SharePoint Online and OneDrive, using data surfaced by Microsoft Defender for Cloud Apps in advanced hunting. Which table holds these cloud app file-activity events (for example, ActionType 'FileDownloaded') to correlate with the sign-in?

Correct answer: B. CloudAppEvents

CloudAppEvents contains events involving accounts and objects in Office 365 and other cloud apps and services, populated by Microsoft Defender for Cloud Apps. It records SaaS activities such as FileDownloaded for SharePoint Online and OneDrive, with columns like ActionType, Application, AccountObjectId, and RawEventData that a hunter can pivot on and correlate with the risky sign-in by account. The table requires Defender for Cloud Apps to be deployed and the Microsoft 365 activities connector enabled.

Why the other options are wrong:

  • A. EmailEvents covers email messages processed by Defender for Office 365 (delivery, sender, recipients). It does not capture SharePoint or OneDrive file-download activity.
  • C. IdentityInfo is a reference and enrichment table describing user account attributes. It provides context about the identity but contains no file-download activity events.
  • D. DeviceFileEvents records file create, modify, and delete activity on managed endpoints from Defender for Endpoint. It captures local file operations on a device, not cloud service downloads surfaced by Defender for Cloud Apps.

Memory hook: SaaS/Office 365 activity (FileDownloaded, MailItemsAccessed) = CloudAppEvents (from Defender for Cloud Apps). Not EmailEvents, not DeviceFileEvents.

Microsoft Learn: https://learn.microsoft.com/defender-xdr/advanced-hunting-cloudappevents-table

You want Microsoft Defender for Identity to disable a compromised on-premises Active Directory account and reset its password from the Microsoft Defender portal. All of your sensors are v2.x running on domain controllers. Which account performs these remediation actions, and how does it differ from the Directory Service Account (DSA)?

Correct answer: D. A dedicated action account (a gMSA you scope with the needed permissions) performs remediation, while the DSA is used only to read Active Directory data; by default the v2.x sensor uses the domain controller's LocalSystem account for actions.

Remediation actions such as disabling a user or resetting a password are performed by the action account. By default the v2.x sensor impersonates the domain controller's LocalSystem account; if you want scoped permissions you configure a dedicated gMSA as the action account. This is separate from the DSA, which only reads AD data.

Why the other options are wrong:

  • A. The DSA only reads AD data; remediation is handled by the action account (LocalSystem by default, or a scoped gMSA), not the DSA.
  • B. v2.x sensors on domain controllers already support action accounts; v3.x actually drops gMSA action accounts and always uses LocalSystem.
  • C. A gMSA is the recommended scoped option for the action account; you do not have to use a stored regular user account.

Memory hook: DSA reads; the action account acts (LocalSystem by default, gMSA if you scope it).

Microsoft Learn: https://learn.microsoft.com/defender-for-identity/deploy/manage-action-accounts

During email remediation in Microsoft Defender, which action moves the messages to the user's Recoverable Items\Deletions folder, leaving them recoverable by the user?

Correct answer: C. Soft delete

Soft delete moves messages to the Recoverable Items\Deletions folder, where they remain recoverable by the user (and admins). Hard delete purges the message (recoverable only by an admin via single-item recovery), and Move to Deleted Items only places it in the visible Deleted Items folder.

Why the other options are wrong:

  • A. Move to Deleted Items places messages in the ordinary Deleted Items folder, not Recoverable Items\Deletions.
  • B. Hard delete purges the message; only admins can recover it via single-item recovery, not the user from Recoverable Items.
  • D. Quarantine email holds the message in quarantine for admin review; it is not a move to Recoverable Items.

Memory hook: Soft delete = Recoverable Items (user can get it back); Hard delete = purged (admin-only recovery).

Microsoft Learn: https://learn.microsoft.com/defender-office-365/remediate-malicious-email-delivered-office-365

In Microsoft Security Exposure Management, a database server matches two critical asset classification rules at the same time: a predefined rule that assigns High criticality and a custom rule that assigns Medium criticality. Months later, the server is rebuilt and no longer matches the High-criticality rule's criteria. How does Exposure Management handle the asset's criticality level across these events?

Correct answer: B. The rule with the highest criticality level takes precedence, so the asset is High; when it no longer meets that rule's criteria, it automatically reverts to the next applicable classification level (Medium).

Microsoft Security Exposure Management categorizes assets into four criticality levels: Very High, High, Medium, and Low. When multiple classification rules apply to the same asset, the rule with the highest criticality level takes precedence. That classification remains in effect until the asset no longer meets the criteria for that rule, at which point it automatically reverts to the next applicable classification level. So the server is treated as High while it matches the predefined rule, then automatically drops to Medium after the rebuild. Getting criticality right matters operationally: criticality feeds prioritization surfaces such as device inventory sorting, security recommendations (exposed critical assets), and incident prioritization in the Defender portal.

Why the other options are wrong:

  • A. There is no dual-classification state or forced manual resolution. The platform resolves the conflict automatically by applying the highest applicable criticality level.
  • C. Rule origin (custom versus predefined) does not determine precedence. A predefined High rule outranks a custom Medium rule because High outranks Medium.
  • D. Rule recency is not the tiebreaker. Precedence is determined by the criticality level each rule assigns, with the highest level winning.

Memory hook: Criticality conflicts: highest level wins, and the asset auto-demotes to the next applicable level when that rule stops matching.

Microsoft Learn: https://learn.microsoft.com/security-exposure-management/classify-critical-assets

A vulnerability management lead opens Threat analytics in the Microsoft Defender portal (Threat intelligence, then Threat analytics). They want to prioritize patching against tracked threats the organization has not yet generated any alerts for, ranked by how severe the exploited vulnerabilities are and how many onboarded devices carry those weaknesses. Which dashboard section provides this ranking?

Correct answer: D. Highest exposure threats

The threat analytics dashboard (https://security.microsoft.com/threatanalytics3) summarizes threats in three sections: Latest threats (most recently published or updated reports), High-impact threats (ranked by the number of active and resolved alerts in your organization), and Highest exposure threats. Per Microsoft Learn, the exposure level is calculated using two pieces of information: how severe the vulnerabilities associated with the threat are, and how many devices in your organization could be exploited by those vulnerabilities. Because exposure is driven by device posture rather than alerts, this section can surface threats the tenant has never seen an alert for, which is exactly what proactive patch prioritization needs.

Why the other options are wrong:

  • A. High-impact threats ranks by the number of active and resolved alerts in your own tenant, so it answers 'what is already hitting us,' not 'what could hit us.' A threat with zero alerts sits low there regardless of your vulnerability posture.
  • B. The Related incidents tab lists incidents in your tenant already correlated to the threat; by definition it requires alerts to exist and offers no vulnerability-based ranking across threats.
  • C. Latest threats orders reports by publication or update recency. It tells you what is new, not how exposed your devices are to it.

Memory hook: High impact = already burning you (alert counts). Highest exposure = could burn you (vuln severity x vulnerable devices). Patch off the exposure list.

Microsoft Learn: https://learn.microsoft.com/defender-xdr/threat-analytics

A SOC lead wants to add custom case status values such as 'Pending vendor response' and 'Detection tuning' to case management in the Microsoft Defender portal. The lead currently holds Microsoft Sentinel Responder, which already lets them create cases and link incidents. Using Microsoft Sentinel roles, what is the minimum role required to customize the case status options?

Correct answer: A. Microsoft Sentinel Contributor

Customizing case status options requires the Microsoft Sentinel Contributor role, or Core Security settings (manage) under Authorization and settings in unified RBAC. That is the top tier of case management RBAC in the Defender portal: viewing the case queue, details, tasks, comments, and audits needs only Security data basics (read) or Microsoft Sentinel Reader, while creating and managing cases and case tasks, assigning, updating status, and linking or unlinking incidents needs Alerts (manage) or Microsoft Sentinel Responder. The trap is assuming Responder covers everything case-related; changing the status menu is a configuration change, one tier above day-to-day case work and typically a SOC lead or admin function.

Why the other options are wrong:

  • B. Subscription Owner is far beyond the minimum. The documented minimum Sentinel role for customizing case status options is Microsoft Sentinel Contributor (or Core Security settings (manage) in Defender unified RBAC).
  • C. Microsoft Sentinel Reader maps to view-only case access: queue, details, tasks, comments, and audits. It cannot create cases, let alone customize status values.
  • D. Microsoft Sentinel Responder covers working cases (create, manage, assign, update status, link/unlink incidents) but not customizing the available status options, which is a settings-level change.

Memory hook: Cases RBAC ladder: Reader views, Responder works the case, Contributor changes the status menu.

Microsoft Learn: https://learn.microsoft.com/unified-secops/cases-overview

A SOC has onboarded Microsoft Sentinel to the Microsoft Defender portal. A detection engineer is writing a brand-new detection over DeviceEvents and EmailEvents data and wants native Defender XDR remediation actions with automatic entity mapping, while minimizing ingestion costs. Which detection mechanism does Microsoft currently recommend for this rule?

Correct answer: D. A custom detection rule in the Microsoft Defender portal

Microsoft's feature-comparison guidance states that custom detections are now the best way to create new rules across Microsoft Sentinel and Microsoft Defender XDR. Custom detections reduce ingestion costs by running directly against already-available Defender data, provide real-time detections, and integrate directly with Defender XDR data, functions, and native remediation actions with automatic entity mapping. Since this detection targets Defender XDR tables (DeviceEvents, EmailEvents), a custom detection rule is exactly the recommended vehicle. Existing analytics rules keep running, and analytics rules still lead in a few areas (such as full MITRE technique coverage), but new detections on Defender data should be custom detections.

Why the other options are wrong:

  • A. Sentinel NRT analytics rules test events only after they're ingested and are limited to Sentinel data. Custom detections offer NRT streaming evaluation and are the recommended path for new rules on Defender data.
  • B. Scheduled analytics rules cannot query Defender XDR data natively (that data would first have to be ingested into the workspace, incurring ingestion cost) and do not provide native Defender XDR remediation actions.
  • C. Microsoft security rules only create Sentinel incidents from alerts generated by other Microsoft security products. They cannot express a custom KQL detection over DeviceEvents and EmailEvents.

Memory hook: New detection on Defender data in the unified portal = custom detection: cheaper (no re-ingestion), real-time, native XDR response actions.

Microsoft Learn: https://learn.microsoft.com/azure/sentinel/compare-analytics-rules-custom-detections

A security operations manager still runs Microsoft Sentinel exclusively in the Azure portal and asks how long that experience remains supported before the team must operate from the Microsoft Defender portal. What should you tell them?

Correct answer: B. After March 31, 2027, Microsoft Sentinel will no longer be supported in the Azure portal and will be available only in the Microsoft Defender portal.

Microsoft's published retirement timeline states that after March 31, 2027, Microsoft Sentinel will no longer be supported in the Azure portal and will be available only in the Microsoft Defender portal. Microsoft Sentinel is generally available in the Defender portal, including for customers without Defender XDR or an E5 license, and Microsoft recommends that Azure-portal customers start planning their transition now. Teams still operating from the Azure portal should treat this as a hard deadline for moving their SOC workflows.

Why the other options are wrong:

  • A. July 2025 is when new customers onboarding their first Sentinel workspace (with subscription Owner or User Access Administrator permissions, and not Lighthouse-delegated) began being automatically onboarded to the Defender portal. It was not a retirement or forced migration of existing Azure-portal workspaces.
  • C. There is no indefinite grandfathering for older workspaces. All customers using Sentinel in the Azure portal will be redirected to the Defender portal after the retirement date.
  • D. Log Analytics retention governs how long data is kept, not portal support. The retirement is a fixed calendar date for the whole service, unrelated to any workspace's retention settings.

Memory hook: March 31, 2027: Azure portal Sentinel goes dark. The Defender portal is the only home after that.

Microsoft Learn: https://learn.microsoft.com/azure/sentinel/overview#microsoft-sentinel-in-the-azure-portal-retirement-timeline

During an incident investigation, Microsoft Defender XDR automatically contained several user accounts and isolated two devices without analyst intervention. The incident carries the 'Attack Disruption' tag. Which feature triggered these containment actions?

Correct answer: D. Automatic attack disruption in Microsoft Defender XDR

Automatic attack disruption in Microsoft Defender XDR correlates signals from endpoints, identities, email, and SaaS applications to identify active human-operated attacks (such as ransomware and business email compromise) with high confidence and automatically contains compromised assets. Disrupted incidents are tagged with 'Attack Disruption' and the specific threat type. Actions include containing devices and disabling user accounts.

Why the other options are wrong:

  • A. Microsoft Sentinel automation rules can trigger playbooks, but they do not produce the 'Attack Disruption' incident tag. Sentinel automation operates at the SIEM layer and calls Logic Apps, rather than performing XDR-native containment actions directly.
  • B. AIR (Automated Investigation and Response) is triggered by specific alerts and applies remediation actions based on investigation results. It does not tag incidents with 'Attack Disruption' and operates differently from the cross-workload automatic attack disruption capability.
  • C. Custom detection rules can trigger alerts and response actions but operate per-rule based on a specific query match. They do not produce the 'Attack Disruption' tag and do not correlate signals across the entire XDR suite to disrupt multi-stage attacks.

Memory hook: Attack Disruption tag = XDR's AI-driven automatic containment. No human needed, no playbook required.

Microsoft Learn: https://learn.microsoft.com/defender-xdr/automatic-attack-disruption

A threat hunting team uses case management in the Microsoft Defender portal to track a long-running phishing campaign that has generated roughly 250 related incidents. The team wants to link every incident to a single case so the whole campaign has one durable record. Which documented service limit forces a different design?

Correct answer: A. Each case supports a maximum of 100 linked incidents, so the campaign's 250 incidents must be split across multiple cases.

The Microsoft Sentinel service limits page documents the case management limits: 100,000 cases per tenant, 500 GB of attachments per tenant, and 100 linked incidents per case. Linking 250 incidents to one case exceeds the per-case incident cap, so the team must split the campaign across multiple cases (for example, by wave or by month) and use the case descriptions, tasks, or naming conventions to tie them together. Cases themselves are durable: they do not expire or auto-delete, and case IDs (starting at 1000) are never recycled, which is why archival is handled with custom statuses and filters rather than deletion.

Why the other options are wrong:

  • B. Cases do not auto-close or auto-purge. They persist until manually deleted (which requires typing 'delete' in a confirmation dialog); archival is managed with statuses and filters.
  • C. The tenant limit is 100,000 cases, not 1,000, and case IDs are never reused, so there is no ID recycling.
  • D. There is no status-based restriction on linking. The constraint on this scenario is the documented cap of 100 linked incidents per case.

Memory hook: Case limits: 100 incidents per case, 100,000 cases per tenant, 500 GB of attachments. The '100 per case' is the one that bites campaign tracking.

Microsoft Learn: https://learn.microsoft.com/azure/sentinel/sentinel-service-limits

While investigating in the incident graph, an analyst switches the associated-incidents view from This incident only to All associated incidents. What is the effect of this change?

Correct answer: A. It expands the graph to show related incidents and alerts for context only; it does not change grouping, correlation rules, merge logic, or the other incidents' separate ownership and lifecycle.

The All associated incidents view helps analysts see additional related incidents and alerts in the investigation graph for added context. It does not change incident grouping, correlation rules, or merge logic, and the associated incidents keep their own owner, status, and lifecycle until an actual merge occurs.

Why the other options are wrong:

  • B. It does not reassign alerts; associated incidents retain their own ownership.
  • C. It does not alter correlation rules or how future alerts are grouped.
  • D. The view is contextual only; it does not perform a merge.

Memory hook: 'All associated incidents' = look wider, change nothing (no merge, no reassignment).

Microsoft Learn: https://learn.microsoft.com/defender-xdr/alerts-incidents-correlation

Microsoft Defender for Endpoint (15 questions)

Go deeper on this topic in Microsoft Defender for Endpoint Field Guide.

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. 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. 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 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: https://learn.microsoft.com/defender-endpoint/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. 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 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. 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: https://learn.microsoft.com/defender-endpoint/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. Pending approval applies only to files that are NOT in temporary folders; Downloads is a temp folder, so no approval is required.
  • B. Automatic remediation of temp-folder files already occurs at the non-temp level; you don't need Full automation to act on Downloads.
  • C. 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: https://learn.microsoft.com/defender-endpoint/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. 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. 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 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: https://learn.microsoft.com/defender-endpoint/live-response

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. Non-blocked categories are audited (logged), not silently ignored, and disabling network protection is not how you allow a single site.
  • C. Non-blocked categories are not blocked by default; they are audited/allowed, and there is no "add to an allowed category" mechanism.
  • D. 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: https://learn.microsoft.com/defender-endpoint/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. 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. 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. 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: https://learn.microsoft.com/defender-endpoint/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. 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. '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 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: https://learn.microsoft.com/defender-endpoint/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. 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. 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. 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: https://learn.microsoft.com/defender-endpoint/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. 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. 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. 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: https://learn.microsoft.com/defender-endpoint/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. 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. 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. 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: https://learn.microsoft.com/defender-endpoint/attack-surface-reduction-rules-overview#file-and-folder-exclusions-for-asr-rules

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. 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. '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. 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: https://learn.microsoft.com/defender-endpoint/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. 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. A Sentinel watchlist is static reference data. It neither discovers devices nor performs any vulnerability assessment against them.
  • C. 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: https://learn.microsoft.com/defender-endpoint/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. 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. 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. 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: https://learn.microsoft.com/defender-endpoint/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' 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' 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' 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: https://learn.microsoft.com/defender-endpoint/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 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 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. '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: https://learn.microsoft.com/defender-endpoint/advanced-features

Microsoft Sentinel (16 questions)

Go deeper on this topic in Microsoft Sentinel Field Guide.

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. Disconnecting the XDR connector abandons XDR incident integration and isn't the recommended fix.
  • C. Bi-directional sync isn't the source of duplicate incidents; the legacy connector and incident rules are.
  • D. 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: https://learn.microsoft.com/azure/defender-for-cloud/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 inherit techniques (and sub-techniques) too, not just the tactic.
  • C. They inherit the query's specific mapping, not every technique under the tactic.
  • D. 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: https://learn.microsoft.com/azure/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. The AMA approach requires deploying and maintaining a log-forwarder VM/agent, which violates the 'no agent to maintain' requirement.
  • C. 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. 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: https://learn.microsoft.com/azure/sentinel/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.AnomalyScore ranges 0-1 and reflects holistic, batch-processed behavior across multiple events, not single-event triage.
  • C. IdentityInfo holds entity profile data such as Entra ID risk level, not the per-event UEBA priority score.
  • D. 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: https://learn.microsoft.com/azure/sentinel/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. Wrong - summary rules run on a recurring schedule defined by their frequency/binSize.
  • B. Wrong - summary results are stored in an Analytics-plan table and are fully queryable with KQL.
  • C. 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: https://learn.microsoft.com/azure/sentinel/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. Neither action filters the incident nor deletes the entity; the row selection simply opens a side panel.
  • C. There is a clear difference: the name navigates away, the row stays in the incident.
  • D. 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: https://learn.microsoft.com/azure/sentinel/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. 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 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. 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: https://learn.microsoft.com/azure/sentinel/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 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 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 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: https://learn.microsoft.com/azure/sentinel/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. Contributor includes all Responder rights and additionally allows creating and editing analytics rules, workbooks, and other configuration resources, which exceeds the stated requirement.
  • C. Reader can only view data and incidents. The analyst would not be able to update incident status, assign owners, or add comments.
  • D. 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: https://learn.microsoft.com/azure/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. Notebooks query Log Analytics but execute on Azure ML compute, and the Reader role alone is not sufficient to run them.
  • C. Azure Automation and the Logic Apps runtime are used for playbooks, not for running Sentinel notebooks.
  • D. 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: https://learn.microsoft.com/azure/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. The AML workspace and compute are unaffected by a kernel restart; recreating them is unnecessary.
  • C. State does not persist across a kernel restart; discarding in-memory state is the purpose of a restart.
  • D. 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: https://learn.microsoft.com/azure/sentinel/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 stores enriched behavioral events with the InvestigationPriority score, not peer rankings.
  • B. UserAccessAnalytics is not a Microsoft Sentinel UEBA table; it is a distractor.
  • C. 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: https://learn.microsoft.com/azure/sentinel/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. 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. 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. 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: https://learn.microsoft.com/azure/sentinel/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 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. ML Behavior Analytics rules detect anomalous SSH/RDP login behavior, not indicator-to-event matches.
  • C. 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: https://learn.microsoft.com/azure/sentinel/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. 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. 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. 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: https://learn.microsoft.com/en-us/azure/sentinel/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 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 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 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: https://learn.microsoft.com/azure/sentinel/automation/automate-responses-with-playbooks#prerequisites

Threat Hunting with KQL (15 questions)

Go deeper on this topic in Threat Hunting with KQL Field Guide.

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. 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. 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 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: https://learn.microsoft.com/kusto/query/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. union stacks rows from both tables without correlating them, so it cannot answer 'which flows match a suspicious IP.'
  • C. Placing the huge table on the left forces the larger dataset into the join's in-memory side, degrading performance.
  • D. 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: https://learn.microsoft.com/kusto/query/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. make_set() aggregates distinct values into a dynamic array during summarize; it doesn't split a string into columns.
  • C. 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 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: https://learn.microsoft.com/kusto/query/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 is the command line of the recorded process, not the parent's name.
  • C. FileName is the recorded/created process itself (powershell.exe), not its parent.
  • D. 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: https://learn.microsoft.com/defender-xdr/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 returns only the ID column, losing the fields needed to compute metrics.
  • B. arg_min returns the earliest (creation) record rather than the current state, which skews "mean time to" metrics.
  • C. 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: https://learn.microsoft.com/azure/sentinel/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. autocluster() finds common attribute-value patterns; it is not time-series decomposition and does not score seasonal anomalies.
  • B. 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) 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: https://learn.microsoft.com/kusto/query/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 runs a subquery per expanded element; the shown form aggregates rather than simply expanding, and it is more than is needed here.
  • B. make-list does the opposite: it packs multiple values into a single dynamic array.
  • D. 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: https://learn.microsoft.com/kusto/query/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. 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. 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. 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: https://learn.microsoft.com/kusto/query/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. 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. Reaching 100 percent of the tenant CPU allocation blocks queries with an 'exceeded processing resources' error. It does not return partial results.
  • D. 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: https://learn.microsoft.com/defender-xdr/advanced-hunting-overview#quotas-and-usage-parameters

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. 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. 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. 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: https://learn.microsoft.com/defender-xdr/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 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 contains alert metadata not raw ZAP events. IdentityQueryEvents captures Active Directory object queries (e.g., LDAP queries), not user logon events.
  • D. 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: https://learn.microsoft.com/en-us/microsoft-365/security/defender/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. 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. 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. 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: https://learn.microsoft.com/en-us/microsoft-365/security/defender/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 records process creation events. It could show the malware launching, but it does not capture the registry value the process wrote.
  • B. 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 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: https://learn.microsoft.com/defender-xdr/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. 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. 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. 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: https://learn.microsoft.com/en-us/microsoft-365/security/defender/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 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 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 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: https://learn.microsoft.com/azure/sentinel/hunts

Manage a security operations environment (13 questions)

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 is weighted 8 points - high, but below Enable MFA's 10.
  • C. Remediate vulnerabilities is weighted 6 points.
  • D. Apply system updates is weighted 6 points.

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

Microsoft Learn: https://learn.microsoft.com/azure/defender-for-cloud/secure-score-security-controls

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. The Log Analytics agent retired in August 2024; capabilities moved to Defender for Endpoint and agentless scanning.
  • C. No VPN is needed; the connector uses federated authentication plus Arc.
  • D. EC2 instances stay in AWS; Arc extends Azure management without migration.

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

Microsoft Learn: https://learn.microsoft.com/azure/defender-for-cloud/quickstart-onboard-aws

Which statement accurately describes how agentless machine scanning in Microsoft Defender for Cloud operates?

Correct answer: D. It runs on a nonconfigurable schedule once every 24 hours and scans only VMs that are powered on

Agentless machine scanning runs on a fixed, nonconfigurable schedule of once every 24 hours and only scans VMs that are running. It works by taking out-of-band disk snapshots and analyzing them, so it requires no installed agent and doesn't affect VM performance.

Why the other options are wrong:

  • A. It's agentless and snapshot-based, not a real-time installed agent.
  • B. The cadence is every 24 hours and isn't configurable.
  • C. Powered-off VMs aren't scanned; the process snapshots running VMs rather than mounting live disks.

Memory hook: Agentless = snapshot every 24h, running VMs only.

Microsoft Learn: https://learn.microsoft.com/azure/defender-for-cloud/enable-agentless-scanning-vms

A subscription has Defender CSPM enabled with 'Agentless scanning for machines' turned on, but Defender for Servers Plan 2 is not enabled. The team expects agentless malware detection on their Azure VMs but receives no malware alerts. Why?

Correct answer: D. Agentless malware scanning requires Defender for Servers Plan 2; Defender CSPM's agentless scanning covers vulnerabilities and secrets but not malware

Enabling agentless scanning under Defender CSPM provides agentless vulnerability assessment and secrets scanning, but agentless malware scanning is available only with Defender for Servers Plan 2. Without Plan 2, no malware scanning occurs even though agentless scanning is on.

Why the other options are wrong:

  • A. Agentless malware scanning supports Azure VMs (and AWS/GCP), so platform isn't the issue.
  • B. There's no such delay; Defender CSPM simply doesn't include malware scanning.
  • C. The Log Analytics agent was retired and isn't required; the missing element is Plan 2.

Memory hook: Agentless malware = Servers Plan 2 only; CSPM gives vulns + secrets.

Microsoft Learn: https://learn.microsoft.com/azure/defender-for-cloud/agentless-malware-scanning

Your team enabled the Defender for Containers plan on the subscription hosting your AKS clusters. You now need runtime threat detection for suspicious activity occurring inside running containers (for example, a reverse-shell process spawned in a pod). Which Defender for Containers component must be deployed to provide this?

Correct answer: B. The Defender sensor (a DaemonSet deployed to cluster nodes)

Workload/runtime threat detection for activity inside running containers relies on the Defender sensor, which runs as a DaemonSet on the cluster nodes and collects node and workload runtime telemetry. Control-plane detections and posture checks come from other components.

Why the other options are wrong:

  • A. Azure Policy for Kubernetes delivers posture assessments and admission control, not runtime detection.
  • C. Control plane audit logs (agentless) detect control-plane threats such as an exposed dashboard or sensitive role creation, not activity inside a running pod.
  • D. Kubernetes API access supports cluster inventory and configuration analysis, not runtime process detection.

Memory hook: Inside-the-pod runtime = Defender sensor; audit logs only watch the control plane.

Microsoft Learn: https://learn.microsoft.com/azure/defender-for-cloud/defender-for-containers-introduction

Two Defender for Cloud governance rules apply to the same recommendation on an Azure subscription: one rule is defined at the parent management group, the other at the subscription, each specifying a different owner and due date. How does Defender for Cloud resolve the conflict?

Correct answer: B. Rules on higher management scopes (management groups, AWS accounts, GCP organizations) take effect before rules on subscription/project scopes, and among applicable rules the highest-priority rule assigns the owner and due date

Conflicting governance rules are applied in scope order: rules on a management scope (Azure management groups, AWS accounts, GCP organizations) take effect before rules on subscription/project scopes. When multiple rules still apply, the rule with the highest priority assigns the owner and due date.

Why the other options are wrong:

  • A. A single winning rule assigns the owner and due date; owners aren't merged.
  • C. It's the reverse; the higher management scope takes effect first.
  • D. Resolution is based on scope order and priority, not creation date.

Memory hook: Governance conflicts: higher scope first, then highest priority wins.

Microsoft Learn: https://learn.microsoft.com/azure/defender-for-cloud/governance-rules

In the Just-in-time VM access page in Defender for Cloud, one of your VMs is listed under the Unsupported tab. Which condition explains why Defender for Cloud considers it unsupported for JIT?

Correct answer: B. It's a classic (non-Azure Resource Manager) VM, or it has neither a network security group nor an Azure Firewall configured

JIT requires an Azure Resource Manager-deployed VM that has a network security group and/or an Azure Firewall to enforce the port rules. VMs deployed with the classic model, or VMs missing both an NSG and a firewall, are marked Unsupported (as are VMs where the JIT solution is disabled in the security policy).

Why the other options are wrong:

  • A. JIT supports Linux (SSH 22) as well as Windows (RDP 3389, WinRM 5985/5986).
  • C. The 14-disk limit pertains to agentless machine scanning, not JIT eligibility.
  • D. Having a public IP doesn't make a VM unsupported for JIT.

Memory hook: No NSG/firewall or classic VM = JIT can't help it.

Microsoft Learn: https://learn.microsoft.com/azure/defender-for-cloud/enable-just-in-time-access

You plan to protect Azure VM management ports with just-in-time (JIT) VM access. Which Defender plan is required, and what is the default maximum access time window when JIT is enabled with default settings?

Correct answer: D. Defender for Servers Plan 2; 3 hours

Just-in-time VM access is a Defender for Servers Plan 2 feature. When you enable JIT with default settings (for example, RDP 3389 on Windows or SSH 22 on Linux), the default maximum allowed access window is 3 hours.

Why the other options are wrong:

  • A. JIT isn't part of Defender CSPM, and the default window is 3 hours.
  • B. Correct plan, but the default maximum window is 3 hours, not 24.
  • C. JIT is not included in Plan 1; it's a Plan 2 capability.

Memory hook: JIT = Servers Plan 2, 3-hour door.

Microsoft Learn: https://learn.microsoft.com/azure/defender-for-cloud/just-in-time-access-overview

During a security review, you're asked how Defender for Cloud authenticates to a connected AWS account. Which description is correct for the native AWS connector?

Correct answer: C. It uses OpenID Connect (OIDC) federation with a Microsoft-managed Microsoft Entra application, exchanging tokens for short-lived AWS STS credentials, without storing long-lived secrets

The native AWS connector establishes federated trust: onboarding creates an OIDC identity provider bound to a Microsoft-managed Entra application and IAM roles that Defender for Cloud assumes via web identity federation. It obtains short-lived credentials through AWS STS and stores no long-lived secrets.

Why the other options are wrong:

  • A. No long-lived IAM keys are stored; avoiding that is the whole point of the federated model.
  • B. There's no shared service-principal password; authentication is token-based and short-lived.
  • D. It uses a Microsoft-managed Entra app, not the customer's AD FS/SAML.

Memory hook: AWS connector = OIDC federation + short-lived STS, zero stored secrets.

Microsoft Learn: https://learn.microsoft.com/azure/defender-for-cloud/concept-authentication-architecture-aws

You remediated a Defender for Cloud recommendation that is tagged 'Preview' across all affected resources. Eight hours later, your subscription's classic secure score is unchanged. What is the most likely reason?

Correct answer: C. Preview recommendations are excluded from secure score calculations until they reach general availability

Recommendations flagged as Preview are deliberately not included in secure score calculations. They only begin contributing to the score once they reach general availability, so remediating a preview recommendation produces no score movement even though it should still be fixed.

Why the other options are wrong:

  • A. Partial credit is given per healthy resource (score per resource x number of healthy resources); you don't need every resource remediated to gain points.
  • B. Defender for Cloud recalculates each control roughly every 8 hours per subscription or connector, not monthly.
  • D. The opposite is true: only built-in MCSB recommendations affect the classic secure score, not custom standards.

Memory hook: Preview = no points until it goes GA.

Microsoft Learn: https://learn.microsoft.com/azure/defender-for-cloud/secure-score-security-controls

A SOC analyst is assigned the Security Reader role on an Azure subscription. They open the Regulatory compliance dashboard in Defender for Cloud, but the policy compliance data doesn't appear for them. Which change lets them view the policy compliance data while following least privilege?

Correct answer: B. Assign the Reader role on the subscription

The subscription Reader role includes access to Azure Policy compliance data; Security Reader, despite the name, does not. That's the trap: the security-flavored role sounds like it should cover a security dashboard, but the compliance data rides on Azure Policy permissions. Adding Reader is the least-privileged fix.

Why the other options are wrong:

  • A. Owner would work but grossly over-privileges the analyst; Reader is sufficient.
  • C. Compliance Administrator is a Microsoft Entra/Purview role and doesn't grant access to Azure Policy compliance data in Defender for Cloud.
  • D. Security Reader specifically does not have access to policy compliance data; waiting won't help.

Memory hook: For compliance data, Reader reads - Security Reader can't.

Microsoft Learn: https://learn.microsoft.com/azure/defender-for-cloud/regulatory-compliance-dashboard

You enable Microsoft Defender for Storage (per-storage-account plan) with on-upload malware scanning. To control cost, you want to confirm the default monthly scan cap and how to remove it. Which statement is correct?

Correct answer: B. The default cap is 10,000 GB scanned per storage account per month; set the cap to -1 to allow unlimited scanning

The capGBPerMonthPerStorageAccount setting defaults to 10,000 GB (10 TB) of uploaded blobs scanned per storage account per month. Assigning a value of -1 removes the cap and permits unlimited scanning. Once the cap is reached, scanning halts (within a ~20 GB confidence interval) until it resets at month end.

Why the other options are wrong:

  • A. The default is 10,000 GB, not 2,000.
  • C. The cap is applied per storage account (it can be set subscription-wide but still applies to each account), and -1, not deleting the property, sets unlimited.
  • D. The default is 10,000 GB, not 5,000, and -1 (not 0) means unlimited.

Memory hook: 10,000 GB per account per month; -1 = no cap.

Microsoft Learn: https://learn.microsoft.com/azure/defender-for-cloud/defender-for-storage-introduction

When you first enable Microsoft Defender for Cloud on an Azure subscription, which security/compliance standard is automatically assigned and immediately begins assessing your resources by default?

Correct answer: B. Microsoft cloud security benchmark (MCSB)

Enabling Defender for Cloud on an Azure subscription automatically applies the Microsoft cloud security benchmark (MCSB) standard, which begins assessing in-scope resources and drives the recommendations that feed the secure score. Other frameworks must be added manually.

Why the other options are wrong:

  • A. PCI DSS is an optional add-on standard and requires a paid Defender plan to add.
  • C. NIST SP 800-53 is an optional add-on standard, not the default.
  • D. CIS benchmarks are optional standards you add manually; they aren't applied by default.

Memory hook: New subscription: MCSB is the default yardstick.

Microsoft Learn: https://learn.microsoft.com/azure/defender-for-cloud/concept-regulatory-compliance-standards