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

151

MCQhard

Your organization uses Microsoft Defender XDR and you are configuring attack surface reduction (ASR) rules. You need to implement a rule that blocks executable files from running unless they meet a prevalence, age, or trusted list criterion. Which ASR rule should you enable?

A.Block untrusted and unsigned processes that run from USB

B.Block Office applications from creating executable content

C.Block credential stealing from the Windows local security authority subsystem (lsass.exe)

D.Block executable files from running unless they meet a prevalence, age, or trusted list criterion

AnswerD

This is the correct ASR rule: it uses Microsoft's cloud-based threat intelligence to compute a risk score for each executable file. An executable is allowed to run only if it is widely prevalent, has been observed for a sufficiently long time, or is explicitly listed in a trusted list; otherwise, execution is blocked. This directly matches the requirement to block executable files from running unless they meet a prevalence, age, or trusted list criterion, making it the appropriate choice.

Why this answer

The ASR rule 'Block executable files from running unless they meet a prevalence, age, or trusted list criterion' (GUID: 01443614-cd74-433a-b99e-2ecdc07bfc25) is specifically designed to prevent executable files (e.g., .exe, .dll, .scr) from running unless they have been seen in the organization (prevalence), are old enough (age), or are on a trusted list. This rule uses cloud-delivered protection and Microsoft's reputation-based intelligence to evaluate files before execution, directly matching the requirement described in the question.

Exam trap

The trap here is that candidates often confuse this ASR rule with the 'Block untrusted and unsigned processes that run from USB' rule, mistakenly thinking that 'untrusted' means the same as 'not meeting prevalence/age/trusted list criteria,' but the USB rule only applies to removable drives, not all executable files from any location.

How to eliminate wrong answers

Option A is wrong because 'Block untrusted and unsigned processes that run from USB' (GUID: b2b3f03d-6a4c-4b7e-8f6f-0c7f8f8e8f8f) only blocks processes launched from USB removable drives, not all executable files regardless of source. Option B is wrong because 'Block Office applications from creating executable content' (GUID: 3b576869-a4ec-4529-8536-b80a7769e899) specifically targets Office apps (Word, Excel, etc.) creating executable content, not all executable files from any source. Option C is wrong because 'Block credential stealing from the Windows local security authority subsystem (lsass.exe)' (GUID: 9e6c4e1f-7d60-472f-b1a0-3f2d6d7e8f9a) is an ASR rule that protects LSASS from credential dumping attacks, not a rule that evaluates executable files based on prevalence, age, or trusted list criteria.

Practice this question →

152

Multi-Selecteasy

Your SOC team needs to ensure that all incidents in Microsoft Sentinel are assigned to an analyst within 30 minutes of creation. Which TWO configurations should you implement?

Select 2 answers

A.Create a playbook that uses the Update Incident action to set the owner field.

B.Set up a playbook that sends an email to the SOC manager when an incident is created.

C.Create an automation rule that triggers when an incident is created and sets the owner.

D.Configure a Microsoft Teams connector to post incidents to a channel.

E.Modify the analytics rule to include a custom details field for analyst name.

AnswersA, C

Microsoft Sentinel playbooks, built on Azure Logic Apps, include an 'Update Incident' action that can directly set the incident's Owner property to a specific user or group. When invoked from an automation rule on incident creation, this action assigns ownership as part of the incident lifecycle, making it a fully valid solution. The playbook can also incorporate conditions or lookups to choose the right owner dynamically.

Why this answer

A playbook (an Azure Logic Apps workflow) can use the 'Update Incident' action to programmatically set the owner field on an incident. This allows you to implement custom assignment logic, such as round-robin or based on analyst skill set, triggered by an automation rule or manually. Option C is correct because an automation rule can directly set the owner field when an incident is created, without needing a playbook, by using the 'Update incident' action within the rule itself.

Both configurations ensure incidents are assigned within the required 30-minute window.

Exam trap

The trap here is that candidates often confuse notification actions (email, Teams) with assignment actions, assuming that notifying a manager or posting to a channel fulfills the requirement to 'assign' the incident, but only setting the owner field in the incident object actually assigns it.

Practice this question →

153

MCQeasy

Your organization uses Microsoft Sentinel. The SOC manager wants to track the average time to triage incidents. You need to create a report that shows this metric. What should you use?

A.Create a workbook that uses KQL to query incident data and display the average time.

B.Create a playbook that sends a report via email.

C.Create an automation rule that logs the triage time to a custom table.

D.Create an analytics rule that calculates the time to triage.

AnswerA

Workbooks query the Sentinel data lake with KQL, so incident records can be aggregated to compute average triage duration and rendered as a report. Analytics rules generate incidents and automation rules respond to them; neither produces the requested metric visualisation.

Why this answer

Microsoft Sentinel workbooks can be built using Kusto Query Language (KQL) to query the SecurityIncident table and compute the average time to triage, allowing the SOC manager to track this metric. Option B is incorrect because playbooks are designed for automation and response, not for creating reports. Option C is incorrect because automation rules are for automated incident handling, not for reporting or logging custom metrics.

Option D is incorrect because analytics rules are used to generate alerts based on queries, not to produce reports.

Practice this question →

154

MCQhard

Your organization has Microsoft Sentinel with UEBA enabled. An incident is generated for a user with high risk score. You need to identify if the user's recent behavior deviates from their baseline. Which Sentinel feature should you use?

A.A custom hunting query using the BehaviorAnalytics table.

B.The user's Azure AD sign-in logs.

C.The UEBA timeline in the entity page.

D.The incident investigation graph.

AnswerC

The UEBA timeline is a dedicated tab on the Sentinel entity page that presents a chronological view of a user's or device's activities, highlighting deviations from established behavioral baselines and flagging risky actions with anomaly scores. Because UEBA is natively integrated into entity pages, this is the built-in feature designed to show baseline deviations over time. It directly addresses the requirement to see anomalies relative to normal behavior.

Why this answer

The UEBA timeline in the entity page is the correct feature because it provides a chronological view of a user's activities, including deviations from their established behavioral baseline. When UEBA is enabled, Sentinel profiles normal behavior for each user and flags anomalies; the timeline directly visualizes these deviations, such as unusual login times, locations, or resource access, which aligns with the need to identify if recent behavior deviates from the baseline.

Exam trap

The trap here is that candidates often confuse the BehaviorAnalytics table (option A) as the primary tool for deviation analysis, overlooking that the UEBA timeline is the purpose-built, no-code interface for visualizing baseline deviations directly on the entity page.

How to eliminate wrong answers

Option A is wrong because a custom hunting query using the BehaviorAnalytics table, while capable of surfacing UEBA data, is not the dedicated feature for quickly viewing a user's behavioral timeline and deviations; it requires writing and executing a KQL query, which is less efficient than the built-in timeline. Option B is wrong because Azure AD sign-in logs only show authentication events and do not incorporate UEBA's behavioral baseline analysis or deviations; they lack the contextual anomaly scoring and timeline of behavioral changes. Option D is wrong because the incident investigation graph focuses on mapping relationships between entities and alerts within an incident, not on displaying a user's behavioral timeline or baseline deviations.

Practice this question →

155

MCQmedium

Your organization has a Microsoft Sentinel workspace that ingests logs from multiple sources. You need to implement a process to review and approve changes to analytics rules before they are deployed to production. What should you use?

A.Create a playbook that emails the SOC manager when an analytics rule is modified.

B.Use a workbook to track changes to analytics rules.

C.Configure Microsoft Sentinel repository integration with Azure DevOps and use branch policies for approval.

D.Export analytics rules to a notebook for manual review.

AnswerC

Microsoft Sentinel repository integration connects your workspace to an Azure DevOps (or GitHub) repository that stores analytics rules as ARM templates or Terraform files. By configuring branch policies on the main branch, you mandate that any rule modification must be made in a separate branch and merged only after a reviewer approves the pull request. Successful merge then triggers a CI/CD pipeline to deploy the rules to Sentinel, providing version control, audit history, and a hard, enforceable approval gate that governs every change before it reaches the production workspace.

Why this answer

Microsoft Sentinel repository integration with Azure DevOps (or GitHub) enables source control for analytics rules, allowing changes to be managed through pull requests and branch policies. This enforces a review and approval workflow before rules are deployed to production, directly meeting the requirement for a structured change management process.

Exam trap

The trap here is that candidates may confuse notification or tracking mechanisms (like playbooks or workbooks) with actual approval workflows, overlooking that only source control integration with branch policies provides a formal review and approval gate before deployment.

How to eliminate wrong answers

Option A is wrong because a playbook that emails the SOC manager when a rule is modified only provides notification, not a formal review and approval process; it lacks enforcement of approval before deployment. Option B is wrong because a workbook is a visualization tool for querying and displaying data, not a mechanism for managing or approving changes to analytics rules. Option D is wrong because exporting rules to a notebook for manual review is an offline, non-automated process that does not integrate with version control or enforce approval workflows.

Practice this question →

156

Multi-Selecteasy

Your organization uses Microsoft Defender XDR (formerly Microsoft 365 Defender). You need to configure role-based access control (RBAC) for the security team. Which TWO built-in roles can be assigned in Microsoft 365 Defender to manage incidents and alerts?

Select 2 answers

A.Global Administrator

B.Compliance Administrator

C.Security Operator

D.Security Administrator

E.Security Reader

AnswersC, D

Security Operator is purpose-built for tier-1 incident response within Microsoft 365 Defender. It can view active incidents, modify their status, assign them to analysts, and perform basic response actions like isolating devices or blocking senders—without granting broader administrative control over security policies or identity management. This role provides the exact permissions required for day-to-day alert handling while adhering to least privilege, making it the correct answer.

Why this answer

Security Operator and Security Administrator are the two built-in roles in Microsoft 365 Defender that include permissions to manage incidents and alerts. Security Operator can view and respond to incidents and alerts, while Security Administrator has full access to all security features, including the ability to edit policies and manage incidents. These roles are specifically designed for security operations tasks within Defender XDR.

Exam trap

The trap here is that candidates often confuse Security Reader (read-only) with Security Operator (read-write for incidents/alerts), or assume Global Administrator is required for incident management, when in fact Security Operator and Security Administrator are the correct roles with the necessary permissions.

Practice this question →

157

MCQmedium

Refer to the exhibit. You have a KQL query in a Microsoft Sentinel analytics rule. The rule is not generating incidents even though there are 'Suspicious sign-in' alerts from non-contoso.com users. What is the most likely issue?

A.The 'extend' line is incorrectly parsing the entity.

B.The query is querying the wrong table. 'Suspicious sign-in' alerts may be in a different table.

C.The 'where' clause using !endswith is incorrect.

D.The query does not filter by AlertName correctly.

AnswerB

This is the correct issue. 'Suspicious sign-in' alerts are typically surfaced through Microsoft Sentinel's SecurityAlert table or through identity protection logs such as SigninLogs, and these records are not guaranteed to exist in the table referenced by this query. Querying the wrong table means the where and extend clauses are applied to a schema that lacks the alert evidence or uses different field names, resulting in no matching rows. Confirming the table name against the alert product's data connector is the necessary first troubleshooting step.

Why this answer

The query is likely querying the 'Alert' table, but 'Suspicious sign-in' alerts from non-contoso.com users are generated by Microsoft Defender for Identity or Azure AD Identity Protection and stored in the 'SecurityAlert' table (or 'AlertEvidence' in the new schema). The rule's query must reference the correct table to retrieve these alerts; otherwise, no matching records are found, and no incidents are created.

Exam trap

The trap here is that candidates assume all security alerts are stored in a single 'Alert' table, but Microsoft Sentinel separates alerts into multiple tables (e.g., 'SecurityAlert', 'AlertEvidence', 'SigninLogs') based on the source service, and the exam tests your knowledge of which table corresponds to which alert type.

How to eliminate wrong answers

Option A is wrong because the 'extend' line is used to add or modify columns, not to parse entities; entity parsing is done via the 'EntityMapping' section of the analytics rule, not within the KQL query itself. Option C is wrong because the 'where' clause using '!endswith' is syntactically correct for filtering out domains that do not end with a specific suffix (e.g., 'contoso.com'); the logic is valid if the field contains the full user principal name. Option D is wrong because the query does not need to filter by AlertName if the rule is triggered by the presence of any alert from the 'Suspicious sign-in' category; the rule's trigger condition is based on the query returning results, not on a specific alert name filter.

Practice this question →

158

MCQmedium

Your Microsoft Sentinel workspace is ingesting logs from multiple sources. You notice that the data ingestion cost is higher than expected. You want to reduce costs without losing security value. Which action should you take?

A.Reduce the retention period for all data to 30 days.

B.Switch the pricing tier from Capacity Reservations to Pay-as-you-go.

C.Disable analytics rules that generate high volume of alerts.

D.Configure basic logs ingestion for verbose data sources such as firewall logs.

AnswerD

Configuring Basic Logs ingestion for verbose data sources such as firewall logs is a valid cost optimization because this data tier is significantly cheaper per GB than Analytics Logs, yet still queryable for incident response using KQL within the 8-day default retention window. This allows you to preserve high-volume raw telemetry for on-demand hunting and investigation without paying full analytics prices for every event, and you can selectively upgrade specific tables or add dedicated retention policies as needed. It directly reduces the main cost driver—ingestion—while maintaining access to the data for Deep Dive (also known as resource-oriented) when a security incident occurs.

Why this answer

Basic logs are designed for high-volume, verbose data sources (e.g., firewall logs, syslog) that have lower security value. They are stored at a reduced cost and support only summary queries, not full KQL analytics. By routing verbose logs to basic logs, you reduce ingestion costs while retaining the ability to perform threat hunting and incident response on high-value analytics logs.

Exam trap

The trap here is that candidates confuse reducing retention (Option A) with reducing ingestion volume, or they mistakenly think disabling analytics rules (Option C) lowers ingestion costs, when in fact ingestion cost is driven by data volume, not rule execution.

How to eliminate wrong answers

Option A is wrong because reducing retention to 30 days may delete historical data needed for compliance or long-term threat hunting, and it does not address the root cause of high ingestion volume. Option B is wrong because switching from Capacity Reservations to Pay-as-you-go typically increases per-GB costs, especially at high ingestion volumes, making the problem worse. Option C is wrong because disabling analytics rules reduces security monitoring coverage and may allow threats to go undetected; it does not reduce the cost of ingesting the underlying log data.

Practice this question →

159

MCQhard

Your organization uses Microsoft Defender XDR. You need to configure a custom detection rule that runs every hour and alerts when a specific process is executed on multiple devices within 10 minutes. Which type of rule should you create?

A.Hunting query saved as a detection

B.Behavioral rule

C.Custom detection rule

D.Advanced hunting query

AnswerC

Custom detection rule is correct because this is the dedicated rule type in Microsoft Defender XDR that allows you to schedule an Advanced Hunting KQL query to run at defined intervals, apply time-based aggregations, and automatically generate alerts and incidents when thresholds are met. Custom detection rules provide full control over frequency, severity, and response actions, and they directly integrate with the incident management pipeline. This makes them the precisely designed mechanism for turning a recurring query into an active, automated detection.

Why this answer

Custom detection rules in Microsoft Defender XDR allow you to define a query that runs on a schedule (e.g., every hour) and triggers an alert based on aggregation over a specified time window (e.g., 10 minutes). This rule type supports the exact requirement: detecting a specific process executed on multiple devices within a short timeframe, using the `make_set` or `dcount` aggregation functions in KQL.

Exam trap

The trap here is that candidates confuse 'custom detection rule' with 'advanced hunting query' or 'saved hunting query,' assuming any KQL-based alert is the same, but only custom detection rules provide the scheduled, time-windowed aggregation and alerting required for this scenario.

How to eliminate wrong answers

Option A is wrong because a hunting query saved as a detection is a static query that runs on a schedule but does not natively support time-windowed aggregation across multiple devices; it would require manual KQL to simulate the 10-minute window, and it lacks the built-in alerting and tuning capabilities of a custom detection rule. Option B is wrong because behavioral rules are designed to detect anomalies based on learned baselines (e.g., user or device behavior), not to match a specific process name across multiple devices within a fixed time window. Option D is wrong because an advanced hunting query is an ad-hoc, interactive search tool that does not run on a schedule or generate alerts automatically; it requires manual execution and cannot be used as a persistent detection.

