Microsoft Security Operations Analyst SC-200 SC-200 Questions 901–975 | Page 13/18

901

MCQeasy

Your company uses Microsoft Defender for Office 365. You want to automatically take action on malicious emails that bypass the filter. What should you configure?

A.Enable anti-phishing policy.

B.Enable Safe Attachments policy.

C.Create a transport rule in Exchange.

D.Configure automated investigation and response (AIR) policies.

AnswerD

Automated investigation and response (AIR) policies in Defender for Office 365 use built-in playbooks triggered by security alerts to automatically investigate potentially malicious emails and take remediation actions. These actions include soft-deleting messages, quarantining suspicious content, blocking sender IPs or URLs, and disabling compromised accounts based on the investigation verdict. AIR is specifically designed for post-delivery response, making it the correct choice to automatically remediate a confirmed threat.

Why this answer

Automated investigation and response (AIR) policies in Microsoft Defender for Office 365 are specifically designed to automatically take action on malicious emails that bypass initial filters. AIR uses playbooks to investigate threats and automatically remediate, such as deleting or moving emails, without manual intervention. This directly addresses the requirement to automatically act on bypassed malicious emails.

Exam trap

The trap here is that candidates often confuse pre-delivery protection policies (like anti-phishing or Safe Attachments) with post-delivery automated response capabilities, assuming any security policy can automatically act on bypassed emails, but only AIR provides the automated investigation and remediation workflow for threats that have already evaded initial filters.

How to eliminate wrong answers

Option A is wrong because anti-phishing policies in Defender for Office 365 are preventive controls that block phishing attempts at the point of delivery, not reactive actions for emails that have already bypassed filters. Option B is wrong because Safe Attachments policies scan attachments in email in real-time to block malicious files, but they do not automatically take action on emails that have already bypassed the filter—they are a pre-delivery protection mechanism. Option C is wrong because transport rules in Exchange (mail flow rules) are used for custom routing, compliance, or filtering based on conditions, but they are not designed to automatically investigate and remediate malicious emails that bypassed Defender filters; they lack the automated investigation and response capabilities of AIR.

Full explanation →

902

MCQhard

A SOC analyst is creating a scheduled analytics rule in Microsoft Sentinel to detect sign-ins from IP addresses that are not in the organization's known allow list. The allow list is maintained in a custom watchlist named 'AllowedIPs'. The analyst wants the KQL query to efficiently filter out allowed IPs. Which KQL approach should the analyst use?

A.Use the 'lookup' operator to map IPs against the watchlist.

B.Use a 'let' statement to define a static list of allowed IPs.

C.Use the _GetWatchlist('AllowedIPs') function and filter with the '!in' operator.

D.Use the 'evaluate' operator with a python script.

AnswerC

Using `_GetWatchlist('AllowedIPs')` pulls the watchlist into the query, then `!in` excludes those addresses from the sign-in results. This directly satisfies the requirement to filter out allow-listed IPs efficiently, since the function reads the watchlist at query time without hard-coding values into the KQL.

Why this answer

The _GetWatchlist('AllowedIPs') function retrieves the watchlist content at query runtime, and combining it with the '!in' operator efficiently filters out sign-ins from IPs present in the watchlist. This approach is dynamic, meaning updates to the watchlist are automatically reflected without modifying the query, and it avoids hardcoding IPs or using inefficient row-by-row lookups.

Exam trap

The trap here is that candidates often confuse the 'lookup' operator with filtering, or assume a static 'let' statement is acceptable, failing to recognize that watchlists are designed for dynamic, centrally managed data that must be referenced at query runtime.

How to eliminate wrong answers

Option A is wrong because the 'lookup' operator is designed to extend a table with columns from another table based on matching keys, not to filter rows; using it here would be semantically incorrect and less efficient than a simple '!in' filter. Option B is wrong because a 'let' statement with a static list would require manual updates whenever the allow list changes, defeating the purpose of a dynamic watchlist and introducing maintenance overhead. Option D is wrong because the 'evaluate' operator with a python script is overkill for a simple IP filtering task, introduces unnecessary complexity and performance overhead, and is not the recommended pattern for watchlist-based filtering in Sentinel.

Full explanation →

903

MCQeasy

Your organization uses Microsoft Sentinel. You receive an incident for a potential malware outbreak. You need to quickly see which entities are involved (e.g., IPs, hosts, accounts). Where should you look?

A.Incident timeline

B.Comments section

C.Entities tab

D.Alerts tab

AnswerC

The Entities tab on the incident page aggregates and displays every entity that Microsoft Sentinel extracted from the alert data, such as user accounts, hostnames, IP addresses, URLs, and file hashes. Each entity is presented with its type, name, and a link to its full investigation details, allowing you to pivot directly to related incidents and actions. This dedicated, structured view is the appropriate place to identify all entities associated with the incident.

Why this answer

The Entities tab in a Microsoft Sentinel incident provides a consolidated view of all related entities such as IP addresses, hosts, user accounts, and other resources that were identified during the alert investigation. This allows you to quickly assess the scope of a potential malware outbreak by seeing which systems and identities are involved, without needing to navigate through raw alerts or timeline events.

Exam trap

The trap here is that candidates often confuse the Alerts tab (which shows raw alert details) with the Entities tab (which provides a consolidated, entity-focused view), leading them to select the Alerts tab when they need to quickly see all involved IPs, hosts, and accounts.

How to eliminate wrong answers

Option A is wrong because the Incident timeline shows the chronological sequence of events and activities related to the incident, but it does not aggregate or display the distinct entities (IPs, hosts, accounts) in a structured list. Option B is wrong because the Comments section is for manual notes and collaboration between analysts, not for automatically surfaced entity data. Option D is wrong because the Alerts tab lists the individual alerts that triggered the incident, but it does not extract or present the entities (such as IPs or hosts) in a unified, entity-centric view.

Full explanation →

904

MCQhard

Refer to the exhibit. You are reviewing an automation rule configuration in Microsoft Sentinel. Based on the JSON snippet, what will happen when a high-severity incident is created?

A.The rule will run a playbook when a high-severity incident is created

B.The rule will change the severity of the incident to Medium

C.The rule will assign the incident to the SOC manager

D.The rule will run the playbook when a new alert is created

AnswerA

This is the correct interpretation. The automation rule's trigger is set to 'When an incident is created,' and its condition filters for incidents with a severity equal to High. The only action defined is to run a specified playbook, so the rule's sole effect is to invoke that playbook for qualifying high-severity incidents.

Why this answer

The automation rule's trigger condition is set to 'When incident is created' and the condition filters for incidents with a severity of 'High'. When a high-severity incident is created, the rule will execute the associated playbook, which is a common use case for automated response in Microsoft Sentinel.

Exam trap

The trap here is that candidates may confuse the incident creation trigger with alert creation trigger, or assume that any rule with a condition automatically modifies the incident properties like severity or assignment, when in fact the rule only executes the defined actions (playbook) based on the condition.

How to eliminate wrong answers

Option B is wrong because the JSON snippet does not include any action to change the severity of the incident; it only triggers a playbook. Option C is wrong because there is no assignment action configured in the rule; the rule only runs a playbook, not reassigns ownership. Option D is wrong because the trigger is set to 'When incident is created', not 'When alert is created'; alerts are separate entities that can be correlated into incidents, but the rule specifically acts on incident creation.

Full explanation →

905

MCQeasy

You need to ensure that Microsoft Sentinel can access threat intelligence feeds from external sources like AlienVault OTX. Which data connector should you use?

A.Microsoft 365 Defender data connector

B.Microsoft Entra ID data connector

C.Amazon Web Services data connector

D.Threat Intelligence - TAXII data connector

AnswerD

The Threat Intelligence - TAXII data connector is the correct choice because it enables Sentinel to connect directly to TAXII 2.x servers and ingest STIX-formatted threat-intelligence indicators (e.g., IP addresses, URLs, file hashes). This connector supports feeds such as AlienVault OTX. Once ingested, the indicators are stored in the ThreatIntelligenceIndicator table and can be used by analytics rules to correlate against logs and trigger incidents.

Why this answer

The Threat Intelligence - TAXII data connector is the correct choice because it enables Microsoft Sentinel to ingest threat intelligence feeds from external sources that support the TAXII (Trusted Automated eXchange of Indicator Information) protocol, such as AlienVault OTX. This connector uses the STIX (Structured Threat Information Expression) standard to pull indicators of compromise (IOCs) like IP addresses, domains, and hashes directly into Sentinel for correlation and alerting.

Exam trap

The trap here is that candidates may confuse the 'Threat Intelligence - TAXII' connector with other data connectors that also deal with external data (like AWS or Microsoft 365), but only the TAXII connector is specifically designed to ingest structured threat intelligence feeds using the STIX/TAXII standard.

How to eliminate wrong answers

Option A is wrong because the Microsoft 365 Defender data connector ingests alerts and incidents from Microsoft 365 Defender (e.g., Defender for Endpoint, Defender for Office 365), not external threat intelligence feeds like AlienVault OTX. Option B is wrong because the Microsoft Entra ID data connector (formerly Azure AD) ingests sign-in logs and audit logs for identity-related security events, not threat intelligence feeds. Option C is wrong because the Amazon Web Services data connector ingests AWS CloudTrail and other AWS service logs, not external threat intelligence feeds.

Full explanation →

906

MCQmedium

During a threat hunt, you notice an anomalous number of failed logon attempts from a single IP address across multiple user accounts in Microsoft Entra ID sign-in logs. What is the most effective next step to determine if this is a brute-force attack?

A.Immediately block the IP address in the firewall

B.Reset passwords for all affected accounts

C.Disable the accounts that had failed logons

D.Correlate with successful logon events from the same IP for those accounts

AnswerD

Correlating successful logon events from the same IP against those accounts reveals whether the failed attempts culminated in compromise, distinguishing brute-force success from mere noise. This directly satisfies the stem's goal of determining whether the activity constitutes an actual brute-force attack rather than isolated failures.

Why this answer

Correlating failed logon attempts with successful logon events from the same IP address for the same accounts is the most effective next step. If a successful logon occurs shortly after failures, it strongly indicates a brute-force attack succeeded. This evidence justifies further action like blocking the IP or resetting the compromised account.

Option A (blocking IP immediately) may be premature without confirming success. Option B (resetting all affected passwords) is disruptive and may not address the root cause if no breach occurred. Option C (disabling accounts) could block legitimate users unnecessarily.

Full explanation →

907

MCQmedium

A SOC team wants to automatically run a playbook that retrieves threat intelligence details whenever a high-severity incident is created in Microsoft Sentinel. Which type of automation should they configure?

A.Automation rule with incident trigger

B.Automation rule with alert trigger

C.Playbook with manual trigger

D.Logic app with recurrence

AnswerA

Automation rules in Microsoft Sentinel are event-driven, and the incident trigger fires when a new incident is created. This trigger automatically invokes a linked playbook, passing the incident's properties and entities so the playbook can retrieve relevant data immediately. Because no human interaction is required, this is the correct mechanism to automatically run a playbook on incident creation.

Why this answer

Automation rules in Microsoft Sentinel can be configured with an incident trigger to automatically run playbooks when incidents are created or updated. Since the requirement is to run a playbook on high-severity incidents, an automation rule with an incident trigger allows you to filter by severity (e.g., High) and invoke the playbook without manual intervention.

Exam trap

The trap here is confusing the incident trigger with the alert trigger; candidates often select alert trigger because they think alerts are the primary event, but incidents are the higher-level object that SOC teams triage, and the question explicitly says 'incident is created'.

How to eliminate wrong answers

Option B is wrong because an automation rule with an alert trigger runs when an alert is generated, not when an incident is created; incidents aggregate alerts, so this would not meet the requirement to act on incident creation. Option C is wrong because a playbook with a manual trigger requires a human to run it, which contradicts the 'automatically' requirement. Option D is wrong because a Logic App with a recurrence trigger runs on a schedule (e.g., every hour) and cannot respond to real-time incident creation events in Sentinel.

Full explanation →

908

MCQhard

The KQL query above is used in a Microsoft Sentinel analytics rule. What is the purpose of this rule?

A.Detect when a disabled user account attempts to sign in.

B.Identify users who have been disabled due to inactivity.

C.Detect brute force attempts against disabled user accounts.

D.Monitor sign-in attempts from suspicious IP addresses.

AnswerC

This is correct because the query combines two key conditions: an account-level condition (the account is disabled) and an activity-level condition (a high count of sign-in attempts from the same source IP within a window). Repeated, high-frequency authentication attempts against disabled accounts are a hallmark of a brute-force attack, where an adversary tries many passwords against a known username without realizing the account has been deactivated. The query's aggregation by IP address and its threshold on the number of attempts filters out ordinary, low-volume failures and isolates a sustained, suspicious pattern.

Why this answer

The KQL query filters for sign-in events where the user account is disabled (e.g., StatusCode = 50057 or UserAccountControl flags indicate disabled) and then groups by source IP and user to count failed attempts over a short window. When the count exceeds a threshold, it signals a brute force attack targeting disabled accounts, which is a common post-exploitation or reconnaissance technique. Option C is correct because the rule specifically detects repeated authentication failures against disabled accounts, not just any sign-in attempt or inactivity.

Exam trap

The trap here is that candidates may choose Option A because they see 'disabled user account' and assume any sign-in attempt is detected, but the rule requires multiple attempts (brute force pattern), not a single event.

How to eliminate wrong answers

Option A is wrong because the rule does not detect a single sign-in attempt by a disabled user; it requires multiple failed attempts (brute force pattern) and does not trigger on a single event. Option B is wrong because the rule does not identify users disabled due to inactivity; it focuses on authentication attempts against already-disabled accounts, not the reason for disablement. Option D is wrong because the rule does not filter by suspicious IP addresses; it aggregates by source IP but does not use threat intelligence or reputation lists to classify IPs as suspicious.

Full explanation →

909

MCQhard

During an incident, you need to prevent a malicious process from running on all endpoints using Microsoft Defender for Endpoint. The process is not yet detected by antivirus signatures. Which action should you use?

A.Run antivirus scan

B.Add an indicator to block the process

C.Collect investigation package

D.Initiate Live Response

AnswerB

Adding an indicator of compromise (IoC) in Microsoft 365 Defender with the action 'Alert and block' or 'Block' immediately prevents the malicious process from running on any onboarded device. This indicator can be a file hash, signing certificate, or other process attribute, and the block is enforced by the Defender for Endpoint sensor in real time. Unlike scanning, this is a proactive, organization-wide prevention control that stops execution before or during launch.

Why this answer

Microsoft Defender for Endpoint allows you to create custom indicators of compromise (IoCs) to block or allow specific processes, files, or behaviors. Since the malicious process is not yet detected by antivirus signatures, adding an indicator to block the process file hash or certificate is the most direct and immediate action to prevent it from running on all endpoints.

Exam trap

The trap here is that candidates often confuse 'collect investigation package' or 'Live Response' as proactive blocking tools, when in fact they are post-incident forensic or single-endpoint actions, not scalable prevention mechanisms.

How to eliminate wrong answers

Option A is wrong because running an antivirus scan will only detect threats that are already in the antivirus signature database; since the process is not yet detected by signatures, a scan will not prevent it from running. Option C is wrong because collecting an investigation package gathers forensic data for analysis but does not actively block or prevent the malicious process from executing. Option D is wrong because initiating Live Response provides a remote shell for manual investigation and remediation on a single endpoint, but it is not designed to apply a block across all endpoints simultaneously.

Full explanation →

910

Multi-Selecthard

Which THREE of the following are best practices for performing threat hunting in Microsoft Defender XDR? (Select THREE.)

Select 3 answers

A.Focus only on alerts generated by automated detection rules.

B.Limit hunting to a single data source to reduce complexity.

C.Start with a hypothesis based on threat intelligence or recent incidents.

D.Use a combination of KQL queries and built-in hunting capabilities.

E.Leverage advanced hunting across devices, email, and identities.

AnswersC, D, E

A hypothesis grounded in threat intelligence or recent incidents directs hunting toward plausible adversary behaviour rather than unfocused querying. This satisfies the stem's best-practise criterion by making hunting purposeful and evidence-driven within Microsoft Defender XDR.

Why this answer

