CCNA Manage a security operations environment Questions — Page 6 of 7

376

Multi-Selectmedium

Which TWO actions can be performed using Microsoft Sentinel automation rules? (Select TWO.)

Select 2 answers

A.Assign an incident to a specific SOC analyst

B.Modify a data connector's configuration

C.Create a new analytics rule

D.Create a new watchlist

E.Run a playbook on an incident

AnswersA, E

Within Microsoft Sentinel, an incident can be assigned to a specific SOC analyst either manually through the incident details pane or automatically via an automation rule action that sets the incident owner. Automation rules use conditions like severity or entity to route ownership to a chosen user or group, ensuring immediate accountability. This action is one of the incident-management capabilities that make Sentinel a central SOC workspace.

Why this answer

Automation rules in Microsoft Sentinel allow you to automate incident management tasks, such as assigning incidents to specific SOC analysts based on criteria like severity or type. This is a core capability of automation rules, which can set the owner of an incident to a specific user or group, enabling efficient triage and accountability.

Exam trap

The trap here is that candidates often confuse automation rules with playbooks or analytics rules, assuming automation rules can create or modify detection logic, when in fact they are strictly for incident response and management actions.

Practice this question →

377

MCQhard

Your organization uses Microsoft Sentinel with UEBA enabled. You are investigating a suspicious incident where a user's account is reported to have accessed an unusual amount of data from a SharePoint site. The incident alert points to the user 'jdoe@contoso.com'. You open the incident and see that the entity timeline for jdoe shows several activities, including file downloads. However, you notice that the timeline does not include any Azure AD sign-in events for this user. You need to include sign-in events in the entity timeline to get a complete picture. What should you do?

A.Install the Azure Active Directory connector to ingest sign-in logs.

B.Enable UEBA for Azure AD in the Sentinel settings.

C.Install the Office 365 connector to ingest Azure AD logs.

D.Configure the entity timeline to include Azure AD events manually.

AnswerA

Installing the Microsoft Entra ID (Azure AD) connector is the required first step because Microsoft Sentinel does not natively ingest cloud identity auditing data. This connector pulls SigninLogs and AuditLogs into the Log Analytics workspace, which UEBA's behavioral profiling engine then consumes to generate entity timelines and spot anomalous identity activity. Without those sign-in logs, UEBA has no identity-related raw data to analyze, so enabling the feature alone accomplishes nothing.

Why this answer

The entity timeline in Microsoft Sentinel relies on data already ingested into the workspace. Since Azure AD sign-in events are not appearing, the most likely cause is that the Azure Active Directory connector has not been installed or configured. Installing this connector ingests sign-in logs (and audit logs) into Sentinel, which then populates the entity timeline with sign-in activities for users like jdoe.

Exam trap

The trap here is that candidates confuse the Office 365 connector (which handles SharePoint, Exchange, Teams) with the Azure AD connector (which handles sign-in and audit logs), leading them to choose Option C instead of A.

How to eliminate wrong answers

Option B is wrong because enabling UEBA for Azure AD in Sentinel settings does not ingest data; it only enables behavioral analytics on already-ingested data. Option C is wrong because the Office 365 connector ingests Exchange, Teams, and SharePoint logs, not Azure AD sign-in logs (those require the Azure AD connector). Option D is wrong because the entity timeline cannot be manually configured to include Azure AD events; it automatically displays any ingested entity-related data from connected sources.

Practice this question →

378

MCQeasy

Refer to the exhibit. You are viewing an incident in Microsoft Sentinel via the API. The incident is missing an owner. Which automation rule action would assign this incident to the SOC manager?

A.Change incident status to: Active

B.Run playbook (SimplePlaybook)

C.Add tags: ["Malware", "Endpoint"]

D.Assign incident to: SOC Manager

AnswerD

The 'Assign incident to' action directly updates the Owner property of the incident, enabling you to specify the SOC Manager as the designated owner. In Microsoft Sentinel, this is the standard, explicit method to assign or transfer responsibility for an incident to a specific user or group. By selecting this action, you fulfill the requirement to assign the SOC Manager as the owner, making it the correct choice.

Why this answer

The 'Assign incident to' action in Microsoft Sentinel automation rules directly changes the incident's owner property. By selecting 'SOC Manager' as the value, the rule sets the incident's owner field to that specific user or group, which is the exact requirement to resolve the missing owner.

Exam trap

The SC-200 exam often tests the distinction between actions that modify incident metadata (like status or tags) versus actions that directly change the owner property, leading candidates to confuse categorization with assignment.

How to eliminate wrong answers

Option A is wrong because changing the incident status to 'Active' does not modify the owner field; it only updates the status, leaving the incident unassigned. Option B is wrong because running a playbook (SimplePlaybook) executes a logic app or automation workflow, but it does not inherently assign an owner unless the playbook explicitly includes an API call to update the incident owner, which is not guaranteed by this action alone. Option C is wrong because adding tags like 'Malware' and 'Endpoint' only appends metadata to the incident for categorization; it has no effect on the owner assignment.

Practice this question →

379

MCQmedium

Your SOC uses Microsoft Defender XDR. You need to create a custom detection rule that triggers when a specific process is executed on multiple devices within an hour. Which feature should you use?

A.Advanced hunting query

B.Microsoft Sentinel scheduled analytics rule

C.Attack simulation training

D.Microsoft Defender XDR custom detection rule

AnswerD

Custom detection rules in Microsoft Defender XDR allow you to author KQL queries against the platform's unified data model and run them on a schedule, generating alerts and incidents that flow into the XDR workflow. They are the native equivalent to Sentinel analytics rules but operate directly in Defender XDR, making them the correct method for creating a custom detection in this environment. You can even start from an existing advanced hunting query and save it as a custom detection rule.

Why this answer

Microsoft Defender XDR custom detection rules are built on top of Advanced Hunting and allow you to define conditions that trigger an alert when a specific process is executed across multiple devices within a defined time window (e.g., one hour). This feature is native to Defender XDR and does not require a separate SIEM like Sentinel, making it the correct choice for creating a detection rule that operates within the Defender XDR environment.

Exam trap

The trap here is that candidates often confuse Advanced Hunting (a query tool) with the custom detection rule feature (which uses Advanced Hunting queries as a foundation but is a distinct rule-creation capability), leading them to select Option A instead of D.

How to eliminate wrong answers

Option A is wrong because Advanced Hunting is a query-based tool for hunting threats and creating custom detections, but it is not a feature that directly creates a detection rule; you must use a custom detection rule (which leverages Advanced Hunting queries) to set up the alert. Option B is wrong because Microsoft Sentinel scheduled analytics rules are designed for Azure Sentinel, not Microsoft Defender XDR, and they require Sentinel workspace and Log Analytics, which is an external SIEM layer, not native to Defender XDR. Option C is wrong because Attack simulation training is a feature for conducting simulated phishing and password attacks to train users, not for creating detection rules based on process execution across devices.

Practice this question →

380

MCQeasy

You are configuring Microsoft Sentinel to ingest logs from a third-party firewall via Syslog. After configuring the data connector, you notice that no logs are appearing. You verify that the firewall is sending logs to the Syslog collector. What is the most likely cause?

A.The firewall is sending logs in a format incompatible with the Azure Monitor Agent.

B.The ingestion cost is too high and Sentinel throttled the connection.

C.The syslog daemon on the collector is not configured to forward logs to the Log Analytics workspace.

D.The data connector is disabled in the Log Analytics workspace.

AnswerC

The root cause is that the syslog daemon on the collector Linux VM must be explicitly configured to forward events to the Log Analytics agent's local socket or TCP port (typically 25226). By default, rsyslog/syslog-ng only writes to /var/log/messages and does not know to forward to the agent, so the agent never sees the firewall logs and cannot send them to the workspace. Reconfiguring the daemon's forwarding rules (e.g., via /etc/rsyslog.d/95-omsagent.conf) is the missing step that resolves this scenario.

Why this answer

The most common reason logs fail to appear in Microsoft Sentinel after configuring a Syslog data connector is that the Syslog daemon (e.g., rsyslog or syslog-ng) on the collector VM is not configured to forward logs to the Log Analytics workspace. Even if the firewall sends logs to the collector, the Azure Monitor Agent (AMA) or legacy Log Analytics agent relies on the local Syslog daemon to listen on UDP port 514 (or TCP 6514) and forward those events to the agent, which then sends them to the workspace. Without proper daemon configuration (e.g., adding rules in /etc/rsyslog.d/ to forward facility/severity levels), the agent never receives the logs.

Exam trap

The trap here is that candidates assume the data connector directly receives Syslog traffic, when in fact the connector only configures the agent, and the Syslog daemon must be separately configured to forward logs to the agent.

How to eliminate wrong answers

Option A is wrong because the Azure Monitor Agent (AMA) for Syslog uses the standard Syslog protocol (RFC 5424 or RFC 3164) and can parse common formats; incompatibility is rare and would typically cause parsing errors, not a complete absence of logs. Option B is wrong because Microsoft Sentinel does not throttle ingestion based on cost; it may drop logs if the daily ingestion cap is reached, but that would affect all data types, not just this connector, and would generate a warning in the workspace. Option D is wrong because if the data connector were disabled, it would not appear as configured in Sentinel, and the question states the connector was configured, implying it is enabled; disabling would prevent the agent from sending data, but the connector itself is a UI configuration, not a toggle that stops the agent.

Practice this question →

381

MCQmedium

You are configuring a Microsoft Sentinel analytics rule to detect brute-force attacks on your Azure Virtual Machines. The rule uses the 'SecurityEvent' table. You notice that the rule is not generating incidents even though you see failed logon events in the logs. What should you check?

A.An automation rule is suppressing incidents with the same name.

B.The workspace retention period is set to less than 90 days.

C.The Log Analytics agent is not installed on the VMs.

D.The analytics rule is enabled and the query is correctly filtering for event ID 4625.

AnswerD

For an analytics rule to generate incidents, it must be enabled and its query must be properly constructed to return the relevant records — in this case, failed Windows logon attempts with event ID 4625 in the SecurityEvent table. If the rule is disabled, the query uses the wrong event ID, references the wrong table, or includes an overly restrictive filter (such as an incorrect time range or a nonexistent field), no matching events are detected and no incidents are created, making this the correct root cause to suspect.

Why this answer

The most immediate reason a rule fails to generate incidents despite seeing failed logon events is that the rule itself is either disabled or its query does not correctly filter for event ID 4625, which is the specific Windows security event ID for failed logon attempts. Even if logs are present, the analytics rule must be enabled and its KQL query must accurately target the right event ID to trigger an incident. Without this, the rule will not process the events into alerts.

Exam trap

The trap here is that candidates often assume the issue must be with data collection (agent or retention) when they see logs present, but the real problem is almost always a misconfigured or disabled analytics rule, specifically the query logic or the rule's enabled state.

How to eliminate wrong answers

Option A is wrong because an automation rule suppressing incidents with the same name would only affect incident creation after the analytics rule has already generated an alert; it would not prevent the analytics rule from seeing the events in the first place. Option B is wrong because the workspace retention period (default 30-730 days) does not affect real-time detection; it only controls how long historical data is stored, not whether current events are ingested or evaluated by the rule. Option C is wrong because if the Log Analytics agent were not installed on the VMs, you would not see any SecurityEvent data in the logs at all; the question states you do see failed logon events, proving the agent is present and sending data.

Practice this question →

382

MCQmedium

You are a security operations analyst using Microsoft Sentinel. You need to configure a workbook that displays a map of failed sign-in attempts by location over the last 24 hours. The data is stored in the SigninLogs table. Which two elements must you include in the workbook to achieve this?

A.A query that counts failed sign-ins by user and a time chart visualization.

B.A query that joins SigninLogs with Heartbeat and a grid visualization.

C.A query that summarizes failed sign-ins by location and a map visualization.

D.A query that lists all sign-in events and a pie chart visualization.

AnswerC

This is correct because to display a map, you need a query that aggregates data by location (e.g., using the location field) and a map visualization that plots those locations. The query should filter for failed sign-ins in the last 24 hours and group by location to provide the necessary data points.

Why this answer

To create a map in a Microsoft Sentinel workbook, you need a query that returns location data (such as latitude and longitude or country) and a map visualization that interprets that data. The query should filter for failed sign-ins in the last 24 hours and summarize by location. Other visualizations like pie charts or time charts do not display geographic information effectively.

Exam trap

The trap here is assuming that any visualization can display location data, when only specific map visualizations can plot geographic coordinates.

Practice this question →

383

MCQeasy

Your Microsoft Sentinel workspace is experiencing high ingestion costs. Which of the following actions will most effectively reduce costs while maintaining security visibility?

A.Delete unused analytics rules to reduce log ingestion.

B.Configure Basic Logs for verbose logs like Windows events from non-critical servers.

C.Disable collection of all informational logs.

D.Reduce the data retention period to 30 days.

AnswerB

Configuring Basic Logs for verbose Windows events from non-critical servers is the correct approach because Basic Logs use a lower-cost ingestion tier designed for high-volume, less-frequently queried data. These logs are stored in a separate table that supports simple search operations but avoids the full analytical query cost, dramatically lowering the per-gigabyte charge. This keeps the events available for incident response or compliance while reducing Sentinel's ingest bill, provided you do not need real-time alerting or rich KQL on that table.

Why this answer

Configuring Basic Logs for verbose logs (e.g., Windows Event ID 4688 from non-critical servers) reduces ingestion costs by storing them in a lower-cost tier while still retaining them for security investigations. Basic Logs are charged at a lower ingestion rate and support simple queries and search jobs, preserving visibility for incident response without the full cost of Analytics Logs.

Exam trap

The trap here is that candidates confuse reducing data retention (Option D) with reducing ingestion costs, but retention only affects storage charges, not the per-GB ingestion fee, which is the primary cost driver in Sentinel.

How to eliminate wrong answers

Option A is wrong because deleting unused analytics rules does not reduce log ingestion; analytics rules only consume data already ingested, and removing them does not lower the volume of logs sent to the workspace. Option C is wrong because disabling all informational logs can blind security operations to critical events like user logon failures (Event ID 4625) or privilege escalations, violating the requirement to maintain security visibility. Option D is wrong because reducing the retention period to 30 days may lower storage costs but does not address the ingestion cost itself, which is the primary driver of high costs; it also risks losing historical data needed for long-term threat hunting and compliance.

Practice this question →

384

MCQeasy

Refer to the exhibit. You are reviewing a playbook configuration for Microsoft Sentinel. What does this playbook do?

A.It runs only on medium severity incidents

B.It runs when a new alert is generated with high severity

C.It runs on all incidents regardless of severity

D.It runs when a high severity incident is created

AnswerD

This is correct because the playbook's trigger condition checks the incident severity field and only allows execution when the value is 'High.' It is configured to run at incident creation time, so whenever a new incident with high severity is generated, the playbook will execute. Any incident created with a severity other than High will not satisfy the condition and will not run the playbook.

Why this answer

The playbook is configured with a trigger condition that specifies 'When a high severity incident is created'. This means the playbook will only execute when an incident with a severity level of 'High' is generated in Microsoft Sentinel. The condition filters out incidents of other severity levels, ensuring the playbook runs exclusively for high-severity incidents.

Exam trap

The trap here is that candidates may confuse the trigger for incident creation versus alert generation, or overlook the severity filter in the condition, leading them to incorrectly select option B or C.

How to eliminate wrong answers

Option A is wrong because the trigger condition explicitly checks for 'high severity', not 'medium severity', so the playbook does not run on medium severity incidents. Option B is wrong because the trigger is based on incident creation, not alert generation; the playbook runs when an incident is created, not when a new alert is generated. Option C is wrong because the trigger condition includes a severity filter, so it does not run on all incidents regardless of severity; it only runs on high severity incidents.

Practice this question →

385

MCQmedium

Your organization uses Microsoft Defender for Office 365 and Microsoft Sentinel. You discover that phishing emails are bypassing Defender for Office 365 and being reported by users. You need to ensure that user-reported emails are automatically analyzed and incidents are created in Sentinel for high-confidence phishing. What should you configure?

A.Set up a custom connector using Microsoft Graph API to ingest user-reported messages into Sentinel.

B.Use the Microsoft 365 Defender portal to create a submission rule for user-reported messages.

C.Configure a mail flow rule to forward user-reported messages to a dedicated mailbox monitored by Sentinel.

D.Enable the 'User reported messages' feature in Defender for Office 365 and ensure the Microsoft Defender XDR connector is enabled in Sentinel.

AnswerD