Practice this question →

160

MCQmedium

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

A.Enable diagnostic settings on the Defender for Cloud subscription.

B.Configure the 'Azure Activity' data connector.

C.Create an automation rule in Sentinel to fetch alerts from Defender for Cloud.

D.Add the 'Microsoft Defender for Cloud' data connector in Microsoft Sentinel.

AnswerD

The Microsoft Defender for Cloud data connector is the standard, supported method to ingest security alerts from Defender for Cloud into Microsoft Sentinel. It connects to your subscriptions and streams alerts into the SecurityAlert table, while optionally enabling incident creation and bi-directional synchronization of alert status. Once configured, your analytics rules and automation rules can then operate on those alerts directly.

Why this answer

The 'Microsoft Defender for Cloud' data connector in Microsoft Sentinel is specifically designed to ingest security alerts from Defender for Cloud into Sentinel. When you enable this connector, it automatically synchronizes alerts from all connected Defender for Cloud subscriptions, allowing you to investigate and respond to those alerts within Sentinel's unified security operations environment.

Exam trap

The trap here is that candidates often confuse diagnostic settings (which export logs) with data connectors (which import security alerts), leading them to choose Option A instead of the correct data connector in Option D.

How to eliminate wrong answers

Option A is wrong because enabling diagnostic settings on a Defender for Cloud subscription sends logs and metrics to a Log Analytics workspace, but it does not automatically ingest security alerts into Sentinel; diagnostic settings are used for resource logs, not for alert ingestion. Option B is wrong because the 'Azure Activity' data connector ingests subscription-level operational logs (e.g., create/delete resources), not security alerts from Defender for Cloud. Option C is wrong because automation rules in Sentinel trigger actions on already-ingested alerts or incidents; they cannot fetch or import alerts from external sources like Defender for Cloud.

Practice this question →

161

MCQmedium

Your organization uses Microsoft Defender for Cloud Apps. You need to receive alerts when a user accesses a cloud app from a location that is not whitelisted. What should you configure?

A.Create a conditional access policy in Microsoft Entra ID.

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

C.Configure an access policy in Microsoft Defender for Cloud Apps.

D.Create an activity policy in Microsoft Defender for Cloud Apps.

AnswerD

Creating an activity policy in Microsoft Defender for Cloud Apps is correct because activity policies are purpose-built to monitor user activities and trigger alerts when specific conditions, such as an unusual location, are met. You can define rules based on attributes like IP address, geographic location, device, and activity type to generate alerts for investigation. This directly fulfills the requirement of alerting on location-based anomalies.

Why this answer

An activity policy in Microsoft Defender for Cloud Apps monitors user activities and can trigger alerts based on specific conditions, such as access from non-whitelisted locations. This policy type evaluates activities against defined criteria (e.g., IP address ranges) and generates alerts without blocking access, which matches the requirement to receive alerts.

Exam trap

The trap here is confusing activity policies (which alert) with access or session policies (which enforce controls), leading candidates to choose an option that blocks access instead of generating an alert.

How to eliminate wrong answers

Option A is wrong because a conditional access policy in Microsoft Entra ID controls access (e.g., block or require MFA) but does not generate alerts in Defender for Cloud Apps; it enforces access decisions at the authentication level. Option B is wrong because a session policy in Defender for Cloud Apps monitors and controls real-time app sessions (e.g., blocking downloads) but is designed for session-level control, not for alerting on location-based access. Option C is wrong because an access policy in Defender for Cloud Apps blocks or allows access based on conditions (e.g., location) but does not generate alerts; it enforces access control rather than notification.

Practice this question →

162

Multi-Selectmedium

Which TWO of the following are valid ways to automate incident response in Microsoft Sentinel?

Select 2 answers

A.Create a playbook using Azure Logic Apps.

B.Use Azure Functions to run a script.

C.Use PowerShell to modify incidents via API.

D.Use Microsoft Power Automate to create a flow.

E.Create an automation rule that triggers a playbook.

AnswersA, E

Creating a playbook using Azure Logic Apps is a native Microsoft Sentinel automation capability because Sentinel playbooks are implemented as Logic Apps workflows, purpose-built to run automated response actions on incidents and alerts. These workflows can be invoked directly from an incident's context or via an automation rule without any custom code or external infrastructure, making it a valid automation method.

Why this answer

Azure Logic Apps is the native workflow engine for Microsoft Sentinel playbooks, allowing security analysts to automate incident response actions such as blocking IPs, resetting passwords, or enriching alerts. Playbooks are triggered by automation rules or directly from incidents, and they leverage hundreds of connectors to integrate with external systems. This is the primary and recommended method for building automated response workflows in Sentinel.

Exam trap

The trap here is that candidates often confuse 'automation rule' with 'playbook' — an automation rule is the trigger condition, while a playbook is the action workflow; both are required for full automation, and the exam expects you to recognize that creating a playbook (A) and creating an automation rule that triggers a playbook (E) are the two valid steps in the process.

Practice this question →

163

Multi-Selecteasy

Which TWO of the following are required to enable Microsoft Sentinel UEBA (User and Entity Behavior Analytics)?

Select 2 answers

A.Enable UEBA in the Microsoft Sentinel workspace settings.

B.Integrate Microsoft Defender for Cloud Apps.

C.Purchase a separate UEBA license.

D.Configure Azure Key Vault to store UEBA data.

E.Ingest Microsoft Entra ID sign-in logs and audit logs.

AnswersA, E

UEBA is disabled by default in Microsoft Sentinel; you must explicitly turn it on via the workspace settings under Entity behavior. This setting activates the machine learning-based analytics that profile entities and surface anomalous activity. Without toggling this on, UEBA features remain dormant even if other data sources are connected.

Why this answer

UEBA must be explicitly enabled in the Microsoft Sentinel workspace settings under the 'Entity behavior analytics' blade. This activation allows Sentinel to start profiling user and entity behaviors using built-in machine learning models. Without this toggle, UEBA remains disabled regardless of other configurations.

Exam trap

The trap here is that candidates often assume UEBA requires a separate license or integration with a specific security product like Defender for Cloud Apps, when in fact it is a built-in feature of Sentinel that only needs to be enabled and fed with appropriate log sources.

Practice this question →

164

MCQhard

Your organization uses Microsoft Sentinel with UEBA (User and Entity Behavior Analytics) enabled. The SOC team notices that UEBA is not generating any anomalies for a specific user group. What is the most likely cause?

A.The user group is excluded from Identity Protection.

B.The data history for that user group is less than the required baseline period.

C.The user group is not being monitored by any data connector.

D.The analytics rules for UEBA are not enabled.

AnswerB

UEBA builds behavioural baselines from historical activity before it can flag deviations. A user group with insufficient data history has no established normal pattern, so the analytics engine cannot compute anomalies for it regardless of connector health or licensing state.

Why this answer

UEBA in Microsoft Sentinel requires a baseline period of historical data (typically 14 days minimum, often up to 30 days) before it can establish normal behavior patterns and generate meaningful anomalies. If a user group was recently added or their identity data has only been ingested for a short time, Sentinel lacks the behavioral baseline needed to flag deviations, so no anomalies appear. This is expected behavior, not a misconfiguration.

Exam trap

SC-200 often tests the UEBA baseline requirement, tricking candidates into blaming missing data connectors or disabled analytics rules when the real issue is simply insufficient historical data for behavioral learning.

How to eliminate wrong answers

Option A is wrong because Identity Protection exclusions affect risk detections in Entra ID, not Sentinel UEBA anomaly generation — these are separate systems. Option C is wrong because if no data connector were feeding identity logs, UEBA would show no data at all rather than selectively failing for one group; also UEBA depends on Azure AD/Entra sign-in and audit logs, which are typically tenant-wide. Option D is wrong because UEBA analytics are built-in and enabled by the UEBA toggle in Sentinel settings; there is no separate 'analytics rules for UEBA' that must be enabled per group.

Practice this question →

165

MCQmedium

Your organization has a Microsoft Sentinel workspace that ingests logs from Azure resources, Microsoft 365, and third-party firewalls. You need to ensure that data retention for Azure Activity logs complies with a regulatory requirement of 3 years, while keeping costs low for other data types. What should you do?

A.Use the Archive tier for Azure Activity logs and set the total retention period to 3 years.

B.Set the workspace retention to 3 years.

C.Configure a data retention policy on the AzureActivity table to 3 years.

D.Enable Basic Logs plan on the AzureActivity table.

AnswerC

This is correct because table-level retention policies let you extend or shorten the retention for a specific table, here the AzureActivity table, to meet 3-year compliance for Azure Activity logs without affecting other tables' data lifecycle. Since the policy targets only that table's logs, it balances compliance requirements with cost optimization while keeping the data natively queryable in the Log Analytics workspace.

Why this answer

Azure Sentinel allows you to configure a custom retention policy on a specific table (e.g., AzureActivity) to retain data for up to 2 years (or longer with Archive tier) independently of the workspace's default retention. This meets the 3-year regulatory requirement for Azure Activity logs without increasing retention costs for other data types, as the workspace default can remain shorter.

Exam trap

The trap here is that candidates often confuse workspace-level retention with table-level retention, assuming that setting the workspace retention to 3 years is the only way to meet the requirement, when in fact table-level policies allow granular control without affecting other data types.

How to eliminate wrong answers

Option A is wrong because the Archive tier is used for long-term, low-cost storage after an initial retention period (typically 30 days for Activity logs), but it does not by itself set the total retention to 3 years; you must also configure a table-level retention policy to define the total retention period, and the Archive tier alone does not guarantee compliance without that policy. Option B is wrong because setting the workspace retention to 3 years would apply that retention to all data types in the workspace, increasing costs unnecessarily for non-Activity logs that do not require 3-year retention. Option D is wrong because enabling Basic Logs plan on the AzureActivity table reduces ingestion costs but does not change the retention period; it still requires a separate retention policy to meet the 3-year requirement.

Practice this question →

166

Multi-Selecthard

Which TWO are required to enable Microsoft Sentinel to use AI-generated incident summaries?

Select 2 answers

A.The Security Reader role assigned to the user

B.Microsoft Copilot for Security enabled

C.An Azure OpenAI service instance deployed

D.A Log Analytics workspace with a premium pricing tier

E.A Power BI Pro license

AnswersA, B

The Security Reader role is a least-privilege RBAC role that grants read-only access to Microsoft Sentinel resources, including incidents, alerts, and the AI-generated summaries. Without this role, Microsoft Copilot for Security may be enabled, but the user will see an authorization error rather than the Copilot-derived narrative in the incident pane. This role is required at minimum to retrieve incident details that Copilot's summarization pipeline consumes and displays.

Why this answer

Microsoft Sentinel's AI-generated incident summaries require Microsoft Copilot for Security to be enabled, as this feature leverages Copilot's natural language processing capabilities to summarize incidents. Additionally, the user must have the Security Reader role assigned to access and view these summaries within Sentinel, ensuring proper permissions for security data.

Exam trap

The trap here is that candidates often assume a separate Azure OpenAI service or premium Log Analytics tier is needed, but Microsoft Copilot for Security is a standalone licensed service that handles AI processing without requiring those additional resources.

Practice this question →

167

MCQmedium

You are managing a Microsoft Sentinel environment that ingests data from multiple sources: Microsoft 365, Azure Activity, and custom logs via AMA. The SOC manager has requested that all security events from Windows servers be collected and stored for 90 days for compliance purposes. You have configured the Windows Security Events via AMA data connector to collect all events (Event ID 4624, 4625, etc.) and set the workspace retention to 90 days. After a week, you notice that the daily ingested volume is higher than expected, exceeding the budget. You analyze the data and find that many low-severity informational events are being ingested, such as Event ID 5156 (Windows Filtering Platform allowed connection). The manager confirms that only security-relevant events are needed. What should you do to reduce ingestion volume while still meeting compliance requirements?

A.Reduce the workspace retention period to 30 days to lower storage costs.

B.Configure the Azure Activity data connector to filter out low-severity events.

C.Modify the data collection rule (DCR) for the Windows Security Events connector to use a custom XPath query that excludes informational events (e.g., exclude Event ID 5156).

D.Disable the AMA-based connector and use the legacy MMA-based connector instead.

AnswerC

Filtering at the data collection rule with a custom XPath query stops Event ID 5156 and similar informational events before ingestion, directly cutting volume and cost. Because the DCR sits between the AMA agent and the workspace, excluded events never reach Microsoft Sentinel, while security-relevant events still land and satisfy the 90-day retention requirement.

Why this answer

The AMA connector uses data collection rules (DCRs) that allow you to filter events based on custom XPath queries. By creating a custom XPath query that excludes informational events like Event ID 5156, you can reduce ingestion volume while still collecting security-relevant events (e.g., 4624, 4625) for the required 90-day retention. Option A is incorrect because reducing the workspace retention to 30 days would violate the compliance requirement for 90 days.

Option B is incorrect because the Azure Activity data connector collects Azure resource logs, not Windows security events. Option D is incorrect because the legacy MMA connector is deprecated and does not provide the same filtering capabilities; AMA is the recommended solution.

Practice this question →

168

MCQhard

You are a SOC analyst using Microsoft Sentinel. You have a scheduled analytics rule that generates incidents from KQL queries. Recently, incidents are being created but automatically closed within minutes without any actions taken. You suspect a configuration issue. What should you check first?

A.Verify the 'Alert grouping' settings in the analytics rule; they might be grouping alerts incorrectly.

B.Check if the analytics rule has a 'Suppression' setting enabled that causes the incident to close.

C.Review the incident automation rules that might have a 'Close incident' action triggered by a condition.

D.Examine the entity mapping configuration; it might be causing the incident to close automatically.

AnswerC

Incident automation rules in Microsoft Sentinel run automatically upon incident creation or update, and they can include a 'Close incident' action when defined conditions are met. For example, a rule with a condition like 'Alert severity equals Low' will close any newly created matching incident without human intervention. Reviewing these rules is the correct approach because they are the primary native mechanism that automatically closes incidents based on incident properties.

Why this answer

Incident automation rules in Microsoft Sentinel can be configured to automatically close incidents when specific conditions are met, such as a related alert being resolved or a playbook completing. Since the incidents are being closed within minutes without manual intervention, an automation rule with a 'Close incident' action is the most likely cause, as it directly triggers closure based on conditions. Checking this first aligns with the SOC analyst's need to identify automated actions that could prematurely close incidents.

Exam trap

The trap here is that candidates confuse 'suppression' (which stops alert creation) with 'automation rules' (which can close incidents), leading them to choose Option B instead of recognizing that suppression does not affect existing incidents.

How to eliminate wrong answers

Option A is wrong because 'Alert grouping' settings control how alerts are combined into incidents, not how incidents are closed; incorrect grouping might create duplicate or merged incidents but does not automatically close them. Option B is wrong because 'Suppression' settings in an analytics rule prevent the rule from running or generating alerts for a specified period after an incident is created, but they do not close existing incidents; suppression stops new alerts, not closes incidents. Option D is wrong because entity mapping configuration maps entities (like users or IPs) to alerts for correlation and investigation, but it has no mechanism to automatically close incidents; it affects data enrichment, not incident lifecycle.

Practice this question →

169

MCQmedium

You are managing a Microsoft Defender XDR environment. The security team wants to receive email notifications when a new incident is created with severity 'High' or 'Medium'. They also want to ensure that notifications are sent only for incidents that are not automatically resolved by AIR. What should you configure?

A.Create a playbook in Microsoft Sentinel that sends an email when an incident is created.

B.Configure an automation rule in Microsoft Sentinel to send email notifications.

C.Create an email notification rule in Microsoft Defender XDR with conditions for severity and status set to 'Active'.

D.Configure alert service settings in the Microsoft 365 Defender portal to send emails for high and medium severity alerts.

AnswerC

Email notification rules in Microsoft Defender XDR are the native mechanism for sending email alerts when incidents meet specific criteria, such as severity (high, medium) and status (New, Active, Resolved). To receive notifications for open investigations, you would set the status condition to 'Active' and select the desired severity levels, then specify the recipient address and notification frequency. This rule is managed directly in Microsoft 365 Defender portal under Settings > Microsoft 365 Defender > Email notifications > Incidents, making it the intended feature for this scenario. It operates independently of Microsoft Sentinel and covers the full scope of Defender XDR incidents.