Option C is correct because effective threat hunting in Microsoft Defender XDR is hypothesis-driven: analysts should begin with a testable hypothesis derived from threat intelligence, known adversary TTPs, or lessons learned from recent incidents, then validate or refute it with data. Option D is correct because advanced hunting in Defender XDR relies on KQL (Kusto Query Language) queries against the unified schema, and combining custom KQL with built-in hunting capabilities (such as built-in queries, hunting graphs, and detection-rule creation from query results) gives both flexibility and efficiency. Option E is correct because Defender XDR's core strength is cross-domain correlation, so hunting should span the unified advanced hunting tables covering devices (DeviceEvents, DeviceProcessEvents), email (EmailEvents, EmailAttachmentInfo), and identities (IdentityLogonEvents, IdentityInfo) to surface multi-stage attacks that a single workload would miss.

Option A is not a best practice because relying only on automated detection alerts is reactive alert triage, not proactive hunting for threats that evade existing detections. Option B is not a best practice because restricting hunting to a single data source defeats the purpose of Defender XDR's unified, cross-domain telemetry and hides correlated attack chains.

Exam trap

SC-200 often tests the misconception that threat hunting equals reviewing automated alerts, when the exam expects candidates to recognize hunting as a proactive, hypothesis-driven, cross-domain activity.

Full explanation →

911

MCQeasy

A SOC analyst receives a Microsoft Defender for Cloud Apps alert about a mass download of files from a SharePoint site by a single user. The analyst needs to contain the incident. Which action should be taken first?

A.Increase the SharePoint download limit.

B.Notify the user's manager.

C.Suspend the user account in Microsoft Entra ID.

D.Run a malware scan on the downloaded files.

AnswerC

Suspending the user account in Microsoft Entra ID is the correct immediate containment action because it revokes the user's ability to sign in and access SharePoint, stopping all further downloads at once. Defender for Cloud Apps can trigger this governance action natively, integrating with Entra ID to disable the account. This aligns with incident response best practices, prioritizing containment of a likely data exfiltration before investigation.

Why this answer

Suspending the user account in Microsoft Entra ID immediately revokes all access tokens and prevents further authentication, stopping the mass download in progress. This is the fastest containment action because it disables the user's ability to access any Microsoft 365 resource, including SharePoint, without waiting for other processes like scanning or notifications.

Exam trap

The trap here is that candidates confuse containment with investigation or remediation, picking a post-incident step like malware scanning instead of the immediate account disablement action that stops the active threat.

How to eliminate wrong answers

Option A is wrong because increasing the SharePoint download limit would allow more data to be exfiltrated, worsening the incident. Option B is wrong because notifying the user's manager is a communication step that does not stop the ongoing data exfiltration. Option D is wrong because running a malware scan on already-downloaded files does not prevent further downloads and is a post-incident forensic step, not a containment action.

Full explanation →

912

MCQhard

An organization uses Microsoft Defender for Endpoint (MDE) to hunt for signs of credential dumping. An analyst runs a custom advanced hunting query that searches for processes accessing LSASS.exe. The query uses DeviceProcessEvents and DeviceFileEvents. The analyst notices that some known credential dumping tools are detected, but they want to find previously unknown variants. Which approach should the analyst take to improve the hunt?

A.Enable LSASS auditing via Windows Security Event Log.

B.Focus on file reputation data to exclude clean files.

C.Add more signature-based indicators to the query.

D.Look for anomalous LSASS access patterns using process lineage and call stacks.

AnswerD

Signature-based matching only catches known tools, so behavioural analysis is needed. Correlating process lineage and call stacks exposes anomalous LSASS access by novel variants, satisfying the requirement to detect previously unknown credential dumping tools rather than relying on known indicators.

Why this answer

To catch previously unknown credential-dumping variants, the analyst must move beyond signature and file-reputation indicators and instead hunt for behavioral anomalies in how processes access LSASS. Analyzing process lineage (which parent spawned the accessing process) and call stacks (which modules and functions are invoking LSASS) surfaces suspicious patterns like unsigned binaries, unusual parent-child relationships, or direct syscalls that signature-based detections miss. This is the essence of hypothesis-driven, behavior-based hunting in MDE advanced hunting.

Exam trap

SC-200 often tests the distinction between signature-based detection (which only catches known threats) and behavior-based hunting (which finds unknown variants) — candidates who default to 'add more indicators' fall for the signature trap.

How to eliminate wrong answers

Option A is wrong because enabling LSASS auditing via the Windows Security Event Log produces Event ID 4656/4663 entries but does not itself improve the KQL hunt in MDE and is noisy and limited in scope. Option B is wrong because file reputation data only helps exclude known-good files; it does nothing to reveal unknown malicious variants and can cause false negatives if a malicious file has a signed or reputable-looking hash. Option C is wrong because adding more signature-based indicators is a detection-engineering approach that only catches known tools and directly contradicts the goal of finding unknown variants.

Full explanation →

913

MCQmedium

A SOC analyst is investigating a potential brute-force attack on an Azure VM. The analyst has ingested Windows Security Events into Microsoft Sentinel. Which KQL query would count the number of failed logon attempts (EventID 4625) per user account in the last hour?

A.SecurityEvent | where EventID == 4625 | summarize Count = count() by Account | where TimeGenerated > ago(1h)

B.SecurityEvent | where EventID == 4625 and TimeGenerated > ago(1h) | summarize Count = count() by Account

C.SigninLogs | where ResultType != 0 | summarize Count = count() by UserPrincipalName | where TimeGenerated > ago(1h)

D.SecurityEvent | where EventID == 4625 | make-series Count = count() default=0 on TimeGenerated from ago(1h) to now() step 1h by Account

AnswerB

This query correctly applies the time filter alongside the EventID filter in the where clause, so only failed logon events (Event 4625) from the last hour are passed into the summarize operator. The summarize then groups these pre-filtered rows by Account, yielding the failure count for each account within the desired time window. This is a textbook example of proper KQL query ordering: filter first, aggregate second, and optionally post-filter aggregated results only if needed.

Why this answer

It filters for EventID 4625 (failed logon) and restricts the time range to the last hour before summarizing the count per Account. This ensures only relevant events are counted, and the aggregation is performed on the correct field (Account) from the SecurityEvent table, which contains Windows Security Events ingested into Sentinel.

Exam trap

The trap here is that candidates often apply the time filter after the summarize operator (as in Option A), which incorrectly counts all historical data before filtering, or they confuse the SecurityEvent table with SigninLogs (Option C), which is for Azure AD sign-ins and not Windows Security Events on a VM.

How to eliminate wrong answers

Option A is wrong because the time filter (where TimeGenerated > ago(1h)) is applied after the summarize operator, meaning the count includes all historical failed logons and only then filters the results, which does not limit the events to the last hour. Option C is wrong because it uses the SigninLogs table, which contains Azure AD sign-in logs, not Windows Security Events; EventID 4625 is specific to Windows Security Events, and the query also incorrectly filters by ResultType != 0 (which indicates failure in Azure AD sign-ins) but does not use the correct field (Account) for user accounts. Option D is wrong because it uses make-series to create a time series, which is overkill for a simple count and does not produce a straightforward count per user account; it also applies the time filter only in the make-series range, not as a filter on the events themselves, potentially including older data.

Full explanation →

914

MCQeasy

A company has enabled Microsoft Defender for Cloud on its Azure subscription. The security team wants to ensure that all existing virtual machines have a vulnerability assessment solution installed. Which Defender for Cloud feature can automatically deploy a vulnerability assessment agent to supported VMs?

A.Vulnerability assessment recommendations

B.Defender for Servers plan

C.Security policies

D.Workload protections

AnswerA

In Microsoft Defender for Cloud, vulnerability assessment recommendations (such as 'Machines should have a vulnerability assessment solution' or 'A vulnerability assessment solution should be enabled on your virtual machines') are the actionable items that include a 'Fix' (remediation) option. When you trigger remediation on one of these recommendations, Defender for Cloud automatically deploys the integrated vulnerability assessment agent—either Qualys or Microsoft Defender Vulnerability Management—onto the target VMs. This makes the recommendations the specific mechanism for agent deployment, not the plan itself.

Why this answer

The Vulnerability Assessment (VA) recommendations in Microsoft Defender for Cloud can automatically deploy a vulnerability assessment agent (such as the Qualys or Microsoft Defender Vulnerability Management agent) to supported Azure VMs. When a VM is found to be missing a VA solution, Defender for Cloud can enable the 'Auto-provision' setting for the VA recommendation, which triggers the agent installation without manual intervention. This directly meets the requirement to ensure all existing VMs have a vulnerability assessment solution installed.

Exam trap

The trap here is that candidates often confuse the 'Defender for Servers plan' (which enables the feature set) with the actual automated deployment mechanism, assuming the plan itself installs agents, when in fact the deployment is triggered by enabling the 'Auto-provision' setting on the specific vulnerability assessment recommendation.

How to eliminate wrong answers

Option B is wrong because the Defender for Servers plan enables advanced security capabilities (e.g., file integrity monitoring, just-in-time VM access, and adaptive application controls) but does not itself automatically deploy a vulnerability assessment agent; it only makes the VA recommendations available. Option C is wrong because security policies define the compliance rules and initiatives (e.g., Azure Policy) that govern resource configurations, but they do not directly deploy agents; they can enforce the VA recommendation but the deployment action is handled by the recommendation's auto-provision feature. Option D is wrong because workload protections refer to the set of threat detection alerts and security signals for workloads (e.g., SQL, storage, containers), not the automated deployment of vulnerability assessment agents to VMs.

Full explanation →

915

MCQeasy

Your Microsoft Sentinel workspace has a Microsoft 365 Defender connector configured. You notice that incidents are being created from Microsoft Defender for Office 365 alerts, but not from Microsoft Defender for Identity alerts. What should you check?

A.Enable the Microsoft Defender for Identity alert streaming in the connector configuration.

B.Verify that the Microsoft 365 Defender connector is connected.

C.Ensure you have licenses for Microsoft Defender for Identity.

D.Check the incident correlation rules in Microsoft Defender XDR.

AnswerA

The Microsoft 365 Defender connector in Microsoft Sentinel has a service-selection pane that allows you to choose which Defender signal sources to ingest, including Microsoft Defender for Identity alerts. If only Office 365 alerts are flowing, the most likely root cause is that the Defender for Identity alert stream was not toggled on in the connector's configuration. After enabling it, save the connector configuration and wait for new alerts to start appearing in the Sentinel workspace.

Why this answer

The Microsoft 365 Defender connector in Microsoft Sentinel requires explicit enablement of alert streaming for each Microsoft Defender service. By default, the connector may stream alerts from Defender for Office 365 but not from Defender for Identity unless the corresponding toggle is turned on in the connector configuration. Option A directly addresses this by instructing you to enable the Defender for Identity alert streaming, which resolves the missing incident creation.

Exam trap

The trap here is that candidates assume a working connector automatically streams all Defender alerts, but Microsoft deliberately tests whether you know that each workload's alert streaming must be individually enabled in the connector configuration.

How to eliminate wrong answers

Option B is wrong because the connector is already confirmed to be working (incidents are being created from Defender for Office 365), so the connection is not the issue. Option C is wrong because if you lacked licenses for Defender for Identity, you would not receive any alerts from that service at all, but the question implies the connector is configured and alerts are expected; the problem is specifically about streaming those alerts into Sentinel. Option D is wrong because incident correlation rules in Microsoft Defender XDR govern how alerts are grouped into incidents within the Defender portal, not how alerts are ingested into Sentinel; the issue is at the data ingestion layer, not correlation.

Full explanation →

916

MCQmedium

Your company uses Microsoft Defender for Cloud to monitor multi-cloud resources. You want to ensure that all critical security recommendations are automatically assigned to the appropriate team leads based on the resource's tags. Which feature should you configure?

A.Configure a regulatory compliance standard to send email notifications.

B.Create a workbook that lists recommendations and manually assign them.

C.Use the 'Assign ownership' feature in Microsoft Defender for Cloud to map tags to owners.

D.Create a governance rule that automatically applies a compliance standard.

AnswerC

The 'Assign ownership' feature in Microsoft Defender for Cloud lets you configure resource tag keys (for example, 'owner' or 'business-unit') and map the tag values to Azure AD users or groups, which then become recommendation owners. This creates a governance rule that automatically assigns every recommendation for resources with matching tags to the designated owner, optionally with a fix timeframe and escalation path. This is the native, purpose-built mechanism for distributing security recommendation ownership across teams, and it is the correct way to ensure each recommendation is acted upon.

Why this answer

The 'Assign ownership' feature in Microsoft Defender for Cloud allows you to map resource tags to specific owners (e.g., team leads) via an automated rule. When a critical security recommendation is generated for a resource with a matching tag, the recommendation is automatically assigned to the designated owner, ensuring accountability without manual intervention.

Exam trap

The trap here is confusing governance rules (which enforce compliance standards or auto-remediation) with the 'Assign ownership' feature, which specifically handles tag-based assignment of recommendations to users.

How to eliminate wrong answers

Option A is wrong because regulatory compliance standards are used to assess compliance against frameworks (e.g., CIS, NIST) and send email notifications for compliance drift, not to assign recommendations to owners based on tags. Option B is wrong because creating a workbook only provides a visual list of recommendations; it does not automate assignment to team leads based on tags. Option D is wrong because a governance rule that applies a compliance standard enforces compliance policies (e.g., auto-remediation), but it does not assign ownership of recommendations to specific users based on resource tags.

Full explanation →

917

MCQhard

A security analyst is configuring a playbook in Microsoft Sentinel to run automatically when a new incident of severity 'High' is created. The playbook should only run for incidents that are not already assigned to an analyst. How can the analyst configure this automation?

A.Create an automation rule with a condition on 'Owner' field equals 'Unassigned'

B.Use a playbook trigger 'When a Microsoft Sentinel incident is created' and add a condition in the playbook

C.Configure a watchlist to filter incidents

D.Use a Logic Apps trigger for all incidents and check owner within the playbook

AnswerA

Automation rules in Microsoft Sentinel are the recommended way to conditionally invoke playbooks based on incident properties at creation or update. Setting a condition on the Owner field equals 'Unassigned' ensures the playbook runs only for incidents that are both unassigned and (with an additional severity condition) High severity, avoiding unnecessary executions. This pre-filtering at the platform level reduces resource consumption and is more efficient than inside the playbook.

Why this answer

Microsoft Sentinel automation rules can evaluate incident properties at creation time, including the 'Owner' field. By setting a condition that 'Owner' equals 'Unassigned', the rule triggers the playbook only for high-severity incidents that have not yet been assigned to an analyst, meeting the requirement without requiring custom logic inside the playbook.

Exam trap

The trap here is that candidates often think they must embed filtering logic inside the playbook (Option B or D), overlooking that automation rules provide a native, efficient pre-filtering mechanism that avoids unnecessary playbook executions.

How to eliminate wrong answers

Option B is wrong because using a playbook trigger 'When a Microsoft Sentinel incident is created' and adding a condition inside the playbook would cause the playbook to run for every new incident, even those already assigned, wasting resources and potentially causing unintended actions before the condition is evaluated. Option C is wrong because watchlists are used for correlation, enrichment, or filtering of data during queries and analytics rules, not for controlling automation rule triggers based on incident ownership. Option D is wrong because using a Logic Apps trigger for all incidents and checking the owner within the playbook is inefficient and redundant; automation rules are the correct and intended mechanism to filter incidents before invoking a playbook, and this approach would still invoke the playbook for every incident, consuming unnecessary compute and API calls.

Full explanation →

918

MCQeasy

You are a threat hunter and you want to identify potential lateral movement in your environment. Which Microsoft Defender XDR hunting table would you query to find network connections from a compromised workstation to other internal devices?

A.DeviceProcessEvents

B.DeviceLogonEvents

C.DeviceNetworkEvents

D.DeviceFileEvents

AnswerC

DeviceNetworkEvents records inbound and outbound network connections with remote IP addresses, ports and initiating processes, so querying it reveals a compromised workstation connecting to other internal devices — exactly the lateral movement indicator the hunt requires.

Why this answer

DeviceNetworkEvents is the correct table because it records network connection telemetry from Defender for Endpoint sensors, including outbound and inbound connections, remote IPs, ports, and the initiating process. Lateral movement typically manifests as SMB, RDP, WinRM, or other internal connections from a compromised host to peer systems, all of which appear in this table. Querying DeviceNetworkEvents lets you correlate the initiating process with remote endpoints to spot anomalous east-west traffic.

The other tables capture process, logon, or file activity, not raw network connection details.

Exam trap

SC-200 often tests whether candidates can distinguish between endpoint telemetry tables by their core data type, and the trap is confusing process execution (DeviceProcessEvents) with network connection activity (DeviceNetworkEvents) when hunting for lateral movement.

