How many Troubleshooting Scenario Questions questions are on this page?

This page has 14 Troubleshooting Scenario Questions scenario questions for the SC-200 exam, each with detailed explanations and wrong-answer analysis.

How should I approach SC-200 scenario questions?

Read the full scenario before looking at the answer options. Identify the constraint or requirement in the scenario, then eliminate options that are generally true but wrong for this specific case. Scenario questions reward careful reading over pattern matching.

← Back to Microsoft Security Operations Analyst SC-200 questions

Scenario-based practice

Troubleshooting Scenario Questions

Practise Microsoft Security Operations Analyst SC-200 practice questions — original exam-style scenarios covering every exam domain, with detailed explanations, wrong-answer analysis, and common exam traps.

Start full practice test Read exam guide

scenario questions

SC-200

exam code

Microsoft

vendor

Scenario guide

How to approach troubleshooting scenario questions

These questions describe a network symptom and ask you to identify the root cause or the correct fix. They appear across all certification exams and reward systematic thinking over memorisation. The best candidates follow a consistent troubleshooting framework even under time pressure.

Quick answer

Troubleshooting Scenario Questions questions test whether you can apply the concept in context, not just recognise a definition.

How the topic appears in realistic exam-style scenarios.

Which detail in the question changes the correct answer.

How to eliminate plausible but wrong options.

How to connect the question back to the wider exam objective.

Practice scenarios

Question 1hardmultiple choice

Full question →

Your security team uses Microsoft Defender XDR (formerly Microsoft 365 Defender) to investigate incidents. You notice that some alerts from Microsoft Defender for Endpoint are not being automatically correlated into incidents as expected. You have confirmed that the relevant alert sources are enabled in the Microsoft Defender XDR portal. What is the most likely cause?

A
Alert tuning rules are causing the alerts to be excluded.
Why wrong: Tuning rules reduce alert volume but do not prevent incident creation from remaining alerts.
B
Incident correlation rules are not enabled for the relevant alert sources.
Correlation rules must be enabled to automatically create incidents from alerts.
C
Automation rules in Microsoft Sentinel are deleting the alerts.
Why wrong: Sentinel automation rules apply to Sentinel alerts, not Defender XDR incidents.
D
Alert suppression rules are blocking the alerts.
Why wrong: Suppression rules hide alerts but do not prevent incident creation.

Full breakdown with real-world context →

Question 2mediummultiple choice

Full question →

Your organization uses Microsoft Sentinel with Microsoft Defender XDR integrated. A critical incident has been raised involving a user account that was used to access a confidential SharePoint site from an unusual location at 2:00 AM. The incident includes alerts from Microsoft Defender for Cloud Apps, Microsoft Defender for Identity, and Microsoft Defender for Office 365. The analyst needs to contain the incident, investigate the scope, and begin remediation. The environment has the following: Microsoft Entra ID with conditional access policies, Microsoft Intune for device management, and Microsoft Defender for Endpoint on all devices. The analyst has identified the user account and the device used. Which course of action should the analyst take first?

A
Create a conditional access policy to block the user.
Why wrong: Policy may take minutes to propagate; disabling account is instant.
B
Isolate the user's device using Microsoft Defender for Endpoint.
Why wrong: Device isolation doesn't stop cloud access from other devices.
C
Run a KQL query to find all resources accessed by the user.
Why wrong: Investigation should follow containment.
D
Disable the user account in Microsoft Entra ID and revoke all sessions.
Immediately stops the user from accessing any resources.

Full breakdown with real-world context →

Question 3mediummultiple choice

Full question →

During a threat hunt, a security analyst uses Microsoft Sentinel and identifies a series of failed logon attempts from a single IP address targeting multiple user accounts. The analyst wants to create a scheduled analytics rule that generates an alert when the same IP address fails to logon to more than 10 different accounts within 5 minutes. Which KQL operator should be used to count distinct accounts per IP?

A
count()
Why wrong: count() counts all events, not distinct user accounts.
B
summarize count() by Account
Why wrong: This counts events per account, not distinct accounts across events.
C
distinct Account
Why wrong: distinct returns unique accounts but does not count them.
D
dcount(Account)
dcount provides an approximate distinct count of accounts, suitable for performance.