Enabling the 'User reported messages' feature in Defender for Office 365 ensures that user-reported emails are automatically submitted for analysis by Microsoft's threat intelligence systems, including detonation and reputation checks. When the Microsoft Defender XDR connector is enabled in Microsoft Sentinel, the resulting alerts and incidents—such as high-confidence phishing verdicts—are streamed into Sentinel automatically, creating security incidents without manual intervention. This native integration is the correct method to meet the requirement for automated analysis and incident creation.

Why this answer

Enabling the 'User reported messages' feature in Defender for Office 365 allows user-reported phishing emails to be automatically submitted to Microsoft for analysis. When the Microsoft Defender XDR connector is enabled in Sentinel, high-confidence phishing verdicts from this analysis are ingested as incidents, creating a seamless automated pipeline without custom infrastructure.

Exam trap

The trap here is that candidates often assume a custom connector or mail flow rule is necessary for ingestion, overlooking that the built-in Defender for Office 365 user-reported messages feature, when combined with the Microsoft Defender XDR connector, provides a fully automated and integrated solution for high-confidence phishing incident creation in Sentinel.

How to eliminate wrong answers

Option A is wrong because while a custom Graph API connector could ingest messages, it would require manual development and maintenance, and it bypasses the built-in automated analysis and verdict pipeline that Defender for Office 365 provides for user-reported messages. Option B is wrong because the Microsoft 365 Defender portal submission rule is for administrators to submit messages for analysis, not for automatically processing user-reported emails into Sentinel incidents. Option C is wrong because a mail flow rule forwarding to a dedicated mailbox would require a separate logic app or custom connector to parse and analyze the messages, lacking the integrated high-confidence phishing verdict that the built-in feature provides.

Practice this question →

386

MCQeasy

Your organization wants to use Microsoft Copilot for Security to generate incident summaries. What is the minimum license required?

A.Microsoft 365 E5

B.Microsoft Sentinel

C.Microsoft Defender for Office 365 P2

D.Microsoft Copilot for Security standalone or add-on

AnswerD

Microsoft Copilot for Security is the only licensing option that actually grants access to the embedded AI features in Microsoft security products, whether you purchase it as a standalone capacity-based SKU with Security Compute Units or as an add-on to an eligible plan such as Microsoft 365 E5. This license provides the entitlement for Copilot experiences across Defender, Sentinel, and Entra, which is why it is the required license for the organization's goal.

Why this answer

Microsoft Copilot for Security is a standalone product that can be licensed independently or as an add-on to existing security subscriptions. It is not included in any Microsoft 365 or Defender plan by default; therefore, the minimum license required is either the standalone Copilot for Security SKU or the add-on license. This ensures the organization has the necessary entitlements to generate incident summaries using Copilot for Security.

Exam trap

The trap here is that candidates often assume Copilot for Security is included with high-tier licenses like Microsoft 365 E5 or Microsoft Sentinel, but Microsoft explicitly requires a separate Copilot for Security license (standalone or add-on) to use its AI capabilities.

How to eliminate wrong answers

Option A is wrong because Microsoft 365 E5 provides advanced security features like Defender for Office 365 P2 and Microsoft Sentinel, but it does not include Microsoft Copilot for Security; a separate license is required. Option B is wrong because Microsoft Sentinel is a SIEM/SOAR solution that ingests and analyzes security data, but it does not include Copilot for Security; Copilot for Security is a separate AI-powered tool that can integrate with Sentinel but requires its own license. Option C is wrong because Microsoft Defender for Office 365 P2 offers advanced threat protection for email and collaboration tools, but it does not include Copilot for Security; the Copilot for Security add-on or standalone license is needed to access its AI capabilities.

Practice this question →

387

MCQmedium

You manage a Microsoft Sentinel workspace with multiple analytics rules. You notice that an analytics rule has not generated any alerts in the past month despite relevant data being ingested. The rule uses a custom KQL query that joins two tables. What is the most likely cause?

A.The join condition in the KQL query is incorrect, resulting in no matching records

B.The rule is using an unsupported KQL function

C.The data connector for the tables is disabled

D.The rule is running on a schedule of 5 minutes but the data arrives every hour

AnswerA

The join condition in the KQL query is incorrect, which means the query syntactically runs but produces no matching rows. For example, joining on fields with different names, data types, or case values (since KQL joins are case-sensitive) prevents any records from pairing. As a result, the rule's query returns an empty result set each time it executes, so no alerts are created even though both tables contain relevant data.

Why this answer

The most likely cause is an incorrect join condition in the KQL query. When a custom analytics rule uses a JOIN operation between two tables, if the join keys or conditions do not match any records in the ingested data, the query returns zero results, and no alerts are generated. Since the question states that relevant data is being ingested, the issue is not with data availability but with the query logic itself.

Exam trap

The trap here is that candidates may assume the schedule or data connector is the problem, but the key clue is that 'relevant data is being ingested' — this forces you to focus on the query logic, specifically the JOIN condition, as the root cause.

How to eliminate wrong answers

Option B is wrong because unsupported KQL functions would typically cause a query execution error, not a silent failure to generate alerts; the rule would show as 'error' in the analytics rule status. Option C is wrong because if the data connector for the tables were disabled, no data would be ingested at all, contradicting the premise that relevant data is being ingested. Option D is wrong because a 5-minute schedule with hourly data arrival would still generate alerts when data does arrive (e.g., once per hour), not result in zero alerts over an entire month.

Practice this question →

388

MCQmedium

You are managing a Microsoft Sentinel environment with multiple workspaces across different regions. You need to centralize incident management and allow security analysts to triage incidents from all workspaces in a single view. What should you configure?

A.Configure a central Microsoft Sentinel workspace with cross-workspace analytics rules.

B.Create a workbook that queries all workspaces.

C.Use the Microsoft Sentinel SIEM Migration experience.

D.Use Azure Lighthouse to manage all workspaces from a single pane of glass.

AnswerA

A central Microsoft Sentinel workspace with cross-workspace analytics rules is the correct approach because it lets you define detection rules that query multiple workspaces (e.g., via the workspace() expression or union operator) and route resulting alerts into a single incident queue. This consolidates detection and incident management so security teams can investigate correlated events across all environments without manually stitching incidents together. It also aligns with Sentinel's native support for centralized SOC operations, where one workspace serves as the primary monitoring and response hub.

Why this answer

Cross-workspace analytics rules in Microsoft Sentinel allow you to define a single analytics rule that queries multiple workspaces, enabling centralized incident creation and management. This configuration ensures that security analysts can view and triage incidents from all workspaces in a single Microsoft Sentinel instance, without needing to switch between different workspace blades.

Exam trap

The trap here is that candidates often confuse Azure Lighthouse's cross-tenant management capabilities with the specific need to aggregate incidents into a single view, overlooking that Lighthouse alone does not merge incident queues across workspaces.

How to eliminate wrong answers

Option B is wrong because a workbook is a visualization and reporting tool, not an incident management interface; it cannot centralize incident triage or provide a unified incident queue. Option C is wrong because the SIEM Migration experience is designed to help migrate from a third-party SIEM to Microsoft Sentinel, not to centralize incident management across existing Sentinel workspaces. Option D is wrong because Azure Lighthouse provides cross-tenant management capabilities but does not natively aggregate incidents from multiple Sentinel workspaces into a single incident view; it still requires navigating separate Sentinel instances per workspace.

Practice this question →

389

MCQeasy

Your organization uses Microsoft Defender for Cloud Apps. You need to ensure that alerts from Defender for Cloud Apps are forwarded to Microsoft Sentinel. Which connector should you use in Sentinel?

A.Windows Security Events via AMA connector

B.Microsoft Defender for Cloud Apps connector

C.Microsoft 365 Defender connector

D.Azure Activity connector

AnswerB

This is the dedicated Microsoft Sentinel data connector for ingesting alerts and anomalies from Microsoft Defender for Cloud Apps, including policy violations, activity anomalies, and threat detection from cloud applications. It uses the Defender for Cloud Apps API to pull alerts into Log Analytics when enabled. Choosing this connector ensures that all cloud app security alerts are available for investigation and for use in analytics rules.

Why this answer

The Microsoft Defender for Cloud Apps connector in Microsoft Sentinel is specifically designed to ingest alerts and logs from Defender for Cloud Apps, including anomaly detection, policy violations, and threat intelligence alerts. This connector uses the Microsoft Graph API to pull data directly from the Defender for Cloud Apps service, ensuring that all relevant security alerts are forwarded to Sentinel for centralized monitoring and incident response.

Exam trap

The trap here is that candidates often confuse the Microsoft 365 Defender connector as a catch-all for all Microsoft security alerts, but it does not include Defender for Cloud Apps alerts, which require their own dedicated connector.

How to eliminate wrong answers

Option A is wrong because the Windows Security Events via AMA connector is used to collect security event logs from Windows machines, not alerts from Defender for Cloud Apps. Option C is wrong because the Microsoft 365 Defender connector ingests alerts and incidents from Microsoft 365 Defender (which includes Defender for Endpoint, Defender for Office 365, etc.), but it does not directly pull alerts from Defender for Cloud Apps; those alerts must be routed through the dedicated Defender for Cloud Apps connector. Option D is wrong because the Azure Activity connector captures subscription-level operational logs from Azure Resource Manager, not security alerts from a cloud app security broker like Defender for Cloud Apps.

Practice this question →

390

Multi-Selecteasy

Which TWO roles in Microsoft Entra ID can manage Microsoft Defender for Cloud Apps? (Select two.)

Select 2 answers

A.Compliance Administrator

B.Security Administrator

C.Global Administrator

D.Security Reader

E.Application Administrator

AnswersB, C

Security Administrator is one of the two Microsoft Entra ID roles that can manage Microsoft Defender. It has broad permissions to read, configure, and manage security settings across the organization, including threat protection policies, security alerts, and Defender for Endpoint and Defender for Office 365 configurations. This role is designed for day-to-day security operations.

Why this answer

The Security Administrator role in Microsoft Entra ID has the necessary permissions to manage Microsoft Defender for Cloud Apps, including configuring policies, investigating alerts, and managing app permissions. This role is specifically designed for security-related tasks within Microsoft 365 security products, making it a correct choice for managing Defender for Cloud Apps.

Exam trap

The trap here is that candidates often confuse the Compliance Administrator role as having security management capabilities due to its name, but it is strictly limited to compliance tasks and cannot manage Defender for Cloud Apps.

Practice this question →

391

MCQmedium

You are configuring a Microsoft Sentinel workbook to display incident metrics. You want to show the average time to triage incidents over the last 30 days. Which data source should you use?

A.CommonSecurityLog table.

B.SecurityIncident table.

C.SecurityAlert table.

D.SigninLogs table.

AnswerB

SecurityIncident is the canonical Microsoft Sentinel table for incident records, generated by the incident management service. Each row represents a single incident and includes authoritative fields such as IncidentNumber, Title, Status, Owner, CreatedTimeUTC, FirstActivityTimeUTC, LastActivityTimeUTC, and TriageTimeUTC. Querying this table directly lets a workbook aggregate incidents by time or status without joins or approximations, making it the correct source for incident lifecycle metrics like created and triaged times.

Why this answer

The SecurityIncident table in Microsoft Sentinel contains all incident-related data, including timestamps for creation, triage, and resolution. To calculate the average time to triage (e.g., the time between incident creation and the first triage action), you query this table using KQL to compute the mean duration. The other tables (CommonSecurityLog, SecurityAlert, SigninLogs) do not store incident lifecycle metadata.

Exam trap

The trap here is that candidates confuse the SecurityAlert table (which holds raw alert data) with the SecurityIncident table (which holds the correlated incident record), leading them to incorrectly choose SecurityAlert for incident-level metrics.

How to eliminate wrong answers

Option A is wrong because CommonSecurityLog stores syslog-style security events from third-party appliances (e.g., firewalls), not incident triage timestamps. Option C is wrong because SecurityAlert records individual alert details (e.g., alert name, severity) but lacks the incident-level triage or closure timestamps needed for time-to-triage calculations. Option D is wrong because SigninLogs captures user authentication events (e.g., success/failure, location) and has no relation to incident management workflows.

Practice this question →

392

MCQmedium

Refer to the exhibit. You are reviewing an automation rule in Microsoft Sentinel. What will happen when a new incident is created?

A.The incident severity will be changed

B.A new analytics rule will be created

C.The playbook 'BlockIPPlaybook' will be executed

D.The incident will be automatically closed

AnswerC

The automation rule in the exhibit includes a 'Run playbook' action that explicitly references the playbook named 'BlockIPPlaybook'. When the rule's trigger conditions are met, Microsoft Sentinel invokes the associated Logic App, which likely performs a connection- or firewall-blocking action against the offending IP. This is a standard way to automate response actions directly from an incident, and it is the sole effect defined in the automation rule's configured actions.

Why this answer

The automation rule is configured to trigger a playbook when an incident is created. The rule's action specifies 'Run playbook' with 'BlockIPPlaybook' selected, and the trigger condition is set to 'When incident is created'. This means that upon incident creation, Sentinel will execute the playbook as an automated response.

Exam trap

The trap here is that candidates may confuse automation rules with analytics rules, assuming that any rule in Sentinel must either create or modify incidents, rather than recognizing that automation rules are purely for orchestrated responses like playbook execution.

How to eliminate wrong answers

Option A is wrong because the automation rule does not contain any action to change the incident severity; it only triggers a playbook. Option B is wrong because automation rules do not create analytics rules; they respond to incidents generated by existing analytics rules. Option D is wrong because the rule has no condition or action to close the incident; it only runs a playbook.

Practice this question →

393

Multi-Selectmedium

Which TWO actions can be performed using automation rules in Microsoft Sentinel? (Select TWO.)

Select 2 answers

A.Create a new incident from an alert.

B.Modify the query of an existing analytics rule.

C.Assign an incident to a specific owner.

D.Delete an incident automatically.

E.Trigger a playbook when an incident is created.

AnswersC, E

Automation rules run on incidents after creation and can assign an owner, change severity, add tags, or run a playbook. Assigning an incident to a specific owner is a supported action, letting triage routing happen automatically without manual analyst intervention.

Why this answer

Option C is correct because Microsoft Sentinel automation rules can perform incident management actions such as changing the owner, status, severity, or adding tags to an incident when their conditions are met. Option E is correct because automation rules can invoke a playbook (Logic App) in response to an incident being created, which is a core use case for orchestrating automated responses. Option A is not correct because incidents are generated from alerts by analytics rules, not by automation rules.

Option B is not correct because automation rules cannot modify the query or logic of an existing analytics rule. Option D is not correct because automation rules do not support deleting incidents; they can close or change incident properties but not remove the incident record.

Exam trap

The trap here is that candidates often confuse automation rules with analytics rules, mistakenly thinking automation rules can create incidents or modify analytics rule logic, when in fact automation rules only act on existing incidents and cannot alter detection logic or delete incidents.

Practice this question →

394

MCQhard

Your SOC team uses Microsoft Sentinel's UEBA to detect insider threats. You want to ensure that UEBA can correlate activities across multiple data sources. Which data source must be enabled for UEBA to function properly?

A.Azure Activity logs

B.Office 365 audit logs

C.Windows Security Events

D.Microsoft Entra ID audit logs

AnswerD

Microsoft Entra ID audit logs are the correct primary source for UEBA because they contain identity-centric actions such as user sign-ins, conditional access evaluations, and directory modifications (e.g., password changes, role assignments). UEBA uses these logs to construct user profiles and establish behavioral baselines, enabling detection of anomalous activity like impossible travel or unusual authentication patterns. Since UEBA is fundamentally about user entity behavior, Entra ID logs provide the identity context that other logs lack.

Why this answer

Microsoft Sentinel's UEBA relies on Microsoft Entra ID (formerly Azure AD) audit logs as the primary identity source to establish a baseline of user behavior and correlate activities across different data sources. Without these logs, UEBA cannot map activities to specific user identities, which is essential for detecting anomalous behavior patterns indicative of insider threats.

Exam trap

The trap here is that candidates often assume Office 365 audit logs (Option B) are the primary identity source because they contain user actions, but Microsoft Sentinel's UEBA specifically requires Entra ID audit logs to establish the foundational identity baseline before correlating other data sources.

How to eliminate wrong answers

Option A is wrong because Azure Activity logs provide operational data about Azure resource management (e.g., VM creation, resource group changes) but do not contain user-level identity context required for UEBA correlation. Option B is wrong because Office 365 audit logs capture user actions in Exchange, SharePoint, and Teams, but they are a secondary data source that UEBA can ingest after identity mapping is established via Entra ID logs. Option C is wrong because Windows Security Events record local system-level activities (e.g., logon events, process creation) but lack the centralized identity context needed for cross-source user behavior correlation.

Practice this question →

395

MCQhard