How to eliminate wrong answers

Option A is wrong because DeviceProcessEvents records process creation, command-line arguments, and parent-child process relationships, but it does not contain remote IP addresses or network connection metadata needed to identify lateral movement targets. Option B is wrong because DeviceLogonEvents captures authentication events (successful and failed logons, logon types, and account details) but lacks the network connection context such as remote IPs and ports that indicate lateral movement paths. Option D is wrong because DeviceFileEvents tracks file creation, modification, and deletion activity, which is unrelated to identifying network connections between internal devices.

Full explanation →

919

MCQmedium

You have detected a suspicious PowerShell command running on several workstations. The command appears to be downloading a payload from a known malicious URL. What is the most effective immediate response using Microsoft Defender for Endpoint?

A.Add the URL to the custom threat indicator list in Microsoft Defender for Endpoint.

B.Quarantine the affected workstations.

C.Enable attack surface reduction rule to block PowerShell scripts.

D.Initiate a Live Response session to investigate each workstation.

AnswerA

Adding the URL as a custom threat indicator with the action 'Alert and block' creates an immediate, environment-wide deny for that address. Defender for Endpoint enforces URL/domain indicators through Windows Defender SmartScreen and network protection, so any onboarded endpoint attempting to reach the URL is blocked before the response, not after. This targeted action stops further downloads without broad disruption to legitimate PowerShell or other workloads.

Why this answer

Adding the URL to the custom threat indicator list in Microsoft Defender for Endpoint is the most effective immediate response because it creates a block indicator that applies to all endpoints in the organization. This action prevents any further downloads from that malicious URL across all workstations, stopping the attack in its tracks without disrupting user productivity or requiring manual intervention on each machine.

Exam trap

The trap here is that candidates often choose a reactive, manual investigation step (like Live Response) or a broad configuration change (like ASR rules) instead of recognizing that a custom indicator provides an immediate, automated, and organization-wide block that stops the attack at the network layer.

How to eliminate wrong answers

Option B is wrong because quarantining the affected workstations is a reactive, disruptive measure that removes devices from the network, potentially halting business operations, and does not prevent the same attack from occurring on other workstations that have not yet executed the command. Option C is wrong because enabling an attack surface reduction rule to block PowerShell scripts is a broad, preventative configuration change that would require testing and could break legitimate scripts; it is not an immediate response to an active threat. Option D is wrong because initiating a Live Response session to investigate each workstation is a time-consuming, manual forensic step that does not provide an immediate, organization-wide block of the malicious URL, leaving other workstations vulnerable during the investigation.

Full explanation →

920

MCQmedium

Your organization has Microsoft Defender XDR enabled. An incident is generated for a user who clicked a phishing link in an email. The analyst needs to automatically disable the user's mailbox for suspicious activity. Which automated action should the analyst configure in a Microsoft Sentinel automation rule?

A.Run a playbook that deletes the phishing email from the user's inbox.

B.Configure an automation rule to block the sender IP address in Defender for Cloud Apps.

C.Run a playbook that resets the user's password.

D.Run a playbook that uses the Microsoft 365 Defender connector to disable the mailbox.

AnswerD

Running a playbook that uses the Microsoft 365 Defender connector is the correct approach because this connector exposes a 'Disable mailbox' remediation action designed for incident response scenarios. When triggered from a Microsoft Defender XDR incident, the playbook can execute this action directly against the affected user's mailbox in Exchange Online, immediately preventing further access and exfiltration. This precisely satisfies the requirement to disable the mailbox as a containment step.

Why this answer

The goal is to disable the user's mailbox, which is a Microsoft 365 Exchange Online action. A Microsoft Sentinel automation rule can trigger a playbook that uses the Microsoft 365 Defender connector to execute the 'Disable mailbox' action directly against Exchange Online, effectively suspending the user's ability to send or receive email. This aligns with the requirement to automatically respond to a phishing incident by disabling the compromised mailbox.

Exam trap

The trap here is that candidates confuse 'disabling the mailbox' with other remediation actions like password reset or email deletion, failing to recognize that only a playbook with the Microsoft 365 Defender connector can directly execute the mailbox disablement action in Exchange Online.

How to eliminate wrong answers

Option A is wrong because deleting the phishing email from the user's inbox does not disable the mailbox; the user could still access other emails or be compromised further. Option B is wrong because blocking the sender IP address in Defender for Cloud Apps is a network-level action that does not affect the user's mailbox state; it also does not address the compromised user account. Option C is wrong because resetting the user's password does not disable the mailbox; the user could still access email via cached credentials or other means until the password change propagates, and it does not prevent mailbox access if the session token is still valid.

Full explanation →

921

MCQeasy

During a threat hunt in Microsoft Defender XDR, you notice repeated failed logon attempts from an IP address that belongs to a known anonymizer service. What is the first action you should take?

A.Block the IP address in Microsoft Defender for Cloud Apps.

B.Create an analytics rule in Microsoft Sentinel to alert on all anonymizer IP addresses.

C.Initiate an investigation by reviewing the impacted user accounts and endpoints for signs of compromise.

D.Report the IP to the Microsoft Sentinel Threat Intelligence team.

AnswerC

The correct initial action in a threat hunt is to pivot from the observed indicator—the anonymizer IP—to the associated entities, specifically the impacted user accounts and endpoints, and examine authentication logs, behavioral anomalies, and device telemetry for evidence of unauthorized access or lateral movement. Microsoft Defender XDR provides integrated signals such as IdentityLogonEvents, DeviceNetworkEvents, and alerts that enable this scoping, aligning with the MITRE ATT&CK technique of discovering the full attack surface. Only after determining whether accounts are compromised and what systems are affected can you make informed decisions on containment and remediation.

Why this answer

In a threat hunt, the discovery of failed logons from an anonymizer IP is a potential indicator of compromise (IoC) that requires immediate validation. The first action should be to investigate the impacted user accounts and endpoints to determine if any logons succeeded or if there are other signs of malicious activity. This aligns with the incident response process of identification and scoping before taking containment or remediation actions.

Blocking or creating rules without understanding the scope could disrupt legitimate activity or miss broader compromise.

Exam trap

SC-200 often tests the order of incident response steps, and candidates may confuse containment with investigation, picking a blocking action before verifying the threat.

How to eliminate wrong answers

Option A is wrong because blocking the IP in Defender for Cloud Apps is a containment action that should follow investigation, not precede it; it may also be ineffective if the attacker uses multiple IPs. Option B is wrong because creating an analytics rule is a proactive detection measure, not an immediate response to a specific potential incident; it doesn't address the current threat. Option D is wrong because reporting the IP to Microsoft's threat intelligence team is not a standard first response action and does not help mitigate the immediate risk to the organization.

Full explanation →

922

Multi-Selectmedium

Which TWO actions can you perform using Microsoft Sentinel automation rules?

Select 2 answers

A.Create a new analytics rule based on an incident.

B.Assign an incident to a specific analyst.

C.Modify the data connector's polling interval.

D.Run a playbook automatically when an incident is created.

E.Automatically create an incident from a log event.

AnswersB, D

Assigning an incident to a specific analyst is a supported automation rule action, where you can set the owner to a particular Microsoft Entra ID user or group. This action is frequently used to implement dynamic triage and routing, such as sending all high-severity incidents to a senior threat hunter or specific incident responder as soon as the incident is created. It exists as a first-class action in the automation rule configuration pane.

Why this answer

Microsoft Sentinel automation rules can directly assign an incident to a specific analyst using the 'Assign owner' action. This allows security operations teams to automatically route incidents to the appropriate personnel based on criteria such as severity, tactic, or entity, improving response efficiency.

Exam trap

Microsoft often tests the distinction between automation rules (which act on incidents/alerts) and analytics rules (which generate incidents from log data), causing candidates to confuse the scope of automation rule actions.

Full explanation →

923

MCQmedium

Refer to the exhibit. You are reviewing a KQL query used in a Microsoft Sentinel scheduled analytics rule. What is the primary purpose of this query?

A.To investigate a new type of attack pattern

B.To identify which accounts are associated with the most incidents

C.To find accounts that have generated false positive alerts

D.To detect accounts that have triggered a high number of suspicious process alerts within 7 days

AnswerD

This query correctly identifies accounts that fire a high number of 'suspicious process' alerts within a 7-day lookback. It uses a filter for that alert name, summarize by AccountName to count occurrences, and then sets a threshold of more than 5 alerts—surfacing users whose process execution behavior is repeatedly flagged as suspicious. The time window and threshold are both configurable, thereby allowing defenders to tune the query to their environment's baseline noise.

Why this answer

The query uses `summarize` with `dcount(EventID)` to count distinct process creation events per account, then filters for accounts with a count greater than 10 using `where EventCount > 10`. The `where TimeGenerated > ago(7d)` restricts the time window to the last 7 days. This pattern is designed to detect accounts that have triggered a high number of suspicious process alerts (EventID 4688) within a week, making D correct.

Exam trap

The trap here is that candidates may confuse counting process alerts (EventID 4688) with counting incidents or false positives, leading them to select options B or C without recognizing the query's focus on raw event aggregation over a specific time window.

How to eliminate wrong answers

Option A is wrong because the query does not analyze new attack patterns; it simply aggregates known process creation events by account without comparing to baselines or identifying novel behaviors. Option B is wrong because the query does not correlate accounts with incidents; it counts process alerts, not incidents, and incidents are not referenced in the query. Option C is wrong because the query does not evaluate alert accuracy or false positives; it only counts raw process creation events without any mechanism to distinguish true positives from false positives.

Full explanation →

924

MCQmedium

A cloud security team uses Microsoft Defender for Cloud with Defender for Servers enabled. They want to ensure that all Azure virtual machines have automatic provisioning of the Log Analytics agent (Azure Monitor Agent) turned on. Where should this configuration be set to cover existing and future VMs?

A.In Microsoft Defender for Cloud > Environment settings > Select subscription > Settings & monitoring > Log Analytics agent for Azure VMs > Set to 'On'

B.In Azure Policy > Assign a policy that deploys the Log Analytics agent to VMs

C.In Microsoft Defender for Cloud > Security policy > Data collection

D.In Azure virtual machine blade > Auto-provisioning

AnswerA

This is the correct path because Microsoft Defender for Cloud's integrated automatic provisioning is managed under Environment settings for the subscription, then Settings & monitoring, where the Log Analytics agent for Azure VMs toggle is enabled. Turning this on ensures the agent is deployed to every existing and future Azure VM in that subscription without individual manual action. This setting is purpose-built for Defender for Cloud's security data collection and is the authoritative way to satisfy the requirement.

Why this answer

The 'Settings & monitoring' pane under Environment settings in Microsoft Defender for Cloud is the centralized location to enable automatic provisioning of the Log Analytics agent (Azure Monitor Agent) at the subscription level. This setting ensures that both existing Azure VMs and any future VMs are automatically provisioned with the agent, without requiring individual VM configuration or manual policy assignment.

Exam trap

The trap here is that candidates often confuse the deprecated 'Data collection' option under Security policy (Option C) with the current 'Settings & monitoring' pane, or they assume that Azure Policy (Option B) is the only way to enforce agent deployment, missing the built-in auto-provisioning toggle in Defender for Cloud.

How to eliminate wrong answers

Option B is wrong because Azure Policy can deploy the Log Analytics agent, but it is not the native Defender for Cloud auto-provisioning mechanism; using a custom policy requires additional management and does not integrate with Defender for Cloud's monitoring settings. Option C is wrong because the 'Security policy > Data collection' option in Defender for Cloud is deprecated and no longer controls auto-provisioning for the Log Analytics agent; it was used for the legacy Microsoft Monitoring Agent, not the Azure Monitor Agent. Option D is wrong because the Azure virtual machine blade's 'Auto-provisioning' setting does not exist; auto-provisioning is configured at the subscription level in Defender for Cloud, not per VM.

Full explanation →

925

MCQmedium

During a threat hunting exercise, an analyst discovers a suspicious PowerShell process that executed encoded commands and made outbound connections to an unknown IP address. The process tree shows it was spawned by a Microsoft Word instance. What is the most likely attack technique being observed?

A.Service Execution

B.Phishing with malicious macro

C.Execution via Rundll32

D.Lateral Movement via WMI

AnswerB

Phishing with malicious macro is correct because the suspicious chain—Microsoft Word spawning PowerShell with an encoded command line—is a classic indicator of a macro-enabled Office document used as an initial access vector. Attackers embed VBA macros that invoke PowerShell via a WMI CreateProcess or direct CreateProcess call, often using -EncodedCommand or -EncodedArguments to hide the payload from command-line logging and initial inspection. This aligns with MITRE ATT&CK techniques T1566.001 (Spearphishing Attachment) and T1204.002 (User Execution: Malicious File), where the macro acts as the execution trigger and PowerShell serves as the download cradle or in-memory loader.

Why this answer

A Microsoft Word process spawning PowerShell that then runs encoded commands and beacons to an unknown external IP is the textbook signature of a malicious macro. Office macros (VBA) are commonly used to launch PowerShell with -EncodedCommand, which base64-encodes the payload to evade string-based detection. The parent-child relationship (WINWORD.EXE → powershell.exe) combined with outbound C2 traffic confirms macro-based initial execution and command-and-control.

Exam trap

SC-200 often tests whether candidates can distinguish initial-access techniques (phishing/macro) from later-stage techniques (lateral movement, service execution) by reading the process tree carefully — the Word parent is the giveaway that this is initial execution, not post-exploitation.

How to eliminate wrong answers

Option A is wrong because 'Service Execution' is not a recognized MITRE ATT&CK technique; the closest real technique is T1569 System Services, which involves PsExec or service creation, not Office spawning PowerShell. Option C is wrong because Rundll32 execution would show rundll32.exe as the child process loading a DLL or JavaScript/VBScript, not powershell.exe with encoded commands. Option D is wrong because WMI lateral movement would appear as wmic.exe or Win32_Process Create events on a remote host, and there is no evidence of remote execution or a second machine in the process tree.

Full explanation →

926

MCQhard

Your company has a hybrid environment with Microsoft Sentinel and Microsoft Defender for Cloud. You notice that the 'Priority' field in Sentinel incidents is not being populated correctly. You need to ensure that Sentinel incidents inherit the priority from Microsoft Defender for Cloud alerts. What should you configure?

A.Enable the 'Sync incidents and alerts' setting in Microsoft Defender XDR.

B.Configure the Microsoft Defender for Cloud data connector to map severity and use an automation rule to set priority based on severity.

C.Use a workbook to display priority and manually update incidents.

D.Create an analytics rule that queries Microsoft Defender for Cloud alerts and sets the priority in the incident creation.

AnswerB

The Microsoft Defender for Cloud data connector ingests security alerts into Microsoft Sentinel and its configuration maps each alert's severity to the incident severity field, preserving the original alert's impact level. You then create an automation rule that triggers when an incident is created and sets the incident's priority (for example, via a tag or custom property) based on that mapped severity. This is the only option that correctly combines ingestion-level severity mapping with automated, rule-based priority assignment without manual effort or duplicate-creation risk.

Why this answer

Microsoft Defender for Cloud alerts include a severity field, and the Microsoft Defender for Cloud data connector in Sentinel can ingest this severity. By mapping the severity in the connector configuration, you can then use an automation rule to set the Sentinel incident's 'Priority' field based on the mapped severity, ensuring inheritance from Defender for Cloud alerts.

Exam trap

The trap here is that candidates often confuse the 'severity' field (which is automatically mapped by the connector) with the custom 'Priority' field, assuming they are the same or that synchronization settings like 'Sync incidents and alerts' will automatically populate Priority, when in fact Priority requires explicit automation rule configuration.

How to eliminate wrong answers

Option A is wrong because the 'Sync incidents and alerts' setting in Microsoft Defender XDR synchronizes incidents between Defender XDR and Sentinel, but it does not map or populate the custom 'Priority' field in Sentinel incidents; it only syncs incident metadata. Option C is wrong because workbooks are visualization tools and cannot automatically update incident fields; manually updating incidents is not a scalable or automated solution for ensuring priority inheritance. Option D is wrong because analytics rules create new incidents from queries, but they do not modify the priority of existing incidents that are already ingested from Defender for Cloud; the priority must be set during or after ingestion via the data connector and automation rules.

Full explanation →

927

MCQmedium

During a ransomware incident, an analyst needs to identify which files were encrypted on an endpoint. The endpoint is running Windows and is managed by Microsoft Defender for Endpoint. Which data source should the analyst query in Advanced hunting?