Why this answer

Microsoft Defender XDR allows you to create email notification rules specifically for incidents, with conditions to filter by severity (e.g., High, Medium) and status (e.g., Active). This ensures notifications are sent only for new incidents that are not automatically resolved by AIR, as AIR-resolved incidents would have a status of 'Resolved' or 'Redirected', not 'Active'.

Exam trap

The trap here is confusing Microsoft Sentinel's incident management (which uses automation rules and playbooks) with Microsoft Defender XDR's native incident notification system, leading candidates to select options that apply to Sentinel rather than Defender XDR.

How to eliminate wrong answers

Option A is wrong because Microsoft Sentinel playbooks are designed for automated response actions, not for configuring native email notifications within Defender XDR; they would require additional licensing and integration, and do not directly address the requirement to exclude AIR-resolved incidents. Option B is wrong because automation rules in Microsoft Sentinel operate on Sentinel incidents, not on Defender XDR incidents; the requirement is specifically for Defender XDR incident notifications. Option D is wrong because alert service settings in the Microsoft 365 Defender portal send notifications for alerts, not incidents, and they lack the granularity to filter by incident status (Active vs.

Resolved) or to exclude AIR-resolved incidents.

Practice this question →

170

Multi-Selecthard

Which THREE components are required to implement a threat intelligence feed in Microsoft Sentinel using the Threat Intelligence - TAXII data connector?

Select 3 answers

A.Root collection ID

B.A Log Analytics workspace with Microsoft Sentinel enabled

C.TAXII server URL

D.API key for the TAXII server

E.A watchlist named 'ThreatIntelligenceIndicators'

AnswersA, C, D

The Root collection ID is a mandatory parameter for the Microsoft Defender Threat Intelligence (MDTI) TAXII connector. It uniquely identifies the specific collection of threat intelligence indicators to be ingested, as a single TAXII 2.0 server can host multiple collections. Without this ID, the connector cannot determine which feed to pull from, even if the server URL and API key are correctly configured. This value is typically provided in the form of a UUID and is required to establish a successful data pull.

Why this answer

The root collection ID is a required component for the Threat Intelligence - TAXII data connector because it identifies the specific collection of threat indicators on the TAXII server. Without this ID, Microsoft Sentinel cannot determine which set of indicators to ingest, as a single TAXII server may host multiple collections. The connector uses the root collection ID to query the correct STIX/TAXII endpoint and retrieve the relevant threat intelligence feed.

Exam trap

The trap here is that candidates often confuse the prerequisite (a Log Analytics workspace with Sentinel enabled) with a required component for the connector, or mistakenly think a watchlist is needed to store ingested threat indicators, when in fact the indicators are stored directly in the ThreatIntelligenceIndicator table.

Practice this question →

171

MCQhard

Your organization uses Microsoft Defender XDR and has a custom detection rule that queries DeviceProcessEvents for suspicious PowerShell commands. You notice that the rule is generating a high number of false positives. You need to reduce false positives while still detecting real threats. What should you do?

A.Add a condition to exclude processes signed by trusted certificates or from known IT admin accounts.

B.Disable the rule and create a new rule with a different MITRE technique.

C.Increase the lookback period from 7 to 30 days.

D.Modify the rule to set the severity to 'Informational'.

AnswerA

Adding an exclusion condition that filters out processes signed by trusted certificate publishers or running from known IT admin accounts directly targets the root cause of false positives, because many legitimate administration tools (e.g., PsExec, remote management scripts) share behavioral indicators with malicious activity. This allowlist-based approach preserves detection coverage for unsigned or anomalous processes while suppressing benign alerts that security analysts would otherwise need to triage. It is a standard tuning practice for custom detection rules in Microsoft Defender XDR.

Why this answer

Adding a condition to exclude processes signed by trusted certificates or from known IT admin accounts directly reduces false positives by filtering out legitimate administrative activity. Custom detection rules in Microsoft Defender XDR allow you to refine queries with additional conditions, such as excluding specific signers or accounts, which preserves detection of malicious PowerShell commands while ignoring benign ones.

Exam trap

The trap here is that candidates may think lowering severity or changing the detection technique reduces false positives, but only refining the query logic (e.g., excluding trusted signers or accounts) directly addresses the root cause of false alerts.

How to eliminate wrong answers

Option B is wrong because disabling the rule and creating a new rule with a different MITRE technique does not address the false positive issue; it changes the detection focus rather than refining the existing query. Option C is wrong because increasing the lookback period from 7 to 30 days would only expand the data window, potentially increasing false positives and not filtering out legitimate activity. Option D is wrong because setting the severity to 'Informational' merely lowers the alert priority but does not reduce the number of false positives; the rule would still generate the same volume of alerts.

Practice this question →

172

MCQmedium

Your SOC team needs to ensure that all high-severity Microsoft Sentinel incidents are automatically assigned to the senior analyst on call. The team uses Microsoft Teams for communication. Which configuration should you implement?

A.Configure an analytics rule to set the incident owner to the senior analyst and enable Teams integration in Sentinel settings.

B.Create a playbook that reassigns incidents and posts to Teams, and attach it to an automation rule triggered by high-severity incidents.

C.Create a workbook that filters high-severity incidents and configure a Teams webhook in the workbook settings.

D.Create an automation rule that runs when an incident is created with severity High, sets the owner to the senior analyst, and then runs a playbook to post a message to Teams.

AnswerD

An automation rule can be configured to trigger 'When incident is created' and apply a condition for Severity equals High, then perform actions such as setting the owner to the senior analyst and running a playbook. The playbook, typically an Azure Logic App with a Microsoft Teams connector, can post an adaptive card message to a Teams channel. This combined approach correctly satisfies both requirements: automated ownership assignment and proactive notification, making it the right solution.

Why this answer

Automation rules in Microsoft Sentinel can directly set the incident owner when an incident is created, and then trigger a playbook to post a message to Microsoft Teams. This two-step configuration ensures high-severity incidents are automatically assigned to the senior analyst on call and the SOC team is notified via Teams without manual intervention.

Exam trap

The trap here is that candidates often assume a playbook alone can handle both assignment and notification, but Microsoft Sentinel automation rules are the correct mechanism for setting incident properties like owner, while playbooks are best suited for external actions like posting to Teams.

How to eliminate wrong answers

Option A is wrong because analytics rules do not have the capability to set the incident owner; that is a function of automation rules or playbooks, and enabling Teams integration in Sentinel settings only provides basic connectivity, not automated assignment. Option B is wrong because while a playbook can reassign incidents and post to Teams, attaching it to an automation rule triggered by high-severity incidents would require the playbook to also set the owner, but the automation rule itself can set the owner more efficiently and reliably without relying on the playbook for assignment. Option C is wrong because workbooks are visualization tools that do not modify incident properties or trigger actions; configuring a Teams webhook in a workbook would only allow manual export or refresh, not automated incident assignment or notification.

Practice this question →

173

Multi-Selecthard

Which THREE of the following are valid components of Microsoft Defender XDR? (Select three.)

Select 3 answers

A.Microsoft Defender for Endpoint

B.Microsoft Defender for Office 365

C.Microsoft Purview

D.Microsoft Defender for Identity

E.Microsoft Sentinel

AnswersA, B, D

Microsoft Defender for Endpoint is a cloud-based endpoint detection and response (EDR) solution that provides risk-based vulnerability management, antivirus, attack surface reduction, and automated investigation and remediation on devices. It natively shares signals with other Defender products in the Defender XDR portal, allowing correlated incidents across endpoints, identities, and email. This makes it a fitting component of the XDR suite because it contributes telemetry from the physical and virtual endpoints across your organization.

Why this answer

Microsoft Defender XDR is a unified security operations platform that integrates signals from multiple Microsoft security products. Microsoft Defender for Endpoint provides endpoint detection and response (EDR) capabilities, including behavioral-based detection and automated investigation. It is a core component of the XDR solution, enabling cross-domain correlation of alerts from endpoints.

Exam trap

The trap here is that candidates often confuse Microsoft Purview (a compliance and data governance tool) or Microsoft Sentinel (a SIEM) as being part of Defender XDR, when in fact they are separate services that integrate with, but are not components of, the XDR platform.

Practice this question →

174

MCQmedium

Your security team is investigating an incident in Microsoft Defender XDR where a user received multiple phishing emails. The team needs to create an automated response that blocks the sender's email address across all mailboxes in the organization. Which action should you configure in an automated investigation and response (AIR) playbook?

A.Add a 'Block IP address' action in Microsoft Defender for Cloud Apps.

B.Create a custom detection rule in Microsoft Sentinel.

C.Add a 'Block sender' action in Microsoft Defender for Office 365.

D.Deploy a configuration profile in Microsoft Intune.

AnswerC

In Microsoft Defender for Office 365, the 'Block sender' action directly adds the sender's email address to the tenant-level block list used by Exchange Online Protection, causing future messages from that address to be rejected during mail flow. This is the appropriate remediation when an email-based threat needs to be stopped at the messaging layer, and it can be executed from the email entity or threat explorer. It is therefore the correct action to block the sender across Exchange Online.

Why this answer

Blocking a sender's email address across all mailboxes is a native capability of Microsoft Defender for Office 365. The 'Block sender' action in an AIR playbook directly adds the sender to the tenant's block list, which is enforced at the transport layer for all inbound email, effectively preventing any further delivery from that address.

Exam trap

The trap here is that candidates confuse the scope of Microsoft Defender for Cloud Apps (Option A) with email security controls, mistakenly thinking IP blocking in MDCA can stop email from a specific sender, when in fact email transport blocking is handled exclusively by Defender for Office 365.

How to eliminate wrong answers

Option A is wrong because blocking an IP address in Microsoft Defender for Cloud Apps (MDCA) applies to cloud app sessions and API connections, not to email transport; it cannot block a sender's email address in Exchange Online. Option B is wrong because a custom detection rule in Microsoft Sentinel is for generating alerts from log data, not for executing remediation actions like blocking a sender in mail flow. Option D is wrong because a configuration profile in Microsoft Intune manages device settings and compliance policies, not email sender blocking, which is a mail flow control.

Practice this question →

175

MCQeasy

Your organization uses Microsoft Sentinel and wants to ensure that all incident-related data is retained for at least 90 days for compliance purposes. Which configuration should you check?

A.Log Analytics workspace retention settings

B.Watchlist settings

C.Analytics rule settings

D.Incident settings in Sentinel

AnswerA

In Microsoft Sentinel, all ingested telemetry resides in a designated Log Analytics workspace, and the workspace's retention settings determine how many days of raw logs are available for queries, analytics, and threat hunting. Adjusting table-level or workspace-level retention directly controls the lifespan of that data, including whether it moves to long-term retention or archive. Because Sentinel does not maintain a separate storage pool, the Log Analytics retention configuration is the authoritative mechanism for data retention.

Why this answer

Log Analytics workspace retention settings directly control how long raw data ingested into Microsoft Sentinel is stored. For compliance requiring 90-day retention of incident-related data, you must configure the workspace retention period to at least 90 days (or use archive policies for longer retention). Incident data in Sentinel is derived from this underlying workspace data, so retention settings at the workspace level ensure the data persists for the required duration.

Exam trap

The trap here is that candidates often confuse incident settings (which manage incident metadata and lifecycle) with data retention settings, assuming that configuring incident retention in Sentinel is sufficient, when in fact the underlying log data retention is controlled at the Log Analytics workspace level.

How to eliminate wrong answers

Option B is wrong because watchlist settings manage collections of external data (e.g., CSV files) used for correlation and enrichment, not the retention duration of incident-related data. Option C is wrong because analytics rule settings define detection logic, schedule, and alert creation, but do not control how long incident data is retained after ingestion. Option D is wrong because incident settings in Sentinel (e.g., status, classification, automation) manage incident lifecycle and response, not the underlying data retention period, which is governed by the Log Analytics workspace.

Practice this question →

176

MCQeasy

As a SOC analyst, you need to quickly identify if a specific user account has been involved in any incidents in the past week. Which feature in Microsoft Sentinel allows you to search for user-related incidents?

A.Incidents blade with time range filter

B.Hunting blade with user query

C.Entity behavior blade

D.Workbooks with KQL query

AnswerC

The Entity behavior blade is the correct feature because when you open a specific entity (user, device, or domain) in the Defender portal, the Entity behavior tab automatically renders a timeline of that entity's activities, associated alerts, and incident history. This direct entity-focused view lets an analyst immediately see whether that user was implicated in past incidents without writing any queries or building custom workbooks. Correct.

Why this answer

The Entity behavior blade in Microsoft Sentinel provides a user-centric view that aggregates all incidents, alerts, and activities associated with a specific user account. By selecting a user entity and navigating to the 'Incidents' tab within the blade, you can quickly filter incidents involving that user over a defined time range, such as the past week. This feature is designed specifically for investigating user-related security events without needing to write custom queries.

Exam trap

Microsoft often tests the misconception that the Incidents blade (Option A) is sufficient for user-specific searches, but the trap is that it lacks entity-level filtering, requiring analysts to manually correlate users across incidents, whereas the Entity behavior blade provides a consolidated user-centric view.

How to eliminate wrong answers

Option A is wrong because the Incidents blade with a time range filter shows all incidents across the workspace, but it does not allow you to search or filter by a specific user account directly; you would need to manually inspect each incident or use a KQL query to correlate user entities. Option B is wrong because the Hunting blade is used for proactive threat hunting with KQL queries to find potential threats, not for quickly identifying incidents already raised against a specific user; it requires writing and running custom queries, which is less efficient for this task. Option D is wrong because Workbooks with KQL queries are customizable dashboards for reporting and visualization, not a direct feature for searching user-related incidents; they require pre-built queries and are not designed for ad-hoc user lookups.

Practice this question →

177

Multi-Selecthard

Which THREE capabilities are provided by Microsoft Sentinel's UEBA (User and Entity Behavior Analytics)? (Select THREE.)

Select 3 answers

A.Identify users whose behavior deviates from their peers

B.Provide a timeline of a user's recent activities on the entity page

C.Automatically run playbooks when anomalies are detected

D.Detect anomalous sign-in locations and times

E.Create watchlists for high-value users

AnswersA, B, D

Microsoft Sentinel's UEBA engine leverages machine learning to establish a baseline of typical behavior for each user and their peer group. When a user's activities—such as access patterns, resource usage, or data exfiltration attempts—diverge significantly from that baseline, Sentinel surfaces an anomaly. This peer-to-peer comparison is a core UEBA capability that helps identify insider threats and compromised accounts, and it is distinct from simple rule-based alerting.

Why this answer

Microsoft Sentinel's UEBA uses machine learning models to establish a baseline of normal behavior for each user and then compares individual user activity against peer group behavior. When a user's actions deviate significantly from their peers, such as accessing unusual resources or performing atypical data transfers, an anomaly is generated, enabling security analysts to investigate potential insider threats or compromised accounts.

Exam trap

The trap here is that candidates may confuse UEBA's anomaly detection with the broader automation capabilities of Microsoft Sentinel, mistakenly thinking that UEBA itself automatically runs playbooks, when in fact playbook execution requires separate automation rules and is not a built-in UEBA feature.

Practice this question →

178

MCQhard

Your company deploys Microsoft Sentinel in a multi-workspace environment. You need to centralize incident management across workspaces while maintaining data residency. You configure Sentinel workspaces in each region. What additional configuration is required to view all incidents from a single pane?

A.Deploy the Microsoft Sentinel solution across workspaces.

B.Assign the same Azure RBAC roles to all users in each workspace.

C.Merge the workspaces into a single workspace.

D.Use an incident manager with a cross-workspace view.

AnswerD

Using an incident manager with a cross-workspace view is the correct approach because Microsoft Sentinel can aggregate incidents from multiple workspaces through Azure Lighthouse delegation. A central SOC workspace can then query and manage incidents across all listed workspaces from a single pane of glass, while each workspace retains its data residency and collection boundaries. This directly centralizes the incident lifecycle—triage, assignment, and closure—without duplicating configuration or merging data stores.

Why this answer

Microsoft Sentinel supports cross-workspace incident management through the incident manager, which can be configured to display incidents from multiple workspaces in a single view. This is achieved by using the 'cross-workspace view' feature, which leverages Azure Resource Graph to query incidents across workspaces without moving data, thus maintaining data residency requirements.