Your organization has a hybrid identity environment with Microsoft Entra ID and on-premises Active Directory. You are configuring Microsoft Defender for Identity to protect against lateral movement attacks. Which configuration should you prioritize to detect pass-the-hash attacks?

A.Configure port mirroring for domain controllers

B.Enable 'SAM-R' (Remote SAM) in the Microsoft Defender for Identity sensor configuration

C.Configure Windows Event Forwarding (WEF) for domain controllers

D.Enable 'Capture NTLM hashes' in the Microsoft Defender for Identity sensor configuration

AnswerD

Enabling the 'Capture NTLM hashes' setting in the Microsoft Defender for Identity sensor configuration instructs the sensor to intercept NTLM authentication traffic on the network and extract the NTLM hashes used during the handshake. This is the foundational telemetry for pass-the-hash detection because the sensor can then correlate these captured hashes against account logon events to identify when a hash is reused from a different source. Without this setting, the sensor lacks the specific data needed to trigger pass-the-hash alerts, making it the correct configuration for this scenario.

Why this answer

Enabling 'Capture NTLM hashes' in the Microsoft Defender for Identity sensor configuration allows the sensor to extract NTLM hashes from network traffic. Pass-the-hash attacks rely on capturing and reusing NTLM hashes to authenticate laterally; by capturing these hashes, Defender for Identity can detect anomalies such as a hash being used from a different source or for suspicious logon attempts, directly identifying the attack.

Exam trap

The trap here is that candidates confuse prerequisites (port mirroring) or supporting features (SAM-R for lateral movement paths, WEF for event collection) with the specific configuration needed to detect pass-the-hash, which is the direct capture of NTLM hashes from network traffic.

How to eliminate wrong answers

Option A is wrong because port mirroring for domain controllers is a prerequisite for network traffic capture but does not itself enable detection of pass-the-hash attacks; it only provides the raw data. Option B is wrong because enabling SAM-R (Remote SAM) is used for lateral movement path detection (e.g., enumerating local admin groups) but does not capture or analyze NTLM hashes for pass-the-hash detection. Option C is wrong because configuring Windows Event Forwarding (WEF) for domain controllers collects Windows security events (e.g., 4624 logon events) but does not capture NTLM hashes from network traffic, which is essential for detecting pass-the-hash.

Practice this question →

396

MCQmedium

A SOC analyst receives a high-severity alert for a user who downloaded a malicious file from a phishing email. The analyst needs to quickly assess the scope of the incident across endpoints, email, and identities. Which Microsoft Defender XDR feature should the analyst use to get a unified view of the incident?

A.Microsoft Defender XDR incident queue

B.Microsoft Purview compliance portal

C.Microsoft Intune device compliance dashboard

D.Microsoft Sentinel incidents blade

AnswerA

The Microsoft Defender XDR incident queue is the correct location because it consolidates alerts from Defender for Endpoint, Defender for Identity, Defender for Office 365, Defender for Cloud Apps, and other Microsoft 365 security signals into a single correlated incident. This gives the SOC analyst the full attack story, affected assets, and evidence, along with integrated investigation and response actions. High-severity alerts originating from Microsoft Defender workloads are automatically aggregated here, making it the primary triage and investigation surface.

Why this answer

The Microsoft Defender XDR incident queue is the correct choice because it aggregates alerts from Microsoft Defender for Endpoint, Office 365, and Identity into a single incident view, enabling the analyst to correlate the malicious file download across endpoints, email, and user identities without switching consoles. This unified incident management is a core feature of Microsoft Defender XDR, designed specifically for rapid triage and scope assessment in multi-domain threats.

Exam trap

The trap here is that candidates often confuse the Microsoft Defender XDR incident queue with Microsoft Sentinel incidents, assuming Sentinel is the primary unified view, but the question specifically asks for the Microsoft Defender XDR feature, not a separate SIEM product.

How to eliminate wrong answers

Option B is wrong because the Microsoft Purview compliance portal focuses on data governance, eDiscovery, and compliance policies (e.g., DLP, retention), not on real-time incident correlation across endpoints, email, and identities. Option C is wrong because the Microsoft Intune device compliance dashboard provides device compliance status and policy enforcement for managed devices, but it does not aggregate security alerts or provide a unified incident view across email and identity domains. Option D is wrong because the Microsoft Sentinel incidents blade is a SIEM/SOAR tool that can ingest alerts from multiple sources, but it is not the native Microsoft Defender XDR incident queue; using Sentinel for this purpose would require additional configuration and is not the direct, built-in feature for unified incident management within the Defender XDR ecosystem.

Practice this question →

397

MCQeasy

You are configuring Microsoft Sentinel to ingest logs from Azure Active Directory (now Microsoft Entra ID). Which of the following connectors should you use to collect sign-in logs and audit logs?

A.Microsoft Defender for Cloud connector.

B.Office 365 connector.

C.Azure Activity connector.

D.Microsoft Entra ID connector.

AnswerD

The Microsoft Entra ID connector pulls sign-in and audit logs through the Microsoft Entra ID diagnostic settings pipeline into the workspace. It is the supported data connector for these identity event tables, matching the stem's collection requirement.

Why this answer

The Microsoft Entra ID connector (formerly Azure AD connector) is the correct choice because it is specifically designed to ingest sign-in logs, audit logs, and provisioning logs from Microsoft Entra ID into Microsoft Sentinel. This connector uses the Microsoft Graph API to pull these logs, enabling security monitoring of user authentication and administrative activities.

Exam trap

The trap here is that candidates often confuse the Azure Activity connector (which logs Azure resource operations) with the Entra ID connector (which logs identity and authentication events), leading them to incorrectly select option C.

How to eliminate wrong answers

Option A is wrong because the Microsoft Defender for Cloud connector is used to ingest security alerts and recommendations from Defender for Cloud, not Azure AD sign-in or audit logs. Option B is wrong because the Office 365 connector ingests logs from Exchange Online, SharePoint Online, Teams, and other Office 365 workloads, but it does not include Azure AD sign-in or audit logs. Option C is wrong because the Azure Activity connector ingests subscription-level operational logs from Azure Resource Manager (e.g., create/delete resources), not Azure AD sign-in or audit logs.

Practice this question →

398

Multi-Selecthard

Which THREE are valid ways to ingest data into Microsoft Sentinel? (Select three.)

Select 3 answers

A.Configuring Syslog using Azure Monitor Agent (AMA)

B.Using the Microsoft Sentinel API to push custom logs

C.Connecting to Azure DevOps directly

D.Importing from Power BI datasets

E.Using a built-in data connector for Microsoft Entra ID

AnswersA, B, E

Configuring Syslog using Azure Monitor Agent (AMA) is a fully supported ingestion path in Microsoft Sentinel. AMA runs on Linux virtual machines and uses Data Collection Rules (DCRs) to define which facilities and severities to forward to the Log Analytics workspace that Sentinel monitors. This method replaces the legacy Log Analytics agent, allowing you to collect syslog events from on-premises and cloud Linux servers, and it is a first-party, no-code option in the data connectors gallery.

Why this answer

The Azure Monitor Agent (AMA) can collect Syslog events from Linux-based sources and forward them to a Log Analytics workspace, which is the underlying data store for Microsoft Sentinel. By configuring a Data Collection Rule (DCR) that specifies the Syslog facility and severity levels, AMA streams these logs into the Syslog table in the workspace, making them available for detection and analysis within Sentinel.

Exam trap

The trap here is that candidates may assume any Microsoft service (like Azure DevOps or Power BI) can be directly connected via a built-in connector, but Sentinel only provides connectors for services that generate security-relevant logs, not for project management or BI analytics tools.

Practice this question →

399

MCQmedium

Your organization uses Microsoft Sentinel and Microsoft Defender XDR. You need to ensure that incidents created in Microsoft Defender XDR are automatically synchronized to Microsoft Sentinel with the least administrative effort. What should you configure?

A.Create a Logic App that uses the Microsoft Defender XDR API to fetch incidents and push them to Microsoft Sentinel.

B.Use the Microsoft Sentinel API to pull incidents from Microsoft Defender XDR.

C.Enable raw data ingestion from Microsoft Defender for Endpoint to Microsoft Sentinel.

D.Enable the Microsoft Defender XDR data connector in Microsoft Sentinel.

AnswerD

The Microsoft Defender XDR data connector is the supported, out-of-the-box integration that automatically imports incidents and alerts generated by Defender for Endpoint, Defender for Identity, Defender for Office 365, and Defender for Cloud Apps into Microsoft Sentinel. It leverages the Microsoft Graph security API, preserves the full incident schema, and provides bidirectional synchronization of incident status and comments between Sentinel and the Microsoft 365 Defender portal, requiring no custom code and minimal configuration.

Why this answer

The Microsoft Defender XDR data connector in Microsoft Sentinel provides a built-in, one-click integration that automatically synchronizes incidents from Microsoft Defender XDR to Microsoft Sentinel with no custom development required. This connector uses the Microsoft Graph Security API to ingest incidents, alerts, and evidence, ensuring seamless bidirectional synchronization with the least administrative effort.

Exam trap

The trap here is that candidates often confuse raw data ingestion (e.g., streaming raw logs from Defender for Endpoint) with incident synchronization, leading them to select Option C, when in fact incidents require the dedicated Microsoft Defender XDR data connector for automated, low-effort synchronization.

How to eliminate wrong answers

Option A is wrong because creating a custom Logic App to fetch incidents via the Microsoft Defender XDR API introduces unnecessary complexity, maintenance overhead, and administrative effort, contradicting the requirement for the least administrative effort. Option B is wrong because using the Microsoft Sentinel API to pull incidents from Microsoft Defender XDR would require custom scripting and polling logic, which is not a built-in or automated solution and adds administrative burden. Option C is wrong because enabling raw data ingestion from Microsoft Defender for Endpoint only ingests raw telemetry (e.g., advanced hunting tables) into a Log Analytics workspace, not incidents; incidents require the dedicated Microsoft Defender XDR data connector for proper synchronization.

Practice this question →

400

Multi-Selecthard

Which TWO actions are valid for automation rules in Microsoft Sentinel? (Choose two.)

Select 2 answers

A.Change the severity of an incident.

B.Delete an incident.

C.Run a playbook.

D.Add tags to an incident.

E.Modify an existing analytics rule.

AnswersA, C

Automation rules can directly change an incident's severity by specifying a new severity value (e.g., Low, Medium, High, or Critical) as part of the rule's action set. This is a built-in action that does not require a playbook and is commonly used to reclassify incidents based on custom logic, such as elevating severe events for priority response.

Why this answer

Automation rules in Microsoft Sentinel allow you to automate incident management tasks without requiring a playbook. Changing the severity of an incident is a supported action, enabling you to adjust the priority based on custom criteria such as incident properties or enrichment data.

Exam trap

The trap here is that candidates often confuse automation rule actions with playbook actions, assuming that any action available in a playbook (like adding tags or deleting incidents) is also available in automation rules, but automation rules have a fixed, limited set of direct actions.

Practice this question →

401

MCQmedium

Your organization uses Microsoft Defender XDR. You want to ensure that all incidents with severity 'High' are automatically assigned to the 'Tier1' group and have a playbook executed. What should you use?

A.Microsoft Defender XDR incident assignment manually by analysts

B.Custom analytics rules in Microsoft Sentinel

C.Automation rules in Microsoft Sentinel

D.Playbooks in Microsoft Sentinel

AnswerC

Automation rules in Microsoft Sentinel are the correct mechanism because they are designed to trigger automatically when an incident is created. They can perform actions such as assigning the incident to a specific owner or group, modifying severity, adding tags, or invoking a playbook, all without manual intervention. These rules provide consistent, policy-based incident assignment directly within the Sentinel incident lifecycle.

Why this answer

Automation rules in Microsoft Sentinel allow you to automatically assign incidents to a specific group (e.g., 'Tier1') and trigger a playbook based on incident properties such as severity. This directly meets the requirement to assign 'High' severity incidents to the 'Tier1' group and execute a playbook without manual intervention.

Exam trap

The trap here is that candidates often confuse playbooks with automation rules, thinking playbooks alone can handle assignment and triggering, but playbooks are just the action component and require an automation rule to define the trigger and assignment logic.

How to eliminate wrong answers

Option A is wrong because manual assignment by analysts does not automate the process; it requires human action for each incident, which contradicts the requirement for automatic assignment. Option B is wrong because custom analytics rules in Microsoft Sentinel are used to generate alerts from raw data, not to manage incident assignment or trigger playbooks after an incident is created. Option D is wrong because playbooks in Microsoft Sentinel are automated response workflows that can be triggered by automation rules, but they cannot by themselves assign incidents to groups or set conditions for execution; they require an automation rule to define the trigger and assignment logic.

Practice this question →

402

Multi-Selectmedium

Which THREE components are part of Microsoft Sentinel's SOAR capabilities? (Choose three.)

Select 3 answers

A.Workbooks

B.Incident management

C.Watchlists

D.Automation rules

E.Playbooks

AnswersB, D, E

Incident management is a core SOAR component in Microsoft Sentinel because incidents serve as the central case-management entity for investigation and response. Sentinel's SOAR capabilities are centered on the full incident lifecycle—creation, assignment, triage, investigation, and resolution—enabling consistent handling. Incident management integrates with automation rules and playbooks to drive orchestrated response, making it essential to the SOAR framework.

Why this answer

Incident management is a core SOAR component in Microsoft Sentinel because it provides the structured workflow for security analysts to triage, investigate, and respond to security incidents. It integrates with automation rules and playbooks to orchestrate response actions, enabling consistent and efficient handling of threats.

Exam trap

The trap here is that candidates confuse data enrichment or visualization tools (Workbooks, Watchlists) with SOAR components, when only incident management, automation rules, and playbooks directly enable automated response and orchestration workflows.

Practice this question →

403

MCQhard

Your security team uses Microsoft Sentinel UEBA to detect anomalous user behavior. You need to configure UEBA to baseline user activities and generate alerts for deviations. What must you do first?

A.Create an Azure Machine Learning workspace for anomaly detection.

B.Enable UEBA in the Sentinel Settings blade and select relevant data sources.

C.Assign Microsoft 365 E5 licenses to all users.

D.Deploy a custom data connector for HR systems.

AnswerB

In Microsoft Sentinel, UEBA is disabled by default; you must open Settings > UEBA, toggle it on, and select the relevant data sources such as Azure AD sign-in logs, Azure AD audit logs, and Microsoft Defender for Identity data. Once enabled, Sentinel creates entity profiles, establishes behavioral baselines over time, and uses built-in ML to detect anomalies including impossible travel and sign-in from unusual locations. This is the definitive prerequisite step; without it, no entity behavior analytics or anomaly scoring runs in Sentinel.

Why this answer

Microsoft Sentinel UEBA requires explicit enablement in the Sentinel Settings blade under the 'Entity behavior analytics' section. Once enabled, you must select the relevant data sources (e.g., Azure Active Directory sign-in logs, Office 365 audit logs, Windows Security Events) so that Sentinel can baseline normal user behavior patterns and generate alerts for anomalous deviations. Without this initial configuration, UEBA cannot process any data or produce behavioral analytics.

Exam trap

The trap here is that candidates often assume UEBA is automatically enabled or that it requires external ML services (like Azure Machine Learning) or premium licenses (like M365 E5), when in fact the first step is simply toggling the feature on and selecting data sources within Sentinel's own settings.

How to eliminate wrong answers

Option A is wrong because Azure Machine Learning workspace is not required for Sentinel UEBA; UEBA uses built-in machine learning models within Sentinel itself, not an external ML workspace. Option C is wrong because Microsoft 365 E5 licenses are not a prerequisite for UEBA; Sentinel UEBA works with any license that provides the necessary data sources (e.g., Azure AD P1/P2, Office 365 E3/E5) and does not mandate E5 for all users. Option D is wrong because deploying a custom data connector for HR systems is an optional enhancement for enriching entity data (e.g., employee role, manager), but it is not the first step; UEBA must be enabled and data sources selected before any custom connectors can contribute to baselining.

Practice this question →

404

MCQhard

Your organization uses Microsoft Defender XDR and Microsoft Sentinel. You need to ensure that when a device is identified as compromised by Defender for Endpoint, an incident is automatically created in Sentinel with high severity. What should you configure?

A.Configure the Defender XDR connector to create incidents

B.Write an analytics rule that queries Defender for Endpoint data

C.Create a playbook to create an incident from the alert

D.Create an automation rule that triggers when an incident is created and set severity to High

AnswerD

Automation rules in Microsoft Sentinel run immediately when an incident is created (or updated) and can modify incident properties, including the severity field. By creating an automation rule that triggers on the 'Incident created' condition and sets the severity to 'High', you ensure that all incidents generated from Defender XDR alerts are classified consistently without manual intervention or duplicate incident creation. This is the correct approach because automation rules are designed for such property-level adjustments and do not interfere with the existing connector workflow.

