Manage security and threats by using Microsoft Defender XDR practice questions

PowerShell

Why wrong: PowerShell is a general-purpose scripting and automation language, not a query language for threat hunting in Defender XDR. It can be used to automate interactions with Microsoft Graph or Defender XDR APIs, but the actual query syntax for advanced hunting and custom detections must be KQL executed within the Defender portal or via API calls. Writing a PowerShell script does not replace the need to compose a KQL query, and PowerShell's cmdlets, loops, and pipeline processing are fundamentally different from the declarative, tabular query semantics of KQL.

Splunk SPL

Why wrong: Splunk SPL is the proprietary Search Processing Language for Splunk's SIEM platform, not for Microsoft Defender XDR. Defender XDR's advanced hunting and custom detections rely exclusively on Kusto Query Language (KQL), which has a fundamentally different syntax and data schema. While Splunk can ingest Defender logs via connectors, that does not make SPL a native query language for Defender XDR, and SPL queries cannot be executed in its advanced hunting interface.

SQL

Why wrong: SQL (Structured Query Language) is the standard for relational database queries, but it is not supported in Microsoft Defender XDR's advanced hunting or custom detections. Although KQL resembles SQL in some functions, KQL uses a distinct, pipeline-based syntax (starting with a table name and using `|` operators) and is built on Azure Data Explorer rather than a traditional relational engine. Recognizing the schema differences is important: Defender XDR's data is organized in a flat, time-stamped structure designed for KQL, so attempting SQL statements such as `SELECT * FROM` will fail without a translator, which Microsoft does not provide.

Microsoft Defender for Office 365

Why wrong: Microsoft Defender for Office 365 is designed specifically for email and collaboration threats, including phishing campaigns, malicious attachments and links, business email compromise (BEC), and message disposition in Exchange Online, SharePoint, and OneDrive. It evaluates email metadata and message content, but it does not ingest Azure AD authentication events or analyze sign-in sessions, so it has no capability to detect user sign-in anomalies or credential abuse.

Microsoft Defender for Cloud Apps

Why wrong: Microsoft Defender for Cloud Apps is a cloud access security broker (CASB) that focuses on discovering sanctioned and unsanctioned cloud apps, controlling access via Conditional Access app control, and detecting data exfiltration or unusual file activity. While it can incorporate some user-related signals from connected apps, it does not perform behavioral analysis of sign-in authentication events or domain-joined identity activity; its core is app usage governance rather than user identity compromise detection.

Microsoft Defender for Endpoint

Why wrong: Microsoft Defender for Endpoint is an endpoint detection and response (EDR) agent that monitors devices for malware, exploits, suspicious processes, drivers, and other device-level attack indicators. Its telemetry is based on machine behavior (files, processes, network connections) and does not ingest Azure AD sign-in logs or examine user authentication events, making it blind to identity-based anomalies like impossible travel or unusual credential usage.

EmailEvents

Why wrong: Provides the delivery envelope and message-level metadata, such as sender/recipient, subject, and delivery status. It does not contain the actual URL string or any click/verdict data for links within the email body. So while it's necessary for context (e.g., who received the email), it alone cannot be the source for a URL click detection rule.

EmailAttachmentInfo

Why wrong: This table is designed for attachment-centric hunting, exposing fields like SHA256, filename, and file size, not the links embedded in the email body. Therefore, even if an attachment is benign, a malicious URL could go undetected. It cannot answer "did the user click the link?" because it never records click activity on URLs.

DeviceEvents

Why wrong: Even though user clicks happen on an endpoint (browser), DeviceEvents records process creations, registry modifications, and network connections at the OS level. It does not contain the email's original URL or the email-specific context like NetworkMessageId. Browsers might have network events, but they are not filtered to email URLs and lack the email/URL association that EmailUrlInfo provides.

Collect a forensic package before taking containment action

Why wrong: Collecting a forensic package before containment is appealing for evidence, but in a confirmed active ransomware incident, every minute spent acquiring memory and disk images can allow the malware to encrypt new shares, drop additional payloads, or spread via SMB. Forensic artifacts usually remain accessible after isolation, and you can collect from the isolated device or a disk image without losing key evidence. The priority is stopping the blast radius, not preserving the runtime state, because containment is reversible.

Run a full antivirus scan before isolating the device