Exam trap

The trap here is that candidates often confuse deploying the Sentinel solution (Option A) with enabling cross-workspace views, but the solution deployment is a separate prerequisite and does not itself provide centralized incident management.

How to eliminate wrong answers

Option A is wrong because deploying the Microsoft Sentinel solution across workspaces is a prerequisite for enabling Sentinel in each workspace, but it does not provide a centralized incident view; it only installs the solution components. Option B is wrong because assigning the same Azure RBAC roles to all users in each workspace ensures consistent permissions but does not aggregate incidents into a single pane; RBAC controls access, not data aggregation. Option C is wrong because merging workspaces into a single workspace would violate data residency requirements by centralizing data in one region, and it is not a supported operation in Sentinel; workspaces are region-bound and cannot be merged.

Practice this question →

179

Multi-Selectmedium

Which TWO actions should you take to ensure that Microsoft Sentinel can detect and respond to threats across your multicloud environment, including AWS and GCP?

Select 2 answers

A.Use Azure Policy to deploy the connectors automatically.

B.Create analytics rules in Microsoft Sentinel to detect threats from the ingested multicloud logs.

C.Configure the AWS S3 and GCP Pub/Sub data connectors.

D.Enable the Microsoft Defender XDR connector for AWS and GCP.

E.Create a separate Microsoft Sentinel workspace for each cloud provider.

AnswersB, C

Analytics rules are the core detection mechanism in Microsoft Sentinel; without them, ingested logs remain dormant and never generate alerts or incidents. These rules use Kusto Query Language (KQL) to define detection logic, set alert thresholds, and trigger automated responses when suspicious activity matches. Enabling the AWS S3 and GCP Pub/Sub connectors supplies raw log data, but only analytics rules transform that data into actionable security incidents by performing correlation and pattern matching across the multicloud logs.

Why this answer

Analytics rules in Microsoft Sentinel define the conditions under which alerts are generated from ingested data. Without these rules, the raw logs from AWS S3 and GCP Pub/Sub would be stored but not evaluated for threats, rendering detection ineffective. Creating custom or built-in analytics rules is essential to transform ingested multicloud logs into actionable security incidents.

Exam trap

The trap here is that candidates often assume enabling a connector alone is sufficient for detection, forgetting that analytics rules are required to define what constitutes a threat; they also mistakenly think Microsoft Defender XDR can directly ingest AWS/GCP logs, when it only handles Microsoft 365 data.

Practice this question →

180

Multi-Selecteasy

Which TWO data connectors can be used to ingest Microsoft 365 audit logs into Microsoft Sentinel? (Choose two.)

Select 2 answers

A.Microsoft Defender for Cloud Apps connector.

B.Microsoft 365 Defender connector.

C.Office 365 connector (Exchange, SharePoint, Teams).

D.Azure Activity connector.

E.Azure AD connector (sign-in logs).

AnswersB, C

This connector is a valid choice because it ingests unified audit logs from Microsoft 365, along with alerts and incidents from the Microsoft 365 Defender suite. It allows you to collect audit records related to user actions such as mailbox access, file shares, and Teams messages, which are critical for security investigations. By integrating with Microsoft 365 Defender, the connector provides a streamlined way to bring these logs into your SIEM, making it one of the two correct answers.

Why this answer

The Microsoft 365 Defender connector (Option B) ingests unified audit logs from Microsoft 365 Defender, which includes security-related events from Microsoft 365 services. The Office 365 connector (Option C) directly ingests audit logs from Exchange Online, SharePoint Online, and Microsoft Teams, which are part of the Microsoft 365 audit log. Both connectors are designed to bring Microsoft 365 audit log data into Microsoft Sentinel.

Exam trap

The trap here is that candidates often confuse the Microsoft 365 Defender connector with the Office 365 connector, thinking they are redundant, or they mistakenly select the Azure AD connector because they assume sign-in logs are part of Microsoft 365 audit logs, when in fact the Azure AD connector only captures Azure AD-specific events, not the full Microsoft 365 audit log.

Practice this question →

181

MCQeasy

Your company uses Microsoft Sentinel to monitor security events. You have configured a daily email report that summarizes the top 10 incidents from the past 24 hours. The report is sent using a Logic App playbook triggered by a scheduled query. Recently, the report has stopped being delivered. You check the Logic App run history and see that the last run failed with an HTTP 403 error when connecting to the Microsoft Sentinel API. The Logic App uses a managed identity for authentication. What is the most likely cause of the failure?

A.The managed identity does not have the required permissions on the Sentinel workspace.

B.The managed identity's client ID has changed.

C.The Logic App is not connected to Microsoft Entra ID.

D.The scheduled query is no longer running.

AnswerA

The managed identity must be assigned the Sentinel Reader RBAC role on the target Log Analytics workspace (or its resource group). Without this role, the Microsoft Sentinel connector in the Logic App returns an authorization error when attempting to read incidents or execute a query, even though the Logic App trigger ran successfully. Permissions are not automatically granted to the managed identity's service principal; they must be explicitly assigned via Azure RBAC.

Why this answer

The HTTP 403 error indicates a permissions failure when the Logic App attempted to call the Microsoft Sentinel API. Since the Logic App uses a managed identity for authentication, the most likely cause is that the managed identity lacks the necessary role assignments on the Sentinel workspace, such as 'Microsoft Sentinel Contributor' or 'Microsoft Sentinel Reader', which are required to query incidents via the API.

Exam trap

The trap here is that candidates may confuse an HTTP 403 (forbidden/permissions) with an HTTP 401 (unauthenticated) or assume the managed identity itself is broken, when in fact the identity is valid but lacks the required RBAC role on the Sentinel workspace.

How to eliminate wrong answers

Option B is wrong because a managed identity's client ID is immutable and does not change; if it did, the identity itself would be broken, not just the permissions. Option C is wrong because a Logic App using a managed identity is inherently connected to Microsoft Entra ID (formerly Azure AD) — the managed identity is a feature of Entra ID, so a missing connection would prevent authentication entirely, not cause a 403. Option D is wrong because the scheduled query not running would result in no data or a different error (e.g., empty report), not an HTTP 403 from the Sentinel API; the 403 specifically indicates an authorization failure during the API call.

Practice this question →

182

MCQeasy

You are reviewing the automation rule configuration shown in the exhibit. What is the purpose of this rule?

A.Automatically resolve incidents related to malware

B.Automatically close incidents with 'Malware' in the title

C.Run a playbook to isolate a device when an incident with 'Malware' in the alert title is created

D.Create a playbook for malware alerts

AnswerC

This automation rule is triggered when a new incident is created and its condition matches alert titles containing the word 'Malware.' The rule's action invokes a playbook—an Azure Logic Apps workflow—that is designed to isolate the affected device, typically through a Microsoft Defender for Endpoint connector. This correctly describes the two core parts of the rule: the condition (incident created + alert title contains 'Malware') and the action (run a playbook to isolate a device).

Why this answer

The automation rule is configured to trigger when an incident is created with 'Malware' in the alert title. The action specified is to run a playbook, which in Microsoft Sentinel can perform complex remediation steps such as isolating a device. Option C correctly identifies this combination of trigger condition and action.

Exam trap

The trap here is that candidates may confuse 'run a playbook' with 'resolve' or 'close' incidents, or think the rule itself creates the playbook, when in fact the rule only triggers an existing playbook.

How to eliminate wrong answers

Option A is wrong because the rule does not automatically resolve incidents; it runs a playbook, which may include resolution steps but is not the direct action of the rule. Option B is wrong because the rule does not close incidents; it triggers a playbook execution, not a closure action. Option D is wrong because the rule does not create a playbook; it runs an existing playbook when the condition is met.

Practice this question →

183

MCQhard

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

A.Verify that the Microsoft 365 Defender connector is configured to ingest MDE alerts.

B.Check if the Microsoft Defender for Endpoint data connector is added.

C.Verify that the ingestion rules in Sentinel are not filtering out MDE alerts.

D.Check the Microsoft 365 Defender portal to ensure MDE alerts are being generated and forwarded to Microsoft 365 Defender.

AnswerD

Before troubleshooting Sentinel, verify that Microsoft Defender for Endpoint alerts are actually being produced and sent to Microsoft 365 Defender by reviewing the Microsoft 365 Defender portal. If no MDE alerts are visible there, they cannot propagate downstream to Sentinel, regardless of connector configuration. This is the root-cause check because the Microsoft 365 Defender connector only ingests what Microsoft 365 Defender itself has received and correlated; an empty source yields empty Sentinel tables.

Why this answer

The Microsoft 365 Defender connector in Microsoft Sentinel ingests alerts that have already been generated and forwarded by Microsoft Defender for Endpoint (MDE) to the Microsoft 365 Defender portal. Even if the connector status shows 'Connected', if MDE alerts are not being generated or forwarded to Microsoft 365 Defender (e.g., due to a licensing issue, misconfigured alert policy, or service health problem), they will never reach Sentinel. Therefore, the first troubleshooting step is to verify alert generation and forwarding at the source in the Microsoft 365 Defender portal.

Exam trap

The trap here is that candidates assume a 'Connected' status guarantees data flow, but the connector status only reflects the API connection to Microsoft 365 Defender, not the actual generation or forwarding of alerts from the underlying MDE service.

How to eliminate wrong answers

Option A is wrong because the Microsoft 365 Defender connector is specifically designed to ingest MDE alerts (along with other Microsoft 365 Defender signals) — there is no separate configuration toggle within the connector to enable or disable MDE alert ingestion; if the connector is connected, it ingests all available alerts from Microsoft 365 Defender. Option B is wrong because there is no separate 'Microsoft Defender for Endpoint data connector' in Sentinel; MDE alerts are ingested exclusively through the Microsoft 365 Defender connector, so adding a non-existent connector is not a valid troubleshooting step. Option C is wrong because ingestion rules in Sentinel filter data after it has been received by the connector; if alerts are not appearing, the issue is upstream (before ingestion rules apply), and checking ingestion rules would only be relevant if alerts were being dropped after arrival.

Practice this question →

184

MCQeasy

You are a security operations analyst. You need to review all incidents from the past 24 hours that have a high severity and involve multiple users. In Microsoft Sentinel, which blade should you use?

A.Incidents

B.Hunting

C.Workbooks

D.Analytics

AnswerA

The Incidents blade in Microsoft Sentinel is the dedicated operational workspace for security analysts to triage, investigate, and manage security incidents. It aggregates related alerts into a single incident, provides filtering by status, severity, and product, and supports actions like assignment and closing. This is the correct place to review existing incidents as it centralizes all detection results requiring attention.

Why this answer

The Incidents blade in Microsoft Sentinel is the correct place to review all security incidents, including filtering by severity and the number of users involved. It provides a centralized view where you can apply filters for 'High' severity and 'Multiple users' to meet the requirement of reviewing incidents from the past 24 hours. The Hunting, Workbooks, and Analytics blades serve different purposes and do not offer the same incident review and filtering capabilities.

Exam trap

The trap here is that candidates might confuse the Hunting blade (used for proactive searches) with incident review, or think that Workbooks or Analytics can be used to filter incidents, when in fact only the Incidents blade provides the direct filtering and management interface for security incidents.

How to eliminate wrong answers

Option B is wrong because the Hunting blade is used for proactive threat hunting using KQL queries to find suspicious activities, not for reviewing already-created incidents. Option C is wrong because Workbooks are used for creating custom visualizations and reports from log data, not for directly reviewing or filtering incidents. Option D is wrong because the Analytics blade is used to create and manage analytics rules that generate alerts and incidents, not to review existing incidents.

Practice this question →

185

Multi-Selecthard

You are configuring Microsoft Sentinel to ingest data from multiple sources. Which TWO of the following are valid data connectors that can be used to ingest AWS CloudTrail logs?

Select 2 answers

A.Azure Functions connector

B.Office 365 connector

C.AWS S3 connector

D.Microsoft Defender for Cloud connector

E.Syslog connector

AnswersA, C

Azure Functions can be deployed to create a custom ingestion pipeline for AWS CloudTrail logs. This involves configuring an Azure Function to retrieve logs from the designated AWS S3 bucket where CloudTrail stores its data. The function then processes these logs and forwards them to the Microsoft Sentinel Log Analytics workspace, effectively satisfying the requirement to ingest AWS CloudTrail logs. This method offers flexibility for custom transformations or filtering before ingestion.

Why this answer

The AWS S3 connector (Option C) is a valid data connector for ingesting AWS CloudTrail logs into Microsoft Sentinel by reading the logs directly from an S3 bucket. The Azure Functions connector (Option A) is also valid because it can be configured to trigger on CloudTrail log delivery to S3, using a function app to parse and forward the logs to Sentinel via the Log Analytics HTTP Data Collector API.

Exam trap

The trap here is that candidates often assume only the AWS S3 connector is valid, forgetting that Azure Functions can also serve as a custom data connector for AWS CloudTrail logs when configured with the appropriate trigger and permissions.

Practice this question →

186

MCQmedium

Your organization uses Microsoft Defender XDR. You need to configure automatic attack disruption for identity-related threats. The solution should automatically contain a compromised user by disabling their account. Which setting should you enable?

A.Configure Conditional Access policies to block the user.

B.Enable automatic attack disruption in the Microsoft Defender XDR settings.

C.Use Microsoft Sentinel automation rules to disable the user.

D.Create a custom detection rule to alert on suspicious sign-ins.

AnswerB

Enable automatic attack disruption in the Microsoft Defender XDR settings. This native capability automatically contains compromised identities by disabling user accounts or isolating devices when an active attack is detected, without manual intervention. It uses cross-domain signals to break the attack chain immediately, aligning exactly with the requirement to automatically respond in real time.

Why this answer

Microsoft Defender XDR's automatic attack disruption feature is specifically designed to contain identity-related threats by automatically disabling compromised user accounts. This setting, found in the Microsoft Defender XDR settings under 'Automated investigation and response', triggers when high-confidence identity attacks (e.g., password spray, lateral movement) are detected, without requiring manual intervention or additional infrastructure.

Exam trap

The trap here is that candidates often confuse 'blocking sign-ins' (Conditional Access) with 'disabling the account' (automatic attack disruption), failing to recognize that only the latter fully contains a compromised user by preventing all authentication attempts, including those from trusted devices or locations.

How to eliminate wrong answers

Option A is wrong because Conditional Access policies block sign-in attempts but do not disable the user account; the account remains active and could be used from non-compliant devices or after policy bypass. Option C is wrong because Microsoft Sentinel automation rules can trigger playbooks to disable users, but this requires custom configuration and is not the built-in automatic attack disruption mechanism within Defender XDR for identity threats. Option D is wrong because custom detection rules only generate alerts and do not automatically contain the user; they lack the automated response capability to disable the account.

Practice this question →

187

MCQeasy

You are reviewing an automation rule ARM template for Microsoft Sentinel. What is the result of deploying this automation rule?

A.The rule assigns the incident to SOC-Tier2 only if the severity is Medium.

B.The rule triggers when an incident is updated and resets the severity to High.

C.When a High severity incident is created, the rule changes its severity to Medium and assigns it to SOC-Tier2.

D.The rule triggers when a High severity incident is created but does not change the severity.

AnswerC

This option accurately reflects the ARM template's trigger and action configuration. On incident creation, when 'Severity' equals 'High', the rule executes an update action changing severity to 'Medium' and an assignment action setting the owner to the 'SOC-Tier2' group. Both actions run in sequence as part of that single rule instance, and no other conditions modify this behavior.

Why this answer

The ARM template defines an automation rule that triggers when an incident is created with a severity of High. The rule's actions change the severity to Medium and assign the incident to the SOC-Tier2 owner. This matches option C exactly.

Exam trap

The trap here is that candidates may misinterpret the trigger condition as 'on update' (option B) or overlook the severity change action (option D), focusing only on the assignment part of the rule.

How to eliminate wrong answers

Option A is wrong because the rule triggers on incident creation, not on assignment, and it changes severity from High to Medium, not assigning based on Medium severity. Option B is wrong because the rule triggers on creation, not update, and it changes severity from High to Medium, not resetting to High. Option D is wrong because the rule does change the severity from High to Medium, contradicting the 'does not change the severity' claim.