Full breakdown with real-world context →

Question 4hardmultiple choice

Full question →

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.
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.
B
Query DeviceLogonEvents for LogonType 10 (RemoteInteractive), filtering by initiating device.
Why wrong: DeviceLogonEvents logs successful interactive logons, but the initiating device is not the device where the connection came from; it is the target device. This query would show who logged into DeviceA, not connections from DeviceA.
C
Query IdentityLogonEvents to find logons associated with DeviceA.
Why wrong: IdentityLogonEvents captures cloud-based authentication events for Microsoft Entra ID (Azure AD), such as sign-ins to apps and services, not outbound network connections or RDP sessions. A logon associated with DeviceA would reflect the identity used to authenticate, not the network destination or port, and it cannot reveal which target devices DeviceA connected to over port 3389. Thus it is the wrong table for this investigation.
D
Query EmailEvents to find emails sent from DeviceA that contain RDP configuration files.
Why wrong: EmailEvents in Advanced Hunting contains metadata about email messages handled by Microsoft 365 Defender (delivery, spoofing, phishing verdicts), not the network traffic generated by a device. Searching for emails sent from DeviceA is conceptually wrong because devices do not appear as senders in EmailEvents—those are mailbox and tenant mail flow events—and even if a message contained RDP configuration files, it proves nothing about actual RDP connections from that device. This option fails to provide any destination IP or port evidence.

Full breakdown with real-world context →

Question 5easymultiple choice

Full question →

A SOC analyst wants to create a scheduled analytics rule in Microsoft Sentinel that runs every 5 minutes and alerts when a single IP address fails to authenticate more than 10 times in that time window using the Microsoft Entra ID SigninLogs table. Which KQL function should be used to group the results into 5-minute intervals?

A
bin()
The bin() function in KQL is a scalar function that rounds a datetime value down to the nearest multiple of the specified interval, such as 5 minutes (e.g., bin(TimeGenerated, 5m)). This creates uniform time buckets that allow a scheduled analytics rule to aggregate events into fixed windows, making it essential for time-series analysis, rate detection, and anomaly identification. Without bin(), time values remain continuous and ungrouped, so patterns across discrete intervals would be impossible to discern. In practice, you pair bin() with summarize, as in `summarize count() by bin(TimeGenerated, 5m)`, to produce the time-bucketed aggregates the rule needs.
B
summarize
Why wrong: summarize is a KQL aggregation operator that groups rows by one or more key columns, but it does not automatically create time intervals. To achieve time-based grouping, you must explicitly include a computed column like bin(TimeGenerated, 5m) in the group-by clause; otherwise, summarize will treat every distinct timestamp as its own bucket, yielding an overwhelming number of groups that are useless for interval-based analytics. For example, `summarize count() by TimeGenerated` returns a separate count for each exact second, not a 5-minute aggregate. Thus, summarize is a necessary companion to bin(), but it cannot perform the interval bucketing on its own.
C
count
Why wrong: count is an aggregate function used inside a summarize block to count rows, typically written as `summarize count() by ...`. It calculates the number of events in each group but has no ability to define what those groups are, nor does it perform any time-based transformation. In a scheduled analytics rule, count is useful for measuring event volume per bucket, but it must be combined with a group key such as bin(TimeGenerated, 5m) to provide the interval structure. Using count alone, without a proper grouping field, will simply return a total count of all matching events, which does not satisfy the need for time-interval grouping.
D
where
Why wrong: where is a KQL filtering operator that narrows a result set to rows meeting a specified condition, such as `where EventID == 4625`. It is used to select only relevant events before aggregation, but it has no grouping capability and cannot create time intervals. In a scheduled analytics rule, a where clause might filter for a specific security event type, but you would still need bin() to partition those filtered events into time buckets for further analysis. Confusing where with bin() would mean you merely restrict the dataset, never producing the time-series structure required for interval-based detections.

Full breakdown with real-world context →

Question 6hardmultiple choice

Full question →