Why wrong: Running a full antivirus scan prior to isolating the device is ineffective as a first response because the scan workload competes with the infected system for CPU and I/O while the ransomware keeps network access. Defender's real-time protection and cloud-delivered scanning can identify malware, but a full scan is time-consuming and does not terminate active network connections or block lateral movement. Isolation should happen first; the scan can then run safely with no further network propagation.

Wait for automated investigation to complete before responding

Why wrong: Waiting for the automated investigation to complete before acting assumes the orchestrated playbook has already activated containment, but automated response decisions can be throttled by policy, pending approval, or waiting on additional evidence. In a confirmed ransomware alert, the incident response playbook explicitly calls for manual containment; delaying manual isolation while awaiting automation leaves an active encryption loop free to compromise domain-joined workstations and file shares. Take immediate action, then allow automated investigation to continue collecting context.

DeviceProcessEvents

Why wrong: DeviceProcessEvents is the wrong source because it captures process creation, modification, and termination events—command lines, executable hashes, parent-process relationships—but has no network-specific fields such as RemoteIP, RemotePort, or destination protocol. A custom detection rule built on this table would only see the initiating process, not the endpoint it contacted, so it cannot evaluate destination-based indicators like a known malicious C2 IP address. Process events are useful for behavioral reconnaissance, but they do not replace the network connection logs stored in DeviceNetworkEvents.

EmailEvents

Why wrong: EmailEvents belongs to the Microsoft 365 Defender email schema and contains message-level metadata—sender, recipients, subject, delivery action, and threat verdicts from Defender for Office 365. It is completely unrelated to endpoint network stack events; there are no columns for local/remote endpoint ports or protocol, and email transport data is collected by Exchange Online, not by the device sensor. Therefore, using EmailEvents as the query table for a device-network custom detection rule would be semantically invalid and would not return any DeviceNetworkEvents-style rows.

IdentityLogonEvents

Why wrong: IdentityLogonEvents logs authentication attempts and sign-in activity for user identities across Azure AD and on-premises Active Directory, with fields such as AccountUpn, Application, LogonType, and the source IP of the authentication request. Although this table contains an IP address, that address identifies where the user's logon originated, not the remote destination a device connected to, and it lacks port/protocol data for endpoint connections. A custom detection rule seeking device network events would be querying an identity-based table, which cannot represent the outbound network conversations stored in DeviceNetworkEvents.

EmailEvents and DeviceNetworkEvents

Why wrong: DeviceNetworkEvents shows network connections but not the email receipt or which URLs were clicked.

EmailEvents and IdentityLogonEvents

Why wrong: IdentityLogonEvents tracks user sign-ins, not click events.

UrlClickEvents and DeviceNetworkEvents

Why wrong: Incorrect. Although UrlClickEvents and DeviceNetworkEvents can link a click to subsequent network activity, they lack the email receipt information (EmailEvents). The scenario requires detection starting from the phishing email delivery, which is missing in this pair.

DeviceProcessEvents

Why wrong: DeviceProcessEvents stores process creation and termination metadata—such as ProcessCommandLine, ParentProcessId, and FileName—but does not include the destination IP address, port, or protocol of any network communication. While you could join DeviceProcessEvents to DeviceNetworkEvents on ProcessId to relate a process to its connections, the process event itself is insufficient for a rule that must filter on remote network endpoints. Therefore this table alone cannot serve as the primary schema for a network-connection detection rule.

DeviceFileEvents

Why wrong: DeviceFileEvents tracks filesystem activity including file creation, modification, renaming, and deletion, with details like FolderPath, FileName, and SHA256 hash. It contains no network-specific attributes like remote IP addresses or port numbers, so it cannot identify network connections or the destination of a transfer. Although a detection rule for malware downloads might reference both file and network events, FileEvents on its own provides no endpoint network visibility.

IdentityLogonEvents

Why wrong: IdentityLogonEvents captures authentication and sign-in activity for identities—such as AccountUpn, LogonType, and TargetDeviceName—and belongs to the IdentityLogonEvents schema in Microsoft 365 Defender. It is unrelated to endpoint network connections and has no fields for remote IP, remote port, or network protocol. A custom detection that needs to flag outbound connections from a device, rather than a user logon, would be using the wrong data source.

DeviceProcessEvents | where ProcessId in (select ProcessId from DeviceNetworkEvents where RemoteIP == 'malicious IP' and Timestamp > ago(7d)) | project DeviceName, ProcessFileName, Timestamp