A.DeviceRegistryEvents

B.DeviceNetworkEvents

C.DeviceProcessEvents

D.DeviceFileEvents

AnswerD

DeviceFileEvents is correct because this table records file system operations such as creation, modification, renaming, and deletion. Ransomware encrypts files by writing encrypted content, often renaming them with new extensions and creating ransom notes, all of which generate file events. Security analysts can query this table for patterns like mass FileModified events from a single process or unusual file extension changes, making it the primary source for directly identifying encryption activity.

Why this answer

DeviceFileEvents is the correct data source because it captures file creation, modification, and deletion events on endpoints. During a ransomware incident, encrypted files are typically created with a new extension or modified in place, and DeviceFileEvents logs these changes, allowing the analyst to identify which files were affected.

Exam trap

The trap here is that candidates may confuse process-level events (DeviceProcessEvents) with file-level events, assuming that seeing the ransomware process run is sufficient to identify encrypted files, but only DeviceFileEvents provides the actual file paths and timestamps of encryption.

How to eliminate wrong answers

Option A is wrong because DeviceRegistryEvents tracks changes to the Windows registry, not file-level encryption events. Option B is wrong because DeviceNetworkEvents logs network connections and traffic, which may indicate C2 communication but does not directly show which files were encrypted. Option C is wrong because DeviceProcessEvents records process creation and termination, which can show ransomware execution but not the specific files that were encrypted.

Full explanation →

928

MCQmedium

You are performing a threat hunt in Microsoft Sentinel and have a KQL query that returns a high number of false positives. You want to reduce the noise without missing real threats. Which approach should you take?

A.Write a KQL query that looks for uncommon process chains, such as wscript.exe launched from Microsoft Office.

B.Add a filter to exclude all Microsoft signed processes.

C.Remove the time filter and run the query against all historical data.

D.Broaden the time range to capture more data.

AnswerA

A KQL query targeting uncommon process chains, such as wscript.exe spawned from Microsoft Office, directly identifies suspicious child-process relationships that align with known script-based attack sequences (macro execution, DDE abuse). By focusing on the parent-child correlation rather than broad attributes, the query maintains a low false-positive rate because it only surfaces events matching a specific, behaviorally suspicious pattern, not every process creation.

Why this answer

Option A is correct because focusing on uncommon process chains—like wscript.exe spawned by Microsoft Office—targets specific, high-fidelity indicators of malicious activity (e.g., macro-based attacks) rather than relying on broad, noisy signatures. This approach reduces false positives by filtering out normal, benign process relationships while preserving detection of real threats that deviate from baseline behavior. In Microsoft Sentinel, such behavioral hunting queries leverage KQL joins and process lineage to surface anomalies that are more likely to be true positives.

Exam trap

SC-200 often tests the misconception that reducing false positives means filtering out broad categories like signed processes or expanding data scope, when in fact it requires precise, behavior-based indicators that balance noise reduction with threat coverage.

How to eliminate wrong answers

Option B is wrong because excluding all Microsoft signed processes would create a massive blind spot: attackers often use signed binaries (LOLBins) like PowerShell or wscript.exe for malicious purposes, so this filter would suppress many real threats. Option C is wrong because removing the time filter and querying all historical data would drastically increase the volume of results, amplifying false positives and making triage impractical; it does not reduce noise. Option D is wrong because broadening the time range captures more data, which typically increases the number of false positives and does not address the root cause of noise; it may also dilute the signal-to-noise ratio.

Full explanation →

929

MCQeasy

Your organization has Microsoft Defender for Cloud Apps enabled. You need to generate an alert when a user downloads more than 100 files from SharePoint in one hour. What should you create?

A.A data loss prevention (DLP) policy in Microsoft Purview.

B.A custom alert in Microsoft Sentinel using the CloudAppEvents table.

C.An app governance policy in Microsoft Defender for Cloud Apps.

D.An anomaly detection policy in Microsoft Defender for Cloud Apps.

AnswerD

An anomaly detection policy in Microsoft Defender for Cloud Apps uses user and entity behavior analytics (UEBA) to build a per-user baseline of normal activity. When a user's activity volume significantly deviates from that baseline—for example, an unusually high number of file downloads or sign-in events—the policy generates an alert, making it the correct native mechanism for this scenario.

Why this answer

An anomaly detection policy in Microsoft Defender for Cloud Apps is designed to detect unusual user behavior, such as mass file downloads, by establishing a baseline and triggering alerts when activity deviates from the norm. This policy type specifically supports the scenario of detecting a user downloading more than 100 files from SharePoint in one hour, as it can be configured with custom thresholds for file download activity.

Exam trap

The trap here is that candidates often confuse anomaly detection policies with DLP policies, assuming that any data exfiltration scenario must be handled by DLP, but DLP policies in Purview are content-based, not volume-based, making anomaly detection the correct choice for this behavioral threshold scenario.

How to eliminate wrong answers

Option A is wrong because a data loss prevention (DLP) policy in Microsoft Purview focuses on preventing data exfiltration by inspecting content and applying actions like blocking or encrypting, not on detecting volume-based anomalies like a high number of downloads. Option B is wrong because a custom alert in Microsoft Sentinel using the CloudAppEvents table would require ingesting logs and writing a KQL query, which is a more complex, post-facto detection method rather than a native, real-time policy within Defender for Cloud Apps. Option C is wrong because an app governance policy in Microsoft Defender for Cloud Apps is specifically for managing and monitoring OAuth-enabled apps (e.g., permissions, consent), not for detecting user behavior anomalies like mass file downloads.

Full explanation →

930

MCQmedium

Your threat hunting hypothesis is that a user's credentials were used to sign in from two geographically distant locations within a short time. In Microsoft Defender for Cloud Apps, which log type would you query in Microsoft Sentinel to detect impossible travel?

A.SigninLogs

B.AuditLogs

C.CommonSecurityLog

D.OfficeActivity

AnswerA

SigninLogs in Microsoft Sentinel records Microsoft Entra ID sign-in events with IP-derived location and timestamp data. Querying it lets you correlate two authentications from geographically distant locations within an implausible interval, directly testing the impossible travel hypothesis.

Why this answer

Impossible travel detection relies on analyzing sign-in events with their source IP geolocation and timestamps. In Microsoft Sentinel, Azure AD (Entra ID) sign-in events are stored in the SigninLogs table, which contains fields like IPAddress, Location, and TimeGenerated needed to compute whether a user signed in from two distant locations within an implausible timeframe. Defender for Cloud Apps surfaces these as impossible travel alerts, but the underlying Sentinel query targets SigninLogs.

Exam trap

The trap is confusing sign-in telemetry with activity telemetry — candidates may pick OfficeActivity because the user 'did something,' but impossible travel specifically requires sign-in geolocation data, which lives in SigninLogs.

How to eliminate wrong answers

Option B is wrong because AuditLogs contains directory and administrative activity (user creation, role changes, policy updates), not interactive sign-in events with geolocation. Option C is wrong because CommonSecurityLog holds CEF-formatted data from third-party security appliances (firewalls, proxies, IDS), not Azure AD sign-in telemetry. Option D is wrong because OfficeActivity captures user actions within Office 365 workloads (file access, email, SharePoint), which may show activity but lacks the sign-in geolocation context needed for impossible travel.

Full explanation →

931

MCQhard

You are a security analyst for a company that uses Azure Firewall. You are reviewing a custom rule deployed via Azure Firewall Manager. The exhibit shows the rule configuration. The rule is intended to block inbound traffic from known Tor exit nodes. However, a recent incident involved an attacker using a Tor exit node with IP 138.197.5.5 to access an internal web server on port 8080. The log shows the traffic was ALLOWED. What is the most likely reason the rule did not block the traffic?

A.The destination port 8080 is not listed in the rule.

B.The source address range does not include 138.197.5.5.

C.The rule type is 'Prevention' but should be 'Detection'.

D.The rule priority is too low and is overridden by a higher priority rule.

AnswerA

The application rule's destination port list is the crux: it only specifies 443 (HTTPS) and 80 (HTTP), so any outbound connection to port 8080 does not match the rule's conditions, even when the destination FQDN or IP is otherwise covered. A matching source and destination are not enough; for an Azure Firewall application rule to apply, the protocol:port must also be present in the rule. Because 8080 is absent, the traffic bypasses this deny action, which explains why the connection was allowed.

Why this answer

The rule is configured to block traffic on destination port 80, but the attacker used port 8080. Azure Firewall rules are explicit; if the destination port in the traffic does not match any port specified in the rule, the rule is not applied, and the traffic is evaluated by subsequent rules or default allow logic. Since the rule only lists port 80, traffic to port 8080 is not matched, and thus the rule does not block it.

Exam trap

The trap here is that candidates assume a rule blocking a source IP will block all traffic from that IP, but Azure Firewall rules require exact port matching, and the rule only specifies port 80, not port 8080.

How to eliminate wrong answers

Option B is wrong because the exhibit shows the source address range includes 138.197.5.5, so the source IP is correctly covered. Option C is wrong because Azure Firewall Manager does not use 'Prevention' or 'Detection' rule types; those are concepts from other security products like Microsoft Defender for Cloud or IDS/IPS systems, not Azure Firewall custom rules. Option D is wrong because rule priority determines the order of evaluation, but if the rule does not match the traffic (due to port mismatch), priority is irrelevant; the rule is simply skipped.

Full explanation →

932

MCQmedium

Your organization uses Microsoft Defender for Office 365. You want to automatically isolate a user's mailbox if a high-confidence phishing email is detected. Which Microsoft Sentinel automation should you use?

A.Configure a workbook to display the alert and manually isolate the mailbox.

B.Create a playbook that uses the Microsoft Graph API to apply a mailbox litigation hold or block access.

C.Enable the Office 365 connector and configure automatic response in the data connector.

D.Create a scheduled analytics rule that isolates the mailbox when triggered.

AnswerB

Playbooks in Microsoft Sentinel are Azure Logic Apps workflows that automate response actions when triggered by an incident or alert. By calling the Microsoft Graph API, a playbook can programmatically apply a litigation hold to preserve mailbox content or block user access through conditional access policies. This provides a reliable, repeatable SOAR solution that integrates with Office 365 without requiring manual intervention.

Why this answer

Microsoft Sentinel playbooks, built on Azure Logic Apps, can use the Microsoft Graph API to perform automated remediation actions like applying a mailbox litigation hold or blocking user access. This enables automatic isolation of a user's mailbox when a high-confidence phishing email is detected, which is a key incident response capability in Defender for Office 365.

Exam trap

The trap here is that candidates often confuse data connectors (which only ingest data) with automated response capabilities, or assume that analytics rules can directly execute remediation actions, when in fact only playbooks (or automation rules that invoke playbooks) can perform such actions.

How to eliminate wrong answers

Option A is wrong because workbooks are visualization tools for displaying data and alerts, not automation mechanisms; they cannot perform actions like mailbox isolation. Option C is wrong because the Office 365 data connector ingests logs and alerts into Sentinel but does not provide native automatic response configuration for mailbox isolation; automated responses require playbooks or custom logic. Option D is wrong because scheduled analytics rules only generate alerts based on query schedules; they cannot directly execute remediation actions like mailbox isolation — that requires a playbook or automation rule.

Full explanation →

933

MCQmedium

A SOC analyst needs to ingest firewall logs from an on-premises Cisco ASA into Microsoft Sentinel. The logs are sent via syslog to a Linux server. Which data connector should the analyst use to properly parse and collect these logs?

A.Common Event Format (CEF)

B.Syslog

C.Windows Firewall

D.Cisco ASA via API

AnswerA

Common Event Format (CEF) is a Syslog-based logging standard widely used by network and security appliances, and Microsoft Sentinel provides a dedicated CEF connector that automatically parses its key-value fields into the CommonSecurityLog schema. For Cisco ASA, you configure the appliance to send CEF-formatted events to the Log Analytics agent or Azure Monitor Agent, which then enriches and normalizes the data for queries and analytics. This is the correct choice because it gives structured, schema-mapped data with minimal configuration in Sentinel.

Why this answer

The Common Event Format (CEF) connector is the correct choice because Cisco ASA firewalls send syslog messages that can be forwarded to a Linux log collector (rsyslog or syslog-ng), which then formats them into CEF (a normalized syslog format) before forwarding to the Sentinel Log Analytics workspace. This connector parses the CEF headers and maps the fields into the CommonSecurityLog table, enabling proper parsing and correlation of firewall events.

Exam trap

The trap here is that candidates see 'syslog' in the question and immediately choose the Syslog connector, not realizing that Cisco ASA logs are best ingested via the CEF connector to leverage automatic parsing into structured fields, whereas raw Syslog would require heavy KQL parsing.

How to eliminate wrong answers

Option B is wrong because the raw Syslog connector ingests syslog messages without parsing them into a structured schema; it stores them in the Syslog table as raw text, which would require custom parsing for Cisco ASA fields like source/destination IP and port. Option C is wrong because the Windows Firewall connector is designed for Windows Defender Firewall logs on Windows machines, not for on-premises Cisco ASA logs sent via syslog. Option D is wrong because Cisco ASA does not natively support a REST API for log export; the ASA uses syslog (UDP/TCP) or SNMP, and the 'Cisco ASA via API' connector does not exist in Microsoft Sentinel.

Full explanation →

934

MCQhard

An analyst uses this KQL query in Microsoft Sentinel to hunt for potential brute-force attacks. What is the primary purpose of the join operation?

A.To filter out IP addresses that have only successful logons

B.To identify accounts that had both a high number of failed logons and at least one successful logon from the same IP

C.To calculate the ratio of failed to successful logons for each account

D.To remove duplicate entries of account and IP combinations

AnswerB

This is correct. The query first aggregates failed logon events by account and IP, then performs an inner join with successful logon events on the same account/IP pair. The inner join ensures that any matched row has at least one successful logon from that IP, while the aggregate count shows a high number of failures. Together these filters reveal accounts that suffered many failed logon attempts and ultimately had a successful logon from the same source IP—a classic indicator of a successful brute-force attack.

Why this answer

The join in the KQL query correlates failed logon events with successful logon events on the same account and IP, so its primary purpose is to surface accounts that experienced many failed logons followed by at least one success from the same IP — a classic brute-force success indicator. This narrows the hunt to high-risk accounts rather than all failed logons.

Exam trap

SC-200 often tests KQL join semantics and detection logic, and the trap is misreading the join as a simple filter or deduplication when it is actually correlating two event sets to identify accounts with both failed and successful logons from the same IP.

How to eliminate wrong answers

Option A is wrong because the join is not merely filtering out IPs with only successful logons — it is correlating failed and successful events to find accounts with both, which is a more specific detection. Option C is wrong because the query does not compute a ratio of failed to successful logons; it identifies the co-occurrence of high failures and at least one success. Option D is wrong because the join is not a deduplication operation — deduplication would use distinct or summarize, not a join between two event sets.

Full explanation →

935

Multi-Selecthard

Your organization uses Microsoft Sentinel and has enabled user and entity behavior analytics (UEBA). You need to identify which two data sources are required to enable UEBA in Microsoft Sentinel. (Choose two.)

Select 2 answers

A.Azure Activity logs

B.Azure Active Directory (Azure AD) audit logs

C.Microsoft Defender for Identity logs

D.Microsoft 365 audit logs

E.Azure Active Directory (Azure AD) sign-in logs

AnswersB, E

Azure AD audit logs are required for UEBA because they track administrative and user activities such as group changes, role assignments, and application consent. These logs help UEBA establish normal behavior and detect suspicious changes. Together with sign-in logs, they form the minimum data set for UEBA.

Why this answer

To enable UEBA in Microsoft Sentinel, you must ingest Azure AD sign-in logs and Azure AD audit logs. These provide the necessary user authentication and activity data for behavioral baselining. Other logs can be added later to enrich UEBA but are not mandatory for the initial enablement.

Exam trap

The trap here is assuming that all Microsoft 365 or Defender logs are required; in fact, only Azure AD sign-in and audit logs are prerequisites for UEBA.

Full explanation →

936

MCQeasy

A security analyst in your SOC is investigating a Microsoft Defender XDR incident. The analyst wants to see a visual representation of the attack timeline and related entities across emails, devices, and identities. Which feature should the analyst use?

A.Microsoft Sentinel incident investigation graph.

B.Advanced hunting in Microsoft Defender XDR.

C.Incident graph in Microsoft Defender XDR.

D.Microsoft Defender for Cloud Apps activity log.

AnswerC