A company uses Microsoft Sentinel with the Microsoft 365 Defender connector. The security team notices that alerts from Microsoft Defender for Endpoint (MDE) are not appearing in Sentinel. The MDE data connector status shows 'Connected'. Which step should you take to troubleshoot this issue?

A
Verify that the Microsoft 365 Defender connector is configured to ingest MDE alerts.
Why wrong: The Microsoft 365 Defender data connector in Sentinel operates as a unified pipeline that pulls all security alerts and incidents from Microsoft 365 Defender without offering per-source toggles. There is no separate configuration switch to selectively enable or disable ingestion of Microsoft Defender for Endpoint (MDE) alerts. Therefore, verifying a specific setting for MDE alert ingestion is not a valid troubleshooting step because the connector's design ingests all available alert types automatically once enabled.
B
Check if the Microsoft Defender for Endpoint data connector is added.
Why wrong: In Microsoft Sentinel, there is no stand-alone 'Microsoft Defender for Endpoint' data connector; alerts from Defender for Endpoint are forwarded through the Microsoft 365 Defender connector, which consolidates signals from all Microsoft Defender workload suites. Checking for a dedicated MDE connector is ineffective because such an entity does not exist in the current connector catalog. The absence of alerts in Sentinel would not be caused by a missing separate connector, but rather by an upstream collection or forwarding failure.
C
Verify that the ingestion rules in Sentinel are not filtering out MDE alerts.
Why wrong: Sentinel ingestion rules (also known as data collection rules) are applied to data after it has already been received by the Log Analytics workspace, so they can only filter or transform events that are present. Since no MDE alerts are appearing from the Microsoft 365 Defender connector, the problem exists before ingestion starts, meaning the alerts are not being generated or forwarded from the source. Conclusion: ingestion rules could not be responsible for the complete lack of data because they cannot act on data that never arrives.
D
Check the Microsoft 365 Defender portal to ensure MDE alerts are being generated and forwarded to Microsoft 365 Defender.
Before troubleshooting Sentinel, verify that Microsoft Defender for Endpoint alerts are actually being produced and sent to Microsoft 365 Defender by reviewing the Microsoft 365 Defender portal. If no MDE alerts are visible there, they cannot propagate downstream to Sentinel, regardless of connector configuration. This is the root-cause check because the Microsoft 365 Defender connector only ingests what Microsoft 365 Defender itself has received and correlated; an empty source yields empty Sentinel tables.

Full breakdown with real-world context →

Question 7easymultiple choice

Full question →

A user reports receiving a suspicious email that bypassed the spam filter. An analyst opens the Microsoft 365 Defender portal to investigate. Which component provides a detailed entity view of the email including delivery actions, phish simulation details, and campaign information?

A
Microsoft Defender for Endpoint
Why wrong: Microsoft Defender for Endpoint is an endpoint detection and response (EDR) solution that monitors devices for malicious activities, vulnerabilities, and behavioral anomalies. It cannot inspect email transport data, mailbox content, or the message-level properties that indicate why a message bypassed a spam filter. While it may alert on malware that executes on a device after arrival via email, it lacks the email entity context needed for this investigation, making it the wrong tool here.
B
Microsoft Defender for Office 365 (Threat Explorer)
Microsoft Defender for Office 365 Threat Explorer is the correct tool because it provides a granular email-focused entity view that includes delivery actions, threat types, phish simulation tags, and associated campaign information for messages that bypassed filtering. Analysts can pivot from a single email ID to see message traces, sender and recipient details, and the specific policy or isolation verdict applied. This investigative capability directly addresses the need to examine a suspicious email received despite the existing spam filter.
C
Microsoft Defender for Identity
Why wrong: Microsoft Defender for Identity (MDI) focuses on detecting identity-based attacks such as compromised accounts, lateral movement, and privilege escalation within on-premises Active Directory environments. It does not analyze email headers, message bodies, transport rules, or mailbox-level delivery details. Although MDI might flag anomalous sign-ins after a user interacts with a phishing email, it cannot trace the email's origin, delivery path, or campaign association, so it is unsuited for this email investigation.
D
Microsoft Defender for Cloud Apps
Why wrong: Microsoft Defender for Cloud Apps is a cloud access security broker (CASB) that provides visibility into cloud application usage, enforces conditional access policies, and controls data sharing across SaaS and PaaS environments. It retrieves audit logs for applications like Exchange Online but does not offer a message-level mailbox view with email-specific properties such as anti-spam verdicts, sender spoofing indicators, or threat categorization. Therefore, it cannot be used to investigate why a particular email bypassed the spam filter.