Why wrong: This query is incorrect because it uses a subquery to retrieve ProcessIds from DeviceNetworkEvents and then looks those up in DeviceProcessEvents, introducing unnecessary complexity and potential performance overhead. More critically, ProcessId is only unique per process on a given device at a given time; without also matching DeviceId and Timestamp, the IN clause can incorrectly match an unrelated process that happens to reuse the same ProcessId. The directly available InitiatingProcessFileName in DeviceNetworkEvents makes this extra step redundant.

DeviceNetworkEvents | where Timestamp > ago(7d) | join DeviceProcessEvents on ProcessId | where RemoteIP == 'malicious IP' | project DeviceName, ProcessFileName, Timestamp

Why wrong: Joining DeviceNetworkEvents to DeviceProcessEvents on ProcessId alone is flawed because the join key is not sufficiently unique across devices and time; without DeviceId and a time window, it can produce incorrect matches and duplicate rows. Additionally, DeviceNetworkEvents already contains the initiating process filename, so the join is architecturally unnecessary. This approach also requires filtering after the join, causing the query to process far more data than needed.

IdentityLogonEvents | where IPAddress == 'malicious IP' | project DeviceName, Timestamp

Why wrong: IdentityLogonEvents is designed to track user authentication and logon activities, not outbound network connections to an IP address, so it cannot answer a question about devices communicating with a malicious IP. The schema lacks a RemoteIP field and process information such as InitiatingProcessFileName; instead it uses IPAddress only for the logon source. DeviceNetworkEvents is the appropriate table because it records network-level events with the initiating process.

EmailEvents and EmailUrlInfo

Why wrong: EmailEvents does not contain click information; EmailUrlInfo has click data but joining only those two does not relate to the device network connection.

EmailEvents and DeviceNetworkEvents

Why wrong: Joining EmailEvents with DeviceNetworkEvents does not reveal which specific URL was clicked. EmailEvents lacks the URL detail needed to correlate with device network activity. The correct join requires EmailUrlInfo to supply the URL from the email.

EmailAttachmentInfo and DeviceProcessEvents

Why wrong: EmailAttachmentInfo is for file attachments, not URLs, and DeviceProcessEvents does not capture network connections to URLs.

DeviceProcessEvents

Why wrong: DeviceProcessEvents contains process creation and termination events, capturing the command line, image path, parent process, and user account for each newly launched process. While this table is useful for understanding what was executed on a device, it does not include any network-specific columns such as remote IP, port, or connection state, so it cannot tell you what network connection a process made. Even if you find the process name in this table, you would have to separately join to network events to see its outbound activity.

DeviceEvents

Why wrong: DeviceEvents is a general-purpose Advanced Hunting table that holds a heterogeneous mix of security events, including file creations, process injections, and other system-level telemetry, but it lacks the standardized network connection schema that DeviceNetworkEvents provides (RemoteIP, RemotePort, direction, etc.). Some network-related events might appear in DeviceEvents, but they are not consistently structured for querying by initiating process and endpoint, making this table unreliable for the analyst need. Additionally, many network connection events are only available in DeviceNetworkEvents, not duplicated into DeviceEvents.

DeviceRegistryEvents

Why wrong: DeviceRegistryEvents specifically tracks modifications to the Windows registry, including the registry key path, value name, and the process that performed the change, such as write operations to Run keys or service configurations. This table contains no network connection data whatsoever — no remote IPs, ports, or protocols — and its process information is tied to registry access, not to network communications. An analyst querying this table would see only hive activity and would find nothing related to the process network behavior.

Advanced Hunting

Why wrong: Advanced Hunting is a security analytics tool in Microsoft 365 Defender that lets you query raw event data using KQL to proactively hunt for threats across endpoints, email, and identities. It is entirely reactive and investigative—it does not generate or send phishing messages, track user click-through, or deliver any awareness training. Thus, while useful for detecting compromise, it cannot simulate attacks or measure user susceptibility, making it the wrong choice here.

Automated Investigation and Response

Why wrong: Automated Investigation and Response (AIR) is a set of playbooks in Microsoft 365 Defender that automatically investigate active alerts, contain compromised accounts, and remediate threats like malware or phishing emails. It operates on real, ongoing incidents and executes remediation actions on devices and mailboxes, not on user behavior or training. Since it reacts to actual attacks rather than simulating them or measuring user awareness, it is not suitable for this scenario.

Threat Analytics

Why wrong: Threat Analytics is a reporting and intelligence feature in Microsoft 365 Defender that provides detailed assessments of active threat actors, attack techniques, and recommended mitigations based on global and organizational telemetry. It serves as an informational source for defenders, offering insights into campaigns and vulnerabilities, but it lacks any interactive simulation or training capability. It cannot create phishing attacks or gauge user performance, so it does not meet the stated requirement.