Why this answer

Automation rules in Microsoft Sentinel can be configured to run when an incident is created, and they can set the severity of the incident to High. In this scenario, when Defender for Endpoint identifies a compromised device, the Defender XDR connector creates an incident in Sentinel. The automation rule then immediately elevates the severity to High, meeting the requirement without additional manual steps or complex logic.

Exam trap

The trap here is that candidates often confuse automation rules with playbooks, thinking that a playbook is required to modify incident properties, when in fact automation rules can directly change severity without invoking a playbook.

How to eliminate wrong answers

Option A is wrong because configuring the Defender XDR connector to create incidents is already the default behavior that generates the incident, but it does not automatically set the severity to High; severity is inherited from the source alert. Option B is wrong because writing an analytics rule that queries Defender for Endpoint data would create a separate scheduled query rule, which is redundant and less efficient than using the existing incident creation from the connector, and it does not directly set severity on the connector-generated incident. Option C is wrong because creating a playbook to create an incident from the alert adds unnecessary complexity and latency; playbooks are better suited for response actions, while automation rules are the native, lightweight method to modify incident properties like severity.

Practice this question →

405

Multi-Selecthard

Which THREE of the following are valid methods to archive logs in Microsoft Sentinel to reduce costs?

Select 3 answers

A.Configure continuous export to Azure Data Lake Storage Gen2

B.Set the workspace to free tier

C.Enable Basic Logs ingestion for all tables

D.Use a Logic App to export logs to Azure Storage

E.Change the table's retention period to include archival

AnswersA, D, E

Continuous export is a native feature that automatically copies ingested log data from a Log Analytics workspace to an Azure Data Lake Storage Gen2 account in near real time, storing each table as a set of Parquet files. This provides long-term retention and cost-effective archival because you can delete the data from the workspace after export or keep it only for the required interactive period. It supports filtering per table and is fully managed, so it is a valid archival method, especially for compliance or big-data analytics scenarios.

Why this answer

Microsoft Sentinel supports continuous export of logs to Azure Data Lake Storage Gen2, which allows you to retain raw log data at lower storage costs while still being able to query it using Azure Synapse or other analytics tools. This method reduces the cost of high-volume log retention in Sentinel's native workspace by moving data to a cheaper long-term storage tier.

Exam trap

The trap here is that candidates often confuse 'Basic Logs' (which reduce ingestion cost but not storage cost) with archival methods, or mistakenly think the free tier can be manually selected for cost savings, when in fact it is a temporary promotional offering.

Practice this question →

406

MCQhard

You are designing a Microsoft Sentinel deployment for a multinational organization that must comply with GDPR and local data residency requirements. They have offices in the US, EU, and Asia. They want to use a single Microsoft Sentinel workspace for global visibility but need to ensure that data from EU sources remains within the EU. What is the best approach to meet these requirements?

A.Deploy a single Microsoft Sentinel workspace in the US and use Azure Policy to restrict data ingestion from EU sources.

B.Deploy separate Microsoft Sentinel workspaces in the US, EU, and Asia, and use cross-workspace queries and Azure Lighthouse to manage them centrally.

C.Deploy a single workspace in the EU and enable UEBA to analyze all data.

D.Use Azure Lighthouse to project a single workspace into multiple regions, which automatically separates data storage.

AnswerB

Separate Sentinel workspaces placed in the US, EU, and Asia keep each region's log data stored within its corresponding geopolitical boundary, satisfying data-residency requirements. Cross-workspace queries use the workspace() KQL operator to query all three workspaces in one investigation, while Azure Lighthouse grants the central SOC delegated RBAC permissions across subscriptions or tenants without duplicating data. This architecture combines regional compliance with a single-pane-of-glass management experience.

Why this answer

Deploying separate Microsoft Sentinel workspaces in each required region (US, EU, Asia) ensures that data from EU sources remains within the EU, satisfying GDPR and local data residency requirements. Cross-workspace queries and Azure Lighthouse allow centralized management and global visibility across these workspaces without moving data between regions.

Exam trap

The trap here is that candidates may think Azure Lighthouse or cross-workspace queries can magically split a single workspace's storage across regions, when in fact a workspace is a regional resource and data residency requires separate workspaces per region.

How to eliminate wrong answers

Option A is wrong because Azure Policy can restrict data ingestion but cannot enforce data residency; data ingested into a single US-based workspace would still be stored in the US, violating GDPR requirements for EU data to remain in the EU. Option C is wrong because a single workspace in the EU would store all global data there, failing data residency requirements for US and Asia data that must remain in their respective regions. Option D is wrong because Azure Lighthouse does not project a single workspace into multiple regions or separate data storage; it only enables cross-tenant management, and a single workspace stores all data in one region regardless of Lighthouse use.

Practice this question →

407

Multi-Selectmedium

Your organization uses Microsoft Sentinel. You need to ensure that incident response times are monitored and reported. Which TWO capabilities should you use?

Select 2 answers

A.Playbooks

B.UEBA

C.Automation rules

D.Watchlists

E.Workbooks

AnswersC, E

Automation rules in Sentinel are the correct choice because they let you define conditions and run actions when an incident is created or updated, including updating fields and setting tags. By configuring a rule that stamps the incident's 'Created' time and another that records when the incident transitions to 'In Progress' or is assigned, you can capture the exact response start time. This information is stored in the incident's properties and can later be queried to compute time-to-respond, directly enabling monitoring of response times.

Why this answer

Automation rules (C) are correct because they allow you to define conditions and actions that automatically trigger when an incident is created or updated, enabling consistent assignment, severity changes, and tagging. Workbooks (E) are correct because they provide customizable visualizations and reports that can track key metrics like incident response times, mean time to acknowledge (MTTA), and mean time to remediate (MTTR) using KQL queries against Sentinel's security data.

Exam trap

The trap here is that candidates often confuse playbooks (automated response actions) with automation rules (incident orchestration) and overlook workbooks in favor of UEBA or watchlists, which are unrelated to monitoring response times.

Practice this question →

408

MCQeasy

Your company is deploying Microsoft Defender for Endpoint. You need to ensure that all devices report their security baseline compliance to Microsoft Intune. Which configuration should you use?

A.Configure a device configuration profile in Microsoft Intune

B.Deploy Windows Update for Business reports

C.Assign a Security Baseline policy in Microsoft Intune to the device groups

D.Enable Microsoft Defender for Cloud Apps session controls

AnswerC