Practice this question →

188

Multi-Selecteasy

Which TWO data connectors are available in Microsoft Sentinel to ingest data from Microsoft 365 services?

Select 2 answers

A.Azure Active Directory

B.Microsoft Defender for Cloud

C.Amazon Web Services

D.Microsoft Entra ID

E.Office 365

AnswersD, E

Microsoft Entra ID is a correct connector because it ingests sign-in logs (including interactive and non-interactive sign-ins) and audit logs from Azure AD into Microsoft Sentinel. This data is essential for identity-based threat detection and investigation, allowing analysts to trace authentication attempts and directory changes.

Why this answer

Microsoft Entra ID (formerly Azure Active Directory) is a correct data connector because it ingests sign-in logs, audit logs, and provisioning events from Microsoft's identity service into Microsoft Sentinel. This connector uses the Microsoft Graph API to pull identity-related telemetry, which is essential for monitoring authentication anomalies and privilege escalation.

Exam trap

The trap here is that candidates confuse the legacy name 'Azure Active Directory' with the current product name 'Microsoft Entra ID', and may also mistakenly think Microsoft Defender for Cloud is a data source for M365 services rather than a security solution for cloud workloads.

Practice this question →

189

MCQmedium

You are using Microsoft Sentinel to manage incidents. You want to automatically close incidents that are older than 90 days and have a status of 'New'. What is the most efficient way to achieve this?

A.Create a workbook that shows old incidents and manually close them.

B.Create a playbook that runs on a schedule (e.g., daily) and closes incidents that meet the criteria.

C.Modify the analytics rule to automatically close incidents after 90 days.

D.Create an automation rule that triggers on incident update and closes the incident if the created time is older than 90 days.

AnswerB

A scheduled playbook uses a recurrence trigger to query Microsoft Sentinel for incidents older than 90 days with status New, then closes them automatically. This satisfies the bulk-closure requirement without manual triage, unlike automation rules, which trigger on incident creation rather than elapsed age.

Why this answer

A scheduled playbook is the most efficient way to automatically close stale incidents because Microsoft Sentinel playbooks (Logic Apps) support recurrence triggers that can query the Sentinel incidents API on a schedule, filter by status 'New' and createdTime older than 90 days, and close them in bulk. This is a native, low-code automation path that doesn't require manual intervention or modifying detection logic.

Exam trap

SC-200 often tests the distinction between automation rules (event-triggered) and playbooks (which can be schedule-triggered) — candidates incorrectly assume automation rules can handle time-based conditions.

How to eliminate wrong answers

Option A is wrong because a workbook is only a visualization/reporting surface — it cannot close incidents and requires manual action, defeating the 'automatically' requirement. Option C is wrong because analytics rules generate incidents; they have no built-in 'auto-close after N days' setting, and modifying them would affect detection, not lifecycle management. Option D is wrong because automation rules trigger on incident creation/update events, not on a time schedule — an incident that simply ages past 90 days without any update will never fire the rule, so stale incidents would remain open.

Practice this question →

190

Multi-Selecthard

Your SOC is implementing a Microsoft Sentinel workspace with multiple content hub solutions. You need to ensure that only approved analytics rules are enabled and that any custom rules are reviewed before activation. Which THREE actions should you take?

Select 3 answers

A.Configure Threat Intelligence - Taxii connector to import rules from an external feed.

B.Use the Hunting blade to create custom hunting queries instead of analytics rules.

C.Use Microsoft Sentinel Repositories (CI/CD) to manage analytics rules via Azure DevOps or GitHub.

D.In Content hub, install only the solutions that contain approved analytics rules.

E.Create an automation rule that disables any newly created analytics rule that is not in an approved list.

AnswersC, D, E

Microsoft Sentinel Repositories (CI/CD) enables you to manage analytics rules as code in Azure DevOps or GitHub, with content deployed via ARM templates or Bicep. This enforces a formal approval workflow through pull requests and branch policies before any rule reaches the workspace, ensuring only reviewed and approved rules are deployed. It also provides version control and rollback capabilities, making it the most robust governance approach for rule lifecycle management.

Why this answer

Option C is correct because Microsoft Sentinel Repositories enable CI/CD-based deployment of analytics rules from Azure DevOps or GitHub, so every rule change goes through a pull request and review before activation, enforcing the approval workflow. Option D is correct because installing only Content hub solutions that contain approved analytics rules ensures that only vetted, Microsoft-published or approved rule templates are deployed into the workspace, preventing unapproved content from being enabled. Option E is correct because an automation rule triggered on analytics rule creation can immediately disable any rule not present in the approved list, providing a runtime guardrail that catches rules created outside the governed pipeline.

Option A is not correct because the Threat Intelligence - TAXII connector imports threat indicators, not analytics rules, so it does not govern rule enablement. Option B is not correct because hunting queries are separate from analytics rules and do not satisfy the requirement to control which analytics rules are enabled or reviewed.

Exam trap

The trap here is that candidates may confuse the purpose of the Threat Intelligence - TAXII connector (which imports threat indicators, not rules) or think that the Hunting blade can serve as a governance mechanism for analytics rules, when in fact it is only for ad-hoc threat hunting.

Practice this question →

191

Multi-Selectmedium

Which TWO actions are valid ways to reduce the number of false positive incidents in Microsoft Sentinel without disabling analytics rules?

Select 2 answers

A.Configure the rule to group all alerts into a single incident per entity.

B.Increase the rule run frequency.

C.Change the incident severity to Informational.

D.Modify the rule's query to include additional filters.

E.Create an automation rule to close incidents that match certain criteria.

AnswersD, E

Modifying the rule's query to include additional filters, such as excluding known-safe IP addresses or requiring specific event attributes, directly increases precision by removing benign activity from the detection logic. This addresses the root cause of false positives because the KQL query is the decision engine that determines which raw events become alerts. Properly scoped filters reduce incident volume while preserving genuine threat detection.

Why this answer

Modifying the rule's query to include additional filters directly reduces false positives by narrowing the conditions that trigger an alert. This approach refines the detection logic without disabling the rule, ensuring only events that more precisely match the intended threat pattern generate incidents.

Exam trap

The trap here is that candidates confuse reducing incident volume (via grouping or severity changes) with reducing false positives, but only query modifications or automation rules that close specific false incidents actually address the root cause of inaccurate detections.

Practice this question →

192

Multi-Selecthard

Which TWO features in Microsoft Sentinel can help reduce alert fatigue by grouping related alerts into incidents? (Select two.)

Select 2 answers

A.Incident merging

B.Entity behavior analytics

C.Automation rules that run playbooks

D.Analytics rules that create incidents

E.Threat intelligence indicators

AnswersA, D

Incident merging in Microsoft Sentinel combines multiple incidents that are part of the same attack campaign or share entities into a single incident. This directly reduces the number of incidents analysts must triage, lowering mean time to respond and preventing alert fatigue. By minimizing the chance that a critical alert is lost in a queue, it reduces the financial impact of a successful breach, thus lowering annualized loss expectancy.

Why this answer

Incident merging (Option A) is correct because it automatically combines multiple alerts that share common entities (such as IP addresses, hostnames, or user accounts) into a single incident. This reduces alert fatigue by preventing security analysts from having to triage dozens of separate alerts that are all part of the same attack chain, allowing them to focus on a single, consolidated incident.

Exam trap

The trap here is that candidates often confuse 'automation rules' (which automate responses) with 'incident creation' (which groups alerts), or they mistakenly think entity behavior analytics or threat intelligence indicators perform the grouping function, when in fact only incident merging and analytics rules with incident creation settings can consolidate related alerts.

Practice this question →

193

MCQmedium

Your organization is using Microsoft Defender for Cloud Apps to protect cloud applications. The security team wants to be alerted when a user shares a sensitive file with an external user. What should you configure?

A.Activity policy

B.App discovery policy

C.Anomaly detection policy

D.File policy

AnswerD

File policies are purpose-built in Defender for Cloud Apps to monitor and govern files stored in connected cloud apps such as SharePoint, OneDrive, Box, and Google Drive. They evaluate conditions on file metadata, sharing permissions, file name, and content inspection, and can trigger alerts or automatic actions like quarantine or revoking access. This allows you to create a policy that specifically detects files shared with external users, thereby directly addressing the requirement to monitor file sharing.

Why this answer

File policies in Microsoft Defender for Cloud Apps are specifically designed to monitor and respond to events involving files stored in connected cloud apps, such as when a sensitive file is shared with an external user. You can configure a file policy with a filter for 'External' sharing and apply a content inspection rule to detect sensitive information types, triggering an alert when the condition is met.

Exam trap

The trap here is that candidates confuse activity policies (which monitor user actions) with file policies (which monitor file attributes and sharing permissions), leading them to choose Option A when the question explicitly mentions 'shares a sensitive file'—a file-centric event requiring content and sharing context.

How to eliminate wrong answers

Option A is wrong because an activity policy monitors user activities (e.g., login from unusual location, mass download) but does not natively inspect file content or sharing permissions for sensitivity. Option B is wrong because an app discovery policy analyzes traffic to identify shadow IT applications, not to monitor file sharing within already sanctioned cloud apps. Option C is wrong because an anomaly detection policy uses machine learning to detect unusual behavior patterns (e.g., impossible travel) but cannot enforce rules based on specific file sensitivity labels or external sharing status.

Practice this question →

194

MCQmedium

Refer to the exhibit. You are investigating a user entity in Microsoft Sentinel. The entity details show a riskLevel of 'high' and riskState 'atRisk'. What does this indicate?

A.The user account has been disabled

B.The user account triggered a Sentinel analytics rule

C.The user account has been flagged by Microsoft Entra ID Protection as at risk

D.The user account has been confirmed compromised

AnswerC

The exhibit exposes riskLevel and riskState, which are populated by Microsoft Entra ID Protection when a user's risk score exceeds a threshold. These fields indicate that the identity has been flagged as at risk due to suspicious activity, such as atypical travel or leaked credentials. This is an automated risk assessment from Entra ID Protection, not a manual determination or a Sentinel analytics detection.

Why this answer

The riskLevel of 'high' and riskState of 'atRisk' are specific properties populated by Microsoft Entra ID Protection (formerly Azure AD Identity Protection). These values indicate that the user account has been flagged as risky based on real-time risk detections (e.g., leaked credentials, anonymous IP address, atypical travel). This is not a direct result of a Sentinel analytics rule, nor does it mean the account is disabled or confirmed compromised—it means the identity protection service has detected suspicious activity and assigned a risk level.

Exam trap

The trap here is that candidates often confuse the riskLevel and riskState fields from Microsoft Entra ID Protection with Sentinel analytics rule alerts, assuming any 'high risk' label must come from a detection rule, when in fact these fields are native identity protection properties that are enriched into the entity.

How to eliminate wrong answers

Option A is wrong because a disabled user account would show a different entity property (e.g., accountEnabled: false) and would not be reflected in the riskLevel or riskState fields, which are specific to identity risk detection. Option B is wrong because triggering a Sentinel analytics rule would generate an incident or alert, but the riskLevel and riskState fields on the user entity are populated by Microsoft Entra ID Protection, not by Sentinel analytics rules. Option D is wrong because a riskState of 'atRisk' indicates the account is suspected to be compromised but has not yet been confirmed; a confirmed compromise would show a riskState of 'confirmedCompromised'.

Practice this question →

195

MCQeasy

Your organization uses Microsoft Sentinel. You need to ensure that an alert is created when a user accesses a sensitive SharePoint site from an unusual location. What should you create?

A.A watchlist

B.An analytics rule

C.A playbook

D.An automation rule

AnswerB

An analytics rule is the correct choice because Microsoft Sentinel uses analytics rules as its primary detection mechanism. A scheduled or Microsoft security analytics rule runs KQL queries on a recurring basis, evaluates results against thresholds or entity behavior, and can generate alerts and incidents for suspicious sign-in patterns or other anomalies, thereby satisfying the requirement to ensure detection and alerting.

Why this answer

An analytics rule in Microsoft Sentinel defines the conditions under which alerts are generated. To detect a user accessing a sensitive SharePoint site from an unusual location, you would create an analytics rule that queries the Office 365 activity logs (e.g., SharePoint operations) and uses the 'Unusual Geo-Location' anomaly detection or a custom KQL query comparing the user's location against a baseline of their typical access patterns. This rule will then generate an alert when the condition is met.

Exam trap

The trap here is that candidates often confuse the purpose of an analytics rule (alert creation) with automation rules (incident management) or playbooks (response actions), leading them to select a post-alert component instead of the rule that actually generates the alert.

How to eliminate wrong answers

Option A is wrong because a watchlist is a static collection of data (e.g., IP addresses or user accounts) used for correlation or enrichment in queries, not for generating alerts based on dynamic behavioral patterns like unusual location access. Option C is wrong because a playbook is an automated response workflow (based on Azure Logic Apps) triggered by an alert, not the mechanism that creates the alert itself. Option D is wrong because an automation rule manages the lifecycle of incidents (e.g., assigning, tagging, or closing) after an alert is generated, not the creation of the alert from raw log data.

Practice this question →

196

MCQeasy

Your organization uses Microsoft Purview Data Loss Prevention (DLP) policies. You need to investigate an incident where sensitive data was shared externally. You want to view the details in Microsoft Sentinel. What should you ensure is configured?

A.The Microsoft 365 data connector in Microsoft Sentinel is enabled and configured to collect DLP alerts.

B.The SharePoint site is configured for external sharing.

C.The DLP policy must be set to 'Audit only' mode.

D.The unified audit log is enabled and the DLP events are being generated.

AnswerA

This connector is the explicit, required data ingestion path between Microsoft Purview DLP and Microsoft Sentinel. It calls the Office 365 Management API to pull DLP alert records and writes them into the SecurityAlert table, which is what Sentinel analytics rules actually query. Without this connector enabled and configured, no DLP alert—regardless of policy mode or audit logging—will appear in Sentinel. Therefore, it is the only condition that directly determines whether DLP alerts are ingested.

Why this answer

Microsoft Sentinel's Microsoft 365 data connector ingests unified audit logs from Microsoft Purview, including DLP alerts. When this connector is enabled and configured to collect DLP alerts, Sentinel can receive and surface the incident details, allowing investigation of externally shared sensitive data. Without this connector, DLP events remain in the Purview compliance portal and are not forwarded to Sentinel.

Exam trap

The trap here is that candidates often assume enabling the unified audit log (Option D) is sufficient for Sentinel to receive DLP alerts, but they overlook that the Microsoft 365 data connector must be specifically configured to collect DLP events, as the connector acts as the bridge between the audit log and Sentinel.

How to eliminate wrong answers

Option B is wrong because configuring a SharePoint site for external sharing is a prerequisite for external sharing to occur, but it does not enable Sentinel to ingest DLP alert details; it is a separate configuration unrelated to data collection. Option C is wrong because setting the DLP policy to 'Audit only' mode means the policy will only log events without blocking or alerting, but it does not affect whether Sentinel can receive DLP alerts; the connector must still be configured. Option D is wrong because while the unified audit log must be enabled and DLP events generated for any DLP alert to exist, this alone does not ensure that Sentinel receives those events; the Microsoft 365 data connector must be explicitly enabled and configured to collect DLP alerts.

Practice this question →

197

MCQhard

Your organization uses Microsoft Defender XDR incident queue. You want to automatically assign incidents related to a specific campaign to a dedicated SOC group. What should you create?

A.A standard rule in Microsoft Defender for Endpoint.

B.An automation rule in Microsoft Sentinel.

C.A custom detection rule in Microsoft Defender XDR that includes an incident assignment action.

D.A custom role in Microsoft Defender XDR.

AnswerC

A custom detection rule in Microsoft Defender XDR is the correct mechanism because it allows you to define a KQL-based query and, in the rule configuration, specify an incident assignment action. When the detection fires and generates an incident, that action automatically assigns the incident to a designated group (or in some cases an individual). This is the officially supported way to automate incident assignment in the Defender XDR incident queue, ensuring every generated incident has an owner from the outset.

Why this answer

Microsoft Defender XDR allows you to create custom detection rules that can include automated incident assignment actions. This enables you to automatically assign incidents related to a specific campaign to a dedicated SOC group directly within the Defender XDR incident queue, without relying on external tools or manual processes.