The incident graph in Microsoft Defender XDR provides a visual representation of the attack timeline and relationships between entities such as users, devices, and emails. It helps analysts understand the scope and progression of an attack across multiple workloads. This is the correct feature for the described requirement.

Why this answer

The incident graph in Microsoft Defender XDR is designed to provide a visual, interactive representation of an incident, showing the relationships between entities like users, devices, mailboxes, and the timeline of events. It aggregates alerts from multiple Defender workloads, enabling analysts to quickly understand the attack's scope. Advanced hunting is query-based, Sentinel's graph is separate, and Defender for Cloud Apps activity log is app-focused.

The incident graph directly fulfills the need for a visual attack timeline and entity mapping.

Exam trap

The trap here is confusing the incident graph with advanced hunting or other investigation tools; the incident graph is specifically for visual incident visualization in Defender XDR.

Full explanation →

937

Matchingmedium

Match each threat intelligence indicator type to its description.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

IPv4 or IPv6 address associated with malicious activity

Domain name used for phishing or C2

Full URL path involved in an attack

MD5, SHA1, or SHA256 hash of a malicious file

Sender address from a phishing campaign

Why these pairings

These are common STIX indicator types used in threat intelligence. Correct matches: IP Address is a numerical label, Domain Name is an identification string, File Hash is a hash of file content. Common confusions involve swapping definitions between IP and Domain, or IP and File Hash.

Full explanation →

938

MCQmedium

You are a Security Operations Analyst at a company that uses Microsoft Defender XDR. An incident named 'Phishing campaign targeting finance' is assigned to you. The incident contains multiple alerts across Exchange Online and Microsoft Defender for Office 365. You need to perform a manual investigation and then take remediation actions. Which built-in incident management capability in the Microsoft 365 Defender portal allows you to view the attack story, evidence, and response actions for this incident in a single pane?

A.The Microsoft Defender for Cloud Apps portal

B.The incident investigation page in the Microsoft 365 Defender portal

C.The Incidents queue page in the Microsoft 365 Defender portal

D.The Advanced hunting page in the Microsoft 365 Defender portal

AnswerB

The incident investigation page is the unified surface in Microsoft Defender XDR where you review the attack story, alert timeline, impacted entities, and evidence, and from which you can run response actions such as soft-deleting emails or isolating devices. It aggregates signals from Defender for Office 365, Exchange Online Protection, and other workloads, exactly matching the need to investigate and remediate this phishing incident in one place.

Why this answer

The incident investigation page in Microsoft Defender XDR consolidates alerts, entities, evidence, and the attack story for a single incident. It is purpose-built for analysts to move from triage to investigation and then to response, with actions like email soft delete and device isolation available inline. Other pages either list incidents, provide raw query access, or focus on a different workload, so they do not meet the single-pane investigation and remediation requirement.

Exam trap

The trap here is confusing the Incidents queue, which is for triage and assignment, with the incident investigation page, where the attack story and response actions actually live.

Full explanation →

939

MCQeasy

A security analyst receives a Microsoft Defender for Cloud Apps alert about a user performing unusual file downloads from SharePoint. The analyst needs to investigate the user's activity in the last 24 hours. Which log source should the analyst query first?

A.Microsoft Entra ID sign-in logs

B.Microsoft Intune device logs

C.Office 365 audit logs

D.Cloud App Security logs in Microsoft Sentinel

AnswerD

Microsoft Defender for Cloud Apps logs in Sentinel, specifically the CloudAppEvents table, provide a centralized, enriched record of user activities across cloud applications, including SharePoint Online file downloads. Each event includes the actor, target file, action, source IP, timestamp, and risk indicators. Because the analyst is investigating a Defender for Cloud Apps alert, these logs allow direct correlation of the file-download activity to the reported incident without relying on separate audit consoles.

Why this answer

D is correct because Cloud App Security logs in Microsoft Sentinel provide the most granular and immediate visibility into user activities within Microsoft Defender for Cloud Apps, including file downloads from SharePoint. These logs capture detailed metadata such as file names, download counts, and user IP addresses, enabling the analyst to quickly identify anomalous behavior without needing to correlate across multiple data sources.

Exam trap

The trap here is that candidates often default to Office 365 audit logs (Option C) because they know SharePoint activity is logged there, but they miss that the alert is specifically from Defender for Cloud Apps, which has its own dedicated logs in Sentinel that are optimized for this investigation.

How to eliminate wrong answers

Option A is wrong because Microsoft Entra ID sign-in logs only record authentication events (e.g., successful or failed logins) and do not include details about specific file downloads or SharePoint activity. Option B is wrong because Microsoft Intune device logs focus on device management, compliance, and configuration, not on user file operations within cloud applications. Option C is wrong because Office 365 audit logs do contain SharePoint file operations, but they are not the first source to query when the alert originates from Defender for Cloud Apps; Cloud App Security logs in Sentinel provide the same data with additional context and are directly integrated with the alert.

Full explanation →

940

MCQmedium

An incident in Microsoft Sentinel involves a phishing campaign that delivered a malicious macro-enabled document. The document was opened by 15 users. Which playbook action should be triggered automatically to contain the threat?

A.Isolate all affected devices from the network

B.Block the sender's IP address on the email gateway

C.Block the file hash using Microsoft Defender for Endpoint

D.Disable the user accounts of those who opened the document

AnswerC

Blocking the file hash with Microsoft Defender for Endpoint is the correct immediate containment because it targets the exact malicious artifact that triggered the incident. Defenders can add the SHA-256 hash as a custom file indicator in the Microsoft 365 Defender portal, which instructs the endpoint sensor to block execution and sometimes prevent the file from being written to disk, across all enrolled devices. This is non-disruptive to user productivity, reversible once the threat is confirmed eliminated, and aligns with the automatic response capabilities in Microsoft Sentinel when connected to a playbook. Because the file is the vector, a file-level block nullifies the attack regardless of how the file arrives in the future.

Why this answer

The automatic playbook action should block the file hash at the endpoint to prevent further execution. Isolating devices may be too aggressive. Blocking sender IP is not effective against phishing.

Disabling user accounts is not direct.

Full explanation →

941

MCQmedium

You are a security operations analyst for a company that uses Microsoft Sentinel. The SOC manager wants to ensure that only incidents with a severity of High or Critical are automatically assigned to the on-call analyst, while all other incidents remain unassigned. You need to create an automation rule that meets this requirement. What should you do first?

A.Create a playbook that runs on incident creation, parses the incident severity, and if High or Critical, assigns the incident using the Microsoft Sentinel API.

B.Create a scheduled query rule that detects High and Critical incidents and then triggers a Logic App to assign them.

C.Create a new automation rule and set the trigger to "When incident is created". Add a condition that checks if the incident severity is High or Critical. Then add an action to assign the incident to the on-call analyst.

D.Modify the incident settings in Microsoft Sentinel to automatically assign all High and Critical incidents to the on-call analyst by default.

AnswerC

This approach uses the native automation rule capability in Microsoft Sentinel to evaluate incident severity at creation time and assign accordingly. Automation rules support conditions based on incident properties, including severity, and can perform assignment actions. This directly satisfies the requirement without custom logic or external components.

Why this answer

Automation rules in Microsoft Sentinel are designed to automate incident handling tasks such as assignment, tagging, and status changes. They can be triggered when an incident is created and include conditions based on incident properties. This makes them the ideal solution for conditionally assigning incidents based on severity without custom development.

Exam trap

The trap here is confusing automation rules with playbooks; automation rules are lightweight and built-in for incident management, while playbooks are more powerful but require Logic Apps and are better suited for complex orchestration.

Full explanation →

942

MCQeasy

Your organization uses Microsoft Sentinel. You have a playbook that sends an email notification to the SOC team when a new incident is created. The playbook is currently triggered manually. You want the playbook to run automatically every time an incident of severity High is created. What should you do?

A.Edit the analytics rule that generates the incident to include the playbook as an automated response.

B.Create an automation rule that triggers when an incident is created with severity High and runs the playbook.

C.Modify the playbook to add a trigger of 'When an incident is created' and set the severity condition.

D.Configure the playbook's Logic Apps designer to use an HTTP trigger that polls Sentinel for new incidents.

AnswerB

Creating an automation rule that triggers when an incident is created with severity High and runs the playbook is correct because automation rules are Microsoft Sentinel's native, event-driven mechanism for incident lifecycle automation. The rule evaluates the incident immediately on creation, checks the severity condition, and executes the playbook via the Actions pane, passing the complete incident context. This approach is consistent, auditable, and ensures that every High-severity incident triggers the playbook without relying on alert-level logic or custom polling.

Why this answer

Automation rules in Sentinel can automatically trigger playbooks based on incident conditions. Option A is correct. Option B is wrong because automation rules are created in the Automation blade.

Option C is wrong because the analytics rule does not directly run playbooks. Option D is wrong because the playbook trigger is not configured in Logic Apps designer.

Full explanation →

943

MCQmedium

A SOC analyst creates a scheduled analytics rule in Microsoft Sentinel with the following KQL query: SigninLogs | where TimeGenerated > ago(1h) | summarize StartTime = min(TimeGenerated), EndTime = max(TimeGenerated) by UserPrincipalName, IPAddress | where EndTime - StartTime < 5m and count_IPAddress > 1 The intended purpose is to detect users logging in from multiple IP addresses in a short time (impossible travel). However, the rule does not generate any alerts. What is the most likely cause?

A.The query references a column 'count_IPAddress' that does not exist. The summarize operator does not create a column with that name.

B.The query does not filter for failed sign-ins (e.g., ResultType == 0).

C.The rule should use a longer time range, such as 24 hours.

D.The rule needs to use the 'make_set' function to correctly count distinct IP addresses.

AnswerA

The `summarize` operator groups by `UserPrincipalName` and `IPAddress`, producing one row per pair; it never emits a `count_IPAddress` column. Referencing that non-existent column causes the query to fail, so the scheduled rule returns no results and raises no alerts, satisfying the stem's "no alerts" constraint.

Why this answer

The query uses `summarize ... by UserPrincipalName, IPAddress` which groups by both fields, so it does not create a column named `count_IPAddress`. The `where` clause then references `count_IPAddress`, which does not exist, causing the query to fail silently or return no results. This is why no alerts are generated.

Exam trap

The trap here is that candidates may focus on the logic of impossible travel detection (e.g., time range, distinct IPs) and overlook the simple syntax error of referencing a column that was never created by the `summarize` operator.

How to eliminate wrong answers

Option B is wrong because filtering for failed sign-ins (ResultType == 0) is irrelevant; the rule is designed to detect impossible travel from successful sign-ins, and the issue is a syntax error, not a missing filter. Option C is wrong because the time range (1 hour) is sufficient for detecting short-interval multiple IP logins; extending it would not fix the missing column error. Option D is wrong because `make_set` is used to create an array of distinct values, not to count them; the correct function to count distinct IPs would be `dcount` or `count_distinct`, but the core problem is the non-existent column reference.

Full explanation →

944

MCQeasy

Your organization uses Microsoft Sentinel. A security analyst receives an alert for a suspicious sign-in from an unfamiliar IP address. The analyst wants to quickly check if the same IP address has been associated with any other alerts in the past 30 days. Which action should the analyst take?

A.Create an automation rule to block the IP address.

B.Submit the IP address to Microsoft for threat intelligence.

C.Create a new analytics rule to detect the IP address.

D.Run a KQL query in the Logs blade to search the Alert table for the IP.

AnswerD

In Microsoft Sentinel, running a KQL query in the Logs blade against the Alert table is the correct way to search for all alerts involving a specific IP address. For example, you can execute a query like `Alert | where TimeGenerated > ago(30d) | where Entities contains "10.0.0.5"` to return every alert where that IP appears in the entity list, enabling a thorough historical investigation. The Alert table stores all alerts generated by analytics rules and data connectors, making it the authoritative source for answering whether an IP is associated with prior alerts. This read-only query provides immediate, actionable evidence without altering detection or response configurations.

Why this answer

The Alert table in Microsoft Sentinel logs contains historical alert data, including IP addresses associated with each alert. Running a KQL query against this table allows the analyst to quickly search for the same IP address across all alerts generated in the past 30 days, enabling efficient incident correlation without modifying detection or response configurations.

Exam trap

The trap here is that candidates may confuse proactive threat hunting actions (like creating rules or submitting to threat intelligence) with the simple investigative task of querying existing log data, leading them to select options that modify the environment rather than just query it.

How to eliminate wrong answers

Option A is wrong because creating an automation rule to block the IP address is a reactive response that does not help the analyst check historical associations; it would only apply to future alerts. Option B is wrong because submitting the IP address to Microsoft for threat intelligence is for enrichment or reputation checking, not for querying existing alert history within the Sentinel workspace. Option C is wrong because creating a new analytics rule to detect the IP address would generate future alerts but does not allow the analyst to search past alerts for the same IP.

Full explanation →

945

Multi-Selecthard

Which TWO of the following are valid methods to retrieve data from Microsoft Sentinel for external analysis during an incident?

Select 2 answers

A.Use Microsoft Sentinel PowerShell cmdlets.

B.Create a Power BI dashboard.

C.Use the Export to CSV feature in the Logs blade.

D.Connect Log Analytics workspace to external tools via API.

E.Use the Microsoft Sentinel API to query incidents and alerts.

AnswersD, E

Connecting the Log Analytics workspace to external tools via the Log Analytics Query API is a valid data-retrieval method because it allows external applications, such as custom scripts or third-party SIEM/BI solutions, to send KQL queries over HTTPS and receive the query results in JSON format. The API supports large result sets with batching/pagination, making it suitable for pulling data out of Sentinel's underlying workspace for analysis or integration. This is one of the canonical approaches to retrieving Microsoft Sentinel data externally.

Why this answer

The Log Analytics workspace that underpins Microsoft Sentinel exposes a REST API, allowing external tools to query and export data programmatically for analysis. This API supports OAuth 2.0 authentication and can retrieve log data via KQL queries, making it a valid method for external integration during incident response.

Exam trap

The trap here is that candidates confuse the Log Analytics API (Option D) with the Microsoft Sentinel API (Option E) as separate valid methods, while dismissing the Export to CSV feature (Option C) as a valid retrieval method despite it being a manual export rather than an automated external analysis pipeline.

Full explanation →

946

Multi-Selecteasy

Your organization uses Microsoft Defender for Cloud. You need to remediate a security recommendation that indicates a virtual machine is missing critical security updates. Which TWO actions should you take to remediate this recommendation?

Select 2 answers

A.Add a network security group to block inbound traffic to the VM.

B.Connect to the VM and install the missing updates.

C.Create an exemption for the recommendation in Defender for Cloud.

D.Configure the VM to automatically install updates from Windows Update.

E.Restart the VM to trigger update installation.

AnswersB, D

Connecting to the VM and installing the missing updates directly resolves the configuration issue identified by Microsoft Defender for Cloud. This action applies the required patches, bringing the system into compliance with the security baseline and eliminating the known vulnerabilities. It is the immediate and definitive remediation for a recommendation that reports missing updates.

Why this answer

Installing the missing updates directly on the VM resolves the underlying vulnerability that Defender for Cloud identified. Option D is correct because configuring automatic updates ensures the VM receives future critical security patches without manual intervention, which proactively remediates the recommendation over time.

Exam trap

The trap here is that candidates often confuse 'remediate' with 'suppress' or 'mitigate'—they may choose to create an exemption (Option C) or block traffic (Option A) thinking it resolves the recommendation, but only installing updates or enabling automatic updates actually addresses the root cause.

Full explanation →

947

MCQeasy

You are investigating a phishing incident in Microsoft Defender XDR. The user reported receiving an email with a malicious link. You need to identify all users who received the same email. Which feature should you use?

A.Automation & investigations

B.Incidents view

C.Threat Explorer

D.Advanced Hunting

AnswerC

Threat Explorer is the dedicated email-trace and forensics tool in Microsoft 365 Defender, purpose-built for investigating malicious mail across Exchange Online and Microsoft Defender for Office 365. It supports near real-time searches and filters by sender, recipient, subject, message ID, detection technology, delivery status, and header data, and it can even display email headers for detailed verification. Because it lets analysts immediately pivot from search results to remediation actions such as soft-deleting from mailboxes, it is the correct surfacing feature for phishing email investigation.

Why this answer

Threat Explorer (part of Microsoft Defender for Office 365 / Defender XDR) is purpose-built for email and collaboration threat investigation. It lets you pivot on a malicious URL, sender, or message and see every recipient who received the same email, along with delivery status and remediation actions. This is the correct tool for identifying the blast radius of a phishing campaign.