Threat & Vulnerability Management

Why wrong: Threat & Vulnerability Management (TVM) in Microsoft Defender Vulnerability Management is designed to discover, assess, and prioritize software vulnerabilities and security misconfigurations across endpoints. It provides risk-based ranking and remediation recommendations, but it does not enforce real-time execution controls. Because it does not inspect or block child process creation from Office applications, it cannot prevent macro-spawned malicious processes.

Web Protection

Why wrong: Web Protection in Microsoft Defender for Endpoint protects users from malicious websites by using SmartScreen and custom URL indicators to block unsafe browsing. It operates at the HTTP/HTTPS layer, preventing access to phishing sites or drive-by download hosts. However, it has no visibility into local process creation: when an Office macro spawns a child process, no URL is involved, so Web Protection cannot intercept that activity.

Network Protection

Why wrong: Network Protection is a Defender for Endpoint feature that uses the Windows Filtering Platform to block outbound connections to malicious IP addresses, domains, and URLs. It is effective at stopping command-and-control traffic or remote payload retrieval after an infection, but it does not control local process execution. A macro can create a malicious child process entirely offline before any network connection is attempted, so Network Protection is unable to block the initial process spawn.

EmailPostDeliveryEvents and DeviceNetworkEvents [CORRECT]

Why wrong: Incorrect. EmailPostDeliveryEvents does capture link clicks, but DeviceNetworkEvents logs network connections, not the click event. Reliable correlation requires DeviceEvents.

EmailUrlInfo and DeviceProcessEvents [wrong]

Why wrong: Incorrect. EmailUrlInfo contains URLs in emails, but DeviceProcessEvents logs process creation, not link clicks.

EmailEvents and DeviceLogonEvents [wrong]

Why wrong: Incorrect. DeviceLogonEvents tracks logon events, not link clicks.

B: DeviceEvents and DeviceFileEvents

Why wrong: Incorrect. DeviceEvents is a generic table that may not include detailed process creation data, and DeviceFileEvents deals with file events, not network connections.

C: IdentityLogonEvents and DeviceProcessEvents

Why wrong: Incorrect. IdentityLogonEvents records logon events, and DeviceProcessEvents records process creation. This join does not include network connections, so it cannot fulfill the requirement of identifying network connections made by processes.

D: EmailEvents and DeviceNetworkEvents

Why wrong: Incorrect. EmailEvents tracks email activity, and DeviceNetworkEvents tracks network connections. This join does not include process creation data, so it cannot link processes to network connections.

DeviceProcessEvents

Why wrong: DeviceProcessEvents logs process creation and invocation events, such as executable names, command lines, and parent-child process relationships. It does not contain fields for network source or destination IP addresses or ports, so it cannot be directly queried to detect connections to a specific suspicious IP. While you might use it to identify a process that later makes a network connection, that requires joining with a network event table, making it unsuitable as the sole data source for this custom detection rule.

EmailEvents

Why wrong: EmailEvents captures email metadata and delivery details, including sender and recipient addresses, subject, and attachment information, but it does not record device-level network connections to arbitrary IP addresses. While email headers may contain an originating IP address, that is a property of the message transport, not the outbound TCP/IP connection from a monitored device. Therefore, this table cannot answer the question of which devices on your network are connecting to a given IP and is irrelevant for a device network connection detection rule.

AlertEvidence

Why wrong: AlertEvidence contains entities and contextual data associated with existing security alerts, such as file paths, users, IP addresses, and process names that were involved in an alert. It is populated only after an alert is generated, and its records are snapshots of evidence rather than a continuous, raw event stream of network connections. A custom detection rule requires a schema with one row per network event, so using AlertEvidence would fail to detect new connections in real time and would not provide the granular per-connection data needed for IP-based detection.

EmailEvents and DeviceProcessEvents

Why wrong: Incorrect. DeviceProcessEvents records process creation events, not network connections. It cannot be used to detect the network connection to a malicious IP.

EmailAttachmentInfo and DeviceRegistryEvents

Why wrong: Incorrect. EmailAttachmentInfo lists attachments in emails but does not record delivery status or network events. DeviceRegistryEvents records registry changes, not network connections.

Create a custom detection rule that triggers on high-severity alerts and uses an automated action.