Exam trap

The trap here is that candidates often confuse Microsoft Defender XDR's custom detection rules with Microsoft Sentinel's automation rules, but the question explicitly references the Defender XDR incident queue, not Sentinel.

How to eliminate wrong answers

Option A is wrong because standard rules in Microsoft Defender for Endpoint are used for alert suppression or tuning, not for incident assignment actions. Option B is wrong because automation rules in Microsoft Sentinel are designed for Azure Sentinel incidents, not for the Microsoft Defender XDR incident queue. Option D is wrong because custom roles in Microsoft Defender XDR control permissions and access, not automated incident assignment logic.

Practice this question →

198

MCQeasy

You need to grant a junior analyst the ability to view and investigate incidents in Microsoft Sentinel, but not make any changes. Which built-in role should you assign?

A.Microsoft Sentinel Responder

B.Microsoft Sentinel Contributor

C.Microsoft Sentinel Automation Contributor

D.Microsoft Sentinel Reader

AnswerD

Microsoft Sentinel Reader is the correct role because it grants read-only access to all Sentinel resources, including incidents, workbooks, hunting queries, and analytics rule templates. This allows the junior analyst to view and investigate security data without any risk of accidental modification, aligning perfectly with the principle of least privilege.

Why this answer

The Microsoft Sentinel Reader role provides read-only access to Sentinel resources, including incidents, workbooks, and analytics rules, without allowing any modifications. This aligns with the requirement to view and investigate incidents without making changes, as the role explicitly denies write, delete, or action permissions on Sentinel data.

Exam trap

The trap here is that candidates often confuse 'view and investigate' with the ability to update incident status or run playbooks, leading them to choose the Responder role, which actually allows changes.

How to eliminate wrong answers

Option A is wrong because the Microsoft Sentinel Responder role allows updating incidents (e.g., changing status, assigning ownership) and running playbooks, which includes making changes, not just viewing. Option B is wrong because the Microsoft Sentinel Contributor role grants full write access to Sentinel resources, including creating and modifying incidents, analytics rules, and automation rules, which exceeds the read-only requirement. Option C is wrong because the Microsoft Sentinel Automation Contributor role is specifically designed to manage automation rules and playbooks, not for viewing or investigating incidents, and it includes write permissions to automation components.

Practice this question →

199

Multi-Selectmedium

Which TWO actions can be performed using automation rules in Microsoft Sentinel?

Select 2 answers

A.Run a playbook

B.Assign an incident to an owner

C.Create an incident

D.Modify an analytics rule

E.Delete an incident

AnswersA, B

Automation rules include a built-in 'Run playbook' action that invokes a Microsoft Sentinel playbook (an Azure Logic Apps workflow) automatically whenever the rule's trigger conditions are met, such as on incident creation or status change. This action allows security analysts to chain SOAR actions—like threat intelligence enrichment, quarantine, or email notification—directly from the incident workflow without manual intervention. The playbook must be registered with the incident trigger to appear in the automation rule.

Why this answer

Automation rules in Microsoft Sentinel can trigger a playbook as an action when an incident is created or updated. Playbooks are automated workflows based on Azure Logic Apps, allowing for complex response actions such as threat containment, notification, or enrichment. This enables security teams to automate incident response without manual intervention.

Exam trap

The trap here is that candidates often confuse automation rules with analytics rules, mistakenly thinking automation rules can create or modify analytics rules, when in fact automation rules only react to incidents and perform actions like assignment or playbook execution.

Practice this question →

200

MCQhard

Your company uses Microsoft Defender for Cloud to assess the security posture of hybrid workloads. You are configuring a governance rule to automatically remediate a specific recommendation that is out of compliance. The recommendation is 'Virtual machines should be migrated to new Azure Resource Manager resources'. You need to ensure that the remediation is applied at scale across all subscriptions in the management group. What should you do?

A.Create a PowerShell script that runs on each VM to migrate it, and execute it via Azure Automation.

B.Create an Azure Policy initiative that includes the recommendation and assign it with a remediation task at the management group level.

C.Create a governance rule in Microsoft Defender for Cloud with scope set to the management group, condition on the recommendation, and action set to 'Automatic'.

D.Create a governance rule in Microsoft Defender for Cloud with scope set to a single subscription and action set to 'Automatic'.

AnswerC

To meet the requirement, create a governance rule in Microsoft Defender for Cloud with scope set to the management group, a condition that includes the specific recommendation, and an action of 'Automatic'. Scoping at the management group makes the rule inherit to all subscriptions beneath it, so every VM is assessed, and the 'Automatic' action invokes Defender's built-in remediation capability to migrate the VMs without manual intervention. This is the native mechanism designed for exactly this scenario.

Why this answer

Governance rules in Microsoft Defender for Cloud allow you to define automatic remediation actions for specific recommendations at scale. By setting the scope to the management group, the rule applies to all subscriptions within that group, and the 'Automatic' action triggers the built-in remediation script for the 'Virtual machines should be migrated to new Azure Resource Manager resources' recommendation without requiring custom scripting or policy assignments.

Exam trap

The trap here is that candidates may confuse Azure Policy remediation tasks with Defender for Cloud governance rules, not realizing that governance rules provide a simpler, built-in mechanism for automatic remediation of specific recommendations at scale without requiring separate policy assignments.

How to eliminate wrong answers

Option A is wrong because creating a PowerShell script and executing it via Azure Automation is a manual, custom approach that does not leverage Defender for Cloud's native governance rule capability for automatic, at-scale remediation across all subscriptions in a management group. Option B is wrong because Azure Policy initiatives can enforce compliance but do not directly integrate with Defender for Cloud's governance rules for automatic remediation of specific recommendations; a governance rule is the correct mechanism for this scenario. Option D is wrong because setting the scope to a single subscription would not apply the remediation across all subscriptions in the management group, failing the requirement for at-scale application.

Practice this question →

201

MCQmedium

You are a security operations analyst for a company that uses Microsoft Defender XDR. You need to configure alert notifications so that the security team receives an email whenever a high-severity alert is generated. What should you do?

A.In Microsoft Sentinel, create an automation rule that triggers on high-severity incidents and sends an email using a playbook.

B.In Microsoft Defender for Endpoint, configure alert notifications for high-severity alerts.

C.In Azure Monitor, create an action group that sends emails for high-severity alerts from Microsoft Defender XDR.

D.In the Microsoft 365 Defender portal, go to Settings > Microsoft 365 Defender > Alert notifications, and create a new notification rule with severity set to High.

AnswerD

The Microsoft 365 Defender portal provides alert notification settings where you can define rules based on alert severity. Creating a rule with severity High ensures that only high-severity alerts trigger email notifications to the specified recipients. This is the correct method.

Why this answer

Microsoft Defender XDR provides built-in alert notification settings that allow you to define rules based on severity, alert category, and other criteria. Configuring a notification rule with severity High ensures that the security team receives email alerts for high-severity incidents across all Defender workloads.

Exam trap

The trap here is assuming that Defender for Endpoint notification settings cover all Defender XDR alerts; they only cover endpoint alerts, while the Microsoft 365 Defender portal settings cover all workloads.

Practice this question →

202

MCQmedium

Refer to the exhibit. You are reviewing a Microsoft Sentinel scheduled analytics rule defined in JSON. The rule is intended to trigger an incident when more than 5 sign-ins from anomalous locations occur within an hour. However, the rule is not triggering as expected. What is the most likely cause?

A.The severity is set to 'Medium', but it must be an integer.

B.The query references a column that does not exist in the SigninLogs table.

C.The triggerThreshold is set to 5, but it should be a string like '5'.

D.The queryFrequency and queryPeriod are set to the same value, which is not allowed.

AnswerB

The rule fails because the KQL query references a column that does not exist in the SigninLogs table. Sentinel resolves column names against the actual Log Analytics schema, so an unknown column such as a misspelled or guessed field name produces a 'Failed to resolve scalar expression' error when the rule is validated or run. The query must reference a valid column from the SigninLogs schema, such as RiskLevelDuringSignIn or RiskLevelAggregated when evaluating risk level.

Why this answer

The query references a column that does not exist in the SigninLogs table. In Microsoft Sentinel, if a scheduled analytics rule's KQL query references a non-existent column, the query will fail silently or return no results, preventing the rule from triggering an incident. The rule logic depends on the query returning a result set that meets the trigger threshold, and a missing column causes the query to fail or return zero rows.

Exam trap

The trap here is that candidates may focus on the JSON syntax or rule configuration parameters (like severity type or triggerThreshold) instead of recognizing that the core issue is a KQL query referencing a non-existent column, which is a common data source mismatch error.

How to eliminate wrong answers

Option A is wrong because the 'severity' field in a Sentinel analytics rule JSON must be a string (e.g., 'Medium'), not an integer; the rule would fail to validate if it were an integer. Option C is wrong because 'triggerThreshold' is not a valid field in a Sentinel scheduled analytics rule; the correct field is 'triggerOperator' and 'triggerThreshold' is used in other contexts like Azure Monitor alerts, and it must be an integer, not a string. Option D is wrong because setting 'queryFrequency' and 'queryPeriod' to the same value is allowed and is actually common for rules that look back exactly one frequency window; the rule would still run correctly.

Practice this question →

203

Multi-Selectmedium

Which TWO capabilities are provided by Microsoft Copilot for Security within the Microsoft Sentinel experience?

Select 2 answers

A.Suggest KQL queries based on a description of what you want to detect.

B.Deploy a new workbook template from a description.

C.Modify an existing playbook by adding steps through natural language.

D.Generate a natural language summary of an incident.

E.Automatically create an automation rule based on a chat prompt.

AnswersA, D

Microsoft Copilot leverages generative AI to translate natural-language descriptions of detection intent into ready-to-run Kusto Query Language (KQL) statements for Advanced Hunting. This capability covers both Defender XDR and Sentinel's Log Analytics schema, allowing analysts to describe behaviors like 'show processes spawning PowerShell from Office apps' and receive schema-aware query syntax. Copilot can also iteratively refine these queries based on feedback, reducing syntax errors and accelerating detection authoring.

Why this answer

Microsoft Copilot for Security in Microsoft Sentinel can generate KQL queries from natural language descriptions, allowing analysts to quickly create detection rules without manually writing KQL syntax. This capability leverages AI to interpret the analyst's intent and produce a query that matches the described detection logic.

Exam trap

The trap here is that candidates may assume Copilot can automate operational tasks like deploying templates or modifying playbooks, but its capabilities are limited to generating KQL queries and summarizing incidents, not performing infrastructure changes.

Practice this question →

204

MCQmedium

Your SOC is investigating an incident in Microsoft Sentinel. You need to quickly identify all related alerts and entities across the timeline. What Microsoft Sentinel feature should you use?

A.Run a hunting query.

B.Open the incident investigation graph.

C.Review the analytics rule that generated the incident.

D.Use the Incident workbook.

AnswerB

The investigation graph visually maps alerts, entities and their relationships across the incident timeline, letting analysts pivot through connected evidence. Logs queries and workbooks show data but lack this interactive entity-relationship exploration, so the graph directly satisfies the need to identify all related alerts and entities.

Why this answer

The incident investigation graph in Microsoft Sentinel provides a visual, interactive map of all alerts, entities (such as users, IP addresses, hosts), and their relationships linked to a specific incident. This allows SOC analysts to quickly see the full scope of an incident across the timeline without manually correlating data, making it the correct tool for this scenario.

Exam trap

The trap here is that candidates may confuse the incident investigation graph with the Incident workbook, assuming both provide incident details, but the workbook is for aggregated reporting while the graph is for interactive, entity-level exploration of a single incident.

How to eliminate wrong answers

Option A is wrong because hunting queries are proactive searches for potential threats across raw data, not designed to retroactively consolidate all alerts and entities for a single incident. Option C is wrong because reviewing the analytics rule only shows the rule's configuration and logic, not the aggregated alerts and entities tied to the incident. Option D is wrong because the Incident workbook provides summary metrics and trends across incidents, not a focused, interactive graph of a single incident's related alerts and entities.

Practice this question →

205

Multi-Selecthard

Your organization uses Microsoft Sentinel with UEBA enabled. You need to investigate a potential insider threat where a user is accessing sensitive data outside of business hours. Which three built-in UEBA entities should you review?

Select 3 answers

A.Azure subscription

B.User account

C.Device

D.IP address

E.Resource group

AnswersB, C, D

The user account is the central entity type in UEBA because it has a distinct identity that can be associated with authentication events, directory actions, and application usage. Sentinel's UEBA profiles the user by aggregating raw activities from sources like Microsoft Entra ID sign-in logs, Office 365 audit logs, and Windows security events, then computes a baseline to identify anomalies such as impossible travel or privileged-account misuse. Without a user entity, behavioral analytics like 'user from new country' or 'user added to privileged group' would have no subject to attach to.

Why this answer

User account (B) is correct because UEBA in Microsoft Sentinel profiles user behavior to detect anomalies such as accessing sensitive data outside business hours. The user account entity is the primary identity used to correlate activities, logon events, and data access patterns, enabling the detection of insider threats based on deviations from established baselines.

Exam trap

The SC-200 exam often tests the distinction between Azure resource management constructs (subscriptions, resource groups) and actual security entities that UEBA monitors, leading candidates to select options that sound related but are not part of the UEBA entity schema.

Practice this question →

206

MCQhard

Your organization has Microsoft Sentinel deployed across multiple workspaces for different business units. The security team wants to view a unified incident queue across all workspaces. What should you implement?

A.Create cross-workspace queries and use the incident view with workspace references

B.Use Microsoft Defender XDR portal to view all incidents

C.Use Azure Lighthouse to manage multiple workspaces

D.Configure a single workspace to receive all incidents

AnswerA

Microsoft Sentinel supports cross-workspace analytics rules that use the workspace() KQL expression to query data from multiple workspaces in a single detection rule. In the incidents blade, you can add workspace references to display and triage incidents from all connected workspaces in one queue, without duplicating data. This preserves data residency and access control while giving security analysts a unified incident management experience across the entire organization.

Why this answer

Microsoft Sentinel supports cross-workspace incident viewing through the use of workspace references in queries and the unified incident view. By configuring cross-workspace queries and enabling the incident view with workspace references, the security team can aggregate and display incidents from multiple Sentinel workspaces in a single queue, providing a unified view without moving data.

Exam trap

The trap here is that candidates often confuse Azure Lighthouse (which enables cross-workspace management but not a unified incident queue) with the native cross-workspace query and incident view capabilities in Sentinel, leading them to choose option C instead of A.

How to eliminate wrong answers

Option B is wrong because Microsoft Defender XDR portal is designed for Microsoft 365 Defender incidents and alerts, not for aggregating Sentinel incidents from multiple workspaces; it does not natively display Sentinel incidents. Option C is wrong because Azure Lighthouse provides delegated resource management across tenants, but it does not natively create a unified incident queue within Sentinel; it allows managing multiple workspaces but each workspace's incidents remain separate unless cross-workspace views are explicitly configured. Option D is wrong because configuring a single workspace to receive all incidents would require ingesting all logs into one workspace, which defeats the purpose of having separate workspaces for different business units and may cause data sovereignty, cost, and performance issues.

Practice this question →

207

MCQhard

Refer to the exhibit. A security administrator runs this PowerShell script. What is the effect?

A.It creates an automation rule that runs a playbook on medium severity incidents

B.It creates a playbook that runs daily for high severity incidents

C.It schedules a daily report generation for all incidents

D.It creates a playbook named 'DailySummaryReport'

AnswerA

This is correct because the PowerShell cmdlet New-AzSentinelAutomationRule creates an automation rule, not a playbook. The rule's trigger condition is set to IncidentSeverity equals Medium at incident creation, and its configured action invokes a Logic Apps playbook. So the script's effect is to run that playbook whenever a medium-severity incident is created.

Why this answer

The PowerShell script uses the `New-AzSentinelAutomationRule` cmdlet to create an automation rule in Microsoft Sentinel. The `-TriggerType` parameter is set to `IncidentCreated`, and the `-Action` parameter specifies a playbook to run. The `-TriggeringLogic` parameter filters for incidents with a severity of `Medium`, so the automation rule triggers the playbook only when a medium-severity incident is created.

Exam trap