Exam trap

SC-200 often tests the distinction between investigation tools — candidates confuse Advanced Hunting (raw KQL queries) with Threat Explorer (purpose-built email investigation UI), even though both can technically surface email data.

How to eliminate wrong answers

Option A is wrong because Automation & investigations (AIR) is used to automate response playbooks and remediate incidents, not to enumerate all recipients of a specific email. Option B is wrong because the Incidents view aggregates correlated alerts into incident records but does not provide email-level recipient enumeration. Option D is wrong because Advanced Hunting (KQL) can query EmailEvents, but it is a raw query tool rather than the purpose-built feature for identifying all recipients of a specific email during phishing triage.

Full explanation →

948

MCQmedium

A SOC analyst is creating a scheduled analytics rule in Microsoft Sentinel to detect when a user account is added to a privileged role in Microsoft Entra ID. The analyst wants to correlate with the user's previous role assignments to identify potential privilege escalation. Which table should the analyst query?

A.AuditLogs

B.SigninLogs

C.AzureActivity

D.SecurityEvent

AnswerA

AuditLogs is the correct table because it captures Microsoft Entra ID directory audit events, including the 'Add member to role' action. This table records the actor, target, and timestamp for every privilege escalation, making it indispensable for detecting suspicious role assignments. Without it, an analytics rule cannot see the actual administrative action that grants elevated permissions.

Why this answer

The AuditLogs table in Microsoft Sentinel captures directory activity, including changes to privileged role assignments in Microsoft Entra ID (formerly Azure AD). By querying AuditLogs, the analyst can correlate the current role addition with historical role assignment events to detect potential privilege escalation. SigninLogs, AzureActivity, and SecurityEvent do not contain the specific role assignment audit data needed for this correlation.

Exam trap

The trap here is that candidates may confuse AzureActivity (which logs Azure resource operations) with Microsoft Entra ID audit logs, or assume SigninLogs contains role assignment data because it includes directory roles in sign-in token claims.

How to eliminate wrong answers

Option B is wrong because SigninLogs records user sign-in events, not directory changes like role assignments. Option C is wrong because AzureActivity logs Azure resource management operations (e.g., VM creation), not Microsoft Entra ID role assignments. Option D is wrong because SecurityEvent collects Windows security events from on-premises or Azure VMs, not cloud directory role changes.

Full explanation →

949

MCQhard

Your organization uses Microsoft Sentinel. You have a scheduled analytics rule that queries Windows Security Events to detect local admin group modifications. The rule runs every hour and looks back 1 hour. However, you are missing events that occur within the first few minutes of the hour. What is the most likely cause?

A.The event time is in local time, and the query uses UTC, causing events near the boundary to be excluded.

B.The query period is too short; it should be 2 hours.

C.The rule is using 'Last activity' instead of 'TimeGenerated'.

D.There is a 5-minute ingestion delay for Windows events.

AnswerA

Sentinel stores and queries timestamps in UTC, while Windows event logs record event time in the machine's local time zone. When an analytics rule uses a local-time field (such as EventTime or TimeCreated) for the where clause, events occurring in the last few minutes of the lookback window can be shifted outside the UTC-based query boundary, so the rule misses them even though they occurred within the intended hour. The fix is to convert time fields to UTC (e.g., using `datetime_utc()` or comparing against UTC datetime literals) or rely on `TimeGenerated`, which is always UTC.

Why this answer

The scheduled analytics rule uses a lookback period of 1 hour, but if the event time is stored in local time while the query uses UTC, events near the hour boundary can be excluded due to time zone offset. Microsoft Sentinel stores events in UTC by default, and the query's time filter (e.g., 'TimeGenerated > ago(1h)') compares against UTC timestamps. If the Windows Security Events are logged in local time and not converted, events occurring just after the hour in local time may fall outside the UTC lookback window, causing them to be missed.

Exam trap

The trap here is that candidates often assume ingestion delay or query period length is the cause, but the real issue is time zone mismatch between event timestamps and the query's UTC-based lookback window.

How to eliminate wrong answers

Option B is wrong because increasing the query period to 2 hours would not fix the root cause of time zone mismatch; it would only shift the boundary issue, not resolve it. Option C is wrong because 'Last activity' is not a valid time field in Windows Security Events; the correct field is 'TimeGenerated', and using 'Last activity' would cause different filtering behavior, not specifically the boundary issue described. Option D is wrong because a 5-minute ingestion delay would cause events to appear later, but the rule runs every hour with a 1-hour lookback, so a 5-minute delay would still capture events within the lookback window; the issue is specifically about events at the start of the hour being excluded due to time zone differences.

Full explanation →

950

MCQeasy

You are configuring Microsoft Sentinel to send email notifications to the SOC manager when a high-severity incident is created. What should you use?

A.Configure an analytics rule to send an email when an incident is created.

B.Create a playbook that sends an email and assign it to an automation rule.

C.Use a workbook to track incidents and configure an alert for email.

D.Add the SOC manager's email to a watchlist and configure a scheduled query.

AnswerB

The correct approach is to create a playbook—a Logic Apps workflow—that uses a connector such as Office 365 Outlook to send an email. You then assign this playbook to an automation rule with the trigger set to 'When incident is created.' This enables automatic, reliable email notifications to your SOC team whenever a new incident is generated.

Why this answer

Automation rules in Microsoft Sentinel can trigger a playbook (an Azure Logic Apps workflow) when an incident is created. The playbook can include an action to send an email notification, enabling automated response to high-severity incidents without manual intervention.

Exam trap

The trap here is confusing analytics rules with automation rules; candidates often think analytics rules can directly send emails, but they only generate alerts or incidents, while automation rules handle post-creation actions like playbook execution.

How to eliminate wrong answers

Option A is wrong because analytics rules generate alerts, not incidents directly; while they can be configured to create incidents, they do not have native email notification capabilities for incident creation. Option C is wrong because workbooks are visualization tools for data analysis and cannot trigger email alerts; they are not designed for automated actions. Option D is wrong because watchlists are used for correlation and enrichment in queries, not for triggering email notifications; a scheduled query can generate alerts but does not directly send emails to a specific recipient without additional automation.

Full explanation →

951

MCQeasy

An organization uses Microsoft Defender for Office 365. The security team wants to automatically investigate and respond to user-reported phishing emails. Which feature should they enable to automate this process?

A.Attack simulation training

B.Automated investigation and response (AIR)

C.Campaign views

D.Threat Explorer

AnswerB

Automated investigation and response (AIR) in Microsoft Defender for Office 365 enables playbook-driven automation that triages alerts generated from user-reported messages. When a user reports a suspicious email, AIR can trigger automated actions such as soft-deleting the message, disabling a malicious URL, quarantining files, and consolidating related alerts into a single investigation. This is the only option that both automatically analyzes and remediates real threats originating from user-reported emails.

Why this answer

Automated investigation and response (AIR) in Microsoft Defender for Office 365 automatically triggers a playbook when a user reports a phishing email via the Report Message or Report Phishing add-in. It collects the email, analyzes it using threat intelligence and machine learning, and takes remediation actions such as soft-deleting the message or blocking the sender, all without manual intervention.

Exam trap

The trap here is that candidates often confuse 'Attack simulation training' (a proactive training tool) with the automated response capability, or they think 'Threat Explorer' or 'Campaign views' can automate responses, when in fact those are manual investigation and visualization tools, not automated response engines.

How to eliminate wrong answers

Option A is wrong because Attack simulation training is used to create and run simulated phishing campaigns to train users, not to automatically investigate or respond to actual user-reported phishing emails. Option C is wrong because Campaign views provide a consolidated dashboard to identify and analyze coordinated phishing or malware campaigns across the organization, but they do not automate the investigation and response process for individual user-reported emails. Option D is wrong because Threat Explorer is a real-time investigation tool that allows security analysts to query and hunt for threats across email and collaboration data, but it does not automatically trigger responses based on user reports.

Full explanation →

952

MCQhard

You are reviewing a Microsoft Sentinel analytics rule configuration. The rule is not generating incidents as expected. What is the most likely cause?

A.The queryFrequency and queryPeriod are mismatched.

B.The suppressionDuration is set to 5 hours, suppressing alerts.

C.The action type 'MFA disabled' is not supported in IdentityLogonEvents.

D.The query references a table that is not available in the Sentinel workspace.

AnswerD

IdentityLogonEvents is a table that is only present when the Microsoft Defender for Identity data connector (or Microsoft 365 Defender connector) is enabled and streaming data into the Sentinel workspace. Without that connector, the table does not exist, so the analytics rule query fails with a 'table not found' error when it tries to run. This is the correct explanation for the rule failing.

Why this answer

If the query in an analytics rule references a table that does not exist in the Microsoft Sentinel workspace, the rule will fail to execute or return no results, preventing incident generation. This is a common misconfiguration when migrating or authoring rules that depend on specific data connectors or schema that have not been onboarded.

Exam trap

The trap here is that candidates often focus on query logic or timing parameters, but Microsoft tests the foundational requirement that referenced tables must exist in the workspace for the rule to function at all.

How to eliminate wrong answers

Option A is wrong because queryFrequency and queryPeriod can be mismatched without preventing incident generation; the rule will still run, though it may produce unexpected results or duplicate alerts. Option B is wrong because suppressionDuration suppresses alerts after they are generated, not preventing incident creation; incidents would still be created initially. Option C is wrong because 'MFA disabled' is a valid action type in IdentityLogonEvents (part of Microsoft Entra ID sign-in logs), and the rule would still generate incidents if the query is otherwise correct.

Full explanation →

953

MCQeasy

Your organization uses Microsoft Defender for Cloud. You receive a security alert about a suspicious process on a virtual machine. You want to investigate the process further. What should you do?

A.Create a custom detection rule to alert on similar processes.

B.Run a vulnerability assessment scan on the VM.

C.Initiate a live response session on the VM from Microsoft Defender for Cloud.

D.Initiate an automated investigation on the VM.

AnswerC

Initiating a live response session from Microsoft Defender for Cloud provides a remote interactive shell to the VM, allowing you to run commands, inspect running processes, collect forensic artifacts, and terminate suspicious processes in real time. Live response is specifically designed for ad-hoc investigations where you need immediate, hands-on visibility. This is the appropriate action when you have identified a specific process and need to examine it directly.

Why this answer

Microsoft Defender for Cloud's live response capability allows you to remotely connect to a VM and perform real-time forensic actions, such as running commands, examining running processes, and collecting artifacts. This is the most direct way to investigate a suspicious process on a specific VM, as it provides interactive access without needing to install additional agents or reboot the machine.

Exam trap

The trap here is that candidates often confuse automated investigation (which runs a predefined playbook) with live response (which provides manual, interactive access), leading them to select option D because they think automation is the default way to respond to alerts.

How to eliminate wrong answers

Option A is wrong because creating a custom detection rule is a proactive measure to detect future similar processes, not a method to investigate an already triggered alert on a specific VM. Option B is wrong because a vulnerability assessment scan identifies missing patches or misconfigurations, not the behavior or details of a currently running suspicious process. Option D is wrong because initiating an automated investigation triggers a predefined playbook that may automatically remediate or gather data, but it does not provide the interactive, real-time forensic access needed to manually examine the specific process in depth.

Full explanation →

954

MCQmedium

Your organization uses Microsoft Sentinel and Microsoft Defender for Cloud. You need to ensure that all security alerts from Defender for Cloud are automatically ingested into Sentinel with the least latency. What should you configure?

A.Configure a custom API connector in Sentinel to pull alerts from Defender for Cloud REST API every 5 minutes.

B.Enable continuous export in Defender for Cloud to send alerts to a Log Analytics workspace and then create a scheduled query in Sentinel.

C.Use the Microsoft Defender for Cloud data connector in Sentinel to stream alerts.

D.Create a Logic App that triggers on Defender for Cloud alerts and sends them to Sentinel via the Azure Monitor HTTP Data Collector API.

AnswerC

The Microsoft Defender for Cloud data connector is a built-in, native integration that streams security alerts and recommendations directly into Sentinel's SecurityAlert table in near real-time, without requiring custom code or polling intervals. It automatically synchronizes alert status, severity, and entities, allowing Sentinel to create incidents immediately and making it the lowest-latency, lowest-maintenance approach.

Why this answer

The Microsoft Defender for Cloud data connector in Microsoft Sentinel provides a native, direct integration that streams security alerts from Defender for Cloud into Sentinel with near-real-time latency. This connector uses the underlying Azure Resource Graph and alert APIs to push alerts automatically, eliminating the need for custom polling or additional orchestration, which ensures the least possible ingestion delay.

Exam trap

The trap here is that candidates often overcomplicate the solution by choosing custom integration methods (Logic Apps, API polling) or multi-step exports, failing to recognize that Microsoft's native data connector is specifically designed for this exact purpose with minimal latency and configuration.

How to eliminate wrong answers

Option A is wrong because a custom API connector polling the Defender for Cloud REST API every 5 minutes introduces a minimum 5-minute latency and adds unnecessary complexity, whereas the native connector streams alerts continuously with lower latency. Option B is wrong because continuous export sends alerts to a Log Analytics workspace, but then using a scheduled query in Sentinel to ingest them adds additional delay and requires manual configuration; the native connector directly streams alerts without intermediate steps. Option D is wrong because a Logic App triggered on Defender for Cloud alerts and using the Azure Monitor HTTP Data Collector API introduces additional latency from the trigger, execution, and data transfer, and is less efficient than the direct streaming provided by the native data connector.

Full explanation →

955

MCQeasy

Your threat hunting team uses Microsoft Sentinel. They want to search for anomalous network connections to known malicious IP addresses over the past 7 days. Which KQL operator should they use to match the source IP addresses against a watchlist containing the malicious IPs?

A.where

B.in

C.has

D.contains

AnswerB

The in operator tests whether a value exists in a dynamic list or watchlist, so source IPs can be matched directly against the malicious IP set. It satisfies the requirement to compare network connection sources with watchlist entries over the past seven days.

Why this answer

The 'in' operator is the correct choice because it checks whether a value (the source IP) exists within a specified set — here, the dynamic list of malicious IPs pulled from a Sentinel watchlist via _GetWatchlist(). This is the idiomatic KQL pattern for matching against watchlists and produces an efficient membership test rather than a substring search.

Exam trap

SC-200 often tests the confusion between substring operators ('contains'/'has') and set-membership ('in'), tricking candidates into picking 'contains' for exact indicator matching against watchlists.

How to eliminate wrong answers

Option A is wrong because 'where' is a tabular filter operator that selects rows based on a predicate; it is not itself a membership operator and must be combined with something like 'in' to compare against a watchlist. Option C is wrong because 'has' performs a term-based (indexed) match suited to full-text token searches, not exact IP membership, and can produce false matches on tokenized strings. Option D is wrong because 'contains' does a case-insensitive substring match, which is slower and can incorrectly match partial IP strings (e.g., '10.0.0.1' inside '10.0.0.10').

Full explanation →

956

MCQmedium

A security analyst is investigating a malware incident and has identified a specific parent process ID (PID) on an endpoint. The analyst wants to retrieve all outbound network connections made by any child processes spawned by this parent process. Which advanced hunting table should the analyst query to get the network connection details, including the destination IP and the child process ID?

A.DeviceProcessEvents

B.DeviceNetworkEvents

C.DeviceEvents

D.IdentityNetworkEvents

AnswerB

DeviceNetworkEvents is the correct table because it captures endpoint-level network connections initiated by processes, including the remote IP address, remote port, protocol, and the initiating process ID (and often the process name). By filtering on the compromised device and looking for suspicious outbound activity, you can directly identify the malicious C2 endpoint. This is the dedicated Advanced Hunting schema for network telemetry on devices.

Why this answer

DeviceNetworkEvents is the correct table because it specifically captures outbound network connections, including destination IP addresses and process IDs (PID). By filtering on the parent process ID and then joining or filtering on child process IDs, the analyst can trace all network connections initiated by child processes spawned from the identified parent PID.

Exam trap

The trap here is that candidates often confuse DeviceProcessEvents (which shows process ancestry) with DeviceNetworkEvents (which shows actual network flows), mistakenly thinking process creation logs include network details, when in fact you need the network-specific table to retrieve destination IPs and child process IDs.

How to eliminate wrong answers