Assigning a Security Baseline policy in Microsoft Intune to the device groups is the correct mechanism because security baselines are pre-defined collections of recommended security settings (e.g., from Microsoft's security baseline for Windows) that Intune applies and then evaluates against each device. The Intune console provides a 'Security Baselines' node that shows per-device compliance status, listing every setting that deviates from the baseline version you assigned. This gives you the exact report of compliance against a security baseline, including the ability to compare against different baseline versions.

Why this answer

Security Baseline policies in Microsoft Intune define a set of pre-configured security settings recommended by Microsoft to harden devices. When assigned to device groups, these policies automatically evaluate and report compliance status for each device, ensuring all devices meet the required security baseline. This directly fulfills the requirement to report security baseline compliance to Intune.

Exam trap

The trap here is that candidates often confuse a generic device configuration profile (Option A) with a Security Baseline policy, not realizing that only the latter provides built-in compliance evaluation and reporting for security baselines.

How to eliminate wrong answers

Option A is wrong because a device configuration profile in Intune is used to configure device settings (e.g., Wi-Fi, certificates) but does not inherently report compliance against a security baseline; it lacks the built-in compliance evaluation and reporting capabilities of a Security Baseline policy. Option B is wrong because Windows Update for Business reports focus on update compliance and deployment status, not security baseline compliance. Option D is wrong because Microsoft Defender for Cloud Apps session controls are designed to monitor and control cloud app access in real-time, not to manage or report device-level security baseline compliance.

Practice this question →

409

MCQmedium

Your organization uses Microsoft Sentinel and has enabled UEBA (User and Entity Behavior Analytics). You notice that the UEBA timeline is not populating for some users. You have verified that the data sources are connected and the UEBA feature is enabled. What could be the issue?

A.There is insufficient data to build baselines for those users; UEBA needs at least 14 days of data.

B.Users must opt in to UEBA tracking.

C.UEBA only works with Azure Active Directory (now Microsoft Entra ID) audit logs.

D.The data sources are not sending logs for those users.

AnswerA

Microsoft Sentinel UEBA uses proprietary machine learning to build behavioral baselines for entities such as users, and it requires at least 14 days of historical telemetry before it can produce analytical timelines. If a user is newly on-boarded or has only sporadic log activity, the available data does not meet that minimum threshold, so no anomaly or timeline appears. This is a documented prerequisite, not a configuration error or a connectivity problem.

Why this answer

UEBA requires a minimum of 14 days of historical data to establish behavioral baselines for each user. Without sufficient data, the timeline cannot detect anomalies or populate entries. Even if data sources are connected and UEBA is enabled, the feature will not generate timeline events until baselines are built.

Exam trap

The trap here is that candidates assume UEBA will work immediately after enabling it, overlooking the mandatory 14-day baseline requirement, and instead blame data source connectivity or user permissions.

How to eliminate wrong answers

Option B is wrong because UEBA does not require user opt-in; it operates automatically on all users once enabled and data is flowing. Option C is wrong because UEBA works with multiple data sources, including Windows Security Events, Azure AD (now Microsoft Entra ID) audit logs, and Office 365 activity logs, not just Azure AD audit logs. Option D is wrong because the question states data sources are connected and verified, so the issue is not missing logs but insufficient data duration for baseline calculation.

Practice this question →

410

MCQhard

Refer to the exhibit. You are reviewing a Microsoft Sentinel analytics rule created via ARM template. What is the effect of the grouping configuration?

A.Groups alerts into one incident if any entity matches.

B.Creates a separate incident for each alert.

C.Suppresses alerts for 5 hours after the first alert.

D.Groups alerts into one incident if all entities match within a 5-hour lookback.

AnswerD

This is correct because the rule groups alerts into a single incident when all entities match within the 5-hour lookback. The entitiesMatchingMethod is All, and lookbackDuration is 5 hours, so only alerts that share every entity value (such as account, host, and IP) in that window will be merged. This consolidates related alerts while minimizing the chance of grouping unrelated activity, and the same incident can be reopened or updated as more matching alerts arrive.

Why this answer

The grouping configuration in the exhibit sets the grouping condition to 'Group alerts into a single incident if all entities match' with a 5-hour lookback period. This means that alerts generated within 5 hours that share identical entities (e.g., same IP, host, or account) will be merged into one incident, reducing alert noise. Option D correctly describes this behavior, as it specifies both the entity matching requirement and the time window.

Exam trap

The trap here is confusing the grouping lookback window with alert suppression or mistaking 'any entity matches' for 'all entities match,' which leads candidates to pick Option A or C instead of D.

How to eliminate wrong answers

Option A is wrong because it states 'if any entity matches,' but the configuration requires all entities to match, not any single entity. Option B is wrong because it describes creating a separate incident for each alert, which is the opposite of grouping; the configuration explicitly enables grouping. Option C is wrong because it refers to suppressing alerts for 5 hours after the first alert, which is a different feature (alert suppression) not related to grouping configuration; the 5-hour value here is the lookback window for grouping, not a suppression period.

Practice this question →

411

Multi-Selecthard

Which THREE of the following are features of Microsoft Defender XDR that help manage a security operations environment?

Select 3 answers

A.Sentinel SIEM integration

B.Threat analytics

C.Automated investigation and response

D.Advanced hunting

E.Unified incident management

AnswersC, D, E

Automated investigation and response (AIR) is a core feature of Microsoft Defender XDR because it enables the platform to orchestrate playbooks across email, endpoints, identities, and cloud apps following an alert trigger. When a suspicious entity is detected, AIR automatically runs investigations, pauses or blocks malicious activities, and takes remediation actions such as quarantining files or disabling accounts — all while keeping security teams informed via the Action Center. This cross-product automation is what distinguishes XDR from individual Defender products, and it is explicitly listed as a primary capability of Defender XDR. The process uses AI-driven assessments to determine whether a threat is malicious, and it helps contain breaches before human analysts can intervene.

Why this answer

Automated Investigation and Response (AIR) in Microsoft Defender XDR uses AI-driven playbooks to automatically investigate alerts and take remediation actions, such as isolating a compromised device or blocking a malicious file, without requiring manual intervention. This directly supports managing a security operations environment by reducing alert fatigue and accelerating incident response.

Exam trap

The trap here is that candidates often confuse 'features of Microsoft Defender XDR' with 'features of Microsoft Sentinel' or other Microsoft security products, leading them to select SIEM integration (Option A) or Threat Analytics (Option B) as operational management features when they are not core to Defender XDR's incident management and response capabilities.

Practice this question →

412

MCQeasy

Your organization uses Microsoft Defender for Cloud. You need to view a list of all security recommendations for your Azure subscriptions. Which blade should you use?

A.Workbooks

B.Regulatory Compliance

C.Inventory

D.Recommendations

AnswerD

The Recommendations blade in Microsoft Defender for Cloud is the single, central pane that gathers every security recommendation for your organization's resources. It lists recommendations with severity, affected resources, remediation steps, security control, and impact on your secure score, enabling immediate triage and action. This is exactly the page needed to simply view security recommendations, so it is the correct answer.

Why this answer

The Recommendations blade in Microsoft Defender for Cloud is the centralized hub that lists all security recommendations for your Azure subscriptions, including those from Azure Security Benchmark and custom initiatives. It provides a prioritized view of security posture improvements, such as remediating vulnerabilities or enabling encryption, directly actionable from the blade.

Exam trap

The trap here is that candidates confuse the Inventory blade (which shows resources and their security state) with the Recommendations blade (which shows the actionable list of security improvements), leading them to select Inventory instead of the correct Recommendations blade.

How to eliminate wrong answers

Option A is wrong because Workbooks are used for creating custom visualizations and reports from Azure Monitor data, not for viewing the list of security recommendations. Option B is wrong because Regulatory Compliance focuses on compliance scores and controls against standards like SOC 2 or ISO 27001, not the full set of security recommendations. Option C is wrong because Inventory shows a list of Azure resources and their security posture, but it does not display the aggregated list of recommendations; it is a resource-centric view, not a recommendation-centric one.

Practice this question →

413

MCQmedium

You are reviewing the KQL query shown in the exhibit. What is the purpose of this query?

A.Count the number of high-severity alerts per hour

B.Return the timestamp of each high-severity alert

C.Identify high-severity alert names that occurred more than 10 times in the last 24 hours

D.List all high-severity incidents in the last 24 hours

AnswerC

This is the correct interpretation because the query explicitly filters for high-severity alerts within the last 24 hours using `where Severity == "High"` and `where TimeGenerated > ago(24h)`, then groups by `AlertName`. The `summarize count() by AlertName` computes the occurrence frequency for each alert name, and the subsequent `where count_ > 10` (or `having count_ > 10`) enforces the threshold. The result is exactly the set of high-severity alert names observed more than 10 times in the specified period.

Why this answer

The query uses `summarize` with `count()` on `AlertName`, then filters with `where count_ > 10`. This groups high-severity alerts by name and returns only those names that appear more than 10 times in the last 24 hours. The `project` statement outputs only the `AlertName` and its count, confirming the purpose is to identify frequently occurring high-severity alert names.

Exam trap

The trap here is that candidates confuse `summarize count()` with `summarize count() by bin(TimeGenerated, 1h)` and mistakenly think the query counts alerts per hour, when it actually counts total occurrences per alert name over the entire time range.

How to eliminate wrong answers

Option A is wrong because the query groups by `AlertName`, not by time bins (e.g., `bin(TimeGenerated, 1h)`), so it does not count alerts per hour. Option B is wrong because the query does not include `TimeGenerated` in the output; it projects only `AlertName` and `count_`. Option D is wrong because the query filters on `AlertName` and counts occurrences, not on incidents; it also does not list all incidents, only aggregated alert names meeting a threshold.

Practice this question →

414

MCQeasy

You are a security operations analyst for a company that uses Microsoft Defender XDR. You need to ensure that when a high-severity alert is generated in Microsoft Defender for Endpoint, an incident is automatically created in Microsoft Defender XDR and appears in the incident queue. What should you do?

A.Enable the Microsoft Defender for Endpoint integration in Microsoft Defender XDR and set the alert severity threshold to High.

B.Create a custom detection rule in Microsoft Defender for Endpoint that triggers on high-severity alerts.

C.Verify that the alert is not suppressed and that incident creation is enabled in the Microsoft Defender XDR settings.

D.Configure a Microsoft Sentinel analytics rule to ingest high-severity alerts from Defender for Endpoint and create incidents.

AnswerC

Microsoft Defender XDR automatically correlates alerts into incidents when incident creation is enabled and alerts are not suppressed. Ensuring these settings are correct allows high-severity alerts from Defender for Endpoint to generate incidents, meeting the requirement.

Why this answer

Microsoft Defender XDR automatically creates incidents from alerts generated by its component services, including Defender for Endpoint, when incident creation is enabled and alerts are not suppressed. Checking these settings ensures that high-severity alerts result in incidents. The other options involve unnecessary customizations or misconfigured features that do not directly control incident creation in Defender XDR.

Exam trap

The trap here is confusing alert generation with incident creation, and assuming that custom detection rules or severity thresholds control incident creation in Defender XDR.

Practice this question →

415

MCQhard

Your organization uses Microsoft Defender for Endpoint. You need to configure a device group that automatically assigns devices to the group based on their domain membership. Devices joined to 'contoso.com' should be in the 'Corporate' group, and all others in 'Non-Corporate'. What should you use?

A.Use a custom detection rule to move devices based on risk level.

B.Create a device group with a rule using the device tag 'Contoso' and assign tags via GPO.

C.Create two device groups and manually move devices.

D.Create a device group with a rule using the domain field 'contoso.com'.

AnswerB

This is the correct approach because Microsoft Defender for Endpoint device groups support rule criteria based on device tags, and device tags can be assigned centrally via Group Policy or Intune. By tagging all Contoso devices with the same device tag and creating a device group rule that matches that tag, you automatically assign the correct devices and keep the group in sync as new devices are onboarded. This is dynamic and scalable, avoiding manual, one-off reconfiguration.

Why this answer

Microsoft Defender for Endpoint device groups can use device tags to automatically assign devices based on domain membership. By creating a device group with a rule that matches the device tag 'Contoso' and assigning that tag to domain-joined machines via Group Policy Object (GPO), you ensure that devices joined to 'contoso.com' are placed in the 'Corporate' group, while all others fall into the default 'Non-Corporate' group.

Exam trap

The trap here is that candidates assume the domain field can be used directly in device group rules, but Defender for Endpoint does not expose the domain attribute for rule creation; instead, you must use tags applied via GPO or other management tools to achieve domain-based grouping.

How to eliminate wrong answers

Option A is wrong because custom detection rules are used for creating custom alerts and automated actions based on threat indicators, not for assigning devices to groups based on domain membership. Option C is wrong because manually moving devices is not scalable and does not meet the requirement for automatic assignment based on domain membership. Option D is wrong because device group rules in Defender for Endpoint do not support filtering directly on the domain field; they support tags, device names, OS platforms, and other attributes, but not the domain field itself.

Practice this question →

416

Multi-Selecteasy

Which TWO data sources can you connect to Microsoft Sentinel to ingest security logs? (Select TWO.)

Select 2 answers

A.Google Cloud Platform audit logs

B.Azure Active Directory (Microsoft Entra ID) audit logs

C.Amazon Web Services (AWS) CloudTrail

D.Trello activity logs

E.GitHub Actions logs

AnswersB, C

Azure Active Directory (Microsoft Entra ID) audit logs are a first-party data source for Sentinel. The built-in Microsoft Entra ID connector ingests both sign-in logs and audit logs through the Microsoft Graph API after you enable diagnostic settings to stream them to Sentinel. This integration gives security teams identity-related telemetry such as sign-in failures, password changes, and conditional access activity without extra infrastructure.

Why this answer

Azure Active Directory (Microsoft Entra ID) audit logs are a native data source for Microsoft Sentinel. They can be connected directly via the Azure AD connector, which ingests sign-in logs, audit logs, and provisioning logs into the Log Analytics workspace. This integration is essential for monitoring identity-related security events and is a standard requirement for SC-200 scenarios.

Exam trap

The trap here is that candidates often assume any cloud or SaaS service can be connected via a generic API, but Microsoft Sentinel only supports specific, pre-built connectors for security-relevant sources like AWS CloudTrail and Azure AD, not for productivity tools like Trello or GitHub Actions logs.

Practice this question →

417

MCQeasy

Your organization uses Microsoft Sentinel. You need to design a solution to automatically respond to a specific type of incident by sending an email to the SOC manager and creating a ticket in ServiceNow. What should you use?

A.Create an analytics rule that directly sends an email.

B.Create a workbook that triggers a webhook.

C.Create an automation rule that sends an email and creates a ticket.

D.Create a playbook in Microsoft Sentinel and trigger it with an automation rule.

AnswerD

Playbooks are Azure Logic Apps that can integrate with external systems through connectors, enabling actions like sending email, creating tickets, or posting to chat. An automation rule can be configured to run a playbook automatically when an incident is created or updated, providing a scalable and customizable response. This design correctly separates detection (analytics rule) from orchestration (automation rule + playbook) and is the standard pattern for complex actions.

Why this answer

Microsoft Sentinel uses Azure Logic Apps-based playbooks to execute complex, multi-step automated responses, such as sending an email and creating a ServiceNow ticket. An automation rule is required to trigger the playbook when an incident meets specific criteria, as analytics rules alone cannot directly invoke external systems like ServiceNow.

Exam trap

The trap here is that candidates confuse automation rules with playbooks, thinking automation rules can directly perform actions like sending emails, when in fact they only orchestrate the triggering of playbooks that contain the actual logic.

How to eliminate wrong answers

Option A is wrong because analytics rules generate alerts or incidents but cannot directly send emails; they require a playbook or automation rule for external actions. Option B is wrong because workbooks are visualization tools that do not trigger automated responses or webhooks for incident handling. Option C is wrong because automation rules can trigger playbooks but cannot natively send emails or create ServiceNow tickets; those actions require a playbook (Logic App) with the appropriate connectors.

Practice this question →

418

Multi-Selecteasy

Which TWO roles can be used to manage Microsoft Sentinel? (Choose two.)

Select 2 answers

A.Compliance Administrator

B.Microsoft Sentinel Responder

C.Security Reader

D.Global Administrator

E.Microsoft Sentinel Contributor

AnswersB, E

Microsoft Sentinel Responder is one of the two built-in Sentinel-specific roles that can manage the day-to-day operational tasks within the product. It allows the assigned user to view and manage incidents, triage alerts, and execute playbooks when responding to threats, while intentionally omitting resource-creation permissions. This makes it the appropriate role for security operations analysts who need to act on active detections without reconfiguring the overall Sentinel environment.

Why this answer

Microsoft Sentinel Contributor (Option E) is a built-in Azure RBAC role that grants full permissions to create and manage Sentinel resources, including data connectors, analytics rules, and workbooks. Microsoft Sentinel Responder (Option B) is a dedicated role that allows users to manage incidents, perform investigations, and respond to threats without having full write access to the Sentinel workspace. Both roles are specifically designed for managing Microsoft Sentinel operations.

Exam trap

The trap here is that candidates often confuse Azure AD roles (like Global Administrator or Security Reader) with Sentinel-specific RBAC roles, assuming that broad administrative roles automatically grant Sentinel management capabilities, when in fact Sentinel requires dedicated roles scoped to the Log Analytics workspace.

Practice this question →

419

MCQeasy

Your Microsoft Sentinel workspace is ingesting data from multiple sources. You need to ensure that data from a specific source is retained for 2 years while other data remains at the default retention. What should you do?

A.Create a custom table for that source and set its retention to 2 years.

B.Adjust the data ingestion settings for that source.

C.Set the workspace retention to 2 years.

D.Configure archiving for that source's data.

AnswerA

Create a custom table for that source and set its retention to 2 years. This is correct because Microsoft Sentinel/Log Analytics supports per-table retention policies. By routing this source's data into its own custom table, you can configure that table's retention to 2 years without changing the workspace default. That gives you precisely the granularity needed for a single source.

Why this answer

In Microsoft Sentinel, retention is set at the table level. By creating a custom table for the specific data source and configuring its retention period to 2 years, you can override the default workspace retention for that table only. This allows other tables to retain the default retention setting while the custom table retains data for the required duration.

Exam trap

The trap here is that candidates often assume retention is set globally at the workspace level, but Microsoft Sentinel allows per-table retention, which is the correct method for applying different retention policies to different data sources.

How to eliminate wrong answers

Option B is wrong because data ingestion settings (like data source connectors or diagnostic settings) control what data is collected, not how long it is retained. Option C is wrong because setting the workspace retention to 2 years would apply to all tables in the workspace, not just the specific source. Option D is wrong because archiving is a separate tier for older data (e.g., after the interactive retention period ends) and does not set a specific retention duration for a source; it complements retention but does not replace the need for table-level retention configuration.

Practice this question →

420

MCQmedium

Your organization uses Microsoft Defender for Office 365. You need to create a custom alert that triggers when users receive external emails with attachments from untrusted domains. What should you configure?

A.Create an alert policy in Microsoft 365 Defender.

B.Create a mail flow rule in Exchange admin center.

C.Set up a conditional access policy in Microsoft Entra ID.

D.Configure a data sensitivity label in Microsoft Purview.

AnswerA

Creating an alert policy in Microsoft 365 Defender is correct because alert policies are specifically designed to monitor email activities and generate alerts when conditions are met. For instance, a policy can detect user-reported phishing, suspected malware, or unusual email forwarding patterns, producing an alert that appears in the Defender portal. These alerts can then be assigned severity, include custom notifications, and integrate with incident response queues.

Why this answer

A custom alert policy in Microsoft 365 Defender can be configured to detect when users receive external emails with attachments from untrusted domains. This leverages the built-in threat detection capabilities of Defender for Office 365, allowing you to define conditions such as sender domain reputation and attachment presence, and trigger an alert when the criteria are met.

Exam trap

The trap here is that candidates often confuse alert policies (which detect and notify) with mail flow rules (which enforce actions like blocking or quarantining), leading them to choose Option B when the question specifically asks for creating a custom alert.

How to eliminate wrong answers

Option B is wrong because a mail flow rule (transport rule) in Exchange admin center can block or modify messages based on sender domain or attachment presence, but it cannot generate a custom alert in the Microsoft 365 Defender portal; it only applies actions during message transport. Option C is wrong because a conditional access policy in Microsoft Entra ID controls access to cloud apps based on user, device, or location signals, not email content or attachments from untrusted domains. Option D is wrong because a data sensitivity label in Microsoft Purview is used to classify and protect sensitive data (e.g., via encryption or visual markings), not to detect or alert on external emails with attachments from untrusted domains.

Practice this question →

421

MCQeasy

Your organization uses Microsoft Sentinel and Microsoft Defender XDR. You want to use a Microsoft Copilot for Security to summarize an incident in Microsoft Defender XDR. What is the minimum role required?

A.Security Administrator

B.Reader

C.Security Reader

D.Global Administrator

AnswerC

Security Reader is an Entra ID role that grants read-only visibility into security settings, alerts, incidents, and threat intelligence across Microsoft 365 Defender and Microsoft Sentinel. Because Microsoft Copilot for Security only needs to retrieve and summarize security information, this read-only access is sufficient and adheres to least privilege. It is the only option from the list that correctly maps to the required permissions for a Copilot summarization task.

Why this answer

The minimum role required to use Microsoft Copilot for Security to summarize an incident in Microsoft Defender XDR is Security Reader. This role grants read-only access to security data, including incidents and alerts, which is sufficient for Copilot to retrieve and summarize incident details without requiring write permissions. Higher-privileged roles like Security Administrator or Global Administrator are unnecessary for this read-only operation.

Exam trap

The trap here is that candidates often confuse the general Azure Reader role with the security-specific Security Reader role, assuming any read-level access is sufficient, but only Security Reader has the precise permissions to access Defender XDR incident data via Copilot.

How to eliminate wrong answers

Option A is wrong because Security Administrator has write permissions to modify security settings and policies, which exceeds the minimum read-only access needed for summarizing incidents. Option B is wrong because the built-in Reader role does not have the specific permissions to access security incident data in Defender XDR; it is a general Azure role that lacks the necessary scope for security-specific resources. Option D is wrong because Global Administrator is a highly privileged role with full access to all Azure AD and security settings, far beyond the minimum required for read-only incident summarization.

Practice this question →

422

MCQhard

You are managing Microsoft Defender XDR. The security team reports that some automated investigations are closing prematurely without sufficient evidence. You need to ensure that investigations only close when a minimum confidence level is reached. What should you modify?

A.Change the action center settings to require manual approval.

B.Modify the tenant-level advanced features in Microsoft Defender XDR.

C.Create a custom detection rule to override default behavior.

D.Adjust the automation level in the Microsoft 365 Defender security settings.

AnswerD

Adjusting the automation level in the Microsoft 365 Defender security settings is the correct action because this setting includes the confidence level required for automatic investigation closure. The automation level can be set to 'Full – Automatically remediate threats,' which allows Defender to act on alerts with a high confidence verdict, or set to 'Semi – require additional confirmation,' which raises the bar for automatic closure. Changing this setting directly controls whether the system closes an investigation without human review, thereby addressing the team's requirement to modify that confidence threshold.

Why this answer

The automation level in Microsoft 365 Defender security settings controls how automated investigations behave, including the confidence level required for actions to be taken or for investigations to close. By adjusting the automation level (e.g., from 'Full – remediate threats automatically' to a higher threshold like 'Semi – require approval for any remediation'), you can ensure that investigations do not close prematurely without sufficient evidence. This setting directly addresses the requirement to enforce a minimum confidence level before closure.

Exam trap

The trap here is that candidates often confuse the 'automation level' setting with 'action center settings' or 'advanced features', leading them to select Option A or B, when in fact the automation level directly controls the confidence threshold for investigation closure.

How to eliminate wrong answers

Option A is wrong because the action center settings for manual approval control whether remediation actions require human approval, not the confidence level threshold for closing investigations. Option B is wrong because tenant-level advanced features in Microsoft Defender XDR (e.g., preview features, data retention) do not include settings for automation confidence levels or investigation closure criteria. Option C is wrong because custom detection rules are used to create custom alerts or detections, not to override the default behavior of automated investigation closure based on confidence levels.

Practice this question →

423

MCQhard

You are configuring Microsoft Sentinel to ingest logs from a third-party firewall via Syslog. The data connector shows 'Connected' but no events are being received. You have verified network connectivity and firewall configuration. What should you check next?

A.Validate that the Data Collection Rule (DCR) is properly configured to ingest the Syslog facility and severity.

B.Verify that the connector has the necessary OAuth permissions in Microsoft Entra ID.

C.Check that the user who configured the connector has the Microsoft Sentinel Contributor role.

D.Ensure the firewall is registered in Azure Policy as a compliant resource.

AnswerA

The Data Collection Rule (DCR) is the authoritative configuration that maps Syslog facility and severity filters to the Log Analytics workspace table. If the DCR's filters are too restrictive, omit the expected facility, or the DCR isn't correctly linked to the Azure Monitor Agent (AMA) and Data Collection Endpoint (DCE), events will be silently dropped. Validating the DCR is the first diagnostic step because misconfigurations here are the most common cause of missing Syslog ingestion.

Why this answer

When a Syslog data connector shows 'Connected' but no events are received, the most common cause is a misconfigured Data Collection Rule (DCR). The DCR defines which Syslog facilities and severities to collect; if it does not match the firewall's actual Syslog output (e.g., facility 'local0' with severity 'informational'), events will be filtered out before ingestion. Network connectivity and firewall configuration are already verified, so the DCR is the next logical check.

Exam trap

The trap here is that candidates assume 'Connected' means data is flowing, but in Syslog connectors, 'Connected' only indicates the agent can reach the Log Analytics workspace—the DCR's filtering logic is the hidden gate that stops events from being ingested.

How to eliminate wrong answers

Option B is wrong because Syslog data connectors do not use OAuth permissions; they rely on the Log Analytics agent or Azure Monitor Agent (AMA) and a DCR, not Microsoft Entra ID authentication. Option C is wrong because the connector configuration does not require the user to have the Microsoft Sentinel Contributor role; the connector setup uses the Log Analytics workspace permissions, and the role is irrelevant to event ingestion. Option D is wrong because Azure Policy compliance is unrelated to Syslog ingestion; firewalls are not registered in Azure Policy as resources, and policy compliance does not affect data flow from on-premises or third-party devices.

Practice this question →

424

MCQmedium

Your organization uses Microsoft Defender for Cloud. You need to recommend a solution to automatically remediate misconfigurations in Azure VMs without manual intervention. What should you use?

A.Use Azure Advisor recommendations

B.Configure Azure Backup

C.Set up Update Management in Azure Automation

D.Enable 'Remediate' option in Defender for Cloud recommendations

AnswerD

The 'Remediate' option in Microsoft Defender for Cloud recommendations is the only choice that directly applies automated corrective actions to non-compliant resources. When you trigger it, Defender for Cloud often deploys an Azure Policy assignment with the DeployIfNotExists effect, which automatically reconfigures the resource to meet the security recommendation. This one-click operation fixes the misconfiguration at scale without requiring manual edits, which is exactly what the organization needs.

Why this answer

Microsoft Defender for Cloud provides a 'Remediate' button on security recommendations that can automatically apply the necessary configuration changes to Azure resources, such as VMs, without manual intervention. This feature leverages Azure Policy's 'deployIfNotExists' effect to enforce compliance by running remediation tasks at scale, directly addressing misconfigurations like open management ports or missing disk encryption.

Exam trap

The trap here is that candidates often confuse Azure Advisor's recommendations with Defender for Cloud's recommendations, not realizing that only Defender for Cloud offers the 'Remediate' button for automatic enforcement, while Advisor merely provides advisory guidance without automated action.

How to eliminate wrong answers

Option A is wrong because Azure Advisor provides best-practice recommendations for cost, performance, reliability, and security, but it does not offer an automatic remediation capability for misconfigurations; it only suggests changes that must be applied manually. Option B is wrong because Azure Backup is a data protection service for creating and managing backup copies of VMs, files, and workloads; it has no role in remediating security misconfigurations. Option C is wrong because Update Management in Azure Automation is specifically designed to manage OS updates and patches, not to fix broader security misconfigurations like network security group rules or encryption settings.

Practice this question →

425

MCQeasy

Your organization has recently deployed Microsoft Sentinel and Microsoft Defender XDR. You are tasked with configuring the environment to ensure that incidents created by Microsoft Defender for Cloud Apps are automatically synchronized to Microsoft Sentinel. The security operations team wants to manage all incidents from within Sentinel. You have already connected the Microsoft Defender XDR connector to Sentinel. However, you notice that incidents from Defender for Cloud Apps are not appearing in Sentinel. You verify that the Defender for Cloud Apps connector is not listed in the data connectors blade. What should you do to resolve this issue?

A.Enable the Microsoft Sentinel integration in the Defender for Cloud Apps portal.

B.Configure a data collection rule in Microsoft Purview to forward alerts to Sentinel.

C.Install the Microsoft Defender for Cloud Apps connector from Sentinel data connectors.

D.Ensure the Microsoft Defender XDR connector is configured to include Defender for Cloud Apps incidents.

AnswerD

The proper way to ingest Defender for Cloud Apps incidents is to ensure the Microsoft Defender XDR data connector is enabled in Sentinel and that the 'Microsoft Defender for Cloud Apps' incident table is checked in its configuration. This connector automatically synchronizes incidents from Defender XDR—which include alerts and incidents generated by Defender for Cloud Apps—into Sentinel without any additional setup. As long as the connector shows a connected status and the correct product is selected, Cloud Apps incidents will flow directly to Sentinel's 'Incidents' blade.

Why this answer

When Microsoft Defender XDR connector is enabled in Sentinel, it can ingest incidents from all Microsoft Defender products, including Defender for Cloud Apps, provided the connector's configuration includes the option to synchronize those incidents. Since the Defender for Cloud Apps connector is not listed separately, the correct approach is to verify and adjust the Microsoft Defender XDR connector's settings to include Defender for Cloud Apps incidents. Option D directly addresses this by ensuring the existing connector is configured to forward those incidents.

Exam trap

The trap here is that candidates assume each Microsoft Defender product requires its own dedicated data connector in Sentinel, when in fact the Microsoft Defender XDR connector serves as the unified ingestion point for all Defender incidents, including those from Defender for Cloud Apps.

How to eliminate wrong answers

Option A is wrong because enabling the Sentinel integration in the Defender for Cloud Apps portal is used to send alerts from Defender for Cloud Apps to Sentinel via a legacy method, but when the Microsoft Defender XDR connector is already connected, incidents flow through the unified Microsoft 365 Defender pipeline, not through a separate portal toggle. Option B is wrong because data collection rules in Microsoft Purview are used for managing data lifecycle and compliance, not for forwarding security alerts or incidents to Sentinel. Option C is wrong because the Defender for Cloud Apps connector is not listed in the data connectors blade; this indicates that incidents from Defender for Cloud Apps are ingested through the Microsoft Defender XDR connector, not through a standalone connector.

Practice this question →

426

MCQmedium

Your organization uses Microsoft Defender XDR. You need to ensure that when a user reports a phishing email in Outlook, it automatically triggers an investigation in Microsoft Defender XDR. What should you configure?

A.Enable user-reported message settings in Microsoft Defender for Office 365 and configure automated investigation.

B.Create a playbook in Microsoft Sentinel triggered by a custom connector.

C.Configure a data loss prevention policy in Microsoft Purview.

D.Set up a session policy in Microsoft Defender for Cloud Apps.

AnswerA

Enabling user-reported message settings in Microsoft Defender for Office 365 ingests reports from the Outlook Report button into the system. When configured with automated investigation, each reported message automatically triggers an AIR (Automated Investigation and Response) workflow that runs detonation, threat hunting, and recommended actions. This is the only option that directly connects the user report to a native investigation in Microsoft Defender XDR, matching the requirement.

Why this answer

Enabling user-reported message settings in Microsoft Defender for Office 365 allows users to report phishing emails directly from Outlook. When combined with automated investigation and response (AIR) policies, this triggers an automatic investigation in Microsoft Defender XDR, leveraging the unified incident and alerting pipeline to analyze the reported message and associated threats.

Exam trap

The trap here is that candidates may confuse the native Defender for Office 365 user-reported message settings with a custom Sentinel playbook, overlooking that the question specifically requires automatic investigation in Defender XDR, not a separate SIEM orchestration.

How to eliminate wrong answers

Option B is wrong because Microsoft Sentinel is a SIEM for broader security analytics, not the native tool for triggering automated investigations from Outlook user reports; a custom connector and playbook would be an overly complex, non-native workaround. Option C is wrong because Data Loss Prevention (DLP) policies in Microsoft Purview are designed to prevent data exfiltration, not to initiate phishing investigations. Option D is wrong because session policies in Microsoft Defender for Cloud Apps control app access and session-level controls (e.g., conditional access app control), not the ingestion of user-reported emails into Defender XDR investigations.

Practice this question →

427

MCQeasy

You are a security analyst at a company that uses Microsoft Defender for Cloud Apps. You receive an alert that an anomalous activity was detected from a user's device. You need to investigate the activity to determine if it is a true positive. What should you do first?

A.Use Microsoft Power BI to analyze user activity data.

B.In the Microsoft Defender for Cloud Apps portal, open the alert and then click 'View activity' to see the detailed activity log.

C.Open the user's page in Microsoft Entra ID to review sign-in logs.

D.Create an IP address range policy to block the user's IP.

AnswerB

In Microsoft Defender for Cloud Apps, alerts are backed by discrete activity records captured via API connectors and conditional access app control. Opening the alert and clicking 'View activity' takes you to the Activity log with a filter pre-applied to that exact event, showing user, IP address, user agent, device, cloud app, action, and result. This is the native investigation path designed for alert triage, allowing you to pivot to adjacent activities, related alerts, or governance actions without leaving the portal. It directly answers who did what, from where, when, and with what outcome, which is exactly what an analyst needs for this alert.

Why this answer

The first step in investigating an anomalous activity alert in Microsoft Defender for Cloud Apps is to open the alert and click 'View activity' to examine the detailed activity log. This log provides the raw telemetry—such as IP address, user agent, timestamp, and activity type—needed to determine if the behavior is malicious or benign. Without reviewing this evidence, you cannot make an informed judgment about the alert's validity.

Exam trap

The trap here is that candidates confuse the investigation phase with the remediation phase, incorrectly choosing to block the IP (Option D) or review sign-in logs (Option C) before examining the actual activity details that confirm the threat.

How to eliminate wrong answers

Option A is wrong because Microsoft Power BI is a business analytics tool for visualizing data, not a security investigation interface; it cannot directly access the granular activity logs within Defender for Cloud Apps alerts. Option C is wrong because reviewing sign-in logs in Microsoft Entra ID only shows authentication events, not the full activity context (e.g., file downloads, app permissions) that Defender for Cloud Apps captures for anomaly detection. Option D is wrong because creating an IP address range policy to block the user's IP is a reactive remediation step, not a first investigative action; you must first confirm the activity is malicious before applying blocking policies.

Practice this question →

428

MCQmedium

Your organization has deployed Microsoft Sentinel and configured a workspace with data connectors for Microsoft 365 Defender, Azure Activity, and Office 365. You need to ensure that security incidents are automatically assigned to the appropriate analyst based on the incident type. What should you configure?

A.Create a playbook triggered by incident creation that assigns the incident to a user based on the incident title.

B.Add a watchlist that maps incident types to analyst email addresses and configure a scheduled analytics rule.

C.Create an automation rule that runs when an incident is created, with conditions on the incident title, and an action to assign the incident to a specific owner.

D.Configure a Microsoft 365 Defender incident assignment rule in the Microsoft 365 Defender portal.

AnswerC

Automation rules are the built-in incident orchestration mechanism in Microsoft Sentinel, and one can be configured to trigger whenever an incident is created. The rule can evaluate a condition on the incident's title, such as 'title contains phishing,' and then execute the 'Assign incident to owner' action, specifying an Azure AD user or group as the owner. This happens natively without invoking external workflows, providing instant, deterministic assignment that matches the requirement exactly.

Why this answer

Automation rules in Microsoft Sentinel allow you to define conditions (e.g., incident title containing specific keywords) and actions (e.g., assign incident to a specific owner) that run automatically when an incident is created. This directly meets the requirement to assign incidents to the appropriate analyst based on incident type without manual intervention.

Exam trap

The trap here is that candidates often confuse automation rules with playbooks or think that Microsoft 365 Defender incident assignment rules can manage all Sentinel incidents, but automation rules are the correct native mechanism for incident assignment within Sentinel across all data connectors.

How to eliminate wrong answers

Option A is wrong because playbooks triggered by incident creation can assign incidents, but they require custom logic and are more complex than necessary; automation rules provide a simpler, native way to assign incidents based on conditions. Option B is wrong because watchlists are used for correlation and enrichment in analytics rules, not for assigning incidents; scheduled analytics rules generate alerts, not incidents, and cannot assign ownership. Option D is wrong because Microsoft 365 Defender incident assignment rules apply only to incidents generated within the Microsoft 365 Defender portal, not to incidents ingested into Microsoft Sentinel from other connectors like Azure Activity or Office 365.

Practice this question →

429

MCQeasy

Refer to the exhibit. You run this KQL query in Microsoft Sentinel. What is the purpose of the query?

A.To list all incidents in the last 7 days

B.To count alerts by severity over the last week

C.To find the most recent high-severity alert

D.To identify hunting results

AnswerB

The query filters SecurityAlert records to the last seven days using the TimeGenerated field and then uses summarize to count rows grouped by AlertSeverity, returning one row per severity value with a count. This directly answers how many low, medium, high, and informational alerts occurred in that window. It is the intended purpose of this KQL statement.

Why this answer

The KQL query uses the `SecurityAlert` table and summarizes alerts by `AlertSeverity` using the `count()` aggregation function. The `where TimeGenerated > ago(7d)` filter restricts results to the last 7 days, and the `project` clause outputs only the severity and count columns. This directly produces a count of alerts grouped by severity over the last week, matching option B.

Exam trap

The SC-200 exam often tests the distinction between the `SecurityAlert` table (alerts) and the `SecurityIncident` table (incidents), and candidates mistakenly interpret any time-filtered count query as 'listing incidents' or 'finding the most recent alert' without recognizing the aggregation and projection logic.

How to eliminate wrong answers

Option A is wrong because the query queries the `SecurityAlert` table (alerts), not the `SecurityIncident` table (incidents), and it counts alerts rather than listing incidents. Option C is wrong because the query summarizes counts by severity, not filtering for the single most recent high-severity alert; there is no `top 1` or `sort by TimeGenerated` to isolate the latest alert. Option D is wrong because hunting results are stored in the `HuntingBookmark` table or generated via custom hunting queries, not the `SecurityAlert` table, and the query performs a simple aggregation, not a hunting operation.

Practice this question →

430

Multi-Selecteasy

You are managing Microsoft Defender for Cloud Apps. Which TWO actions can be performed using the Microsoft Defender XDR integration?

Select 2 answers

A.Quarantine malicious emails.

B.Investigate user activities across cloud apps.

C.Govern discovered apps with access policies.

D.Manage device compliance policies in Microsoft Intune.

E.Onboard devices to Microsoft Defender for Endpoint.

AnswersB, C

Defender for Cloud Apps collects activity log from connected cloud apps, such as Office 365, AWS, and Google Workspace, and presents them in a unified investigation experience. Analysts can search a user's activity timeline, cross-correlate with alerts from Microsoft Defender XDR, and trace the scope of a compromise across multiple SaaS services. This investigation capability directly addresses security incidents that span cloud applications, making it a core function of a CASB.

Why this answer

Microsoft Defender XDR integration with Defender for Cloud Apps enables cross-domain investigation of user activities across cloud apps, leveraging signals from Microsoft 365 Defender to correlate events like sign-ins, file downloads, and admin actions. This allows security analysts to trace a user's behavior across SaaS applications (e.g., SharePoint, OneDrive, Teams) without switching consoles, using the unified incidents and alerts in the Microsoft 365 Defender portal.

Exam trap

The trap here is that candidates confuse the scope of Defender for Cloud Apps with broader Microsoft 365 security features, assuming it can perform email quarantine (A) or endpoint management (D, E) when those actions belong to separate products like Defender for Office 365 and Intune.

Practice this question →

431

Multi-Selectmedium

Your organization uses Microsoft Sentinel with the Azure Activity connector. Which TWO actions should you take to ensure that all subscription-level activity logs are being ingested into Sentinel?

Select 2 answers

A.Install the Azure Activity solution from the content hub.

B.Enable diagnostic settings on each subscription to stream logs to the Sentinel Log Analytics workspace.

C.Assign the 'Reader' role to the Sentinel managed identity on each subscription.

D.Configure the Azure Activity data connector to include all subscriptions.

E.Use the Azure Policy initiative to deploy the connector.

AnswersC, D

The Sentinel workspace's managed identity must be assigned the Reader role on each subscription that will contribute activity logs. This role allows the Azure Activity data connector to call the Azure Monitor Activity Log API and retrieve subscription-level audit events. Without this permission grant, the connector will show success but collect zero records, or will fail authentication when polling for new activity.

Why this answer

The Azure Activity data connector uses a managed identity to read subscription-level activity logs. Assigning the 'Reader' role to that managed identity on each subscription grants it the necessary permissions to access and ingest the logs into Sentinel. Without this role assignment, the connector cannot retrieve the activity data, even if the connector is configured.

Exam trap

The trap here is that candidates often confuse the Azure Activity connector's requirement for a managed identity role assignment with the diagnostic settings method used by other data connectors, leading them to incorrectly select option B.

Practice this question →

432

MCQhard

Your SOC uses Microsoft Sentinel with multiple workspaces for different business units. You want to create a single dashboard that shows key performance indicators (KPIs) across all workspaces. Which approach minimizes complexity and query latency?

A.Export data to Azure Data Explorer and build the dashboard there.

B.Ingest all logs into a single workspace and create the dashboard there.

C.Use Power BI to query each workspace separately and combine data.

D.Use cross-workspace queries in a single dashboard that references all workspaces.

AnswerD

Cross-workspace queries let a single Sentinel dashboard use KQL to query multiple Log Analytics workspaces in real time by referencing each workspace with the workspace() expression, such as union workspace("WS-A").SecurityEvent, workspace("WS-B").SecurityEvent. This approach avoids moving or duplicating data, provides immediate visibility, and is the minimal-effort design intended by Microsoft. It also requires proper read permissions on all referenced workspaces, but no additional infrastructure or data pipelines.

Why this answer

Cross-workspace queries in Microsoft Sentinel allow you to query multiple workspaces in a single KQL query using the `workspace()` expression, enabling a unified dashboard without data duplication or additional infrastructure. This minimizes complexity by avoiding data movement and reduces query latency by leveraging the existing indexing and caching within each workspace.

Exam trap

The trap here is that candidates may assume a single workspace is simpler (Option B) or that external tools like Power BI are required for cross-source aggregation, missing the native cross-workspace query capability in Sentinel that is designed exactly for this multi-workspace scenario.

How to eliminate wrong answers

Option A is wrong because exporting data to Azure Data Explorer introduces additional latency and complexity from data export, transformation, and storage, and is unnecessary when Sentinel already supports cross-workspace queries. Option B is wrong because ingesting all logs into a single workspace violates the requirement of separate workspaces for different business units and creates a single point of failure, increased ingestion costs, and potential data sovereignty issues. Option C is wrong because using Power BI to query each workspace separately requires multiple connections and data merging on the client side, which increases query latency and complexity compared to native cross-workspace queries that run server-side in Sentinel.

Practice this question →

433

Multi-Selectmedium

Your organization uses Microsoft Sentinel and wants to reduce alert fatigue. Which TWO actions should you take to improve the quality of incidents?

Select 2 answers

A.Create separate incidents for each alert.

B.Create automation rules to close all low-severity incidents automatically.

C.Configure alert grouping in analytics rules to combine related alerts into one incident.

D.Use suppression and tuning rules to filter out known benign activity.

E.Increase the severity of all low-severity alerts to high.

AnswersC, D

Alert grouping in an analytics rule, configured under 'Incident settings,' consolidates alerts that share the same group key—commonly entity mappings like account, host, or IP—into a single incident. This reduces alert volume while preserving the correlation between related events, enabling the analyst to see the full attack narrative in one place. Grouping also lets you set a display name and alert severity for the aggregated incident, which improves triage prioritization and reduces the operational overhead of handling many separate incident objects.

Why this answer

Configuring alert grouping in analytics rules consolidates multiple related alerts into a single incident, reducing noise and helping analysts focus on the root cause rather than triaging individual alerts. This directly improves incident quality by providing a richer context and reducing alert fatigue.

Exam trap

The trap here is that candidates often confuse 'reducing alert fatigue' with simply deleting or ignoring low-severity alerts, rather than understanding that intelligent grouping and suppression of known benign activity preserves detection fidelity while reducing noise.

Practice this question →

434

Multi-Selecthard

Which TWO steps are necessary to configure Microsoft Sentinel to automatically disable a compromised user account in Microsoft Entra ID when a high-severity incident is created?

Select 2 answers

A.Create a playbook that uses the Microsoft Entra ID 'Disable user' action.

B.Create an automation rule that triggers the playbook when a high-severity incident is created.

C.Enable the Microsoft Defender XDR connector.

D.Enable the Microsoft Entra ID Protection data connector.

E.Create an analytics rule that detects compromised user accounts.

AnswersA, B

The playbook is the core remediation component because it contains the executable logic that calls the Microsoft Entra ID 'Disable user' action. This action, available via the Microsoft Entra ID connector in Azure Logic Apps, directly disables the targeted user account, effectively neutralizing the compromised identity. Without this action, the playbook would have no ability to apply a security control, so it is a mandatory piece of the automated response.

Why this answer

A playbook is an automated workflow that can contain the 'Disable user' action from Microsoft Entra ID, which directly disables a compromised user account. This action leverages the Microsoft Graph API to update the user's accountEnabled property to false, effectively blocking sign-ins. Without this playbook, there is no mechanism to execute the disablement action when an incident is created.

Exam trap

The trap here is that candidates often confuse data connectors (which only ingest data) with playbooks (which perform actions), leading them to select options like the Microsoft Entra ID Protection data connector instead of the playbook and automation rule combination.

Practice this question →

435

Multi-Selecteasy

Which TWO are supported methods to ingest syslog data into Microsoft Sentinel?

Select 2 answers

A.Common Event Format (CEF) connector

B.Logstash output plugin

C.Azure Event Hubs

D.Syslog connector using Azure Monitor Agent (AMA)

E.Direct Azure Monitor Agent ingestion without connector

AnswersA, D

The Common Event Format (CEF) connector is a supported syslog ingestion method because it uses a dedicated syslog forwarder (typically a Linux VM running the CEF collector) that listens for syslog messages formatted as CEF, normalizes them, and sends them to the CommonSecurityLog table in Microsoft Sentinel. This connector natively parses the key/value pairs in CEF and maps them to standard fields, making it a first-class, documented integration for security devices that emit syslog in CEF format.

Why this answer

The Common Event Format (CEF) connector is a supported method because it uses a syslog daemon on a Linux log collector to receive CEF-formatted syslog messages over UDP/TCP (port 514 or 25226) and forwards them to the Log Analytics workspace via the Log Analytics agent. This connector specifically parses CEF headers and maps fields to Sentinel's schema, making it a native ingestion path for security appliances like Palo Alto Networks or Fortinet.

Exam trap

The trap here is that candidates confuse Azure Event Hubs as a direct ingestion method for syslog data, when it is actually a transport layer that requires additional components (like a syslog collector or Logstash) to forward data to Sentinel.

Practice this question →

436

MCQhard

Your organization uses Microsoft Sentinel and Microsoft Entra ID. You need to implement a solution that automatically disables a user account in Microsoft Entra ID when a high-severity incident involving that user is created in Sentinel. The solution must also send a notification to the security team. You have a playbook that disables the user and sends an email. What should you configure to trigger the playbook?

A.Configure the playbook to run on a schedule and query incidents.

B.Create a workbook that triggers the playbook when a high-severity incident appears.

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

D.Configure the playbook as a response action in the analytics rule that generates the incident.

AnswerC

Automation rules are Sentinel's native mechanism for triggering playbooks in response to incident creation, and they support severity-based conditions. Matching severity High ensures the playbook runs only for the relevant incidents, satisfying the automatic disablement and notification requirement.

Why this answer

To automatically trigger a playbook when a high-severity incident is created in Microsoft Sentinel, you should create an automation rule. Automation rules in Microsoft Sentinel allow you to define conditions (such as incident severity) and actions (such as running a playbook). This is the native, no-code way to trigger playbooks based on incident creation.

Exam trap

SC-200 often tests the difference between automation rules and analytics rule response actions, confusing candidates about which to use for triggering playbooks on incident creation.

How to eliminate wrong answers

Option A is wrong because running a playbook on a schedule would not be event-driven and would not trigger immediately upon incident creation; it would also require the playbook to query incidents, which is inefficient. Option B is wrong because workbooks are for visualization and reporting, not for triggering playbooks. Option D is wrong because while you can configure a playbook as a response action in an analytics rule, that is only for incidents generated by that specific rule, and it is not the most flexible or recommended approach for triggering on any high-severity incident; automation rules are designed for this purpose.

Practice this question →

437

MCQmedium

Your Microsoft Sentinel environment is not generating incidents from a custom KQL detection rule. The rule runs successfully in the Log Analytics query editor but no incidents appear. What is the most likely cause?

A.The rule's alert grouping settings are misconfigured

B.The rule is set to create alerts but not incidents

C.The rule's query schedule is too long

D.The rule does not have entity mapping configured

AnswerB

Sentinel analytics rules have separate toggles for generating alerts and creating incidents. If incident creation is disabled, the rule fires and logs alerts but no incidents appear, matching the symptom of a query that runs successfully yet produces nothing.

Why this answer

The most likely cause is that the rule is set to create alerts but not incidents. In Microsoft Sentinel, analytics rules have a toggle to 'Create incidents' from alerts. If this toggle is disabled, alerts are generated but not grouped into incidents.

The query running successfully in Log Analytics confirms the rule logic works, but incidents will not appear unless the incident creation toggle is enabled. Entity mapping is not required for incident creation; it enhances correlation but is not a prerequisite.

Exam trap

The trap is that candidates often assume entity mapping is necessary for incident creation, but in reality the key setting is the 'Create incident' toggle. They may overlook this simple configuration.

How to eliminate wrong answers

Option A is wrong because alert grouping settings control how alerts are grouped into a single incident (e.g., by entity or time window), but they do not prevent incidents from being created entirely; if incidents are enabled, misconfigured grouping might cause unexpected grouping, not a total absence of incidents. Option B is wrong because this is the correct description of the issue—the rule is set to create alerts but not incidents, which directly explains why no incidents appear despite successful query execution. Option C is wrong because a long query schedule (e.g., running every 24 hours) would delay incident creation but not prevent it; incidents would still appear after the scheduled run if the rule is configured to create them.

Practice this question →

438

MCQmedium

Your organization uses Microsoft Defender for Identity. You need to receive alerts when suspicious LDAP queries are detected. What should you configure?

A.Set up an anomaly detection policy in Microsoft Defender for Cloud Apps.

B.Configure alert rules in Microsoft Defender for Identity.

C.Assign the Security Administrator role in Microsoft Entra ID.

D.Create a custom sensitivity label in Microsoft Purview.

AnswerB

Defender for Identity's alert rules are the correct mechanism to detect suspicious LDAP queries because its lightweight sensor, installed on domain controllers, AD FS, and AD CS servers, monitors incoming LDAP traffic. The service includes a built-in alert rule named "LDAP reconnaissance" that compares query patterns to known reconnaissance techniques such as account enumeration, group membership queries, or unauthenticated LDAP searches. By configuring this alert rule—adjusting thresholds and enabling it to trigger—you directly satisfy the requirement to detect suspicious LDAP queries.

Why this answer

Microsoft Defender for Identity (MDI) detects suspicious LDAP queries, such as LDAP reconnaissance or directory traversal attacks, by analyzing domain controller traffic. To receive alerts for these detections, you must configure alert rules directly within the MDI portal, which allows you to set thresholds and notification preferences for specific LDAP-related activities. Option B is correct because MDI's built-in alert rules are the mechanism for generating and delivering these security alerts.

Exam trap

The trap here is that candidates may confuse Microsoft Defender for Cloud Apps' anomaly detection policies with MDI's alert rules, not realizing that LDAP query monitoring is a core MDI function tied to on-premises Active Directory traffic, not cloud app behavior.

How to eliminate wrong answers

Option A is wrong because Microsoft Defender for Cloud Apps (MCAS) focuses on cloud application usage and shadow IT, not on-premises LDAP traffic; anomaly detection policies in MCAS are for cloud app behavior, not domain controller LDAP queries. Option C is wrong because assigning the Security Administrator role in Microsoft Entra ID grants permissions to manage security settings across Microsoft 365 but does not directly configure alert rules for LDAP queries in MDI; it is an administrative role, not a configuration setting. Option D is wrong because custom sensitivity labels in Microsoft Purview are used for data classification and protection (e.g., labeling documents or emails), not for detecting or alerting on suspicious LDAP queries.

Practice this question →

439

MCQmedium

Your organization has Microsoft Defender for Cloud Apps and Microsoft Sentinel integrated. The security team wants to receive alerts when a user's activity from an anonymous IP address exceeds a certain risk score. What should you configure in Defender for Cloud Apps?

A.Anomaly detection policy

B.File policy

C.Activity policy

D.App discovery policy

AnswerC

Activity policies are the correct choice because they allow you to define custom, rule-based conditions on tens of thousands of user operations, including sign-in events, admin actions, and file accesses. These policies support granular filters like IP category (including Anonymous), user risk level, and device tags, so you can trigger an immediate alert when a user logs in from an anonymous IP. Unlike anomaly detection, this is deterministic and provides precise, actionable results with low noise.

Why this answer

Activity policies in Microsoft Defender for Cloud Apps allow you to monitor and respond to specific user activities based on conditions such as IP address categories (e.g., anonymous proxy) and risk scores. This policy type can trigger alerts when a user's activity from an anonymous IP address exceeds a defined risk score threshold, meeting the security team's requirement.

Exam trap

The trap here is that candidates often confuse anomaly detection policies (which detect behavioral anomalies) with activity policies (which allow explicit condition-based filtering), leading them to select Option A incorrectly.

How to eliminate wrong answers

Option A is wrong because anomaly detection policies focus on identifying unusual patterns of behavior (e.g., impossible travel, unusual mass download) rather than filtering activities based on a specific IP category like anonymous IP addresses combined with a risk score. Option B is wrong because file policies are designed to monitor and control data sharing and file access (e.g., sharing sensitive files externally), not user activities from specific IP types. Option D is wrong because app discovery policies are used to identify and analyze shadow IT usage (i.e., unsanctioned cloud apps), not to alert on user activities from anonymous IP addresses.

Practice this question →

440

MCQhard

You are reviewing the ARM template snippet shown in the exhibit. What is the purpose of this template?

A.Create a workbook in Azure Monitor

B.Create an analytics rule in Microsoft Sentinel

C.Create a saved search in a Log Analytics workspace

D.Create a data connector in Microsoft Sentinel

AnswerC

The resource type 'Microsoft.OperationalInsights/workspaces/savedSearches' is specifically used to create a saved search in a Log Analytics workspace. The 'properties' object includes 'category' and 'query', where the query is the KQL statement to be saved. This saved search can be reused in workbooks or pinned to dashboards, and it is the correct interpretation of this ARM template snippet.

Why this answer

The ARM template snippet defines a saved search resource of type 'Microsoft.OperationalInsights/workspaces/savedSearches'. This resource type is specifically used to create a saved query within a Log Analytics workspace, which can then be used for log queries, alert rules, or workbooks. Option C correctly identifies this purpose.

Exam trap

The trap here is that candidates may confuse saved searches with other Log Analytics features like workbooks or analytics rules, but the resource type 'Microsoft.OperationalInsights/workspaces/savedSearches' is uniquely tied to saved queries, not visualizations or alerting logic.

How to eliminate wrong answers

Option A is wrong because creating a workbook in Azure Monitor uses the resource type 'Microsoft.Insights/workbooks', not 'Microsoft.OperationalInsights/workspaces/savedSearches'. Option B is wrong because creating an analytics rule in Microsoft Sentinel uses the resource type 'Microsoft.SecurityInsights/alertRules', not a saved search. Option D is wrong because creating a data connector in Microsoft Sentinel uses resource types like 'Microsoft.SecurityInsights/dataConnectors' or 'Microsoft.OperationalInsights/workspaces/dataSources', not a saved search.

Practice this question →

441

MCQeasy

Refer to the exhibit. You deploy this ARM template to your subscription. After deployment, you cannot find the saved search 'Test Search' in the Microsoft Sentinel workspace. What is the most likely reason?

A.The resource type should be for analytics rules, not saved searches.

B.The query 'Heartbeat | summarize Count() by Computer' is invalid.

C.The apiVersion is incorrect.

D.The name concatenation is missing a parameter.

AnswerA

The core issue in this template is the resource type. Microsoft Sentinel analytics rules must be declared as `Microsoft.SecurityInsights/alertRules` (or under a Sentinel-compatible solution), not as `Microsoft.OperationalInsights/workspaces/savedSearches`. A savedSearches resource only creates a Log Analytics saved query, which will not appear in the Sentinel Analytics blade or generate alerts. Therefore, the deployment succeeds but the intended detection rule does not function.

Why this answer

The ARM template deploys a resource of type 'Microsoft.OperationsManagement/solutions' with a saved search, but Microsoft Sentinel does not use saved searches for analytics rules. In Sentinel, detection rules are created as 'Microsoft.SecurityInsights/alertRules', not as saved searches under a Log Analytics workspace. The template's resource type is mismatched for the intended functionality, so the saved search 'Test Search' will not appear as a Sentinel analytics rule.

Exam trap

The trap here is that candidates assume any KQL query deployed via ARM template in a Log Analytics workspace will automatically appear as a Sentinel analytics rule, but Microsoft requires the correct resource provider and type for Sentinel-specific features.

How to eliminate wrong answers

Option B is wrong because the query 'Heartbeat | summarize Count() by Computer' is syntactically valid KQL and would execute successfully in Log Analytics; it is not the reason the saved search is missing. Option C is wrong because the apiVersion '2015-11-01-preview' is a valid and supported version for Log Analytics saved searches and solutions; an incorrect apiVersion would cause a deployment error, not a silent failure to find the search. Option D is wrong because the name concatenation '[concat(parameters('workspaceName'), '/', variables('savedSearchName'))]' is correctly formatted and includes all required parameters; missing a parameter would cause a deployment failure, not a missing search.

Practice this question →

442

MCQhard

You are the security operations lead for a multinational company that uses Microsoft Sentinel in a single workspace. You have recently onboarded 10 new business units, each with their own analytics rules and automation. The security team is overwhelmed by the number of low-fidelity incidents generated. You need to reduce noise without disabling critical detections. You must ensure that each business unit retains ownership of their incidents and can customize their own suppression rules. You also need centralized reporting on incident trends across all business units. You have identified that many low-fidelity alerts come from a common set of data sources. What should you do?

A.Disable the data connectors that produce the most noise.

B.Create an automation rule that automatically closes low-severity incidents.

C.Create a separate analytics rule for low-fidelity alerts that uses alert suppression to group similar alerts.

D.Create a workbook that filters out low-severity incidents from the dashboard.

AnswerC

Alert suppression in a dedicated analytics rule groups similar low-fidelity alerts into a single incident, reducing the incident queue while retaining signal awareness. Because it is a separate rule, its suppression settings can be tuned independently without impacting high-fidelity detection rules. This balances detection capability with operational efficiency, making it the only option that actually lowers incident volume without losing data.

Why this answer

Creating a separate analytics rule for low-fidelity alerts with alert suppression enabled allows you to group similar alerts into a single incident, reducing noise without disabling the underlying data connectors or critical detections. This approach preserves each business unit's ownership of their incidents and enables them to customize suppression rules via automation rules or analytics rule settings, while centralized reporting on incident trends remains intact because the workspace still ingests all alerts.

Exam trap

The trap here is that candidates often confuse reducing noise with simply hiding or closing incidents after they are generated, rather than preventing the noise at the analytics rule level through alert suppression, which is the only option that reduces incident volume while preserving data fidelity and per-unit customization.

How to eliminate wrong answers

Option A is wrong because disabling data connectors that produce noise would also remove all alerts from those sources, potentially disabling critical detections that rely on the same data, and it does not allow per-business-unit customization. Option B is wrong because automatically closing low-severity incidents via an automation rule does not reduce the number of incidents generated; it only closes them after creation, still overwhelming the queue and potentially hiding legitimate low-severity incidents that require investigation. Option D is wrong because creating a workbook that filters out low-severity incidents only changes the dashboard view, not the actual incident generation or noise reduction, and it does not address the root cause of excessive low-fidelity alerts.

Practice this question →

443

MCQhard

Refer to the exhibit. An automation rule in Microsoft Sentinel is configured as shown. When a high-severity incident is created, what is the expected behavior?

A.All actions execute successfully: task created, playbook runs, incident owner set to SOC-Tier1.

B.The rule fails to run because the actions are not in valid JSON format.

C.The task is created, then the playbook runs, but the incident modification fails because the owner is incorrectly formatted.

D.The playbook runs first, then the task is created, then the incident is modified.

AnswerC

The automation rule successfully creates the task and triggers the playbook as configured. However, Microsoft Sentinel requires incident owners to be valid Microsoft Entra ID user principal names or object IDs. If the automation rule's configuration for setting the incident owner specifies an incorrectly formatted value, such as an arbitrary string that does not correspond to a recognised identity, the attempt to modify the incident's owner property will fail. This specific constraint on owner format causes the modification failure, even if other actions succeed.

Why this answer

The automation rule in Microsoft Sentinel executes actions sequentially. The task creation and playbook run succeed, but the incident modification fails because the owner field is incorrectly formatted. Sentinel expects the incident owner to be specified as a user principal name (UPN) or object ID, not a plain text string like 'SOC-Tier1'.

Exam trap

The trap here is that candidates assume all actions in an automation rule execute independently and ignore the specific formatting requirements for the incident owner field, leading them to select Option A or D.

How to eliminate wrong answers

Option A is wrong because the incident modification action fails due to the invalid owner format, so not all actions execute successfully. Option B is wrong because the rule actions are defined in the Sentinel UI as structured JSON, which is valid; the failure is due to runtime validation of the owner value, not JSON syntax. Option D is wrong because the actions execute in the order listed in the rule: task creation first, then playbook, then incident modification; the playbook does not run first.

Practice this question →

444

MCQeasy

Your SOC team receives a high-priority incident related to a potential malware outbreak. You need to quickly identify all affected devices and users across the environment. What Microsoft Defender XDR feature should you use?

A.Advanced hunting

B.Action center

C.Incident graph

D.Microsoft Sentinel workbook

AnswerC

Incident graph maps the relationships between alerts, devices, users and mailboxes into a single visual topology, letting analysts pivot from the incident to every affected entity. This directly satisfies the need to identify all impacted devices and users across the environment quickly.

Why this answer

The incident graph in Microsoft Defender XDR visually maps the relationships between alerts, devices, users, IP addresses, and other entities involved in an incident, letting analysts quickly see the full scope of an outbreak. It aggregates related alerts into a single incident and shows lateral movement, affected users, and affected devices in one view. This is the fastest way to identify all impacted assets and accounts during a high-priority malware incident.

Exam trap

SC-200 often tests the difference between hunting (Advanced hunting), remediation tracking (Action center), and incident visualization (Incident graph), so candidates who pick Advanced hunting miss that the question asks for quick identification of all affected entities, not a custom query.

How to eliminate wrong answers

Option A is wrong because Advanced hunting is a query-based tool (KQL) for proactive threat hunting and custom detection, not the visual incident-scoping feature that shows all affected devices and users at a glance. Option B is wrong because Action center tracks remediation actions taken on devices and users, not the relationship map of an incident's affected entities. Option D is wrong because Microsoft Sentinel workbooks are dashboards for log analytics and reporting, not the Defender XDR incident graph that correlates entities within an incident.

Practice this question →

445

MCQmedium

You are a security analyst. You notice that Microsoft Sentinel is not receiving logs from Microsoft 365 Defender incidents. The diagnostic settings in Microsoft 365 Defender are configured to send data to the Sentinel workspace. What should you check first?

A.Check if the Microsoft Sentinel solution is installed.

B.Verify that the Log Analytics workspace is in the same region as the Sentinel workspace.

C.Ensure the Microsoft 365 Defender data connector in Microsoft Sentinel is enabled.

D.Check the 'SecurityIncident' table schema for missing columns.

AnswerC

Ensure the Microsoft 365 Defender data connector is enabled because this connector is the only ingestion path by which incidents generated in Microsoft 365 Defender are pulled into Microsoft Sentinel. When disabled, no SecurityIncident records from Defender are written, and the connector must show a 'Connected' status in the Data connectors blade. The connector uses delegated API permissions to subscribe to Defender incidents; without this enabled configuration, all other workspace and solution settings are irrelevant to the missing data.

Why this answer

The diagnostic settings in Microsoft 365 Defender send raw data to the Log Analytics workspace, but Microsoft Sentinel must have the Microsoft 365 Defender data connector enabled to parse and ingest that data into the correct tables (e.g., SecurityIncident, AlertInfo). Without the connector enabled, the logs arrive in the workspace but are not processed by Sentinel, so incidents won't appear. This is the first and most common check because the connector acts as the ingestion pipeline.

Exam trap

The trap here is that candidates assume diagnostic settings alone are sufficient for data ingestion, but they overlook that the Sentinel data connector is the required bridge to parse and normalize the data into Sentinel-specific tables.

How to eliminate wrong answers

Option A is wrong because the Microsoft Sentinel solution must be installed on the workspace for Sentinel to function at all, but the question states Sentinel is already present and only missing M365 Defender incidents, so the solution is likely installed. Option B is wrong because Log Analytics workspaces do not have a region constraint with Sentinel; Sentinel is a service that runs on top of the workspace, and they must be in the same region, but this is a prerequisite that would prevent all data ingestion, not just M365 Defender incidents. Option D is wrong because the 'SecurityIncident' table schema is fixed and cannot be modified; missing columns would indicate a schema change or corruption, which is extremely rare and not the first troubleshooting step for missing data.

Practice this question →

446

MCQmedium

You are a security analyst for a company that uses Microsoft Defender XDR. You receive a high-severity incident indicating that a user's device has been compromised with a remote access trojan (RAT). The incident is automatically generated by Microsoft Defender XDR. You need to contain the threat immediately while preserving forensic data. You also need to ensure that the user can continue working with minimal disruption. What should you do?

A.Initiate device isolation from Microsoft Defender XDR.

B.Restore the device from a recent backup.

C.Run a full antivirus scan on the device.

D.Reset the user's password and force a sign-out.

AnswerA

Initiating device isolation in Microsoft Defender XDR severs the endpoint's network connections while preserving its communication path to the Defender service, effectively halting the RAT's command-and-control (C2) channel and preventing lateral movement or data exfiltration. This containment action also preserves the in-memory and on-disk artifacts needed for forensic analysis, since the device remains powered on and untouched. Isolation is the immediate, containment-focused response that limits the attacker's ability to operate while allowing the IR team to investigate and remediate safely.

Why this answer

Initiating device isolation from Microsoft Defender XDR immediately disconnects the device from the network while preserving forensic data on the device. This contains the RAT's command-and-control communication without disrupting the user's ability to work offline, and it allows the security team to investigate the compromised device without risk of lateral movement or data exfiltration.

Exam trap

The trap here is that candidates may choose a reactive remediation step like running a scan or resetting credentials, failing to recognize that immediate containment via network isolation is the priority to stop active compromise while preserving evidence.

How to eliminate wrong answers

Option B is wrong because restoring from a recent backup would overwrite existing forensic data, potentially destroying evidence of the RAT's installation and persistence mechanisms, and it does not contain the active threat in real time. Option C is wrong because running a full antivirus scan is a reactive, time-consuming step that does not immediately stop the RAT from communicating or spreading; the threat remains active during the scan. Option D is wrong because resetting the user's password and forcing a sign-out does not address the device-level compromise; the RAT would still be present on the device and could re-establish access or capture new credentials.

Practice this question →

447

MCQmedium

Your organization has deployed Microsoft Sentinel and Microsoft Defender XDR. You need to ensure that all Defender XDR incidents are automatically synchronized into Microsoft Sentinel for a single pane of glass. What should you configure?

A.Enable the Microsoft Sentinel data connector for Microsoft Defender XDR

B.Use Microsoft Graph API to sync incidents daily

C.Create an automation rule in Microsoft Sentinel to create incidents from Defender XDR alerts

D.Configure Microsoft Defender XDR to forward incidents to Sentinel using a webhook

AnswerA

The Microsoft Sentinel data connector for Microsoft Defender XDR is the native, supported integration that continuously streams incidents and alerts from Defender XDR into Sentinel using the Microsoft Graph API. Once enabled, incident properties, status, and severity are automatically synchronized bi-directionally, enabling SOC analysts to manage the full incident lifecycle from a single pane. This requires no custom coding, uses built-in authentication, and provides near real-time ingestion, making it the only correct solution for this scenario.

Why this answer

The Microsoft Sentinel data connector for Microsoft Defender XDR is the native integration that automatically synchronizes all Defender XDR incidents into Sentinel. This connector ingests incidents, alerts, and evidence from Defender XDR into the Sentinel workspace, enabling a single pane of glass without requiring custom scripting or manual workflows.

Exam trap

The trap here is that candidates often confuse alert-based connectors (like the Microsoft Defender for Endpoint connector) with the incident-level Microsoft Defender XDR connector, or they assume that automation rules or webhooks are the correct method for incident synchronization, when the native connector is the only supported and recommended approach.

How to eliminate wrong answers

Option B is wrong because using Microsoft Graph API to sync incidents daily would require custom development, polling logic, and manual scheduling, which is not a built-in or supported method for automatic incident synchronization; the native connector handles this in real time. Option C is wrong because creating an automation rule in Sentinel to create incidents from Defender XDR alerts would only process individual alerts, not the correlated incidents that Defender XDR generates, and would bypass the incident-level synchronization provided by the connector. Option D is wrong because configuring Defender XDR to forward incidents to Sentinel using a webhook is not a supported feature; Defender XDR does not have a native webhook export for incidents, and even if implemented via Logic Apps, it would be a custom, non-standard approach compared to the official connector.

Practice this question →

448

MCQeasy

You are configuring a Microsoft Sentinel automation rule to automatically assign incidents to a specific owner based on a custom property. Which action type should you use?

A.Run playbook

B.Assign owner

C.Change status

D.Create ticket (preview)

AnswerB

The Assign owner action changes an incident's owner to a specified user or group, satisfying the requirement to route incidents based on a custom property. Automation rules evaluate trigger conditions, then execute this action to set ownership automatically.

Why this answer

The 'Assign owner' action type is specifically designed to change the owner of an incident in Microsoft Sentinel. When you need to automatically assign incidents to a specific owner based on a custom property (e.g., a tag or custom field), this action directly modifies the incident's 'Owner' property. Other action types serve different purposes: 'Run playbook' executes a logic app, 'Change status' updates the incident's status (e.g., New, Active, Closed), and 'Create ticket (preview)' creates an external ticket in a connected ticketing system.

Exam trap

The trap here is that candidates often confuse 'Assign owner' with 'Run playbook', thinking a playbook is required to change the owner, but Sentinel provides a native action for this simple property change without needing a Logic App.

How to eliminate wrong answers

Option A is wrong because 'Run playbook' triggers a Logic App workflow, which can include complex logic but is not a direct action to set the incident owner; it is used for automation beyond simple property changes. Option C is wrong because 'Change status' modifies the incident's status (e.g., from New to Active), not the owner assignment. Option D is wrong because 'Create ticket (preview)' generates a ticket in an external system (e.g., ServiceNow) and does not modify the Sentinel incident's owner field.

Practice this question →

449

MCQmedium

Refer to the exhibit. You are deploying a Microsoft Sentinel workspace using an ARM template. After deployment, you notice the workspace is in a disabled state for ingesting data. Which parameter is most likely causing this?

A.The location parameter is set to 'eastus' but Sentinel is not available in that region

B.The dailyQuotaInGB parameter sets a daily cap that may have been exceeded

C.The retentionInDays parameter is set to 90, which is less than the default 30 days

D.The workspaceName parameter is set to 'SentinelWorkspace' but the name must be globally unique

AnswerB

The dailyQuotaInGB parameter is the correct culprit: it configures the workspace's daily ingest cap in the Log Analytics workspace backing your Sentinel deployment. When that cap is reached, Log Analytics pauses data ingestion for the remainder of the day, so Sentinel appears to be 'disabled' because it stops receiving security logs and alerts. This is a well-known operational state that is incorrectly diagnosed as an outage, and it persists until the next day or until the quota is raised.

Why this answer

The dailyQuotaInGB parameter sets a daily ingestion cap for the Log Analytics workspace. If this cap is reached, data ingestion is disabled until the next day, causing the workspace to appear in a disabled state for ingesting data. This is the most likely cause because the question explicitly states the workspace is disabled for data ingestion, which aligns with the behavior of the daily cap being exceeded.

Exam trap

The SC-200 exam often tests the misconception that workspace names must be globally unique (like storage accounts) or that Sentinel availability varies by region, when in fact the daily cap is the direct cause of a disabled ingestion state.

How to eliminate wrong answers

Option A is wrong because Microsoft Sentinel is available in the East US region, so setting the location to 'eastus' would not cause the workspace to be disabled for data ingestion. Option C is wrong because the retentionInDays parameter set to 90 is greater than the default of 30 days, and retention settings do not affect the ingestion state of the workspace. Option D is wrong because workspace names in Log Analytics do not need to be globally unique; they only need to be unique within a resource group, so 'SentinelWorkspace' is a valid name.

Practice this question →

450

MCQhard

Refer to the exhibit. You are analyzing a KQL query used in a custom detection rule in Microsoft Defender XDR. The rule is supposed to detect devices where a parent process launched more than 10 instances of PowerShell or cmd.exe in the last 7 days. However, the query returns no results even though you know such activity exists. What is the most likely reason?

A.The 'extend' line creates a new column that is not used in the subsequent summarize, causing the query to not group by parent process as intended.

B.The 'summarize' operator cannot be used with 'count()' in this context.

C.The 'where' clause filters out all events because the FileName list is incorrect.

D.The 'extend' line uses a column that does not exist in the DeviceProcessEvents schema.

AnswerD

According to the Microsoft 365 Defender DeviceProcessEvents schema, there is no valid column named 'InitiatingProcessParentFileName'; the correct field for the parent process executable is 'InitiatingProcessFileName'. An 'extend' expression that references a non-existent column causes a Kusto semantic error, because schema validation rejects the unrecognized identifier. As a result, the entire query fails or returns an empty result set, rather than creating a new column. This schema mismatch is the direct cause of the issue.

Why this answer

The 'extend' line references a column named 'ParentProcessFileName' that does not exist in the DeviceProcessEvents schema. The actual column is 'InitiatingProcessFileName' (or 'ParentProcessName' in some schemas). Since the column doesn't exist, the 'extend' operation fails silently or produces null values, causing the subsequent 'summarize' to group by null and return no results.

Exam trap

The trap here is that candidates assume the column name 'ParentProcessFileName' is correct based on intuition or generic naming conventions, without verifying the actual schema of the DeviceProcessEvents table in Microsoft Defender XDR.

How to eliminate wrong answers

Option A is wrong because the 'extend' line creates a new column that is indeed used in the 'summarize' operator (the 'by' clause references 'ParentProcessFileName'), so the grouping is not broken by an unused column. Option B is wrong because 'summarize' with 'count()' is perfectly valid in KQL and commonly used to count rows per group. Option C is wrong because the 'where' clause filters on 'FileName' with 'has' operators, which is syntactically correct; the issue is not with the filter logic but with a missing column upstream.

Practice this question →