Full breakdown with real-world context →

Question 8mediummultiple choice

Full question →

A SOC analyst is creating a scheduled analytics rule in Microsoft Sentinel to detect brute-force attacks on Microsoft Entra ID. The rule should generate an incident when a single user account fails to authenticate more than 10 times in 5 minutes from the same IP address. Which KQL operator is most appropriate to aggregate the count of failed sign-ins?

A
summarize
summarize is the KQL aggregation operator that groups rows by specified columns, such as UserPrincipalName or IPAddress, and computes aggregates like count(), sum(), or avg() across each group. In a scheduled analytics rule, this is exactly what enables threshold detection by producing per-entity event counts that can be compared against a threshold, such as more than 5 failed sign-ins for a single user.
B
extend
Why wrong: extend adds new calculated columns to each existing row without grouping or reducing the number of rows. Because it performs row-wise transformations, such as adding a computed field like TotalBytes = Bytes * 2, it cannot aggregate multiple events into per-entity totals, making it impossible to evaluate a detection threshold across a time window.
C
project
Why wrong: project selects a subset of columns from the input table, similar to a SQL SELECT clause, and can optionally rename or compute columns, but it preserves the row count. Since it does not collapse multiple rows into groups or perform any kind of aggregation, it cannot produce the counts needed to evaluate a threshold condition like 'more than 5 events from one IP address.'
D
where
Why wrong: where filters the input set by applying a boolean condition to each row, retaining only matching rows, analogous to a WHERE clause in SQL. It reduces the number of rows but does not group them or calculate counts, so while it can be used to narrow down events before aggregation, on its own it cannot satisfy the requirement to summarize data for threshold comparison.

Full breakdown with real-world context →

Question 9easymultiple choice

Full question →

An organization has connected a Palo Alto Networks firewall to Microsoft Sentinel using the Common Event Format (CEF) connector via a Linux log forwarder. The analyst notices that some expected firewall logs are missing in Sentinel. Which troubleshooting step should be performed first to check if the logs are reaching the Sentinel workspace?

A
Run a KQL query in the Sentinel Logs workspace: CommonSecurityLog | where TimeGenerated > ago(1h) | take 10
Querying CommonSecurityLog with a simple KQL filter for the last hour directly verifies whether Palo Alto CEF messages have been parsed and ingested into the Log Analytics workspace that backs Sentinel. Because CommonSecurityLog is the target schema for third-party syslog/CEF sources, seeing any rows proves the full pipeline (firewall, forwarder, agent, workspace) is functionally delivering data, making this the correct confirmatory test.
B
Check the firewall configuration to ensure syslog forwarding is enabled and pointing to the correct Linux forwarder
Why wrong: Checking the firewall's syslog forwarder settings validates configuration on the Palo Alto device itself, but does not confirm that data has actually reached the Log Analytics workspace; logs could be misconfigured, blocked by a network ACL, or mishandled by the agent. This step is only meaningful after negative evidence from the Sentinel query, making it a secondary troubleshooting action rather than a verification of workspace ingestion.
C
Verify network connectivity between the firewall and the Linux forwarder on port 514 (or the configured port)
Why wrong: Verifying network connectivity between the firewall and the Linux forwarder on port 514 checks only that raw CEF syslog messages can reach the forwarder, but the question asks whether logs are reaching the *Sentinel workspace*. Logs could arrive at the forwarder yet still be lost during parsing, agent forwarding, or ingestion into the Log Analytics workspace. This step is tempting because port-514 connectivity is the first prerequisite for any syslog-based ingestion; in a scenario where no logs appear at the forwarder at all, it would be the correct initial check.
D
Restart the Log Analytics agent on the Linux forwarder
Why wrong: Restarting the Log Analytics agent is a disruptive, last-resort action that may clear a transient agent hang but does not provide diagnostic evidence about whether logs are arriving at Sentinel; it also risks dropping buffered data or interrupting forwarding for all log sources. Since the question asks whether logs are reaching the workspace, the correct approach is to inspect the CommonSecurityLog table first, then methodically test each pipeline component before resorting to a restart.