Option A is wrong because DeviceProcessEvents logs process creation events (e.g., command lines, parent PID) but does not include network connection details such as destination IP or port. Option C is wrong because DeviceEvents captures security-related events (e.g., Windows Defender alerts, file modifications) but not raw network connection logs. Option D is wrong because IdentityNetworkEvents is part of Microsoft Defender for Identity and tracks network activities related to identity-based attacks (e.g., Kerberos, NTLM) on domain controllers, not endpoint outbound connections from arbitrary child processes.

Full explanation →

957

MCQmedium

An organization ingests Windows Security Events into Microsoft Sentinel via the Security Events connector. An analyst wants to create a scheduled analytics rule that alerts when more than 10 failed logon events (Event ID 4625) occur for the same user within a 5-minute window. Which KQL operator should the analyst use to count events per user in that time window?

A.summarize

B.extend

C.project

D.where

AnswerA

summarize is the KQL operator that groups rows by one or more key expressions, such as User and bin(TimeGenerated, 1h), and then computes aggregate values over each group with functions like count(), dcount(), or sum(). It returns exactly one output row per unique combination of grouping keys, which reduces the event-level rows into the desired per-user, per-time-bin statistics. Using summarize count() by User, bin(TimeGenerated, 1h) on the Windows security events table directly answers this requirement, so summarize is the correct choice.

Why this answer

The `summarize` operator is correct because it groups events by user and then applies an aggregation function (like `count()`) to calculate the number of failed logon events per user within the 5-minute window. This directly supports the rule's requirement to count events per user and compare the count to a threshold of 10.

Exam trap

The trap here is that candidates often confuse `summarize` with `extend` or `project`, mistakenly thinking that adding a calculated column or selecting columns can perform grouping and counting, when only `summarize` provides aggregation capabilities.

How to eliminate wrong answers

Option B (`extend`) is wrong because it creates new calculated columns for each row but does not group or aggregate data, so it cannot count events per user. Option C (`project`) is wrong because it selects or reorders columns without performing any aggregation or grouping. Option D (`where`) is wrong because it filters rows based on a condition but does not count or group events per user.

Full explanation →

958

MCQhard

A security analyst is using Microsoft 365 Defender advanced hunting to investigate potential lateral movement. The analyst has identified a compromised device (DeviceA) and wants to find all other devices that initiated a remote desktop connection from DeviceA to other devices in the last 24 hours. Which table and query approach should the analyst use?

A.Query DeviceNetworkEvents for events from DeviceA with RemotePort 3389, then join with DeviceInfo to get target device names.

B.Query DeviceLogonEvents for LogonType 10 (RemoteInteractive), filtering by initiating device.

C.Query IdentityLogonEvents to find logons associated with DeviceA.

D.Query EmailEvents to find emails sent from DeviceA that contain RDP configuration files.

AnswerA

DeviceNetworkEvents in Microsoft 365 Defender Advanced Hunting records network connection attempts by managed devices, including the destination IP and port (RemotePort) and the initiating device ID. Filtering for DeviceA and RemotePort 3389 isolates RDP traffic leaving that device, and joining to DeviceInfo on RemoteIP resolves the target device name for each inbound connection. This directly answers which devices DeviceA connected to via RDP.

Why this answer

DeviceNetworkEvents logs network connections, including outbound RDP traffic (port 3389). By filtering for events from DeviceA with RemotePort 3389, the analyst captures all RDP connections initiated by DeviceA. Joining with DeviceInfo resolves the target IP addresses to device names, providing a complete list of devices that received an RDP connection from DeviceA in the last 24 hours.

Exam trap

The trap here is that candidates confuse 'initiating an RDP connection' (network-level outbound connection) with 'successful RDP logon' (authentication event on the target), leading them to incorrectly choose DeviceLogonEvents with LogonType 10 instead of DeviceNetworkEvents.

How to eliminate wrong answers

Option B is wrong because DeviceLogonEvents with LogonType 10 (RemoteInteractive) records successful interactive logons on the target device, not the initiation of an RDP connection from the source device; it would show logons on DeviceA from other devices, not connections from DeviceA to others. Option C is wrong because IdentityLogonEvents tracks authentication events at the identity level (e.g., Azure AD logons), not device-level network connections or RDP session initiations. Option D is wrong because EmailEvents logs email traffic, not network connections; RDP configuration files attached to emails are irrelevant to detecting actual RDP connections made from DeviceA.

Full explanation →

959

MCQmedium

A security analyst is performing threat hunting in Microsoft Sentinel and wants to identify anomalous outbound network connections from a compromised workstation. The analyst suspects that a beaconing pattern is present. Which KQL function is most appropriate to detect periodic beaconing behavior over time?

A.series_decompose(TimeGenerated)

B.make_list(TimeGenerated)

C.startofday(TimeGenerated)

D.bin(TimeGenerated, 1h)

AnswerC

startofday(TimeGenerated) truncates each timestamp to the beginning of its calendar day, so grouping by this expression counts events per day. For a host that beacons once daily, the daily event count will remain consistently near one per day, making the periodic pattern easy to spot with a simple summarize query. This directly aligns with the hypothesis of a daily beacon and is the most appropriate choice among the options for detecting periodicity in typical C2 traffic.

Why this answer

`startofday` groups timestamps by day, enabling analysts to count events per day and identify regular intervals characteristic of beaconing (e.g., daily connections). Option A is incorrect: `series_decompose` is used for time series decomposition (trend, seasonal, residual) but is not the most direct method for detecting periodic beaconing; it is more complex and typically used after aggregation. Option B is incorrect: `make_list` creates a list of values, not useful for periodicity detection.

Option D is incorrect: `bin(TimeGenerated, 1h)` bins events into hourly buckets, which could detect beaconing at finer granularity, but daily beaconing is better suited to `startofday`; `bin` is not specifically for periodic pattern detection.

Full explanation →

960

MCQhard

You have a Microsoft Sentinel automation rule that triggers a playbook. The playbook definition is shown in the exhibit. The playbook runs but no email is sent. What is the most likely cause?

A.The JSON syntax is invalid.

B.The email operation 'SendEmailV2' is deprecated.

C.The playbook uses a recurrence trigger instead of a Microsoft Sentinel trigger.

D.The connection name 'office365' is incorrect.

AnswerC

This is correct because automation rules require a playbook to start with a Microsoft Sentinel trigger (such as 'When Incident Created or Updated') to receive the incident payload. A recurrence trigger runs on a fixed schedule and does not accept any incident-specific parameters, so the automation rule cannot pass the incident ARM ID or properties to the playbook. As a result, the rule's action to run the playbook either fails validation or the playbook runs without the necessary incident context.

Why this answer

The playbook uses a recurrence trigger, which means it runs on a schedule (e.g., every hour) rather than being invoked by a Microsoft Sentinel incident or alert. A Microsoft Sentinel automation rule can only trigger a playbook that has a Microsoft Sentinel trigger (e.g., 'When a response to a Microsoft Sentinel incident is triggered'). Without the correct trigger, the playbook will execute on its schedule but will not receive the incident context or be invoked by the automation rule, so no email is sent.

Exam trap

The trap here is that candidates assume any playbook that runs will work with an automation rule, but the trigger type must match the automation rule's invocation method; a recurrence trigger runs independently and does not receive the incident context, causing the email to fail silently.

How to eliminate wrong answers

Option A is wrong because if the JSON syntax were invalid, the playbook would fail to save or would show a syntax error in the designer; it would not run at all. Option B is wrong because 'SendEmailV2' is a current, supported operation in Microsoft Sentinel and Logic Apps; it is not deprecated. Option D is wrong because an incorrect connection name would cause a connection error at runtime, not a silent failure where the playbook runs but no email is sent; the connection name is validated when the playbook is saved or run.

Full explanation →

961

Multi-Selectmedium

Which TWO of the following are valid methods to detect Kerberoasting attacks during a threat hunt? (Select TWO.)

Select 2 answers

A.Service account logon events with RC4 encryption type.

B.Multiple Kerberos TGS requests from a single user account to multiple service accounts.

C.Unusual number of LDAP queries from a domain controller.

D.High volume of NTLM authentication failures from a single IP.

E.Detection of forged Kerberos tickets (Golden Ticket) in the domain.

AnswersA, B

Kerberoasting requests RC4-encrypted service tickets, so hunting for service account logon events showing RC4 (0x17) encryption type exposes the attack, since legitimate modern service authentication typically negotiates AES. This satisfies the stem's detection requirement by targeting the encryption downgrade inherent to extracting crackable ticket hashes.

Why this answer

Option A is correct because Kerberoasting requests TGS tickets for service accounts and the attacker typically requests RC4 (etype 0x17) encryption to make offline cracking of the service account hash easier, so service account logon events showing RC4 encryption (Event ID 4769 with Ticket Encryption Type 0x17) are a strong hunting indicator. Option B is correct because a single user account rapidly requesting multiple TGS tickets for many different service accounts (SPNs) is a hallmark of automated Kerberoasting enumeration and ticket harvesting. Option C is not specific to Kerberoasting, since LDAP query volume anomalies can reflect many other reconnaissance or administrative activities.

Option D concerns NTLM authentication failures, which are unrelated to Kerberos TGS abuse. Option E describes Golden Ticket detection, which involves forged TGTs and KRBTGT compromise, not Kerberoasting's TGS request behavior.

Full explanation →

962

MCQeasy

Your organization is migrating from Azure Active Directory to Microsoft Entra ID. You need to ensure that Microsoft Sentinel continues to receive identity logs. What should you do?

A.Install the new Microsoft 365 Defender connector for identity logs.

B.No action is required; the existing connector automatically updates.

C.Reconfigure the diagnostic settings to send logs to a new Log Analytics workspace.

D.Create a new data connector for Microsoft Entra ID.

AnswerB

No action is required because the Microsoft Entra ID connector (formerly Azure AD) uses the same underlying Microsoft Graph API endpoints; the rebranding does not change the data schema or the retrieval method. The connector automatically inherits the updated display name and continues sending audit and sign-in logs to the same Log Analytics workspace. Recreating or reinstalling it would introduce unnecessary disruption and potential data gaps.

Why this answer

The migration from Azure Active Directory (Azure AD) to Microsoft Entra ID is a rebranding and consolidation effort that does not change the underlying service endpoints, APIs, or log schemas. The existing Azure AD data connector in Microsoft Sentinel continues to collect identity logs (e.g., Sign-in logs, Audit logs, Provisioning logs) without any reconfiguration because the connector is tied to the same underlying directory service. Therefore, no action is required; the existing connector automatically updates to reflect the new name.

Exam trap

The trap here is that candidates assume a rebranding or migration requires reconfiguring connectors or creating new ones, when in fact the underlying service and API endpoints remain unchanged, so the existing connector continues to function automatically.

How to eliminate wrong answers

Option A is wrong because the Microsoft 365 Defender connector is designed for security alerts and incidents from Microsoft 365 Defender, not for identity logs like Sign-in or Audit logs; identity logs are collected via the Azure AD (now Entra ID) connector. Option C is wrong because diagnostic settings are used to stream resource logs (e.g., from Azure resources) to a Log Analytics workspace, but identity logs from Entra ID are ingested via the dedicated data connector, not through diagnostic settings; reconfiguring diagnostic settings would not affect the existing connector. Option D is wrong because creating a new data connector for Microsoft Entra ID is unnecessary and would duplicate data ingestion; the existing Azure AD connector is automatically updated to reflect the Entra ID branding and continues to function without manual intervention.

Full explanation →

963

MCQmedium

Your organization uses Microsoft Defender for Identity (MDI) and Microsoft Sentinel. You notice that MDI alerts are not appearing in Sentinel. You have already installed the MDI data connector and configured the workspace. What is the most likely cause?

A.The workspace is in a different region than MDI

B.The Microsoft 365 Defender connector is not installed

C.The data connector is not enabled, even though it is installed

D.Microsoft Defender for Identity is not licensed

AnswerC

Installing the Microsoft Defender for Identity data connector from the Content Hub only copies the connector into your Sentinel workspace; you must separately enable it by opening the connector page and clicking 'Connect' to establish the data flow. In the common scenario where the connector is installed but not enabled, the Health and Status column shows 'Disconnected' while the connector still appears as installed. Without this explicit enablement step, even an active MDI deployment will not send alerts to Sentinel, so the alerts remain missing from the workspace.

Why this answer

The most likely cause is that the MDI data connector, although installed, is not enabled. In Microsoft Sentinel, installing a data connector only makes it available; you must explicitly enable it to start ingesting data. Without enabling the connector, alerts from Microsoft Defender for Identity will not flow into Sentinel, even if the workspace is correctly configured.

Exam trap

The trap here is that candidates confuse 'installed' with 'enabled', assuming that installing a data connector automatically starts data ingestion, when in fact a separate enablement step is required.

How to eliminate wrong answers

Option A is wrong because the workspace region does not affect data ingestion from MDI; Sentinel and MDI can operate in different regions as long as the connector is properly enabled. Option B is wrong because the Microsoft 365 Defender connector is not required for MDI alerts; MDI has its own dedicated data connector in Sentinel. Option D is wrong because the question states that MDI alerts are being generated (you notice they are not appearing in Sentinel), which implies MDI is already licensed and functioning; the issue is specifically with the connector's enabled state.

Full explanation →

964

Multi-Selecthard

Which THREE of the following are key steps when containing a ransomware incident in Microsoft Defender XDR? (Select THREE.)

Select 3 answers

A.Restore encrypted files from backup

B.Block known malicious file hashes via Indicators of compromise

C.Disable compromised user accounts in Microsoft Entra ID

D.Analyze the root cause of the outbreak

E.Isolate compromised devices using Microsoft Defender for Endpoint

AnswersB, C, E

Blocking known malicious file hashes through indicators of compromise directly satisfies the containment requirement by preventing execution of identified ransomware binaries across endpoints. Custom file-hash indicators in Microsoft Defender XDR enforce immediate prevention, halting lateral spread while investigation continues, and this deterministic, signature-based control is a recognised containment step.

Why this answer

Blocking malicious file hashes via indicators of compromise (B), disabling compromised user accounts (C), and isolating compromised devices (E) are key steps in containing a ransomware incident. Restoring from backup (A) is part of recovery, and analyzing root cause (D) is part of investigation, both of which occur after containment.

Full explanation →

965

MCQmedium

Your SOC team uses Microsoft Sentinel to manage incidents. You want to categorize incidents based on the MITRE ATT&CK technique. You notice that some incidents are not being tagged with the correct technique. What should you check first?

A.The playbook assigned to the incident is overriding the technique tag.

B.The incident creation rule in the automation section is misconfigured.

C.The data connector for the source service is not ingesting the required fields.

D.The analytics rule that generated the incident has the correct MITRE ATT&CK technique selected.

AnswerD

MITRE ATT&CK technique tagging is defined on the analytics rule itself; if the rule lacks the correct technique mapping, generated incidents inherit nothing. Checking the rule's technique selection addresses the root cause of missing tags.

Why this answer

MITRE ATT&CK technique tags on a Microsoft Sentinel incident are inherited directly from the analytics (detection) rule that generated the incident. If the rule was created without the correct technique mapped — or the mapping was later edited — every incident it produces will carry the wrong or missing tag. The first place to verify is therefore the analytics rule's 'Incident settings' / 'MITRE ATT&CK' mapping, not downstream automation.

Exam trap

SC-200 often tests the assumption that automation (playbooks or automation rules) can rewrite incident metadata like MITRE technique tags, when in fact the analytics rule is the authoritative source.

How to eliminate wrong answers

Option A is wrong because playbooks (Logic Apps) run after incident creation and do not natively rewrite the MITRE technique taxonomy field — they can add comments, tags, or tasks, but the technique mapping is set by the analytics rule. Option B is wrong because automation rules control triage actions (assign, tag, close, run playbook) and do not author the ATT&CK technique metadata on the incident. Option C is wrong because a data connector that fails to ingest fields would prevent the rule from firing at all or produce malformed events, not silently mis-tag the technique on an incident that was successfully created.

Full explanation →

966

MCQhard

Your organization uses Microsoft Defender for Cloud Apps. You receive an alert about an impossible travel activity for a user. What is the best first step to validate if this is a true positive?

A.Block the user immediately

B.Run an advanced hunting query in Microsoft Sentinel

C.Contact the user's manager

D.Review the user's sign-in logs in Microsoft Entra ID

E.Check the user's device compliance in Microsoft Intune

AnswerD

Reviewing the user's sign-in logs in Microsoft Entra ID is the correct first step because these logs contain the authenticated IP address, exact timestamp, and geolocation data needed to corroborate the anomalous travel activity. This source of truth allows you to verify whether the second sign-in actually occurred from the reported location and whether it was a legitimate authentication. It provides the required evidence to decide whether further action is warranted.