The trap here is that candidates confuse creating an automation rule with creating a playbook, or assume the script schedules a recurring task because of the 'DailySummaryReport' name, when in fact the script only links an existing playbook to a trigger condition.

How to eliminate wrong answers

Option B is wrong because the script creates an automation rule triggered by incident creation, not a scheduled playbook; there is no recurrence or daily schedule defined. Option C is wrong because the script does not generate any report or schedule a report generation; it only associates a playbook with incident creation. Option D is wrong because the script creates an automation rule, not a playbook; the playbook named 'DailySummaryReport' is referenced as an action, but the script itself does not create the playbook.

Practice this question →

208

MCQmedium

Refer to the exhibit. You are analyzing high severity alerts from Microsoft Defender for Endpoint in Microsoft Sentinel. What does this KQL query do?

A.It counts alerts for a specific alert name

B.It displays detailed properties of each alert

C.It lists high severity Defender for Endpoint alerts, grouped by name and day, ordered by frequency

D.It shows all alerts from Defender for Endpoint in the last week

AnswerC

This option correctly describes the query: it filters SecurityAlert for ProviderName == "Microsoft Defender for Endpoint" and Severity == "High", then performs `summarize Count = count() by AlertName, bin(TimeGenerated, 1d)` to group alerts by name and day. Finally, it orders the results by Count descending, which ranks the alert names by frequency. The output is a summary list, not individual alerts, matching the exact behavior of a KQL aggregation query.

Why this answer

The KQL query uses `summarize` with `count()` to group alerts by `AlertName` and `startofday(TimeGenerated)`, then sorts by `count_` descending. This directly produces a list of high severity Defender for Endpoint alerts grouped by name and day, ordered by frequency, matching option C.

Exam trap

Microsoft often tests the distinction between summarizing aggregated data (counts) versus displaying raw event details, so candidates mistakenly choose 'displays detailed properties' when the query uses `summarize` and `count()`.

How to eliminate wrong answers

Option A is wrong because the query groups by alert name and day, not filtering to a single specific alert name. Option B is wrong because the query uses `summarize` to aggregate counts, not `project` or `extend` to display detailed properties of each alert. Option D is wrong because the query filters for `TimeGenerated > ago(7d)` but also filters by `AlertSeverity == 'High'` and groups results, not showing all alerts from the last week.

Practice this question →

209

MCQeasy

Your organization uses Microsoft Sentinel for security operations. You need to ensure that critical alerts are automatically assigned to the appropriate SOC tier for investigation. What should you configure in Microsoft Sentinel?

A.Create a playbook that assigns the incident to a user

B.Use a watchlist to map alert types to owners

C.Configure an analytics rule to set the owner

D.Create an automation rule that sets the incident owner

AnswerD

Automation rules in Microsoft Sentinel trigger on incident creation and can set the owner field, routing critical alerts to the correct SOC tier. This satisfies the requirement for automatic assignment without manual triage, since analytics rules alone cannot assign owners.

Why this answer

Automation rules in Microsoft Sentinel allow you to automatically assign incidents to specific owners based on conditions like severity or alert type. This ensures critical alerts are routed to the appropriate SOC tier without manual intervention, directly meeting the requirement.

Exam trap

The trap here is that candidates often confuse the capabilities of analytics rules (which generate incidents) with automation rules (which handle post-creation actions like owner assignment), leading them to incorrectly select Option C.

How to eliminate wrong answers

Option A is wrong because a playbook that assigns an incident to a user is an over-engineered solution; automation rules are designed for simple owner assignment without the need for a Logic App. Option B is wrong because watchlists are used for correlating data or enriching alerts, not for assigning incident ownership. Option C is wrong because analytics rules define alert conditions and generate incidents, but they do not have a setting to configure the incident owner; owner assignment is handled post-creation by automation rules or playbooks.

Practice this question →

210

MCQeasy

Your organization uses Microsoft Sentinel to manage security incidents. The security team wants to automatically assign incidents to the appropriate analyst based on the incident’s severity and category. Which feature should you configure?

A.Automation rules

B.Analytics rules

C.Playbooks

D.Watchlists

AnswerA

Automation rules are the native Sentinel capability that can automatically assign incidents to an owner or team based on incident conditions like severity, product name, or entity. When an incident is created or updated, the rule evaluates its criteria and directly sets the 'Owner' field, enabling immediate triage and workload routing without requiring external logic. This is the correct answer because assignment is a first-class automation action, not a side effect of detection or a separate workflow.

Why this answer

Automation rules in Microsoft Sentinel allow you to automatically assign incidents to specific analysts or teams based on conditions such as severity and category. This is the correct feature because it provides a rule-based engine that triggers on incident creation or update, enabling automatic assignment without manual intervention.

Exam trap

The trap here is that candidates often confuse playbooks (which can also assign incidents via Logic Apps) with automation rules, but automation rules are the simpler, native feature for direct assignment without needing to build a custom workflow.

How to eliminate wrong answers

Option B is wrong because analytics rules are used to generate alerts from data sources (e.g., detecting suspicious activity via KQL queries), not to assign incidents to analysts. Option C is wrong because playbooks are automated workflows (often using Azure Logic Apps) that respond to incidents or alerts (e.g., sending emails or blocking IPs), but they are not designed for initial assignment based on severity/category; assignment is a native automation rule action. Option D is wrong because watchlists are collections of data (e.g., known malicious IPs) used for correlation or enrichment in analytics rules, not for incident assignment.

Practice this question →

211

MCQmedium

Your company uses Microsoft Sentinel and has a workspace in the East US region. You need to ingest logs from a non-Azure Windows server located in a branch office in Europe. You have limited bandwidth and need to ensure that log ingestion does not impact network performance. What should you use?

A.Use Microsoft Defender for Endpoint to collect logs from the server and forward them to Sentinel.

B.Install the Log Analytics agent (MMA) on the server and configure it to send logs directly to the workspace.

C.Install the Azure Monitor Agent on the server and create a data collection rule to filter and compress logs before sending.

D.Configure the server to send logs to an Azure Event Hub, then stream to Sentinel.

AnswerC

The Azure Monitor Agent (AMA) is the current, cross-platform agent that supports configurable data collection rules (DCRs) for filtering, transforming, and enriching logs before they leave the server. DCR transformations, written in KQL, can discard unnecessary events, and the AMA uses an optimized protocol with built-in compression to minimize bandwidth usage. This approach directly meets the requirement to reduce the volume of data sent to Sentinel while ensuring only relevant logs are ingested.

Why this answer

The Azure Monitor Agent (AMA) supports data collection rules (DCRs) that can filter logs at the source and compress data before transmission, reducing bandwidth usage. This is critical for the limited bandwidth scenario, and AMA is the modern replacement for the Log Analytics agent, designed for efficient log ingestion across regions.

Exam trap

The trap here is that candidates often assume MMA is still the default for on-premises servers, but Microsoft has deprecated MMA in favor of AMA, and AMA’s DCR-based filtering and compression directly address bandwidth constraints, which MMA cannot do natively.

How to eliminate wrong answers

Option A is wrong because Microsoft Defender for Endpoint collects security telemetry (e.g., alerts, EDR signals) but does not natively forward arbitrary Windows event logs or custom logs to Sentinel; it requires additional configuration and does not address bandwidth optimization. Option B is wrong because the Log Analytics agent (MMA) sends logs without built-in compression or filtering at the source, leading to higher bandwidth consumption, and it is deprecated in favor of AMA. Option D is wrong because sending logs to an Azure Event Hub introduces additional network hops and potential latency, and while Event Hubs can handle high throughput, they do not inherently compress or filter logs to reduce bandwidth impact; this approach is typically used for high-volume streaming, not bandwidth-constrained scenarios.

Practice this question →

212

MCQeasy

You are configuring Microsoft Sentinel to ingest syslog data from a network appliance. After configuring the data connector, you notice that no data is appearing in the CommonSecurityLog table. The syslog server is sending data to the Azure Monitor Agent (AMA) on the log collector. What should you verify first?

A.Check the Heartbeat table for the log collector.

B.Verify that a Data Collection Rule is defined to collect the syslog facilities.

C.Ensure the syslog appliance can reach the collector on UDP port 514.

D.Check the data connector health status in Sentinel.

AnswerB

In Microsoft Sentinel with the Azure Monitor Agent, syslog ingestion is driven entirely by a Data Collection Rule (DCR) that explicitly lists which facilities (e.g., auth, cron, daemon) and severity levels to collect. Without such a DCR, the agent runs but the local syslog daemon has no instructions to forward any events to the Log Analytics workspace. You must verify that the DCR exists, is associated with the target VM, and includes the required facilities; simply enabling the Sentinel data connector will not create the rule automatically.

Why this answer

The Azure Monitor Agent (AMA) requires a Data Collection Rule (DCR) to specify which syslog facilities and severity levels to collect. Without a DCR, the AMA will not forward syslog data to the CommonSecurityLog table, even if the syslog server is sending data to the collector. This is the most common missing configuration step after setting up the data connector.

Exam trap

The trap here is that candidates assume the data connector automatically creates the necessary Data Collection Rule, when in fact the DCR must be manually configured or verified after connector setup.

How to eliminate wrong answers

Option A is wrong because the Heartbeat table shows agent connectivity, not whether syslog data is being collected or forwarded to the correct table; a healthy heartbeat does not guarantee DCR configuration. Option C is wrong because the question states the syslog server is already sending data to the AMA, so network connectivity on UDP 514 is already established. Option D is wrong because the data connector health status in Sentinel checks the connector's overall configuration and permissions, not the specific DCR mapping of syslog facilities to the CommonSecurityLog table.

Practice this question →

213

MCQmedium

Your organization uses Microsoft Defender for Cloud to monitor hybrid workloads. You need to ensure that security alerts from on-premises servers are sent to Microsoft Sentinel. What should you configure?

A.Install a third-party SIEM connector on the servers and forward logs to Sentinel.

B.Deploy Azure Policy on the servers to audit security settings.

C.Connect the on-premises servers to Azure Arc and deploy the Log Analytics agent.

D.Configure a site-to-site VPN to Azure and enable network logging.

AnswerC

Connecting the on-premises servers to Azure Arc creates an Azure resource that supports a consistent management plane and enables you to install the Log Analytics agent (or Azure Monitor Agent) through Azure. The agent collects Windows/Linux security events and sends them to a Log Analytics workspace, which Microsoft Sentinel uses as its data source. This is the native, recommended architecture for migrating on-premises log collection to Sentinel.

Why this answer

Azure Arc enables on-premises servers to be managed as Azure resources, allowing the Log Analytics agent to be deployed and configured to forward security alerts to a Log Analytics workspace integrated with Microsoft Sentinel. This is the standard method for ingesting security events from hybrid workloads into Sentinel without requiring third-party connectors or complex network configurations.

Exam trap

The trap here is that candidates may mistakenly think a VPN or third-party connector is required for on-premises data ingestion, overlooking Azure Arc's ability to bridge on-premises servers into Azure management plane and enable agent-based log collection directly to Sentinel.

How to eliminate wrong answers

Option A is wrong because installing a third-party SIEM connector on the servers is unnecessary and introduces additional complexity; Microsoft Sentinel natively supports the Log Analytics agent for collecting security events from Windows and Linux servers, and third-party connectors are typically used for external SIEMs like Splunk or QRadar, not for direct ingestion into Sentinel. Option B is wrong because Azure Policy is a governance tool for auditing and enforcing compliance rules on Azure resources, not a mechanism for forwarding security alerts to Sentinel; it cannot send log data or alerts to a Log Analytics workspace. Option D is wrong because a site-to-site VPN provides network connectivity but does not forward security alerts or logs to Sentinel; network logging would require additional configuration and does not address the requirement of sending security alerts from on-premises servers to Sentinel.

Practice this question →

214

Multi-Selectmedium

Which TWO actions can you perform using Microsoft Sentinel automation rules? (Select two.)

Select 2 answers

A.Create a task on an incident

B.Run a playbook on an incident

C.Create an incident automatically

D.Create a new automation rule

E.Send an email notification

AnswersA, B

Automation rules in Microsoft Sentinel can add a task to an incident, letting the SOC track required follow-up actions; rules also support assignment, tagging, status changes and running playbooks, but task creation is a native incident action.

Why this answer

Option A is correct because Microsoft Sentinel automation rules support the "Create task" action, which adds a task to an incident for analyst follow-up. Option B is correct because automation rules can trigger a playbook (Logic App) to run against an incident, which is one of their primary purposes. Option C is not correct because incident creation is handled by analytics rules, not automation rules.

Option D is not correct because automation rules cannot create other automation rules. Option E is not correct because sending an email is done by a playbook, not directly by an automation rule action.

Exam trap

The trap here is that candidates often confuse automation rules with playbooks, assuming automation rules can directly send emails or create incidents, when in fact they only orchestrate actions that may be executed by playbooks or other components.

Practice this question →

215

MCQhard

Refer to the exhibit. You have an automation rule defined as shown. The rule is enabled but never triggers. What is the most likely reason?

A.The playbook resource ID is incomplete.

B.The condition requires incident status 'Active', but incidents start as 'New'.

C.The trigger type should be 'AlertCreated' instead of 'IncidentCreated'.

D.The rule order is set to 1, which is too low.

AnswerB

When Microsoft Sentinel creates an incident, its Status property is always set to 'New' by default, regardless of the severity or entity classification. The automation rule's condition requires Status to equal 'Active', which is a later state an incident enters only after manual triage or another automation rule changes it. Because the trigger fires at incident creation—before any status transition—the condition evaluates to false and the rule does not execute. This is the definitive cause of the problem.

Why this answer

The automation rule triggers on incident creation, but the condition requires the incident status to be 'Active'. In Microsoft Sentinel, incidents are created with a status of 'New', not 'Active'. Therefore, the condition is never met, and the rule never triggers.

To fix this, the condition should either be removed or changed to include 'New' status.

Exam trap

Microsoft often tests the subtle difference between incident status values ('New' vs 'Active') and the fact that incidents are created as 'New', not 'Active', causing candidates to overlook the condition mismatch.

How to eliminate wrong answers

Option A is wrong because the playbook resource ID is used to identify the playbook to run, and an incomplete ID would cause a different error (e.g., playbook not found), not prevent the rule from triggering entirely. Option C is wrong because the trigger type 'IncidentCreated' is correct for an automation rule that runs when an incident is created; 'AlertCreated' would be used for alert-based automation, not incident-based. Option D is wrong because the rule order (priority) determines the sequence of rule execution but does not prevent a rule from triggering; a low order number simply means it runs earlier among enabled rules.

Practice this question →

216

MCQmedium

Your security team uses Microsoft Defender XDR. You need to ensure that a user who is suspected of credential theft is immediately blocked from accessing corporate email and cloud apps, while the investigation continues. What should you do?

A.Create a conditional access policy in Microsoft Entra ID to block the user

B.Use Microsoft Defender for Cloud Apps to suspend the user

C.Disable the user account in Microsoft Entra ID

D.Reset the user's password from Microsoft Entra ID

AnswerB

Suspending the user in Microsoft Defender for Cloud Apps is the correct immediate response because it sends a governance action through the connected app connectors to invalidate the user’s active sessions and tokens for all connected cloud apps. This terminates ongoing access in near-real time, making it effective for containing an active compromise rather than waiting for sign-in-time controls to take effect.

Why this answer

Suspending the user in Microsoft Defender for Cloud Apps immediately revokes the user's access tokens and active sessions for cloud apps, blocking further access to corporate email and cloud apps without deleting the account. This allows the investigation to continue while the user is isolated, which is the precise requirement for a suspected credential theft scenario.

Exam trap

The trap here is that candidates often confuse 'blocking access' with 'disabling the account' or 'resetting the password,' not realizing that immediate token revocation via Defender for Cloud Apps is the only option that stops active sessions without disrupting the user's directory object.

How to eliminate wrong answers

Option A is wrong because creating a conditional access policy in Microsoft Entra ID requires time to propagate and may not immediately revoke existing sessions; it also does not suspend the user's tokens for already-authenticated sessions. Option C is wrong because disabling the user account in Microsoft Entra ID removes the user from all directory services and can break dependencies like group memberships or licensing, and it does not specifically target cloud app access while preserving the account for investigation. Option D is wrong because resetting the user's password does not invalidate existing active sessions or tokens issued before the reset, so the user could still access email and cloud apps until those tokens expire.