Full breakdown with real-world context →

Question 10hardmultiple choice

Full question →

Your organization uses Microsoft Sentinel with multiple workspaces across different regions. You need to centrally manage all security incidents from a single pane of glass. The solution must allow analysts to investigate incidents across workspaces without switching contexts. What should you configure?

A
Deploy Microsoft Sentinel in a single region and use Azure Arc to connect other workspaces.
Why wrong: Azure Arc is for server management, not Sentinel workspaces.
B
Create a union query across workspaces using the workspace() expression.
Why wrong: Union queries are for log queries, not incident management.
C
Use Azure Lighthouse to manage multiple workspaces and enable cross-workspace incident view in Microsoft Sentinel.
Azure Lighthouse allows managing multiple workspaces from a single view.
D
Configure a single workspace and use diagnostic settings to send all logs to it.
Why wrong: This would centralize data but not necessarily provide cross-workspace incident management.

Full breakdown with real-world context →

Question 11mediummultiple choice

Full question →

Your organization uses Microsoft Sentinel. You receive an incident that involves a potential lateral movement detected by Microsoft Defender for Identity. You need to investigate the timeline of the attack. Which Microsoft Sentinel feature should you use?

A
Workbooks
Why wrong: For reporting, not investigation.
B
Automation rules
Why wrong: Trigger playbooks.
C
Investigation graph
Visual timeline for investigation.
D
Analytics rules
Why wrong: Generate alerts.

Full breakdown with real-world context →

Question 12mediumdrag order

Full question →

Order the steps to investigate a user account compromise using Microsoft Sentinel incidents.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

5Step 5

A
Review incident details, then analyze associated alerts and user behavior analytics, then perform advanced hunting queries for indicators, then remediate and close the incident.
This order follows a logical investigative flow: start with the incident overview to understand the scope, then examine alerts and behavioral data to identify patterns, use deep queries to confirm compromise indicators, and finally take remediation actions based on findings.
B
Perform advanced hunting queries for indicators, then review incident details, then analyze associated alerts and user behavior analytics, then remediate and close the incident.
Why wrong: This order skips initial context by jumping into queries without first reviewing the incident details and alerts, leading to inefficient and potentially misguided investigation.
C
Analyze associated alerts and user behavior analytics, then review incident details, then perform advanced hunting queries for indicators, then remediate and close the incident.
Why wrong: This order starts with alerts without the incident context, which can cause misinterpretation of alerts and missing the bigger picture of the compromise.
D
Remediate and close the incident, then review incident details, then analyze associated alerts and user behavior analytics, then perform advanced hunting queries for indicators.
Why wrong: This order is illogical as remediation should only happen after investigation; acting without understanding leads to incomplete remediation and missed indicators.

Full breakdown with real-world context →

Question 13hardmultiple choice

Full question →

Your organization uses Microsoft Sentinel and has enabled UEBA. A security analyst observes that a user account with no prior administrative activity performed a high volume of Azure Resource Manager operations. The analyst wants to investigate further. Which Microsoft Sentinel feature should the analyst use to quickly identify if this behavior is anomalous based on the user's historical profile?