Why this answer

Impossible travel alerts in Microsoft Defender for Cloud Apps are generated based on sign-in activity and user location data. The most direct way to validate whether the alert is a true positive is to review the user's sign-in logs in Microsoft Entra ID (formerly Azure AD), which provides detailed information about each sign-in attempt, including IP addresses, locations, timestamps, and authentication details. This allows you to confirm whether the two sign-ins occurred within an unrealistic time frame for the geographic distance, or if there are anomalies such as VPN usage or IP spoofing that indicate a false positive.

Exam trap

The trap here is that candidates often jump to advanced hunting in Sentinel (Option B) as the first step, forgetting that the alert originates from Defender for Cloud Apps and the most immediate and authoritative source for sign-in details is the Entra ID sign-in logs, which are the same data that Defender for Cloud Apps uses to generate the alert.

How to eliminate wrong answers

Option A is wrong because immediately blocking the user without investigation could disrupt legitimate access and does not validate the alert; it is a reactive action, not a validation step. Option B is wrong because running an advanced hunting query in Microsoft Sentinel is a deeper investigation step that may be appropriate after initial validation, but it is not the best first step when the alert originates from Defender for Cloud Apps and the sign-in logs in Entra ID are the primary source for immediate verification. Option C is wrong because contacting the user's manager is a secondary step that relies on human confirmation and does not provide technical evidence; it should be done after reviewing logs to gather context.

Option E is wrong because checking the user's device compliance in Microsoft Intune addresses device health and policy compliance, which is unrelated to verifying the geographic plausibility of sign-in events in an impossible travel scenario.

Full explanation →

967

MCQeasy

Your organization uses Microsoft Sentinel for security operations. You need to ensure that a specific AWS CloudTrail log is ingested into Microsoft Sentinel. Which data connector should you use?

A.AWS CloudTrail Connector

B.Amazon Web Services S3 Connector

C.Azure Functions (AWS)

D.AWS Security Hub Connector

AnswerB

The AWS S3 connector is the correct data connector because it directly ingests CloudTrail log files from an S3 bucket into Microsoft Sentinel. It uses an Azure Functions app to poll the bucket or subscribe to an SQS queue, retrieving CloudTrail JSON objects and translating them into the AWSCloudTrail table. This makes it the sole standard first-party connector for shipping CloudTrail logs into the SIEM.

Why this answer

The Amazon Web Services S3 Connector is the correct choice because AWS CloudTrail logs are stored as JSON files in an S3 bucket. Microsoft Sentinel ingests these logs by connecting directly to the S3 bucket, reading the CloudTrail log files, and pulling them into the Log Analytics workspace. The AWS CloudTrail Connector, by contrast, is a legacy connector that requires a separate AWS Lambda function and is deprecated in favor of the S3 connector.

Exam trap

The trap here is that candidates confuse the legacy AWS CloudTrail Connector (Option A) with the modern Amazon Web Services S3 Connector, assuming the name 'CloudTrail' is the correct match, when in fact the S3 connector is the current recommended method for ingesting CloudTrail logs.

How to eliminate wrong answers

Option A is wrong because the AWS CloudTrail Connector is a legacy connector that requires an AWS Lambda function to forward logs, and it is deprecated in favor of the Amazon Web Services S3 Connector. Option C is wrong because Azure Functions (AWS) is a generic compute service used for custom integrations, not a dedicated data connector for CloudTrail logs. Option D is wrong because the AWS Security Hub Connector ingests security findings from AWS Security Hub, not raw CloudTrail log files.

Full explanation →

968

MCQmedium

Your organization uses Microsoft Defender for Cloud Apps. You need to block downloads from a specific app for users outside the corporate network. What should you configure?

A.A session policy

B.An anomaly detection alert

C.A file policy

D.An access policy

AnswerA

A session policy is correct because it operates in real time using Conditional Access App Control to reverse-proxy user actions, enabling granular controls such as blocking a download based on the user's geolocation. Session policies are the only option here that can intercept and enforce at the individual action level within an active application session, not just at sign-in or post-hoc.

Why this answer

A session policy in Microsoft Defender for Cloud Apps allows you to monitor and control user activities in real time by leveraging reverse proxy architecture. To block downloads from a specific app for users outside the corporate network, you configure a session policy with the action 'Block' and apply a condition based on the IP address tag (e.g., 'Not corporate IP range'). This enforces the restriction at the moment the user attempts to download, without affecting other app activities.

Exam trap

The trap here is confusing access policies (which control sign-in) with session policies (which control in-session actions), leading candidates to choose D when they need granular action-level control.

How to eliminate wrong answers

Option B is wrong because an anomaly detection alert only generates alerts for suspicious behavior (e.g., impossible travel) but does not actively block downloads; it is a detection-only control. Option C is wrong because a file policy is designed to scan and govern files at rest (e.g., DLP for stored content) and cannot enforce real-time download blocking based on network location. Option D is wrong because an access policy controls authentication and authorization (e.g., requiring MFA or blocking sign-in) but does not granularly block specific actions like downloads within a session.

Full explanation →

969

Multi-Selectmedium

Which THREE actions are recommended practices for managing Microsoft Sentinel costs?

Select 3 answers

A.Set daily caps on high-volume tables.

B.Use Basic Logs tier for verbose logs.

C.Implement ingestion-time data transformation to filter out noise.

D.Ingest all logs to ensure complete visibility.

E.Increase retention period to 1 year for all tables.

AnswersA, B, C

Setting a daily cap on high-volume tables is a cost-control safeguard that stops ingestion once the defined quota is reached, preventing runaway spend from unexpected data spikes. However, you must configure the cap carefully so that critical security telemetry is not dropped during an incident, since any data exceeding the cap is discarded. This practice is explicitly recommended in Microsoft Sentinel and Log Analytics cost optimization guidance.

Why this answer

Setting daily caps on high-volume tables is a recommended practice because it prevents unexpected cost overruns by limiting the amount of data ingested into expensive tables like SecurityEvent or CommonSecurityLog. Microsoft Sentinel bills per GB ingested, so capping tables that generate large volumes of noise (e.g., verbose Windows event logs) directly controls costs without necessarily impacting security visibility, as critical alerts can still be generated from other sources.

Exam trap

The trap here is that candidates often confuse 'complete visibility' (Option D) with best practice, but Microsoft Sentinel explicitly recommends filtering noise at ingestion to reduce costs and improve signal-to-noise ratio, not ingesting everything.

Full explanation →

970

Multi-Selectmedium

Which TWO roles are included in Microsoft Sentinel built-in roles? (Choose two.)

Select 2 answers

A.Microsoft Sentinel Responder

B.Microsoft Sentinel Administrator

C.Microsoft Sentinel Reader

D.Microsoft Sentinel Operator

E.Global Administrator

AnswersA, C

Microsoft Sentinel Responder is a built-in role intended for security operations analysts who need to triage and manage incidents. It grants permissions to view and act on incidents, including changing their status, assigning ownership, and adding comments, while deliberately excluding write access to Sentinel configuration such as analytics rules or data connectors. This role supports day-to-day incident response without enabling broad changes to the Sentinel environment.

Why this answer

Microsoft Sentinel Responder is a built-in role that grants permissions to respond to incidents, including the ability to update incidents, dismiss alerts, and take response actions. This role is designed for security operations center (SOC) analysts who need to triage and remediate threats without full administrative access.

Exam trap

The trap here is that candidates often confuse the 'Operator' role name with a valid built-in role, or assume 'Administrator' is a built-in role when the correct term is 'Contributor', leading them to select incorrect options that sound plausible but do not exist in Sentinel's RBAC model.

Full explanation →

971

Multi-Selecteasy

Which TWO are valid incident management actions in Microsoft Sentinel? (Choose two.)

Select 2 answers

A.Merge two incidents into one

B.Export the incident to a CSV file

C.Change the incident status to 'Closed'

D.Delete an incident

E.Assign the incident to another analyst

AnswersC, E

Changing an incident's status to 'Closed' is a valid and common incident-management action in Microsoft Sentinel. The status lifecycle includes New, In Progress, and Closed, and closing an incident indicates that it has been resolved and requires no further action. When closing, you must choose a classification (such as True Positive or False Positive) and optionally a reason, which helps preserve metadata for reporting and auditing purposes.

Why this answer

Changing an incident's status to 'Closed' is a standard incident management action in Microsoft Sentinel. This action finalizes the incident after investigation and remediation, and it is a core part of the incident lifecycle within the Sentinel workspace.

Exam trap

The trap here is that candidates may confuse incident management actions in Microsoft Sentinel with those in other SIEMs (like Splunk or QRadar) where merging or deleting incidents is common, leading them to select options A or D incorrectly.

Full explanation →

972

MCQhard

A security analyst in Microsoft Sentinel wants to correlate Microsoft Entra ID sign-in logs with IP addresses known to be associated with a threat actor. The threat actor's IPs are stored in a custom table named 'ThreatIntelligence_IP' that is ingested daily. The analyst needs to create an analytics rule that triggers only when a sign-in occurs from one of these IPs AND when the user is not in a list of approved users (stored in another custom table 'ApprovedUsers'). Which KQL query pattern should the analyst use to achieve this correlation and filtering?

A.SigninLogs | join ThreatIntelligence_IP on IPAddress | where UserId notin (ApprovedUsers | project UserId)

B.SigninLogs | where IPAddress in (ThreatIntelligence_IP | project IPAddress) and UserId !in (ApprovedUsers | project UserId)

C.SigninLogs | join kind=inner ThreatIntelligence_IP on IPAddress | join kind=leftanti (ApprovedUsers | project UserId) on $left.UserId == $right.UserId

D.SigninLogs | join ThreatIntelligence_IP on IPAddress | where not(UserId in (ApprovedUsers | project UserId))

AnswerC

This is the correct pattern. The first join uses `kind=inner`, which explicitly returns only matching rows from both sides without deduplicating the left-side SigninLogs rows—unlike the default `innerunique`—thereby preserving all sign-in events from threat-actor IPs. The second join uses `kind=leftanti` to keep every row from the left that has no match in the ApprovedUsers table on UserId, which is the exact semantic needed to exclude approved users. Both joins are optimized by the Kusto engine using hash-based algorithms, making this approach both logically clear and performant for large Sentinel tables.

Why this answer

It uses a `join kind=inner` to match sign-in logs with threat IPs, ensuring only sign-ins from known malicious IPs are considered. It then applies a `join kind=leftanti` to exclude any user who appears in the ApprovedUsers table, effectively filtering out approved users. This pattern guarantees that the rule triggers only when both conditions are met: the IP is in the threat list and the user is not approved.

Exam trap

The trap here is that candidates often choose Option B thinking that `in` and `!in` with subqueries are the simplest way to filter, but they overlook that KQL requires proper join semantics for correlating two tables, and that `in` with a table expression may not work as expected in all contexts, especially when the subquery returns multiple rows or columns.

How to eliminate wrong answers

Option A is wrong because it uses a `join` without specifying a join kind, which defaults to `innerunique` and may produce duplicate or unexpected results, and the `where` clause after the join does not properly exclude approved users as a set operation. Option B is wrong because it uses `in` and `!in` operators with subqueries that are not supported in the `where` clause for table expressions; KQL requires `in` to work with a list or a subquery that returns a single column, but the syntax `UserId !in (ApprovedUsers | project UserId)` is valid only if the subquery is enclosed in parentheses and the table is referenced correctly, but the main issue is that `IPAddress in (ThreatIntelligence_IP | project IPAddress)` is inefficient and may cause performance issues or incorrect results due to lack of proper join semantics. Option D is wrong because it uses a `join` without specifying a kind (defaulting to `innerunique`), and the `where` clause with `not(UserId in (...))` is syntactically incorrect as `not` cannot be applied to an `in` operator in that way; the correct syntax would be `where UserId !in (...)`.

Full explanation →

973

Multi-Selecteasy

Your organization uses Microsoft 365 Defender. During an incident, which TWO actions can be taken directly from the Microsoft 365 Defender portal to remediate a compromised email account?

Select 2 answers

A.Remove mailbox delegation permissions.

B.Block the sender's email address in the tenant's allow/block list.

C.Soft delete malicious emails from the user's mailbox.

D.Reset the user's password and revoke sessions.

E.Isolate the user's mailbox from receiving emails.

AnswersC, D

Soft delete moves the malicious messages to the Recoverable Items folder, removing them from the user's inbox while retaining them for investigation or restore. This satisfies remediation directly from the Microsoft 365 Defender portal without permanent data loss.

Why this answer

Option C is correct because the Microsoft 365 Defender portal (via the Email & collaboration > Explorer/Threat Explorer remediation actions) lets responders soft delete malicious emails from a user's mailbox, moving them to the Recoverable Items folder so they can be purged or restored. Option D is correct because the portal's action center and user investigation page provide 'Reset password' and 'Revoke sessions' actions, which force a password change and invalidate existing authentication tokens to cut off an attacker's access. Option A is not a direct remediation action offered in the Defender portal for a compromised account, and mailbox delegation is managed through Exchange admin center/PowerShell.

Option B is a preventive tenant-level allow/block list change, not an account remediation action, and it targets a sender address rather than the compromised mailbox. Option E is not a supported action; mail flow cannot be selectively 'isolated' for a mailbox from the Defender portal.

Exam trap

The trap is selecting plausible-sounding but non-native actions (blocking sender, isolating mailbox) instead of the two remediation actions actually exposed in the M365 Defender portal for a compromised account.

Full explanation →

974

MCQhard

A company uses Microsoft Defender for Cloud with Defender for Servers enabled. The security team wants to receive an alert when a new user is added to the local Administrators group on a Windows virtual machine. Which data source must be enabled in Defender for Cloud to capture this event?

A.Enable the collection of Windows Security Event Log events (e.g., Event ID 4732) through the Log Analytics agent configuration.

B.Enable Just-in-Time (JIT) VM access on the virtual machine.

C.Enable Adaptive Application Controls (AAC) for the virtual machine.

D.Enable Azure Defender for SQL on the subscription.

AnswerA

Correct. Local group changes are captured via Windows security event 4732. To get this into Defender for Cloud, you must ensure the Log Analytics agent is collecting security events and that the required audit policies are in place.

Why this answer

The event of adding a user to the local Administrators group on Windows is logged as Security Event ID 4732. To capture this event in Defender for Cloud, the Log Analytics agent must be configured to collect Windows Security Event Log events, which includes Event ID 4732. This data source enables Defender for Cloud to generate security alerts based on such privileged group modifications.

Exam trap

The trap here is that candidates may confuse data collection sources (e.g., JIT, AAC, or SQL Defender) with the specific Windows Security Event Log required to detect local group membership changes, assuming any security control can generate the alert.

How to eliminate wrong answers

Option B is wrong because Just-in-Time (JIT) VM access controls network access to management ports (e.g., RDP, SSH) and does not capture local group membership changes. Option C is wrong because Adaptive Application Controls (AAC) define allowlists for running applications on VMs and do not monitor or alert on user account modifications. Option D is wrong because Azure Defender for SQL is a plan for securing SQL databases and servers, not for monitoring local user group changes on Windows VMs.

Full explanation →

975

MCQmedium

During a threat hunt in Microsoft Sentinel, you want to find hosts that began communicating with a newly registered domain shortly after a suspicious process executed on the same host. Your data is in DeviceProcessEvents and DeviceNetworkEvents. Which approach best correlates process execution and subsequent network connections on the same device within a time window?

A.Join DeviceProcessEvents and DeviceNetworkEvents on DeviceId with a time-window condition that places the network event after the process event

B.Union DeviceProcessEvents and DeviceNetworkEvents and filter by timestamp

C.Summarize each table by DeviceId and compare the resulting counts

D.Join the two tables on the process name and remote IP address

AnswerA

Joining on DeviceId and constraining the network timestamp to fall shortly after the process timestamp links the suspicious execution to the outbound connection on the same host. This preserves the causal sequence the hunt hypothesis depends on and avoids correlating unrelated activity.

Why this answer

Correlating execution to later network activity requires a device-scoped join with a temporal constraint. Joining on DeviceId and requiring the network timestamp to be later than the process timestamp, within a bounded window, preserves causality and keeps unrelated hosts out of the result, which is what the hunt hypothesis needs.

Exam trap

The trap here is joining on process name or remote IP, which are not unique identifiers, instead of using DeviceId with an explicit time-window condition.

Full explanation →

Microsoft Security Operations Analyst SC-200 (SC-200) — Questions 901–975