Why wrong: Custom detection rules are distinct from built-in AIR playbooks; they generate alerts and can trigger a configured response action, but they do not alter the device group's automation level. Even if a custom rule attempts an isolation, the AIR automation level still governs whether that action is executed automatically or queued for approval. Thus, creating such a rule does not configure AIR to isolate high-severity alerts without manual approval.

Configure the device isolation action to require approval in the automation level settings.

Why wrong: Configuring device isolation to require approval places the action in a 'Semi' automation state, meaning the playbook pauses and awaits an analyst's approval before isolation proceeds. This directly contradicts the requirement of automatic execution for high-severity alerts, because the device will remain unisolated until someone manually confirms the action in the investigation queue.

Enable automatic remediation only for medium severity and above.

Why wrong: AIR automation levels are not selected by severity; there is no 'medium and above' automatic remediation option. The automation level is a single group-wide setting that applies to all alerts and actions across that device group, so even if high-severity is 'above medium,' the playbook still needs the Full automation level to automatically isolate. Selecting a partial or approval-based level would not guarantee automatic isolation for any severity.

EmailEvents and DeviceNetworkEvents

Why wrong: Incorrect. EmailEvents does not contain click event data; it records email delivery and metadata but not URL clicks. Therefore, joining it with DeviceNetworkEvents cannot capture the URL click event.

EmailAttachmentInfo and DeviceProcessEvents

Why wrong: Incorrect. EmailAttachmentInfo logs attachments, not URL clicks; DeviceProcessEvents logs process activities, not network connections.

EmailEvents and DeviceFileEvents

Why wrong: Incorrect. EmailEvents is about email events, but DeviceFileEvents logs file operations, not network connections.

DeviceProcessEvents

Why wrong: DeviceProcessEvents captures process creation and execution events, such as ProcessName, ProcessCommandLine, and parent/child relationships. While a malicious executable might eventually appear in this table when it runs, the question asks about finding the executable's file creation, which happens before execution. Relying on this table would miss droppers that create files but are never executed, and even when a process is recorded, the file's creation timestamp and full folder path may not be captured.

DeviceNetworkEvents

Why wrong: DeviceNetworkEvents is incorrect because it tracks outbound and inbound network connections, including SourceIP, DestinationIP, Ports, and URLs. It does not contain a FileName or FolderPath field, so it cannot be used to identify the malicious executable on disk. Network telemetry is useful for discovering command-and-control communication or data exfiltration, but it is not the right source for local file creation events.

DeviceRegistryEvents

Why wrong: DeviceRegistryEvents is not the right table because it records changes to registry keys and values, such as registry value modifications and data written to the Windows Registry. Although malware may create registry persistence entries that reference a file path, the table does not log the file creation itself, and the path is only present if the malware writes it as part of its persistence mechanism. The investigation requires locating the file, not the registry modification, so this table is insufficient.

App discovery policy

Why wrong: App discovery policies in Defender for Cloud Apps are designed to identify shadow IT by analyzing cloud traffic from endpoints and firewalls, then cataloging the apps in use and their risk scores. They provide visibility and governance actions like unsanctioning an app, but they do not intercept or inspect individual user actions such as file uploads. The discovery engine works off logs, not a live reverse proxy, so it cannot prevent a user from uploading a file; it only tells you that the app is being used. Therefore, it does not meet the requirement to block uploads.

Access policy

Why wrong: Access policies in Microsoft Defender for Cloud Apps enforce allow/block decisions at the point of sign-in or first access to a cloud app, using signals like user risk, device compliance, or location. They are implemented through Conditional Access App Control or built-in connectors and can deny a user entry entirely, but they cannot selectively block an activity like uploading while still letting the user browse or view content. Because access policies operate on a binary grant-or-deny model, they lack the granular, per-request inspection needed to stop an upload to unsanctioned cloud storage mid-session. That granular activity-level control is the job of a session policy, not an access policy.

Activity policy

Why wrong: Activity policies in Defender for Cloud Apps continuously monitor the log of activities collected from connected cloud apps and trigger alerts or automated actions when a rule condition is met, such as a user uploading a file to an unsanctioned app. These policies are reactive and API-driven: they evaluate activity metadata after the fact and can respond by suspending a user or flagging an incident, but they do not sit in the live data path to block the upload as it occurs. As a result, an activity policy might notify an admin about the upload after the fact, but it will not prevent the user from uploading the file in the first place. Real-time prevention requires a session policy's reverse proxy enforcement, not an activity policy.