A
Hunting queries
Why wrong: Hunting queries are proactive, investigator-driven KQL searches executed in the Sentinel Logs blade to uncover suspicious activity, but they operate against ingested raw data at query time rather than referencing a persisted machine-learning baseline of each user's historical behavior. While you could write a query that manually compares current activity to a stored profile, the feature itself does not automatically derive or apply user-specific behavioral baselines, so it is not the mechanism that provides UEBA's built-in anomaly detection.
B
Workbooks
Why wrong: Workbooks are interactive dashboards that visualize Sentinel data using KQL queries and tiles, enabling analysts to explore trends, counts, and entity timelines. They can display UEBA baseline data if explicitly queried, but they have no detection engine and do not evaluate events against historical user profiles to generate alerts or anomalies; their role is presentation and investigation support, not autonomous behavioral analysis based on established baselines.
C
User and Entity Behavior Analytics (UEBA)
User and Entity Behavior Analytics (UEBA) is the correct capability because it uses machine learning models to build a personalized historical baseline for each user and entity—such as typical logon times, locations, and performed actions—then continuously scores new activities against that profile to identify anomalous behavior automatically in Sentinel. UEBA's anomaly detections are surfaced as suspicious activities or incidents and feed into the entity timeline, requiring no custom rule authoring to compare current events to the user's own established patterns.
D
Analytics rules
Why wrong: Analytics rules are scheduled or Microsoft Security incident creation rules that detect threats based on KQL queries and alert thresholds, allowing custom detection logic. However, they only evaluate the specific conditions and time windows you define in the rule's query; they do not intrinsically access or compare against an entity's machine-learned historical profile unless you explicitly build that comparison into the rule (which is cumbersome and not automatic). Therefore, analytics rules alone do not provide the out-of-the-box UEBA behavior that establishes baselines and flags anomalies relative to a user's own patterns.

Full breakdown with real-world context →

Question 14easymultiple choice

Full question →

Refer to the exhibit. An admin creates this activity policy in Microsoft Defender for Cloud Apps. What will happen when a user fails to log in from 3 different IP addresses within 10 minutes?

Exhibit

Refer to the exhibit.
```json
// Microsoft Defender for Cloud Apps policy snippet
{
  "policyType": "Activity policy",
  "severity": "High",
  "description": "Detect multiple failed logins from different IPs",
  "filters": {
    "activity": "Failed login",
    "ip": {
      "differentCount": 3,
      "timeWindow": 10
    }
  },
  "actions": [
    {
      "type": "Block",
      "target": "User"
    }
  ]
}
```

A
The policy will generate an alert but not block the user.
Why wrong: The actions include 'Block', so it will block.
B
The user will be blocked immediately after the third failed login from any IP.
Why wrong: The condition is based on different IPs, not total attempts. If all attempts are from the same IP, it won't trigger.
C
The user will be blocked after 10 minutes regardless of the number of IPs.
Why wrong: The time window is 10 minutes, but the condition requires 3 different IPs within that window.
D
The user will be blocked only if the third IP is different from the first two.
The policy requires 3 distinct IP addresses; after the third distinct IP, the user is blocked.

Full breakdown with real-world context →

These SC-200 practice questions are part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style SC-200 questions with detailed explanations, topic-based practice, mock exams, readiness tracking, and study analytics.

Troubleshooting Scenario Questions

How to approach troubleshooting scenario questions

Quick answer

Related SC-200 topic practice pages

Manage a security operations environment practice questions

Respond to security incidents practice questions

Perform threat hunting practice questions

SC-200 fundamentals practice questions

SC-200 scenario practice questions

SC-200 troubleshooting practice questions

Practice scenarios

A company uses Microsoft Sentinel with the Microsoft 365 Defender connector. The security team notices that alerts from Microsoft Defender for Endpoint (MDE) are not appearing in Sentinel. The MDE data connector status shows 'Connected'. Which step should you take to troubleshoot this issue?

A user reports receiving a suspicious email that bypassed the spam filter. An analyst opens the Microsoft 365 Defender portal to investigate. Which component provides a detailed entity view of the email including delivery actions, phish simulation details, and campaign information?

Your organization uses Microsoft Sentinel. You receive an incident that involves a potential lateral movement detected by Microsoft Defender for Identity. You need to investigate the timeline of the attack. Which Microsoft Sentinel feature should you use?

Order the steps to investigate a user account compromise using Microsoft Sentinel incidents.

Refer to the exhibit. An admin creates this activity policy in Microsoft Defender for Cloud Apps. What will happen when a user fails to log in from 3 different IP addresses within 10 minutes?

Exhibit