Practice this question →

217

Multi-Selectmedium

You are managing Microsoft Defender for Endpoint. Which TWO actions can be taken directly from the Microsoft 365 Defender portal to respond to a compromised device?

Select 2 answers

A.Run a full antivirus scan on the device.

B.Block the user's sign-in from Microsoft Entra ID.

C.Remotely wipe the device.

D.Isolate the device from the network.

E.Reset the device's local administrator password.

AnswersA, D

Running a full antivirus scan is a supported response action in Microsoft Defender for Endpoint. It invokes Microsoft Defender Antivirus to scan the entire device for malware, including persistent threats that may survive a quick scan, and automatically remediates detected threats. This action is initiated from the device's page in the Microsoft 365 Defender portal.

Why this answer

The Microsoft 365 Defender portal allows security operators to initiate a full antivirus scan on a compromised device directly from the device's action menu. This leverages Microsoft Defender Antivirus to detect and remediate threats without requiring local user interaction, providing an immediate response capability within the unified security operations interface.

Exam trap

The trap here is that candidates confuse identity-based remediation (like blocking sign-in) with endpoint-based remediation, assuming all security actions are available from the same portal, when in fact Microsoft 365 Defender focuses on device-level responses while identity actions remain in Microsoft Entra ID.

Practice this question →

218

MCQhard

You are managing a Microsoft Sentinel workspace that ingests data from Microsoft 365 Defender. You notice that some incident creation rules are not generating incidents as expected. What should you check first?

A.The Microsoft 365 Defender data connector

B.The workspace daily usage cap

C.The SecurityIncident table schema

D.The analytics rule status

AnswerA

The Microsoft 365 Defender data connector is the ingestion pipeline that pulls incidents generated within M365 Defender into Sentinel's SecurityIncident table. When this connector is disabled or misconfigured, incident records never reach the workspace, even if analytics rules are enabled and querying correctly. Therefore, this is the first thing to verify because without successful connector synchronization, no incidents can appear.

Why this answer

The Microsoft 365 Defender data connector is the correct first check because it is the ingestion pipeline for security alerts from Microsoft 365 Defender into Microsoft Sentinel. If this connector is misconfigured, disconnected, or has stopped syncing, incident creation rules that depend on these alerts will not trigger, even if the analytics rules themselves are enabled and correctly configured.

Exam trap

The trap here is that candidates often jump to checking analytics rule status first, assuming the rule is disabled or misconfigured, but the real issue is that the data connector—the upstream dependency—is broken, preventing the rule from ever receiving the alerts it needs to evaluate.

How to eliminate wrong answers

Option B is wrong because the workspace daily usage cap affects data ingestion costs and can stop data ingestion if exceeded, but it would impact all data types, not just incident creation rules from Microsoft 365 Defender; moreover, Sentinel incident creation rules are based on analytics rule logic, not directly on ingestion volume. Option C is wrong because the SecurityIncident table schema is a fixed schema in Log Analytics that stores incidents after they are created; checking the schema would not reveal why incidents are not being generated, as schema changes are rare and would cause errors, not silent failures. Option D is wrong because while analytics rule status (enabled/disabled) is relevant, the question states that incident creation rules are not generating incidents as expected, implying they are enabled; the root cause is more likely a data connector issue that prevents the required alerts from being ingested.

Practice this question →

219

MCQhard

Your organization uses Microsoft Defender XDR for threat detection and response. The security team wants to automatically isolate a compromised device when a specific malware alert is triggered, but only if the device is not a critical server. What is the most efficient way to achieve this?

A.Use advanced hunting to find devices and then manually isolate

B.Use PowerShell scripts in a playbook

C.Configure an automation rule in Microsoft Defender XDR

D.Create a custom detection rule

AnswerC

Configuring an automation rule in Microsoft Defender XDR is the correct approach because automation rules are native, event-driven response engines that evaluate criteria such as alert title, severity, device group, and incident tags, then automatically perform actions like isolating a device or running an antivirus scan. They are managed centrally, support order of execution for multiple rules, and do not require external services or scripting. This enables an immediate, policy-based containment action precisely when a qualifying alert fires, which is directly aligned with the requirement for automated device isolation.

Why this answer

Automation rules in Microsoft Defender XDR allow you to define conditions (e.g., malware alert triggered) and actions (e.g., isolate device) with scoping filters (e.g., exclude devices tagged as 'critical server'). This provides a no-code, built-in mechanism that runs automatically without manual intervention or external scripting, making it the most efficient approach for conditional automated response.

Exam trap

The trap here is that candidates often confuse automation rules (native to Defender XDR) with playbooks (which require external orchestration like Logic Apps), leading them to choose PowerShell or custom detection rules instead of the simpler built-in automation rule.

How to eliminate wrong answers

Option A is wrong because advanced hunting is a query-based tool for threat investigation, not an automated response mechanism; manually isolating devices after hunting defeats the goal of automatic isolation. Option B is wrong because PowerShell scripts in a playbook require additional infrastructure (e.g., Azure Logic Apps or Microsoft Sentinel) and introduce unnecessary complexity and latency compared to the native automation rule in Defender XDR. Option D is wrong because custom detection rules are used to create custom alerts based on advanced hunting queries, not to define automated response actions like device isolation; they lack the built-in action and scoping capabilities of automation rules.

Practice this question →

220

MCQhard

You are reviewing an analytics rule configuration in Microsoft Sentinel using ARM template JSON. The rule is enabled and incident creation is set to true. However, when alerts are generated, they are not being grouped into a single incident. What is the most likely reason?

A.The lookbackDuration is set to 5 hours which is too short.

B.The groupingConfiguration is disabled.

C.The matchingMethod is set to 'AllEntities' which is not supported.

D.The rule is not enabled properly.

AnswerB

With groupingConfiguration disabled, every alert that the rule generates is immediately converted into its own individual incident. This is exactly why you are seeing separate incidents despite alerts sharing common entities or firing within the same time window. To combine related alerts, grouping must be enabled and configured with a matching method and appropriate lookbackDuration.

Why this answer

The groupingConfiguration in Microsoft Sentinel analytics rules controls whether alerts are grouped into a single incident. When this configuration is disabled, each alert generates its own separate incident, even if the rule is enabled and incident creation is set to true. Therefore, the most likely reason alerts are not being grouped is that the groupingConfiguration is disabled.

Exam trap

The trap here is that candidates often focus on the lookbackDuration or matchingMethod as the cause of grouping failure, overlooking that the groupingConfiguration must be explicitly enabled for any grouping to occur.

How to eliminate wrong answers

Option A is wrong because a short lookbackDuration (e.g., 5 hours) limits the time window for grouping alerts, but it does not prevent grouping entirely; alerts within that window can still be grouped if grouping is enabled. Option C is wrong because 'AllEntities' is a valid matchingMethod in Sentinel's grouping configuration; it matches alerts based on all entity types and is fully supported. Option D is wrong because the rule is explicitly stated to be enabled and incident creation is set to true, so the rule is properly enabled; the issue lies specifically with the grouping configuration.

Practice this question →

221

MCQhard

Your organization uses Microsoft Defender for Endpoint and has enabled the 'Block at First Sight' feature. You notice that some legitimate executables are being blocked incorrectly. You need to temporarily allow these files while you submit them for analysis. What should you do?

A.Create an indicator of compromise (IoC) in Microsoft Defender for Endpoint to allow the file hash.

B.Add an application control policy in Microsoft Intune to allow the files.

C.Submit the files to Microsoft for analysis and wait for the verdict.

D.Disable the 'Block at First Sight' feature until the files are analyzed.

AnswerA

Creating an allow indicator of compromise (IoC) for the file hash in Microsoft Defender for Endpoint is the supported, targeted way to override an automatic block. This action adds an entry to the threat intelligence that the Microsoft Defender for Endpoint sensor enforces; an allow verdict takes precedence over block verdicts for that specific SHA-256 hash, including blocks from the cloud protection service. It applies immediately and leaves protection intact for all other files.

Why this answer

Creating an allow indicator (IoC) in Microsoft Defender for Endpoint explicitly overrides the cloud-based 'Block at First Sight' verdict for a specific file hash. This allows the legitimate executable to run while you submit it for analysis, without disabling the broader protection feature. The allow indicator takes precedence over automated blocking actions, providing a temporary, targeted exemption.

Exam trap

The trap here is that candidates may think disabling the feature entirely (Option D) is a quick fix, but the exam tests the understanding that targeted allow indicators are the correct, least-privilege approach to handle false positives without compromising overall security posture.

How to eliminate wrong answers

Option B is wrong because application control policies in Microsoft Intune (e.g., Windows Defender Application Control) enforce execution rules based on code integrity policies, not file hash overrides for cloud-delivered protection; they cannot bypass the 'Block at First Sight' verdict. Option C is wrong because waiting for Microsoft's analysis without taking immediate action leaves the legitimate executables blocked, disrupting operations; the question explicitly asks for a temporary allow while submitting. Option D is wrong because disabling 'Block at First Sight' removes protection against all unknown files, not just the specific ones, creating a broad security gap; the goal is to allow only the known legitimate files.

Practice this question →

222

MCQmedium

Refer to the exhibit. You are reviewing an Azure Resource Manager (ARM) template for a Microsoft Sentinel analytics rule. Based on the exhibit, which statement is true?

A.The rule will create one incident per alert and group alerts by entity.

B.The rule will only trigger if more than 5 users have MFA disabled.

C.The rule runs every hour and looks back 5 hours.

D.The rule will generate one alert per user that has MFA disabled.

AnswerD

This is correct because the analytics rule is configured with 'Alert Per Result,' which instructs Microsoft Sentinel to create an independent alert for every row returned by the query. The query returns one row for each user who has MFA disabled, so each of those users triggers a separate alert. No incident grouping is applied, so each of these alerts is also converted into its own incident.

Why this answer

The ARM template configures a Microsoft Sentinel scheduled analytics rule that runs every hour, queries for users with MFA disabled, and uses the 'Alert Per Result' event grouping setting. This setting generates a separate alert for each unique result returned by the query, meaning each user who has MFA disabled triggers its own alert.

Exam trap

The trap here is that candidates confuse the 'frequency' and 'period' values (both PT5H) with a common 1-hour interval, or misinterpret 'AlertPerResult' as grouping alerts into incidents, when in fact it creates one alert per query result row.

How to eliminate wrong answers

Option A is wrong because the rule uses 'Alert Per Result' event grouping, not 'Group alerts into a single incident per alert'—the setting creates one alert per result, not one incident per alert with entity grouping. Option B is wrong because the query does not include any aggregation or threshold condition like 'count > 5'; it simply lists users with MFA disabled, so the rule triggers for any number of results. Option C is wrong because the rule runs every 5 hours (frequency: PT5H) and looks back 5 hours (period: PT5H), not every hour.

Practice this question →

223

MCQmedium

You are responsible for Microsoft Defender for Identity. The security team reports that some high-confidence alerts are not triggering any automated response. You need to automate the response for these alerts. What should you configure?

A.Use Microsoft Intune to trigger a script on domain controllers when an alert fires.

B.Create an automation rule in Microsoft Sentinel to respond to Identity alerts.

C.In Microsoft Defender XDR, configure automated investigation and response for Identity alerts.

D.Configure Microsoft Purview compliance policies to respond to Identity alerts.

AnswerC

Defender XDR provides automated investigation and response (AIR) for identity alerts generated by Defender for Identity. This feature automatically investigates suspicious identity activity, such as compromised account usage or lateral movement, and can contain or remediate threats by disabling accounts, resetting passwords, or blocking sign-ins. Enabling AIR for identity alerts in the Defender XDR portal ensures that alerts are handled through the security incident lifecycle rather than requiring separate device management or compliance tooling.

Why this answer

Microsoft Defender for Identity alerts are natively integrated into Microsoft Defender XDR (formerly Microsoft 365 Defender), which provides automated investigation and response (AIR) capabilities. By configuring AIR for Identity alerts in Defender XDR, you can automatically trigger remediation actions such as suspending compromised accounts or blocking suspicious activities without additional scripting or third-party tools.

Exam trap

The trap here is that candidates may confuse Microsoft Sentinel (a SIEM/SOAR) with the native automated investigation and response capabilities within Microsoft Defender XDR, assuming that any automation must go through Sentinel, when in fact Defender XDR provides built-in AIR for its own alerts including Identity alerts.

How to eliminate wrong answers

Option A is wrong because Microsoft Intune is a mobile device management (MDM) and mobile application management (MAM) service, not designed to trigger scripts on domain controllers in response to security alerts; it manages endpoints, not on-premises Active Directory infrastructure. Option B is wrong because Microsoft Sentinel is a SIEM/SOAR platform that can ingest alerts from various sources, but it is not the native automation mechanism for Defender for Identity alerts; the correct native automation is within Defender XDR. Option D is wrong because Microsoft Purview compliance policies focus on data governance, eDiscovery, and compliance (e.g., retention labels, DLP), not on automated response to identity-based security alerts.

Practice this question →

224

MCQeasy

Your organization uses Microsoft Sentinel with a Log Analytics workspace in the East US region. You need to ensure that incident investigation data is retained for two years for compliance. What should you configure?

A.Adjust the Interactive retention period to 730 days in the Log Analytics workspace.

B.Configure a data retention policy in Microsoft Purview.

C.Set the Total retention period to 730 days and enable Archive.

D.Enable Basic Logs and set retention to 730 days.

AnswerA

To meet a 730-day retention requirement, adjust the Interactive retention period in the Log Analytics workspace to 730 days. The Interactive tier is the default hot storage used by Microsoft Sentinel for running KQL queries, analytics rules, and investigations. Log Analytics lets you set interactive retention to up to 730 days (2 years) without moving data into the Archive tier. Merely setting total retention would not guarantee that data stays in the fully queryable, interactive state for the entire 730-day period.

Why this answer

Log Analytics workspaces allow you to configure the Interactive retention period independently from the Total retention period. Setting Interactive retention to 730 days ensures that incident investigation data remains available for interactive queries for the full two-year compliance requirement, without needing to enable archive or change log types.

Exam trap

The trap here is that candidates often confuse the Interactive retention period with the Total retention period, assuming that setting Total retention to 730 days automatically keeps data interactively available, when in fact only the Interactive retention period controls that access, and archive data requires a search job to query.

How to eliminate wrong answers

Option B is wrong because Microsoft Purview manages data governance, compliance, and sensitivity labels, not the retention of operational data in a Log Analytics workspace used by Microsoft Sentinel. Option C is wrong because setting the Total retention period to 730 days and enabling Archive would move data to the archive tier after the interactive period (default 30 days), making it inaccessible for interactive queries and requiring a search job to retrieve, which does not meet the requirement for incident investigation data to be retained for two years in an accessible state. Option D is wrong because Basic Logs are designed for verbose, low-volume logs with reduced query capabilities and a maximum retention of 30 days; setting retention to 730 days is not supported for Basic Logs.

Practice this question →

225

MCQmedium

You are a security operations analyst at a company that uses Microsoft Sentinel. You need to create an automation rule that automatically closes incidents with a severity of Informational and a status of New after 24 hours, but only if they do not contain any entities. Which three conditions must you configure in the automation rule?

A.Severity equals Low, Status equals New, and Entities count equals 0.

B.Severity equals Informational, Status equals New, and Entities count equals 0.

C.Severity equals Informational, Status equals New, and Entities count greater than 0.

D.Severity equals Informational, Status equals Active, and Entities count equals 0.

AnswerB

This option correctly identifies the three conditions required: severity equal to Informational, status equal to New, and no entities present. These conditions ensure that only low-priority incidents without entities are automatically closed after the specified time, aligning with the scenario's requirement to reduce noise from such incidents.

Why this answer

The automation rule must target incidents that are Informational severity, have a status of New, and contain no entities. These conditions ensure that only low-risk, unassigned incidents without any associated entities are automatically closed after 24 hours, reducing analyst workload. The other combinations either target incorrect severity, status, or entity presence, failing to meet the scenario's requirements.

Exam trap

The trap here is confusing incident status values or severity levels, such as using Active instead of New or Low instead of Informational, which would misdirect the automation rule.

Practice this question →