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

MCQmedium

You are configuring Microsoft Sentinel automation rules to handle incidents generated from Microsoft Defender for Cloud. You need to ensure that when a high-severity security alert is triggered, an automated response runs a playbook that creates a support ticket in ServiceNow. However, the playbook fails to execute for some alerts. Upon investigation, you find that the automation rule is triggered only when the incident is created. What is the most likely cause of the failure?

A.The automation rule is configured to trigger only on incident creation, but the playbook requires the incident to be in an updated state.

B.The automation rule lacks permissions to the ServiceNow connector because of Microsoft Entra ID conditional access policies.

C.Playbooks cannot be called by automation rules in Microsoft Sentinel.

D.Automation rules cannot be triggered on incident creation from Microsoft Defender for Cloud.

AnswerA

The automation rule's trigger is the likely culprit. In Microsoft Sentinel, automation rules can be configured to run when an incident is created, when an incident is updated, or when an alert is generated. If your rule runs only at creation time, the playbook executes immediately after the incident is born, before any status changes, owner assignments, or alert grouping that would normally follow. Many playbooks—especially those using the Sentinel incident connector's 'Get incident' action—expect the incident to have these post-creation values, and without them the playbook may error out or take an incorrect action. To resolve this, you should create a second automation rule triggered on incident update, or change the trigger to match the playbook's dependency.

Why this answer

The automation rule is configured to trigger only on incident creation. However, the playbook requires the incident to be in an updated state to execute, meaning the automation rule does not fire when the incident is updated after creation. This mismatch causes the playbook to fail for alerts that require an update trigger.

Exam trap

The trap here is that candidates assume all playbooks can run on incident creation, but many playbooks require the incident to be updated first to access complete data, and the automation rule must be configured with the correct trigger condition.

How to eliminate wrong answers

Option B is wrong because conditional access policies in Microsoft Entra ID affect user authentication, not the service-to-service permissions used by automation rules and playbooks; the issue is about trigger timing, not permissions. Option C is wrong because playbooks can indeed be called by automation rules in Microsoft Sentinel; this is a core feature. Option D is wrong because automation rules can be triggered on incident creation from Microsoft Defender for Cloud; the problem is that the rule is not configured to trigger on updates.

Practice this question →

MCQhard

Refer to the exhibit. You are troubleshooting an endpoint that is not receiving real-time protection from Microsoft Defender Antivirus. The output shows RealTimeProtectionEnabled is False. Which command should you run next to enable real-time protection?

A.Set-MpPreference -DisableRealtimeMonitoring $false

B.Add-MpPreference -ExclusionPath C:\Temp

C.Start-MpScan

D.Update-MpSignature

AnswerA

Set-MpPreference -DisableRealtimeMonitoring $false is the correct command because it explicitly sets the DisableRealtimeMonitoring configuration to false, which re-enables Microsoft Defender's real-time scanning engine. This preference is the direct control for the monitoring state, and applying it reverses any setting that previously disabled the service. It is the only option that addresses the root cause of a disabled real-time protection rather than performing an unrelated action.

Why this answer

The Set-MpPreference cmdlet with the -DisableRealtimeMonitoring $false parameter is the correct command to enable real-time protection in Microsoft Defender Antivirus. The output shows RealTimeProtectionEnabled is False, which directly corresponds to the DisableRealtimeMonitoring setting; setting it to $false re-enables the feature. This cmdlet modifies the local policy for the Microsoft Defender Antivirus engine, immediately activating real-time scanning of file operations and process activity.

Exam trap

The trap here is that candidates often confuse disabling real-time monitoring with other maintenance tasks like scanning or updating signatures, assuming any Defender-related command will fix the protection state, but only Set-MpPreference directly controls the RealTimeProtectionEnabled flag.

How to eliminate wrong answers

Option B is wrong because Add-MpPreference -ExclusionPath C:\Temp adds a file or folder exclusion from scanning, which does not affect the RealTimeProtectionEnabled state; it only prevents Defender from scanning the specified path. Option C is wrong because Start-MpScan initiates a one-time on-demand scan (e.g., quick, full, or custom scan) but does not toggle the real-time protection setting; it runs a scan regardless of whether real-time monitoring is enabled. Option D is wrong because Update-MpSignature downloads and installs the latest security intelligence updates (virus definitions) but has no impact on the RealTimeProtectionEnabled flag; it updates signatures without enabling or disabling real-time protection.

Practice this question →

Multi-Selecteasy

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

Select 2 answers

A.Send an email notification without a playbook.

B.Assign an incident to an analyst.

C.Delete an incident.

D.Change the severity of an incident.

E.Create a new analytics rule.

AnswersB, D

Automation rules support the "Assign owner" action, which lets you set the incident's owner to a specific analyst, a group, or a user by email address. This action can be triggered when an incident is created or updated based on conditions such as severity or analytics rule, thereby enabling systematic incident triage and routing directly from the rule.

Why this answer

Automation rules in Microsoft Sentinel can directly assign incidents to specific analysts or groups without requiring a playbook. This is a native action within the automation rule configuration, enabling immediate ownership and accountability for incident response.

Exam trap

The trap here is that candidates often confuse automation rule capabilities with playbook actions, assuming email notifications or deletions are possible natively, but Microsoft Sentinel restricts automation rules to incident property changes and playbook triggers only.

Practice this question →

Multi-Selecthard

Which TWO actions should you take to ensure that Microsoft Sentinel can properly ingest logs from a Linux server running rsyslog? (Choose two.)

Select 2 answers

A.Install and configure syslog-ng instead of rsyslog

B.Configure rsyslog to forward logs to the agent on TCP 514

C.Install the Log Analytics agent (or Azure Monitor Agent) on the Linux server

D.Configure Windows Event Forwarding (WEF) to collect logs from the Linux server

E.Configure rsyslog to forward logs to the Log Analytics agent on UDP 25224

AnswersC, E

The Log Analytics agent (or Azure Monitor Agent) must be installed on the Linux server before any syslog collection can occur. The agent acts as the local collector: it listens on UDP 25224 for syslog messages forwarded by the rsyslog daemon, applies filtering rules for facilities and severities, and then sends the parsed events to the Log Analytics workspace. Without the agent, there is no component to receive and ingest the syslog stream, regardless of rsyslog configuration.

Why this answer

The Log Analytics agent (or Azure Monitor Agent) must be installed on the Linux server to receive and forward syslog data to Microsoft Sentinel. Without the agent, Sentinel has no direct mechanism to collect logs from the server. The agent listens for syslog messages forwarded by rsyslog and then sends them to the Log Analytics workspace.

Exam trap

The trap here is that candidates often assume syslog must be sent on the standard port 514 (TCP or UDP) or that replacing rsyslog with syslog-ng is necessary, but the Log Analytics agent specifically requires forwarding to UDP 25224 and works with rsyslog out of the box.

Practice this question →

Multi-Selecthard

Which THREE components are required to ingest Microsoft Entra ID (Azure AD) audit logs into Microsoft Sentinel?

Select 3 answers

A.A Log Analytics workspace in the same region as Microsoft Entra ID.

B.A user account with Security Administrator or Global Administrator role to configure the connector.

C.A playbook to parse the audit logs.

D.Microsoft Sentinel's Microsoft Entra ID data connector.

E.Microsoft Entra ID P1 or P2 license.

AnswersB, D, E

Configuring the Microsoft Sentinel Entra ID connector requires interactive authentication with a user who holds the Security Administrator or Global Administrator role. This role is necessary to grant the connector consent to access Microsoft Graph APIs for reading directory audit and sign-in logs, and to create the required diagnostic settings. Without this privilege, the connector cannot be enabled even if the workspace and licenses are in place.

Why this answer

Configuring the Microsoft Entra ID (Azure AD) data connector in Microsoft Sentinel requires a user account with at least the Security Administrator role (or Global Administrator) to grant the necessary permissions for the connector to read audit logs and sign-in logs from Microsoft Entra ID via the Microsoft Graph API. Without this role, the connector cannot authenticate and retrieve the required data.

Exam trap

The trap here is that candidates often assume a Log Analytics workspace must be regionally aligned with the data source, but Microsoft Entra ID is a global service and the workspace region is irrelevant for ingestion.

Practice this question →

MCQhard

You are analyzing sign-in logs in Microsoft Sentinel. The KQL query shown in the exhibit returns a list of users who have signed into Office 365 Exchange Online more than 10 times in the last 24 hours. You need to identify potential brute-force attacks. What additional information should you add to the query to improve detection?

A.Include both successful and failed sign-in attempts, then filter for users with a high number of failed attempts and at least one successful attempt.

B.Change the time window to 1 hour to detect rapid attempts.

C.Add a condition to only include sign-ins from unusual geographic locations.

D.Add a condition to exclude users who have multi-factor authentication (MFA) enabled.

AnswerA

Brute-force detection requires correlating failures with eventual success, not just counting successful sign-ins. Including failed attempts and filtering for users with many failures plus at least one success exposes password-guessing that succeeded, which the current success-only query misses entirely.

Why this answer

To detect brute-force attacks, you need to look for multiple failed sign-in attempts followed by a success. The current query only shows successful sign-ins. Option A is correct because adding a condition to include failed attempts (ResultType != 0) and then filtering for users with many failures and at least one success would better indicate brute-force.

Option B (changing the time window to 1 hour) may help detect rapid attempts but does not consider the success pattern. Option C (filtering by unusual geographic locations) may reduce false positives but does not directly detect brute-force. Option D (excluding users with MFA) is not relevant because MFA reduces risk but does not prevent brute-force detection.

Practice this question →

Multi-Selectmedium

Which TWO actions require the Global Administrator role in Microsoft 365?

Select 2 answers

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

B.Create a custom role in Microsoft Defender XDR

C.View the Microsoft 365 Defender incident queue

D.Configure tenant-wide settings in Microsoft 365

E.Manage roles and administrators in Microsoft Entra ID

AnswersD, E

Configuring tenant-wide settings in Microsoft 365 requires the Global Administrator role because these settings affect the entire organization, such as organizational profile, privacy preferences, and integration options. Only Global Administrators have the necessary authorization to modify settings that apply to all users and services across the tenant, ensuring central control and compliance with organizational governance.

Why this answer

Configuring tenant-wide settings in Microsoft 365 requires the Global Administrator role because these settings affect the entire organization, including security, compliance, and user management. Only the Global Administrator has the broadest permissions to modify such high-level configurations, as defined by Microsoft's role-based access control (RBAC) model.

Exam trap

The trap here is that candidates often confuse 'tenant-wide settings' with workload-specific configurations, assuming that any security or compliance task requires Global Administrator, when in fact Microsoft has delegated many such tasks to specialized roles like Security Administrator or Compliance Administrator.

Practice this question →

MCQeasy

You are configuring Microsoft Sentinel to detect potential ransomware activity. The security team wants to be alerted when a single host contacts multiple suspicious domains within a short time. Which analytic rule type should you create?

A.NRT (Near-Real-Time) rule

B.Scheduled query rule

C.Anomaly rule

D.Microsoft security rule

AnswerA

A Near-Real-Time (NRT) rule in Microsoft Sentinel evaluates the triggering query every minute with a maximum lookback of 30 minutes, using streaming analytics to preserve event ordering and timing. This enables you to catch rapid sequences of events—such as multiple failed logons immediately followed by a successful authentication—that would be missed by periodic batch processing. NRT rules are specifically engineered for low-latency, time-sensitive detections while still allowing KQL logic to match the exact pattern.

Why this answer

A NRT (Near-Real-Time) rule is the correct choice because it continuously processes events with a minimum latency of about 1 minute, making it ideal for detecting patterns like a single host contacting multiple suspicious domains within a short time window. Unlike scheduled rules that run on a fixed interval (e.g., every 5 minutes), NRT rules evaluate data as it arrives, enabling rapid detection of multi-event sequences such as DNS queries to known malicious domains.

Exam trap

The trap here is that candidates often confuse NRT rules with scheduled query rules, assuming a scheduled rule can achieve the same low latency by setting a short interval, but scheduled rules still incur a processing delay and cannot match the continuous streaming evaluation of NRT rules.

How to eliminate wrong answers

Option B (Scheduled query rule) is wrong because it runs on a predefined schedule (e.g., every 5 or 15 minutes), which introduces latency that could miss the tight time window required for detecting rapid multi-domain contacts. Option C (Anomaly rule) is wrong because it uses machine learning to baseline normal behavior and flag statistical outliers, not to match a specific pattern of a single host contacting multiple known suspicious domains. Option D (Microsoft security rule) is wrong because it ingests alerts from other Microsoft security products (e.g., Microsoft Defender for Endpoint) and does not allow custom detection logic based on raw event sequences like DNS queries.

Practice this question →

MCQhard

Refer to the exhibit. You run the KQL query in Microsoft Sentinel to identify analysts with high incident assignments. The query returns no results, but you know incidents exist. What is the most likely reason?

A.The summarize operator is incorrectly used

B.The SecurityIncident table does not exist

C.The query period is too short to capture incidents

D.Incidents are not assigned to any owner, so the Owner field is null

AnswerD

In Sentinel, the Owner field is nullable, and incidents that have not yet been assigned to an analyst or group will contain a null value rather than an empty string. When you summarize by Owner, null values are grouped into a single bucket, but KQL does not consider a null value equal to null with the equality operator (==); it requires the isnull() function to test for absence. The query likely filters with something like where Owner == null, which evaluates to false for all rows and omits the exact incidents the user intended to count, resulting in zero incidents being returned.

Why this answer

If incidents have no assigned owner, the Owner field is null. The KQL query likely filters or groups by Owner, and null values are excluded from results by default in aggregation operations like summarize. Since incidents exist but are unassigned, the query returns no results.

Exam trap

Microsoft often tests the nuance that KQL aggregation operators like summarize exclude null group-by keys by default, leading candidates to overlook the data quality issue and instead blame syntax or table existence.

How to eliminate wrong answers

Option A is wrong because the summarize operator is correctly used for grouping by owner; the issue is not syntax but data content. Option B is wrong because the SecurityIncident table does exist in Microsoft Sentinel; it is a standard table for incident data. Option C is wrong because the query period is not specified as too short; the problem is that incidents exist but lack owner assignments, not that they fall outside the time range.

Practice this question →

MCQhard

You are designing a Microsoft Sentinel deployment. You need to minimize ingestion costs while ensuring that all security-relevant events are collected. Which strategy should you use?

A.Use Analytic Logs for all data sources to ensure full query capabilities

B.Use Basic Logs for verbose data sources like Windows firewall logs, and Analytic Logs for high-value security logs

C.Set short retention periods for all logs and export to storage

D.Collect only logs from Microsoft 365 Defender and ignore other sources

AnswerB

Basic Logs cost less per gigabyte but support only limited querying, so routing verbose, low-value sources such as firewall logs there cuts spend. Analytic Logs retain full KQL and analytics-rule support for high-value security events, meeting both cost and detection requirements.

Why this answer

Microsoft Sentinel offers two log plan tiers: Analytic Logs (full KQL, alerts, workbooks) and Basic Logs (cheaper ingestion, limited query, 30-day retention). Placing high-volume, low-value sources like Windows firewall logs in Basic Logs and reserving Analytic Logs for high-value security events minimizes cost while still collecting all relevant data. This is the documented cost-optimization pattern.

Exam trap

SC-200 often tests the assumption that all logs must be Analytic for full security coverage — candidates miss that Basic Logs still collect data and can be queried, just with limitations, making them ideal for verbose sources.

How to eliminate wrong answers

Option A is wrong because putting everything in Analytic Logs maximizes ingestion and retention cost, defeating the goal of minimizing spend. Option C is wrong because short retention plus export to storage does not reduce ingestion cost and removes the ability to query recent data in Sentinel. Option D is wrong because ignoring non-M365 sources creates visibility gaps and violates the requirement to collect all security-relevant events.

Practice this question →

Multi-Selecteasy

Which TWO Microsoft 365 security solutions include capabilities for managing security incidents?

Select 2 answers

A.Microsoft Intune

B.Microsoft Defender XDR

C.Microsoft Entra ID Protection

D.Microsoft Purview

E.Microsoft Sentinel

AnswersB, E

Microsoft Defender XDR includes a unified incident queue and automated investigation and response, letting security teams manage and remediate incidents across endpoints, identities, email and cloud apps. This built-in incident management capability satisfies the requirement for a Microsoft 365 security solution that manages security incidents.

Why this answer

Microsoft Defender XDR (B) is correct because it natively correlates alerts across endpoints, identities, email, and cloud apps into unified incidents, providing incident management through the Microsoft Defender portal with investigation, automated response, and remediation capabilities. Microsoft Sentinel (E) is correct because it is a cloud-native SIEM/SOAR solution that creates incidents from analytics rules and offers full incident management, including triage, investigation graphs, automation rules, and playbooks. Microsoft Intune (A) is a device and application management (MDM/MAM) service and does not provide security incident management.

Microsoft Entra ID Protection (C) detects identity-based risks and generates risk detections and risky user/sign-in reports, but it is not an incident management solution. Microsoft Purview (D) focuses on data governance, compliance, and information protection (e.g., DLP, eDiscovery), not on managing security incidents.

Practice this question →

MCQeasy

Your organization uses Microsoft Sentinel. An analyst reports that a scheduled analytics rule is not firing. You verify that the rule is enabled and the query returns results when run manually. What is the most likely cause?

A.The alert threshold is set too high

B.The data connector is disconnected

C.The workspace is in a different region

D.The query uses unsupported KQL functions

AnswerA

An alert rule's threshold is set in the 'Alert threshold' field under query scheduling. This defines the minimum number of query results that must be returned for a single run to generate an alert. If, for example, the threshold is 50 and the underlying query currently returns only 20 matching events, the rule will evaluate to 'low' instead of firing and no alert will be created. This can be verified by manually running the rule's query in Log Analytics—if results are present but below the threshold, the misconfiguration is exactly this.

Why this answer

The most likely cause is that the alert threshold is set too high. Even though the query returns results when run manually, the rule's threshold condition (e.g., 'Number of results greater than X') may not be met by the volume of results returned during each scheduled run. If the threshold is higher than the typical result count, the rule will not trigger an alert despite the query being valid.

Exam trap

The trap here is that candidates assume a working query automatically means the rule will fire, overlooking the threshold condition that must be met for alert generation.

How to eliminate wrong answers

Option B is wrong because a disconnected data connector would prevent the query from returning any results at all, but the analyst verified the query returns results when run manually. Option C is wrong because the workspace region does not affect the execution of scheduled analytics rules; Sentinel rules run within the workspace regardless of region. Option D is wrong because if the query used unsupported KQL functions, it would fail to execute or return an error, but the analyst confirmed the query runs successfully.

Practice this question →

MCQmedium

You are the security analyst for a company that uses Microsoft Sentinel. You notice that a critical analytics rule has not generated any incidents in the past week, but you know that relevant logs are being ingested. You need to troubleshoot why the rule is not firing. What is the first step you should take?

A.Check the incident creation rule configuration.

B.Verify that the log sources are connected and sending data to the workspace.

C.Disable and re-enable the analytics rule.

D.Run the analytics rule's query directly in Log Analytics to see if it returns results.

AnswerD

Running the analytics rule's KQL query directly in Log Analytics is the correct first step because it isolates whether the problem lies in the rule logic or in the downstream alert/incident pipeline. By executing the exact query with the same time range and filters, you can see if any rows are returned; if none are, the rule will never fire regardless of its other settings. If the query does return data, then you should examine the rule's alert creation, incident settings, and run history. This approach provides concrete evidence and prevents you from blindly altering configuration.

Why this answer

The first step in troubleshooting a Sentinel analytics rule that is not generating incidents despite relevant logs being ingested is to run the rule's query directly in Log Analytics. This isolates whether the issue is with the query logic itself (e.g., syntax errors, time range misconfiguration, or data not matching the KQL conditions) rather than with data ingestion or rule settings. If the query returns results in Log Analytics, the problem lies elsewhere; if it returns no results, the query needs adjustment.

Exam trap

The trap here is that candidates often jump to checking data ingestion (Option B) even when the question states logs are being ingested, or they assume a rule reset (Option C) will fix a logic problem, missing the fundamental step of validating the query itself.

How to eliminate wrong answers

Option A is wrong because incident creation rule configuration is not a concept in Microsoft Sentinel; analytics rules define incident creation, and checking this is premature before verifying the query returns data. Option B is wrong because the question explicitly states that relevant logs are being ingested, so verifying connectivity is unnecessary and wastes time. Option C is wrong because disabling and re-enabling the rule is a brute-force reset that does not diagnose the root cause and may reset rule state without addressing underlying query or scheduling issues.

Practice this question →

MCQeasy

Your organization uses Microsoft Defender XDR and Microsoft Sentinel. The security operations center (SOC) team frequently receives false positive alerts for a specific user login pattern from a legacy application. You need to reduce alert fatigue without disabling the underlying detection rule. What should you configure?

A.Use Microsoft Sentinel bookmarks to mark the alerts as false positives.

B.Configure an automated investigation and remediation rule in Microsoft Defender XDR to suppress alerts matching the legacy application pattern.

C.Create a watchlist in Microsoft Sentinel containing the legacy application's user accounts and use it in the rule.

D.Modify the analytics rule in Microsoft Sentinel to exclude the legacy application IP range.

AnswerB

An automated investigation and remediation rule in Microsoft Defender XDR can define precise conditions to match the legacy application's characteristic behavior, such as specific process names, users, or IP addresses, and then automatically take an action like closing or suppressing the alert. This works directly at the XDR layer, addressing the root cause of the false positive without modifying the underlying detection query or disabling broader threat visibility. It is the intended, scalable approach for recurring harmless patterns, requiring no manual intervention once configured.

Why this answer

Configuring an automated investigation and remediation rule in Microsoft Defender XDR allows you to suppress alerts that match a specific pattern (e.g., legacy application login behavior) without disabling the underlying detection rule. This directly reduces alert fatigue by automatically closing or ignoring false positive alerts while keeping the rule active for genuine threats.

Exam trap

The trap here is that candidates often confuse modifying the detection rule (options C or D) with configuring a separate suppression or response mechanism, failing to realize that automated investigation and remediation rules in Defender XDR can suppress alerts without altering the original detection logic.

How to eliminate wrong answers

Option A is wrong because Microsoft Sentinel bookmarks are used to preserve and annotate specific events for later investigation, not to suppress or mark alerts as false positives in an automated manner. Option C is wrong because creating a watchlist in Microsoft Sentinel containing user accounts and using it in the rule would require modifying the analytics rule logic to exclude those accounts, which does not reduce alert fatigue without disabling the rule; it changes the rule's behavior. Option D is wrong because modifying the analytics rule to exclude the legacy application IP range would alter the rule's detection logic, effectively disabling detection for that IP range, which contradicts the requirement to not disable the underlying detection rule.

Practice this question →

MCQhard

Your organization has deployed Microsoft Sentinel in multiple regions. You need to ensure that incidents created in one workspace are available for correlation in a central workspace. What should you implement?

A.Cross-workspace queries in KQL

B.Sentinel workspace manager (incident replication)

C.Automated export of incidents to central workspace using Logic Apps

D.Azure Lighthouse

AnswerB

Sentinel workspace manager's incident replication feature is the native, built-in mechanism that replicates incidents from multiple workspaces to a central workspace, providing a single pane of glass for SOC triage. It maintains a one-way copy of incident metadata and status in the central workspace, enabling centralized metrics, queries, and automation without altering the original incident. This is the recommended method over custom exports or cross-workspace queries because it is purpose-built for incident aggregation and requires no manual pipeline.

Why this answer

Sentinel Workspace Manager (incident replication) is the correct choice because it provides native, built-in replication of incidents from multiple workspaces to a central workspace without requiring custom code or external automation. This feature ensures that incidents created in regional workspaces are automatically synchronized to a designated central workspace, enabling unified correlation and investigation across regions.

Exam trap

The trap here is that candidates often confuse cross-workspace queries (which allow querying data across workspaces but do not replicate incidents) with the native incident replication feature, leading them to select Option A instead of the correct Workspace Manager solution.

How to eliminate wrong answers

Option A is wrong because cross-workspace queries in KQL allow querying data across multiple workspaces but do not replicate incidents; they require manual querying and do not provide automatic incident synchronization. Option C is wrong because automated export using Logic Apps is a custom, complex solution that introduces latency and maintenance overhead, whereas Sentinel Workspace Manager provides a native, low-latency replication mechanism without additional components. Option D is wrong because Azure Lighthouse enables cross-tenant management and visibility but does not replicate incidents between workspaces; it allows administrators to manage multiple workspaces from a single pane but does not synchronize incident data.

Practice this question →

MCQhard

You are configuring Microsoft Defender for Cloud Apps. You need to create a policy that alerts when a user downloads more than 100 files in 10 minutes from SharePoint. Which policy type should you use?

A.Anomaly detection policy

B.Activity policy

C.File policy

D.Cloud discovery policy

AnswerB

An activity policy is designed specifically to monitor user sign-in and app activity events, and it allows you to define custom behavioral conditions using filters, thresholds, and time windows. For example, you can create a policy that alerts when a user performs more than N file downloads within a set number of minutes, then automatically respond by suspending the user or requiring re-authentication. This matches the requirement for a custom threshold on download volume.

Why this answer

An Activity policy in Microsoft Defender for Cloud Apps monitors specific user activities (e.g., file downloads) and can trigger alerts based on thresholds like 'more than 100 downloads in 10 minutes'. This policy type is designed for granular, behavior-based detection of suspicious actions, making it the correct choice for this scenario.

Exam trap

The trap here is that candidates often confuse 'Anomaly detection policy' (which uses machine learning for behavioral baselines) with 'Activity policy' (which uses explicit thresholds), leading them to select Option A for any threshold-based alert.

How to eliminate wrong answers

Option A is wrong because Anomaly detection policies use machine learning to detect deviations from a user's baseline behavior, not fixed thresholds like '100 files in 10 minutes'. Option C is wrong because File policies focus on file attributes (e.g., metadata, content, sharing settings) rather than user activity counts over time. Option D is wrong because Cloud discovery policies analyze traffic logs to identify shadow IT usage, not user-specific download activities within a known SharePoint environment.

Practice this question →

MCQeasy

Your SOC team uses Microsoft Sentinel incident management. You need to ensure that when an incident is created, it automatically runs a playbook to gather additional context from threat intelligence sources. What should you create?

A.Workbook that queries threat intelligence.

B.Watchlist that maps to the incident.

C.Automation rule with a trigger on incident creation.

D.Analytics rule that generates an alert.

AnswerC

Automation rules are the native orchestration feature in Microsoft Sentinel that let you define conditions and actions executed when an incident meets predefined criteria. By setting the trigger type to 'When incident is created,' the rule fires immediately upon incident generation, and you can configure it to run a playbook, change the incident status, assign ownership, or add tasks. This is the correct and intended mechanism for automatically invoking a playbook at incident creation time.

Why this answer

Microsoft Sentinel automation rules can be configured with a trigger on incident creation to automatically run a playbook. This allows the SOC team to gather additional context from threat intelligence sources without manual intervention, directly addressing the requirement to execute a playbook when an incident is created.

Exam trap

The trap here is that candidates often confuse automation rules with analytics rules, thinking that analytics rules can directly trigger playbooks on incident creation, when in fact automation rules are the dedicated mechanism for incident-triggered playbook execution.

How to eliminate wrong answers

Option A is wrong because a Workbook in Microsoft Sentinel is a visualization and reporting tool that queries data for analysis, not an automated action that runs a playbook upon incident creation. Option B is wrong because a Watchlist is a static reference data source used for correlation and enrichment within analytics rules or queries, not a mechanism to trigger playbooks automatically. Option D is wrong because an Analytics rule generates alerts based on detection logic, but it does not directly trigger a playbook on incident creation; playbook execution on incident creation requires an automation rule, not the analytics rule itself.

Practice this question →

MCQmedium

Your security team uses Microsoft Sentinel automation rules to respond to incidents. You need to ensure that critical incidents are automatically assigned to a senior analyst in the Americas time zone and that a Teams message is sent to a specific channel. Which configuration should you use?

A.Use a watchlist to map critical incidents to senior analysts and trigger an email

B.Configure the analytics rule to set the incident owner and add a playbook action

C.Create a custom connector in Power Automate to monitor Sentinel incidents

D.Create a playbook that assigns the incident and sends a Teams message, then attach it to a automation rule

AnswerD

A playbook in Microsoft Sentinel is an Azure Logic Apps workflow that can perform actions such as updating the incident owner and sending a Teams message. By attaching this playbook to an automation rule, the rule triggers the playbook when incidents meet specific conditions (e.g., creation, severity, or status change), automating the assignment and notification. This is the correct approach because automation rules are designed to run playbooks as incident-triggered actions, and the playbook can use the 'Update incident' action to set the owner.

Why this answer

Automation rules in Microsoft Sentinel can trigger a playbook when an incident is created or updated. By creating a playbook that assigns the incident to a specific senior analyst (using Microsoft Entra ID or a watchlist for mapping) and sends a Teams message via the Teams connector, then attaching that playbook to an automation rule with conditions for critical severity, you meet both requirements. This approach leverages native Sentinel automation without custom connectors or manual email triggers.

Exam trap

The trap here is that candidates often confuse the capabilities of analytics rules versus automation rules, thinking that analytics rules can directly execute playbooks or set owners, when in fact automation rules are the correct mechanism for triggering playbooks and modifying incident properties after creation.

How to eliminate wrong answers

Option A is wrong because a watchlist alone cannot trigger actions; it is a static data source, and the email action would require a playbook or automation rule, not just a watchlist. Option B is wrong because analytics rules can set the incident owner via the 'Alert Details' configuration, but they cannot directly add a playbook action; playbooks are attached via automation rules, not analytics rules. Option C is wrong because creating a custom connector in Power Automate is unnecessary and overly complex; Sentinel already provides native connectors for Teams and incident management through automation rules and playbooks.

Practice this question →

MCQeasy

Your SOC uses Microsoft Sentinel and Microsoft Defender for Cloud Apps. You need to configure a policy that triggers when a user downloads a large number of files from SharePoint Online within a short period. Which policy type should you use?

A.Session policy

B.File policy

C.Anomaly detection policy

D.Activity policy

AnswerD

Activity policies in Microsoft Defender for Cloud Apps evaluate user activity against thresholds, such as mass file downloads from SharePoint Online within a defined period. They generate alerts or governance actions directly on the activity stream, matching the download-volume scenario.

Why this answer

An activity policy in Microsoft Defender for Cloud Apps is designed to monitor and respond to specific user activities, such as downloading a large number of files from SharePoint Online within a short period. This policy type allows you to set thresholds and triggers based on user actions, making it the correct choice for detecting anomalous download behavior.

Exam trap

The trap here is that candidates often confuse anomaly detection policies (which are predefined and use machine learning) with activity policies (which are customizable and rule-based), leading them to select anomaly detection when a custom threshold-based trigger is required.

How to eliminate wrong answers

Option A is wrong because session policies are used for real-time monitoring and control of user sessions, such as blocking downloads during a session, but they do not trigger based on historical activity thresholds like a large number of downloads over time. Option B is wrong because file policies focus on detecting specific file types, content, or metadata (e.g., sensitive data in files), not on the volume or frequency of file downloads. Option C is wrong because anomaly detection policies in Defender for Cloud Apps use machine learning to detect unusual patterns across users, but they are predefined and cannot be customized to trigger specifically on a high volume of downloads from SharePoint Online within a short period.

Practice this question →

Multi-Selecthard

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

Select 3 answers

A.Create a new analytics rule

B.Add threat intelligence indicators to Sentinel

C.Run a playbook

D.Change the severity of an incident

E.Assign an incident to a specific analyst

AnswersC, D, E

Automation rules can invoke playbooks, which are Azure Logic Apps workflows, as an automated response when an incident is created or updated. The run playbook action lets you enrich, notify, investigate, or remediate without manual intervention. Playbooks triggered by automation rules require a connection with the appropriate permissions in the resource group.

Why this answer

Automation rules in Microsoft Sentinel can trigger a playbook as an automated response to an incident or alert. Playbooks are based on Azure Logic Apps and allow you to run complex workflows, such as gathering additional data, sending notifications, or taking remediation actions, directly from the automation rule.

Exam trap

The trap here is that candidates often confuse automation rules with analytics rules, thinking automation rules can create or modify analytics rules, but automation rules only handle incident and alert response actions, not rule creation.

Practice this question →

Multi-Selecthard

Which THREE components are required to enable automation in Microsoft Sentinel? (Choose three.)

Select 3 answers

A.Microsoft Power Automate license

B.Playbooks based on Azure Logic Apps

C.Microsoft Entra ID P2 license

D.Managed identity or service principal for authentication

E.Automation rules

AnswersB, D, E

Playbooks based on Azure Logic Apps are the execution component that actually performs automated response actions in Microsoft Sentinel. These playbooks represent the procedural logic—such as isolating a compromised host, resetting credentials, or enriching an incident—by calling APIs and orchestrating Azure services. Without a playbook, an automation rule has no substantive task to run, so playbooks are a required foundation for enabling security automation.

Why this answer

Playbooks based on Azure Logic Apps are required because they provide the workflow automation engine that executes response actions in Microsoft Sentinel. Without a Logic Apps resource to define the steps (e.g., triggers, conditions, and actions), there is no executable automation to run when an incident or alert is generated.

Exam trap

The trap here is that candidates often confuse the licensing requirements for Power Automate (Option A) with the actual compute engine (Azure Logic Apps) needed for playbooks, or they mistakenly think Entra ID P2 (Option C) is required for automation when it is only needed for identity protection features.

Practice this question →

Multi-Selectmedium

Which THREE features are available in Microsoft Defender XDR to help automate incident response? (Choose three.)

Select 3 answers

A.Automated investigation and response (AIR)

B.Microsoft Power Automate

C.Advanced hunting

D.Playbooks

E.Microsoft Sentinel fusion rule

AnswersA, C, D

Automated investigation and response (AIR) is a built-in capability of Microsoft Defender XDR that self-executes security investigations triggered by alerts, applying algorithms to examine evidence like files, processes, and network communications. It automatically takes corrective actions, such as isolating devices or blocking malicious indicators, and records findings for analysts. AIR reduces alert fatigue by containing threats with minimal human intervention.

Why this answer

Automated investigation and response (AIR) in Microsoft Defender XDR automatically runs playbooks on alerts to investigate and remediate threats without manual intervention. It leverages machine learning and security signals across endpoints, email, and identities to contain malicious activity, such as isolating a compromised device or blocking a malicious file, directly within the incident response workflow.

Exam trap

The trap here is that candidates may confuse Microsoft Power Automate as a native Defender XDR feature for automation, when in fact it is an external tool that requires custom configuration and is not part of Defender XDR's built-in automated investigation and response capabilities.

Practice this question →

Multi-Selecteasy

You are configuring Microsoft Sentinel to use Microsoft Copilot for Security. Which TWO prerequisites must be met?

Select 2 answers

A.Ensure that the Microsoft Defender XDR tenant is integrated with Copilot for Security.

B.Enable Copilot for Security in the Microsoft Sentinel workspace settings.

C.Deploy Copilot for Security in the same Azure region as the Sentinel workspace.

D.Purchase a Microsoft Sentinel premium license.

E.Provision Security Compute Units (SCUs) in the Copilot for Security portal.

AnswersA, E

To enable Microsoft Copilot for Security to access Sentinel incident data, you must integrate the Microsoft Defender XDR tenant (which serves as the identity and data plane) with Copilot for Security. This integration establishes the required permissions and data flow, allowing the Copilot to retrieve and analyze security signals from Sentinel. Without this tenant-level integration, Copilot cannot authenticate to Sentinel workspaces or access their incidents, even if other components are correctly configured.

Why this answer

Microsoft Copilot for Security must be integrated with the Microsoft Defender XDR tenant to access and correlate security data across the Microsoft security ecosystem. This integration enables Copilot to leverage signals from Defender XDR, Microsoft Sentinel, and other sources for incident response and investigation. Without this tenant-level integration, Copilot cannot authenticate or retrieve the necessary security context from Defender XDR.

Exam trap

The trap here is that candidates often confuse enabling Copilot in Sentinel workspace settings (Option B) with the actual tenant-level integration required, or they assume a premium Sentinel license is mandatory when only SCU provisioning and Defender XDR integration are needed.

Practice this question →

MCQhard

Your organization has multiple offices across the globe and uses Microsoft Sentinel as the primary SIEM. You have deployed Azure Arc on all on-premises servers to manage them centrally. The security team needs to collect Windows Security Events from all servers, including domain controllers, and forward them to Sentinel using the Windows Security Events via AMA connector. The team also wants to minimize administrative overhead when adding new servers. The current environment includes: 500 on-premises Windows servers (200 domain controllers, 300 member servers) managed via Azure Arc, 200 Azure VMs running Windows Server, and a centralized Log Analytics workspace named 'LAW-Security' in the East US region. You have already installed the Azure Monitor Agent (AMA) on all servers via Azure Arc and Azure VMs. However, you notice that security events from domain controllers are not appearing in Sentinel. You have verified that the AMA agent is running and the data collection rule (DCR) is correctly configured to collect Security events. No other issues are present. You need to ensure that security events from domain controllers are collected. What should you do?

A.Reinstall the Windows Security Events via AMA connector in Sentinel.

B.Restart the Azure Monitor Agent on all domain controllers.

C.Recreate the data collection rule with a different namespace.

D.Check the network connectivity from the domain controllers to the Log Analytics workspace endpoint. Ensure that the domain controllers can reach the required URLs.

AnswerD

Domain controllers generate the Security events, but AMA forwards them over HTTPS to the Log Analytics ingestion endpoint. If outbound connectivity to the required URLs is blocked, events silently fail to reach LAW-Security despite correct DCR configuration.

Why this answer

Domain controllers often have more restrictive network policies, and they must be able to reach the Log Analytics workspace endpoint (the data collection endpoint and the Log Analytics service) to send events. The AMA agent is running and the DCR is configured, but if domain controllers cannot connect to the required URLs (e.g., *.ods.opinsights.azure.com, *.oms.opinsights.azure.com, etc.), events will not be collected. Option A is incorrect because the connector configuration is not the issue; the connector is already working for other servers.

Option B is incorrect because restarting the agent does not address network issues. Option C is incorrect because the DCR namespace is irrelevant; the DCR configuration is correct for other servers.

Practice this question →

100

MCQeasy

Your organization uses Microsoft Sentinel. You need to ensure that an incident is automatically assigned to the appropriate team based on the type of alert. What should you configure?

A.Workbook

B.Playbook

C.Analytics rule

D.Automation rule

AnswerD

Automation rules in Microsoft Sentinel can be configured to trigger on alert creation and use conditions such as alert name or severity to automatically assign incidents to a specific team via the "Assign owner" action. This satisfies the stem’s constraint of routing incidents based on alert type without requiring manual triage or separate playbook logic.

Why this answer

Automation rules in Microsoft Sentinel allow you to automatically assign incidents to specific teams based on conditions such as alert type or severity. This is the correct configuration because automation rules can trigger actions like incident assignment, tagging, or status changes without requiring a complex logic app or custom code.

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 native, simpler, and more efficient method for straightforward assignment tasks, while Playbooks are better for complex multi-step workflows.

How to eliminate wrong answers

Option A is wrong because Workbooks are visualization tools for querying and displaying data, not for automating incident assignment. Option B is wrong because Playbooks are automated workflows (often using Azure Logic Apps) that can respond to alerts or incidents, but they are not the primary or simplest method for automatic assignment; automation rules are designed for this purpose. Option C is wrong because Analytics rules generate alerts based on data queries, but they do not handle post-alert actions like incident assignment; that is the role of automation rules.

Practice this question →

101

Multi-Selecteasy

You are a security operations analyst for a company that uses Microsoft Sentinel. You need to ensure that incidents are automatically assigned to the appropriate team based on the incident type. Which two actions should you take?

Select 2 answers

A.Modify the analytics rule to set the incident owner directly.

B.Create a playbook that assigns incidents based on the incident type.

C.Create a workbook that filters incidents by type and assigns them manually.

D.Define custom details in the analytics rule to include the team name, then use an automation rule to assign.

E.Create an automation rule that uses conditions to set the incident owner.

AnswersD, E

To assign incidents to teams based on a team name, you can first configure custom details in the analytics rule to extract the team name from the alert into a custom property on the incident. Then, in the automation rule, you can create a condition that checks this custom detail and set the incident owner accordingly. This approach works because automation rules can only evaluate incident properties, so custom details bridge the gap when the team is not a standard incident field.

Why this answer

Custom details in an analytics rule allow you to extract and store the team name from the incident data, and then an automation rule can use that custom detail as a condition to automatically assign the incident to the appropriate owner. This approach ensures dynamic assignment based on the incident type without requiring a playbook or manual intervention.

Exam trap

The trap here is that candidates often think a playbook (Option B) is required for any automated action beyond basic alerting, but Microsoft Sentinel's automation rules can directly set incident owners based on conditions without needing a playbook.

Practice this question →

102

MCQhard

You are a security operations analyst for a company that uses Microsoft Sentinel. You have a playbook that remediates compromised user accounts by disabling the account and revoking sessions. You need to ensure that the playbook runs automatically whenever an incident is created with the 'Compromised User' tag. What should you configure?

A.An automation rule with a condition that checks for the 'Compromised User' tag and an action to run the playbook.

B.A playbook trigger configured in the Logic App Designer to start when a Sentinel incident is created.

C.A scheduled analytics rule that runs every 5 minutes and triggers the playbook.

D.A Microsoft Sentinel workbook that monitors incidents with the 'Compromised User' tag and sends a command to run the playbook.

AnswerA

Automation rules in Microsoft Sentinel can trigger playbooks based on incident conditions, including tags. You can create a rule that evaluates the incident's tags and, if the 'Compromised User' tag is present, runs the specified playbook. This is the correct method to automatically execute a playbook when an incident with a specific tag is created. It provides the required automation without manual intervention.

Why this answer

Automation rules are the mechanism in Microsoft Sentinel to automatically respond to incidents. By creating an automation rule that checks for the 'Compromised User' tag and then runs the playbook, you ensure the playbook executes only for incidents with that tag. This is the intended use of automation rules for playbook triggering.

Exam trap

The trap here is thinking that a playbook's own trigger can filter by tags, when in fact automation rules provide that conditional logic.

Practice this question →

103

Multi-Selecteasy

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

Select 2 answers

A.Change the severity of an incident

B.Add a tag to an incident

C.Deploy a data connector

D.Modify a watchlist

E.Create a scheduled query rule

AnswersA, B

Automation rules in Microsoft Sentinel include a built-in action that updates the incident severity field. This action can be triggered conditionally, for example when an incident is assigned a MITRE technique or when entity analytics raise the risk score. Because severity directly drives triage priority in the SOC queue, being able to auto-adjust it based on changing context is a core incident-response action, making this a correct answer.

Why this answer

Automation rules in Microsoft Sentinel allow you to automate incident management tasks, including changing the severity of an incident and adding tags. These actions are part of the incident-handling workflow and can be triggered when an incident is created or updated, enabling consistent triage and enrichment without manual intervention.

Exam trap

The trap here is that candidates often confuse automation rules with playbooks or other Sentinel configuration tasks, assuming that any automated action (like deploying connectors or creating rules) can be done via automation rules, when in fact automation rules are strictly for incident management actions.

Practice this question →

104

MCQhard

You are managing a Microsoft Sentinel environment. You need to ensure that incidents are automatically assigned to the appropriate analyst based on the type of attack. The assignment must consider the current workload of each analyst. What should you use?

A.Configure multiple analytics rules, each with a different incident owner.

B.Use an automation rule with a playbook that queries the current incident assignments and assigns to the least busy analyst.

C.Create a watchlist that maps attack types to analyst names and use it in an analytics rule.

D.Create a workbook that shows analyst workload and manually assign.

AnswerB

An automation rule can be triggered on incident creation and invoke a playbook built in Azure Logic Apps. The playbook queries the Microsoft Sentinel API (security insights 'Incident' resource) to retrieve all active incidents, counts the open assignments per analyst, determines the analyst with the fewest open incidents, and then updates the incident owner using an action such as 'Entity Incident Management' or an HTTP call to the API. This provides dynamic, workload-aware assignment that static configuration cannot.

Why this answer

Automation rules in Microsoft Sentinel can trigger a playbook (Azure Logic App) that queries the current incident assignments and assigns the incident to the analyst with the fewest active incidents. This satisfies both the attack-type mapping (via the analytics rule that generates the incident) and the workload-balancing requirement, as the playbook can dynamically evaluate workload using Azure Resource Graph or Sentinel's API.

Exam trap

The trap here is that candidates often confuse static assignment (Option A or C) with dynamic assignment, failing to realize that only a playbook can query real-time workload data and make a runtime decision based on it.

How to eliminate wrong answers

Option A is wrong because configuring multiple analytics rules with different incident owners only allows static assignment per rule, not dynamic workload-based assignment; it cannot consider current analyst workload. Option C is wrong because a watchlist can map attack types to analyst names, but using it in an analytics rule only sets a static owner field, not a dynamic assignment based on real-time workload. Option D is wrong because a workbook only provides a visual report of analyst workload; it cannot automate assignment, and manual assignment does not meet the requirement for automatic assignment.

Practice this question →

105

MCQhard

Your SOC uses Microsoft Sentinel and Microsoft Defender XDR. An incident is generated from a Microsoft Defender for Identity alert about a suspicious Kerberos ticket request. The incident is assigned the 'Medium' severity. You want to automatically increase the severity to 'High' if the user is in a privileged role, based on data from Microsoft Entra ID. What is the most efficient way to achieve this?

A.Enable automatic attack disruption in Microsoft Defender XDR to handle the incident.

B.Modify the analytics rule that generates the incident to check user roles during query execution.

C.Create an automation rule in Microsoft Sentinel triggered on incident creation, which runs a playbook that checks Microsoft Entra ID roles and updates the severity accordingly.

D.Create a scheduled analytics rule that queries Microsoft Entra ID audit logs and updates incident severity via a watchlist.

AnswerC

An automation rule with an incident creation trigger can invoke a playbook that uses Logic Apps and the Microsoft Entra ID connector or Graph API to read the incident's user entity and retrieve their directory role assignments. The playbook can then call the 'Update incident' action to set the severity to a higher value if the user holds a privileged role, such as Global Administrator. This approach is purpose-built for incident lifecycle management and provides real-time, agentless enrichment without altering detection logic.

Why this answer

Automation rules in Microsoft Sentinel can trigger a playbook on incident creation, and that playbook can use the Microsoft Graph API to query Microsoft Entra ID for the user's role assignments. If the user holds a privileged role (e.g., Global Administrator), the playbook can programmatically update the incident's severity to 'High'. This approach is event-driven, efficient, and does not require modifying existing analytics rules or creating additional scheduled queries.

Exam trap

The trap here is that candidates may think modifying the analytics rule (Option B) is simpler, but they overlook that analytics rules cannot natively query external identity stores like Microsoft Entra ID during query execution without complex KQL cross-workspace joins or enrichment, making the automation rule with a playbook the most efficient and maintainable solution.

How to eliminate wrong answers

Option A is wrong because automatic attack disruption in Microsoft Defender XDR is designed to automatically contain active attacks (e.g., by isolating devices or blocking accounts), not to adjust incident severity based on user role data from Microsoft Entra ID. Option B is wrong because analytics rules in Microsoft Sentinel query data already ingested into the Log Analytics workspace (e.g., from Microsoft Defender for Identity), and they cannot directly query Microsoft Entra ID roles during rule execution without a separate data connector or enrichment step, making this approach inefficient and not the most efficient. Option D is wrong because creating a scheduled analytics rule that queries Microsoft Entra ID audit logs and updates severity via a watchlist is an indirect, batch-oriented method that introduces latency and complexity; it is less efficient than a real-time automation rule triggered on incident creation.

Practice this question →

106

Multi-Selectmedium

Which TWO actions should you take when configuring Microsoft Sentinel to minimize false positives from an analytics rule?

Select 2 answers

A.Add a playbook to automatically close low-severity alerts

B.Map entities correctly

C.Enable incident creation automatically

D.Adjust the rule's query threshold

E.Configure alert grouping

AnswersB, D

Mapping entities correctly ties alerts to the right accounts, hosts and IP addresses, so Microsoft Sentinel correlates activity accurately and stops unrelated events triggering the rule. This directly reduces false positives by ensuring entity-based logic matches genuine incidents.

Why this answer

Option B (Map entities correctly) is correct because accurate entity mapping (for example, mapping Account, Host, or IP custom entities in the rule's entity mapping section) lets Sentinel correlate and enrich alerts with the right context, so benign activity isn't misattributed and duplicate or unrelated alerts aren't generated. Option D (Adjust the rule's query threshold) is correct because tuning the rule's KQL query — for example, raising the count or time-window threshold, filtering known-good accounts, or adding exclusions — directly reduces the volume of low-fidelity matches that become false-positive incidents. Option A is not a false-positive reduction measure; a playbook that auto-closes low-severity alerts only handles alerts after they are created and does not stop them from firing.

Option C (Enable incident creation automatically) actually increases noise by turning every matching alert into an incident rather than suppressing false positives. Option E (Configure alert grouping) consolidates related alerts into fewer incidents but does not reduce the underlying false-positive detections.

Practice this question →

107

MCQmedium

Your Microsoft Sentinel workspace ingests logs from multiple sources but you notice that some custom logs are missing in the Log Analytics workspace. You've confirmed that the data connectors are healthy. What is the most likely cause?

A.The custom log table schema does not match the incoming log format.

B.There is a time gap between log generation and ingestion.

C.The workspace has exceeded its daily ingestion limit.

D.The data connectors are not properly configured for custom log ingestion.

AnswerA

Custom log tables in Microsoft Sentinel have a fixed schema defined at creation (via DCR, custom log API, or saved as a table). When the incoming log records contain fields that do not match this defined schema — such as a different column name, wrong data type, or extra fields that are not in the table — the Log Analytics ingestion pipeline validates each record and rejects the entire record during parsing. This causes the logs to be silently dropped before they can be indexed, so you see missing custom log data even though connectors and workspace health are normal.

Why this answer

When data connectors are healthy but custom logs are missing, the most common cause is a schema mismatch between the custom log table definition in the Log Analytics workspace and the actual log data being sent. Microsoft Sentinel requires the custom log table's schema (columns, data types, and delimiters) to exactly match the incoming log format; otherwise, the ingestion pipeline drops the records without error. This is because the Log Analytics agent or AMA uses the table schema to parse and transform the data, and any deviation results in silent failures.

Exam trap

The trap here is that candidates assume a healthy data connector guarantees all logs are ingested, but Microsoft tests the nuance that schema mismatches cause silent ingestion failures even when the connector itself is operational.

How to eliminate wrong answers

Option B is wrong because a time gap between log generation and ingestion does not cause logs to be missing; it only delays their appearance in the workspace, and Sentinel can still ingest them later. Option C is wrong because exceeding the daily ingestion limit would cause all log ingestion to stop or be throttled, not just custom logs, and you would see ingestion quota warnings in the workspace. Option D is wrong because the question explicitly states that data connectors are healthy, meaning they are properly configured for custom log ingestion; if they were misconfigured, the connectors would show an unhealthy status or fail to connect.

Practice this question →

108

MCQeasy

Refer to the exhibit. You have an analytics rule in Microsoft Sentinel that uses this KQL query. The rule is configured to run every hour and alert when the result count is greater than 0. Which type of attack is this rule most likely detecting?

A.Privileged account misuse

B.Data exfiltration via sign-in

C.Account takeover from a new location

D.Brute force attack on user accounts

AnswerD

A brute force attack on user accounts is the correct classification because high-risk sign-ins reflect patterns such as repeated failed password attempts, impossible travel across many accounts, or logins from known malicious IPs—all hallmarks of password guessing or credential stuffing. Sentinel analytics rules that aggregate risk signals from Microsoft Entra ID Protection will generate a single incident when multiple users experience elevated sign-in risk, which matches a coordinated brute-force or password-spray attack rather than a targeted compromise.

Why this answer

The KQL query counts failed sign-in events (ResultType != 0) aggregated by User, IPAddress, and a 5-minute bin, then filters for users with more than 10 failures. This pattern of multiple rapid failed logins from the same IP against a single user is the classic signature of a brute force attack, where an attacker tries many passwords to guess credentials. The rule triggers when the count exceeds 10 within any 5-minute window, making it highly specific to brute force detection.

Exam trap

The trap here is that candidates confuse 'account takeover from a new location' (which requires a successful sign-in from an unfamiliar location) with 'brute force attack' (which is characterized by multiple failed sign-ins), leading them to pick Option C instead of D.

How to eliminate wrong answers

Option A is wrong because privileged account misuse typically involves unusual activity after successful authentication (e.g., abnormal role assignments, privilege escalation), not repeated failed logins. Option B is wrong because data exfiltration via sign-in would focus on successful sign-ins followed by data transfer anomalies, not failed authentication attempts. Option C is wrong because account takeover from a new location would be detected by successful sign-ins from unfamiliar geographic locations or devices, not by a high volume of failed attempts from a single IP.

Practice this question →

109

MCQeasy

Your organization uses Microsoft Defender for Cloud Apps to discover shadow IT. You notice that a new cloud app is being used by multiple users but has a risk score of 8. What should you do first to manage the risk?

A.Investigate the app's risk factors and user activity

B.Block the app at the proxy

C.Immediately unsanction the app in Defender for Cloud Apps

D.Create a policy to alert on use of this app

AnswerA

In Defender for Cloud Apps, investigation involves reviewing the app's cloud app catalog risk score, which includes factors such as data sharing, authentication methods, and compliance certifications, alongside actual user activity like sign-in events, file access, and IP addresses. This allows security analysts to differentiate unsanctioned but benign applications from those posing genuine threats such as credential theft or data exfiltration. By correlating risk factors with usage patterns, an analyst can make an informed governance decision—whether to sanction, alert, or block—without interrupting business continuity.

Why this answer

A risk score of 8 indicates the app is high-risk, but immediate blocking or unsanctioning could disrupt business operations if the app is legitimate or used for approved purposes. The first step is to investigate the app's risk factors (e.g., data residency, encryption standards, compliance certifications) and user activity (e.g., volume of data uploaded, types of files shared) to understand the actual threat. This aligns with Microsoft's recommended incident response process: assess before acting.

Exam trap

The trap here is that candidates assume a high risk score automatically requires immediate blocking or unsanctioning, but Microsoft's guidance emphasizes investigation first to avoid false positives and ensure business continuity.

How to eliminate wrong answers

Option B is wrong because blocking the app at the proxy without investigation could break legitimate business workflows and bypass the need to understand the app's risk profile; Defender for Cloud Apps uses reverse proxy controls only after assessment. Option C is wrong because immediately unsanctioning the app without investigation may cause unnecessary disruption and ignores the possibility that the app is low-risk despite a high score; unsanctioning should be a deliberate action based on evidence. Option D is wrong because creating a policy to alert on use of the app is a reactive measure that does not address the immediate risk; alerts are useful for ongoing monitoring but not the first step when a high-risk app is already in use.

Practice this question →

110

MCQhard

Your organization uses Microsoft Sentinel and has multiple workspaces for different business units. You need to enable cross-workspace querying for the security operations center (SOC) analysts. What should you do?

A.Configure a data connector for each workspace

B.Use the workspace() expression in KQL queries

C.Enable incident merging across workspaces

D.Create a single workspace and migrate all data

AnswerB

The workspace() expression in Kusto Query Language allows you to reference a table in another Log Analytics workspace by appending the workspace resource ID or name to the table name, such as `union workspace('workspace1').SignedInLogs, workspace('workspace2').SignedInLogs`. This enables a single KQL query to span multiple Microsoft Sentinel workspaces, which is exactly the capability you need to search for threats or aggregate data across all your workspaces.

Why this answer

The `workspace()` expression in KQL allows a query to reference tables from multiple Log Analytics workspaces within a single query. This enables SOC analysts to perform cross-workspace queries without moving data, which is the correct approach for a multi-workspace Sentinel deployment.

Exam trap

The trap here is that candidates may confuse data collection configuration (data connectors) with query capabilities, or assume that incident merging is the same as cross-workspace querying, when in fact they serve entirely different purposes.

How to eliminate wrong answers

Option A is wrong because configuring a data connector for each workspace ingests data into each workspace separately but does not enable cross-workspace querying; it only ensures data is collected. Option C is wrong because incident merging across workspaces is a feature for correlating alerts into a single incident, not for querying data across workspaces. Option D is wrong because creating a single workspace and migrating all data is an architectural change that may not be feasible or desired, and it is not the recommended method for enabling cross-workspace queries in a multi-workspace environment.

Practice this question →

111

MCQeasy

A security operations center (SOC) uses Microsoft Sentinel. They want to automatically block a user's account when a high-severity incident is created. Which automation action should you use in a playbook?

A.Run a playbook that revokes the user's current sessions using Microsoft Graph API.

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

C.Run a playbook that calls the Microsoft Graph API to disable the user account.

D.Run a playbook that updates a conditional access policy in Microsoft Entra ID.

AnswerC

A Microsoft Sentinel playbook, powered by Azure Logic Apps, can directly interact with Microsoft Entra ID to manage user accounts. By calling the Microsoft Graph API within the playbook, specifically the Users endpoint to update a user's properties, the `accountEnabled` attribute can be set to `false`. This precise technical mechanism allows the playbook to automatically disable the user account in Microsoft Entra ID, directly fulfilling the requirement to block the user's account upon a high-severity incident.

Why this answer

Disabling the user account via Microsoft Graph API is the most direct and effective way to prevent further access when a high-severity incident is created. This action immediately blocks the user from authenticating across all services, which aligns with the requirement to automatically block the account. Other options either do not block the account (e.g., revoking sessions or resetting password) or are indirect and less reliable (e.g., updating Conditional Access policies).

Exam trap

The trap here is that candidates may confuse 'blocking a user' with temporary measures like revoking sessions or resetting passwords, but only disabling the account (via Graph API) permanently prevents authentication until the account is re-enabled.

How to eliminate wrong answers

Option A is wrong because revoking the user's current sessions only terminates active sessions but does not prevent the user from re-authenticating with valid credentials, so the account remains unblocked. Option B is wrong because resetting the user's password changes the credential but does not disable the account; the user could still be blocked by other means, and the account remains active. Option D is wrong because updating a Conditional Access policy is a tenant-wide or group-level change that may not immediately or reliably block a specific user account, and it does not directly disable the user object in Microsoft Entra ID.

Practice this question →

112

MCQeasy

A security operations center (SOC) uses Microsoft Sentinel. You need to ensure that when a high-severity incident is created, an automated email notification is sent to the on-call security engineer. Which automation option should you use?

A.Set an analytics rule to run a KQL query and send email.

B.Create a workbook that emails the on-call engineer daily.

C.Configure a logic app manually triggered by the analyst.

D.Create a playbook that sends an email and associate it with an automation rule that triggers on high-severity incidents.

AnswerD

This is correct because Sentinel integrates with Azure Logic Apps to create playbooks—workflows that can perform actions like sending email via the Office 365 Outlook connector. An automation rule can be configured with a condition for high-severity incidents and an action to run a playbook, which automatically executes the email-sending workflow when an incident is created. This provides the fully automated notification mechanism required, with no manual steps.

Why this answer

Microsoft Sentinel uses automation rules to trigger playbooks (Azure Logic Apps) based on incident creation or update conditions. By associating a playbook that sends an email with an automation rule set to trigger on high-severity incidents, the SOC achieves fully automated, event-driven notification without manual intervention.

Exam trap

The trap here is confusing analytics rules (which generate alerts) with automation rules (which respond to incidents), leading candidates to incorrectly select Option A instead of recognizing that playbooks are the correct automation mechanism for email notifications.

How to eliminate wrong answers

Option A is wrong because analytics rules generate alerts based on KQL queries, but they cannot directly send email; they can only trigger playbooks or automation rules. Option B is wrong because workbooks are visualization dashboards, not automation tools; they cannot send email notifications. Option C is wrong because manually triggering a logic app defeats the purpose of automated incident response; the requirement is for automatic notification, not analyst-initiated action.

Practice this question →

113

MCQmedium

Your company uses Microsoft Defender for Cloud Apps. You discover that a user is accessing sensitive data from an unfamiliar IP address. You need to immediately block the user's access to all cloud apps while preserving the session for investigation. What should you do?

A.Use the 'Block' governance action in Defender for Cloud Apps

B.Create a conditional access policy to block the IP

C.Add the IP to the blocked IP address range list

D.Suspend the user from Microsoft Entra ID

AnswerA

Using the 'Block' governance action in Defender for Cloud Apps immediately terminates the flagged session via the session proxy and prevents new access from that session, while the full activity log is preserved for forensic review. This action is applied manually from the user or activity page and takes effect instantly, unlike policy-based controls. It is the appropriate granular containment that stops only the suspicious session without disabling the user account.

Why this answer

The 'Block' governance action in Defender for Cloud Apps immediately blocks the user's access to all cloud apps while preserving the session for investigation. This action is applied directly within the Defender for Cloud Apps portal, allowing you to stop data exfiltration without disrupting the ability to analyze the session logs or alerts. It is the only option that meets the requirement of blocking access while keeping the session intact for forensic review.

Exam trap

The trap here is that candidates often confuse the 'Block' governance action with IP-based blocking or user suspension, not realizing that only the governance action within Defender for Cloud Apps can block access while preserving the session for investigation.

How to eliminate wrong answers

Option B is wrong because creating a conditional access policy in Microsoft Entra ID would block access at the authentication level, but it does not preserve the session for investigation; it terminates the session entirely. Option C is wrong because adding the IP to the blocked IP address range list in Defender for Cloud Apps blocks all traffic from that IP, but it does not target the specific user and does not preserve the session for investigation. Option D is wrong because suspending the user from Microsoft Entra ID disables the user account, which blocks all access and terminates the session, preventing any further investigation of the ongoing session.

Practice this question →

114

Multi-Selectmedium

Which TWO actions should you take to improve the performance of Microsoft Sentinel analytics rules that query large datasets?

Select 2 answers

A.Use a time filter in the query to limit the data range.

B.Use a watchlist to pre-filter results.

C.Change the data type of the columns to string.

D.Use summarize operators to aggregate data before performing joins.

E.Simplify the event by removing unused columns using project.

AnswersA, D

Applying a time filter (e.g., where Timestamp between datetime(...) and datetime(...)) restricts the query to only the relevant time range, which directly reduces the number of records scanned. Kusto queries are highly optimized for time-based sharding, so narrowing the window lets the engine skip entire extents that fall outside the filter. This is the most effective first step because it reduces I/O and CPU cost at the source, before any other processing or aggregation occurs.

Why this answer

Applying a time filter (e.g., using the `TimeGenerated` column) in a KQL query restricts the dataset to only the relevant time window, which significantly reduces the amount of data scanned by Microsoft Sentinel. This directly improves query performance by minimizing I/O and processing overhead, especially when analytics rules run against large log tables.

Exam trap

The trap here is that candidates often confuse result-set optimization (like removing columns with `project`) with query-performance optimization, not realizing that the real bottleneck is the amount of raw data scanned from storage.

Practice this question →

115

MCQmedium

Your organization uses Microsoft Sentinel to manage security incidents. You need to ensure that critical incidents are automatically assigned to the senior security analyst on duty. What should you configure?

A.Configure an automation rule with an 'Assign incident' action

B.Modify the analytics rule to set the owner in the incident creation

C.Create a playbook that assigns incidents

D.Use a workbook to filter incidents by severity and assign manually

AnswerA

An automation rule with the 'Assign incident' action runs on incident creation, setting the owner to the senior analyst on duty. This directly satisfies the automatic assignment requirement, as analytics rules detect incidents but cannot assign ownership themselves.

Why this answer

Automation rules in Microsoft Sentinel allow you to automatically assign incidents to a specific owner based on conditions such as severity or title. Configuring an automation rule with the 'Assign incident' action ensures critical incidents are routed to the senior analyst on duty without manual intervention. This is the native, no-code method for incident assignment.

Exam trap

The trap is choosing a playbook because it sounds more powerful, but automation rules are the native, simpler feature for incident assignment—playbooks are overkill and require more setup.

How to eliminate wrong answers

Option B is wrong because analytics rules create incidents but do not provide an option to set the owner during creation; ownership is managed post-creation via automation rules or playbooks. Option C is wrong because a playbook (Logic App) can assign incidents, but it requires additional configuration and is not the simplest or most direct method; automation rules are purpose-built for this. Option D is wrong because workbooks are for visualization and reporting, not for automated assignment—manual assignment defeats the requirement for automation.

Practice this question →

116

MCQmedium

Your organization uses Microsoft Defender XDR. You notice that automated investigations are being blocked for certain devices due to high-severity alerts. You need to ensure that automated actions can proceed for devices with a risk score below 30. What should you configure?

A.Configure a device group with an automated investigation and response rule that excludes devices with a risk score above 30.

B.Disable automated investigation for all devices and rely on manual investigation.

C.Adjust the Microsoft Defender for Cloud Apps policy to allow automated actions for low-risk devices.

D.Modify the attack surface reduction rules to allow automated actions on low-risk devices.

AnswerA

A device group in Microsoft Defender XDR defines the scope of automated investigation and response actions, and you can set a matching condition on the device risk score. By creating a device group that includes only devices with a risk score of 30 or lower and associating an AIR rule that excludes higher-risk devices, automated remediation will run for the low-risk group while high-risk devices require manual approval. This directly satisfies the requirement to proceed automatically only for low-risk devices.

Why this answer

Device groups in Microsoft Defender XDR allow you to scope automated investigation and response (AIR) rules based on device risk scores. By creating a device group that excludes devices with a risk score above 30, you ensure that automated actions proceed only for devices meeting your threshold, directly addressing the requirement.

Exam trap

The trap here is that candidates confuse device groups (which control AIR scope) with other security features like attack surface reduction rules or cloud app policies, leading them to select options that address unrelated controls rather than the correct mechanism for scoping automated investigations.

How to eliminate wrong answers

Option B is wrong because disabling automated investigation entirely would prevent all automated responses, not just for high-risk devices, and contradicts the requirement to allow actions for low-risk devices. Option C is wrong because Microsoft Defender for Cloud Apps policies govern cloud application behavior, not device-level automated investigation and response actions in Defender XDR. Option D is wrong because attack surface reduction rules control exploit mitigation behaviors (e.g., blocking macros or scripts), not the conditional execution of automated investigation actions based on risk scores.

Practice this question →

117

MCQmedium

You are a SOC analyst investigating an incident where a user's credentials were used to access a sensitive SharePoint site from an unusual location. Microsoft Defender for Cloud Apps detected the activity as a suspicious sign-in. You need to create a detection rule that alerts whenever a user accesses SharePoint from a location not in the allowed list. What type of rule should you create in Microsoft Defender for Cloud Apps?

A.App discovery policy.

B.Session policy.

C.Activity policy.

D.Anomaly detection policy.

AnswerC

Activity policy in Microsoft Defender for Cloud Apps allows you to define custom rules based on specific activities, including conditions like location, to trigger alerts. You can set thresholds and filters to detect exactly the kind of user activity in question, such as a sign-in from a particular geographic region. This makes it the appropriate policy type for investigating an incident where a user’s location is a defining factor of the suspicious behavior.

Why this answer

An Activity policy in Microsoft Defender for Cloud Apps allows you to create custom rules that trigger alerts based on specific user activities, such as accessing SharePoint from a location not in the allowed list. This policy type evaluates each activity against defined conditions (e.g., IP address ranges, geolocation) and can generate alerts or take automated actions. It is the correct choice because it directly matches the requirement to detect a specific access pattern (location-based anomaly) rather than broad behavioral patterns.

Exam trap

The trap here is that candidates confuse 'Anomaly detection policy' (which is built-in and uses ML) with the ability to create custom location-based alerts, but only Activity policies allow you to define explicit conditions like 'not in allowed list'.

How to eliminate wrong answers

Option A is wrong because App discovery policies are designed to identify and control the use of cloud apps (shadow IT) by analyzing traffic logs, not to monitor user access to specific SharePoint sites from unusual locations. Option B is wrong because Session policies control user sessions in real time (e.g., blocking downloads or requiring MFA) but do not generate alerts for past or ongoing suspicious sign-ins; they are reactive controls, not detection rules. Option D is wrong because Anomaly detection policies use machine learning to detect unusual patterns across the tenant (e.g., impossible travel, mass download), but they are predefined by Microsoft and cannot be customized to alert on a specific location-based condition like 'not in allowed list'.

Practice this question →

118

MCQeasy

You are a security analyst at a company that uses Microsoft Sentinel. You need to ensure that only users with a specific tag in Microsoft Entra ID can access the Sentinel workspace. Which Azure feature should you use?

A.Assign Azure RBAC roles with a condition on the tag.

B.Use Microsoft Entra Privileged Identity Management (PIM) to require approval for access.

C.Apply an Azure Policy to deny access if the user does not have the tag.

D.Configure a Conditional Access policy in Microsoft Entra ID.

AnswerD

A Conditional Access policy in Microsoft Entra ID acts as a gatekeeper during the authentication process, evaluating signals before a sign-in token is issued. If the policy targets the Microsoft Azure Management application, it can require a user to have a specific tag or identity attribute—often represented as a group membership or custom security attribute—before allowing access to the Azure portal. This makes Conditional Access the correct identity-driven control for blocking portal access, because it evaluates the user's identity and session rather than relying on resource-level RBAC, PIM, or Azure Policy.

Why this answer

Conditional Access policies in Microsoft Entra ID can enforce access controls based on user attributes, including tags. By configuring a Conditional Access policy that grants access to Microsoft Sentinel only if the user has a specific tag, you can restrict workspace access at the authentication layer before any Azure RBAC evaluation occurs. This is the correct approach because Conditional Access operates at the identity level, directly controlling which users can authenticate to the Sentinel workspace.

Exam trap

The trap here is that candidates often confuse Azure RBAC with Conditional Access, assuming that RBAC conditions on tags can control initial access, when in fact RBAC only controls authorization after authentication, whereas Conditional Access controls authentication itself.

How to eliminate wrong answers

Option A is wrong because Azure RBAC roles with conditions on tags apply to Azure resources after authentication, but they cannot prevent a user from authenticating to the Sentinel workspace; they only control actions post-authentication. Option B is wrong because Privileged Identity Management (PIM) manages just-in-time elevation and approval for privileged roles, not attribute-based access restrictions like tags. Option C is wrong because Azure Policy enforces compliance on Azure resource configurations (e.g., ensuring resources have tags), not on user identity attributes or authentication-level access to a workspace.

Practice this question →

119

MCQhard

Your organization uses Microsoft Sentinel with a hybrid environment including on-premises servers and Azure VMs. You notice that some Windows events from on-premises servers are not being collected in Sentinel. Log Analytics agent is installed on all servers. Other events are collected. What should you check first?

A.Confirm that the workspace key is correctly deployed on the servers.

B.Verify that the Log Analytics agent is running and has network connectivity to Azure.

C.Ensure that the servers are listed in the Azure Arc management pane.

D.Check the Windows Event Log collection configuration in the Log Analytics workspace data collection rules.

AnswerD

Since the agent is installed and other events arrive, the gap lies in which Windows event logs and event IDs the workspace actually collects. Data collection rules define that filtering, so a missing channel or level there explains selective non-collection from on-premises servers.

Why this answer

Since the Log Analytics agent is installed and some events are collected, connectivity and agent health are already proven. The most likely cause of selective event gaps is the data collection configuration — specifically the Windows Event Logs settings in the workspace's data collection rules (or legacy agent configuration) that define which event logs and severity levels are forwarded.

Exam trap

SC-200 often tests troubleshooting logic — candidates jump to agent/connectivity checks even when the scenario states other events are flowing, which already rules those out.

How to eliminate wrong answers

Option A is wrong because an incorrect workspace key would prevent all data from that server, not just some events — and other events are being collected. Option B is wrong because if the agent were stopped or had no connectivity, no events would arrive from that server, contradicting the scenario. Option C is wrong because Azure Arc enrollment is required for Azure Monitor Agent on non-Azure machines, but the scenario states the Log Analytics agent (MMA) is installed and functioning, so Arc is not the first thing to check.

Practice this question →

120

MCQmedium

Your organization has a Microsoft Sentinel workspace that ingests data from Microsoft 365 Defender (Defender for Endpoint, Office 365, Identity, Cloud Apps). You have configured a scheduled analytics rule to detect possible privilege escalation based on user activity. The rule runs every 5 minutes and looks at the last 5 minutes of data. Recently, the rule has been generating a high number of false positives. You analyze the alerts and find that they are triggered by legitimate administrative actions. You need to reduce false positives without completely disabling the rule. The rule uses a KQL query that joins the IdentityLogonEvents and CloudAppEvents tables. What should you do?

A.Increase the rule's run frequency to every 30 minutes.

B.Reduce the query's lookback period to 1 minute.

C.Modify the KQL query to exclude events from a list of known administrative user accounts or IP addresses.

D.Add an incident suppression rule that closes incidents from known admin accounts.

AnswerC

The correct approach is to refine the KQL query so that it explicitly excludes events from known administrative user accounts or IP addresses, typically using a watchlist or a static list. This removes the benign baseline activity from the detection scope while retaining coverage for non-admin users and unknown actors. Because the exclusion is part of the query logic, the rule will not generate incidents for those known safe actors, but it will still fire on unusual behavior from other principals.

Why this answer

The false positives come from legitimate administrative actions triggering a privilege-escalation detection. The most targeted fix is to refine the KQL query to exclude known administrative user accounts or IP addresses, which preserves the rule's ability to detect real privilege escalation while filtering out the noisy legitimate activity. This is the standard Sentinel tuning approach for high-fidelity detections.

Exam trap

SC-200 often tests the difference between suppressing incidents (cosmetic) and tuning the detection query (root cause), and candidates frequently pick suppression rules because they sound like a clean fix.

How to eliminate wrong answers

Option A is wrong because increasing the run frequency to every 30 minutes only changes how often the rule executes — it does not reduce false positives and actually delays detection of real threats. Option B is wrong because reducing the lookback to 1 minute would miss events and reduce detection coverage, not improve precision. Option D is wrong because an incident suppression rule that closes incidents from known admin accounts hides the noise but does not prevent the rule from firing, and it risks suppressing a real incident if an admin account is compromised.

Practice this question →

121

Multi-Selectmedium

Which TWO of the following are valid actions that can be performed by an automation rule in Microsoft Sentinel? (Select two.)

Select 2 answers

A.Delete a watchlist

B.Create a task

C.Modify an analytics rule

D.Assign incident to an analyst

E.Run a playbook

AnswersD, E

Automation rules can assign an incident to an analyst by updating its owner field, typically using a property like Owner and a user principal name or object ID. This is a native action that helps route ownership immediately when an incident is created or when a condition such as severity is met, and it requires the same permissions as other incident updates. It is a valid action because it directly changes an incident property rather than a separate resource.

Why this answer

Automation rules in Microsoft Sentinel can assign incidents to specific analysts or groups as part of incident response workflows. This action helps ensure accountability and proper triage by routing incidents to the appropriate personnel based on criteria like severity or type.

Exam trap

The trap here is that candidates may confuse automation rule actions with other Sentinel capabilities, such as thinking automation rules can modify analytics rules or manage watchlists, when in fact those are separate administrative functions.

Practice this question →

122

MCQmedium

You are a SOC analyst using Microsoft Defender for Endpoint. You need to investigate a device that is suspected of being compromised. You want to collect a memory dump for offline analysis. Which action should you take from the Microsoft Defender XDR portal?

A.Initiate a live response session and use the 'Collect memory dump' command.

B.Isolate the device from the network to prevent further damage.

C.Run a PowerShell script through live response to copy the memory dump.

D.Run a full antivirus scan on the device.

AnswerA

Initiate a live response session and use the 'Collect memory dump' command because it is the built-in, Microsoft-supported method for acquiring a full physical memory image from a device. This command invokes a trusted kernel-mode component that captures all volatile data—including running processes, open network connections, injected code, and loaded drivers—without altering system state, making it the gold standard for forensic memory analysis in Microsoft Defender for Endpoint.

Why this answer

The 'Collect memory dump' command is a built-in capability within a live response session in Microsoft Defender for Endpoint. This command allows you to capture a full memory dump of the device for offline forensic analysis, which is essential for investigating a suspected compromise. It is specifically designed for this purpose and does not require additional scripting or external tools.

Exam trap

The trap here is that candidates may confuse the 'Collect memory dump' command with running a custom PowerShell script, assuming that any script can achieve the same result, but Microsoft Defender for Endpoint provides a dedicated, optimized command that ensures the dump is properly captured and uploaded without manual intervention.

How to eliminate wrong answers

Option B is wrong because isolating the device from the network is a containment action, not a method to collect a memory dump; it prevents further damage but does not provide the forensic data needed for offline analysis. Option C is wrong because while you can run PowerShell scripts through live response, there is no built-in 'copy memory dump' command; you would need to use the dedicated 'Collect memory dump' command instead, making this approach unnecessarily complex and error-prone. Option D is wrong because running a full antivirus scan is a reactive measure to detect malware, not a forensic data collection technique; it does not capture a memory dump for offline analysis.

Practice this question →

123

MCQmedium

You are a security operations analyst at a company that uses Microsoft Sentinel. You need to ensure that all incidents generated from Microsoft Defender for Cloud Apps are automatically assigned to the same SOC team. The team uses Microsoft Teams to collaborate. Which configuration should you implement?

A.Create a playbook that assigns the incident to the team and configure an automation rule to run it.

B.Create an automation rule that sets the owner to the team entity.

C.Configure the Microsoft Defender for Cloud Apps connector to assign incidents to the team.

D.Use a logic app to automatically post incidents to a Teams channel and have the team claim them.

AnswerB

Correct: In Microsoft Sentinel, an automation rule's actions include 'Assign owner,' which can set the Owner to either a specific user or a Microsoft Entra ID team (group). This assignment occurs natively during the incident lifecycle (e.g., immediately after creation) with no external service or manual step required. Simply create a rule with a trigger such as 'When incident creation' and the action 'Assign owner' to the appropriate team entity.

Why this answer

Automation rules in Microsoft Sentinel can directly set the incident owner to a specific user or group (such as a SOC team) without requiring a playbook. This ensures all incidents from Microsoft Defender for Cloud Apps are automatically assigned to the designated team, streamlining ownership and collaboration via Microsoft Teams.

Exam trap

The trap here is that candidates often assume a playbook or logic app is required for any custom action, but Microsoft Sentinel's automation rules can directly set the incident owner without additional orchestration.

How to eliminate wrong answers

Option A is wrong because creating a playbook to assign incidents is unnecessary overhead; automation rules can set the owner directly without invoking a playbook, which adds latency and complexity. Option C is wrong because the Microsoft Defender for Cloud Apps connector does not have a configuration to assign incidents to a team; incident assignment is handled within Sentinel's automation rules. Option D is wrong because using a logic app to post incidents to a Teams channel and having the team claim them is a manual, inefficient process that does not automatically assign ownership, and it bypasses Sentinel's built-in assignment capabilities.

Practice this question →

124

MCQeasy

Your security operations center (SOC) uses Microsoft Sentinel. Analysts need to collaborate on incidents by adding comments and changing severity. Which feature should they use?

A.Hunting

B.Playbooks

C.Workbooks

D.Incident management

AnswerD

Incident management in Microsoft Sentinel provides the collaborative workspace where analysts add comments and revise severity on the same incident record, satisfying the SOC's requirement to work together on investigations rather than duplicating effort across separate tools.

Why this answer

Incident management in Microsoft Sentinel provides the built-in capability for SOC analysts to collaborate on incidents by adding comments and changing severity. This feature allows multiple analysts to work on the same incident, track changes, and update the severity level directly within the incident interface, which is essential for effective teamwork and triage.

Exam trap

The trap here is that candidates often confuse Hunting or Workbooks as tools for incident collaboration because they involve data exploration, but they lack the direct incident editing and commenting capabilities that incident management provides.

How to eliminate wrong answers

Option A is wrong because Hunting is a proactive search for threats using KQL queries, not a feature for collaborating on existing incidents or modifying their severity. Option B is wrong because Playbooks are automated workflows triggered by incidents or alerts, designed for response actions, not for manual collaboration or severity changes. Option C is wrong because Workbooks are interactive dashboards for visualizing data and metrics, not for direct incident collaboration or severity updates.

Practice this question →

125

MCQmedium

Your team uses Microsoft Sentinel to monitor Azure subscriptions. You need to ensure that only users with the 'Microsoft Sentinel Contributor' role can create and edit analytics rules. You want to enforce this using Azure Policy. What should you do?

A.Create an Azure Policy that denies creation of analytics rules if the user doesn't have the 'Microsoft Sentinel Contributor' role.

B.Use Azure Blueprints to assign the 'Microsoft Sentinel Contributor' role to a security group.

C.Assign the 'Microsoft Sentinel Contributor' role to all users at the subscription level.

D.Create a custom role that denies write access to analytics rules.

AnswerA

Azure Policy can enforce RBAC at deployment time by using the `requestContext.roleDefinitionIds` property in a policy rule. A custom policy with a `deny` effect on Microsoft.SecurityInsights/alertRules evaluates the caller's roles and blocks creation of analytics rules unless the user holds the Sentinel Contributor role ID. This is a centralized, subscription-wide governance control that prevents unauthorized changes, unlike a one-time role assignment.

Why this answer

Azure Policy can enforce guardrails by denying resource creation or modification based on conditions, such as the user's role. By creating a policy that denies the creation or editing of analytics rules unless the user has the 'Microsoft Sentinel Contributor' role, you directly enforce the requirement. This approach uses Azure Policy's 'deny' effect to prevent unauthorized actions at the Azure Resource Manager level, regardless of other permissions.

Exam trap

The trap here is confusing Azure Policy (which enforces rules at resource creation/modification time) with Azure RBAC (which controls access to actions) or Azure Blueprints (which is a deployment tool), leading candidates to incorrectly choose role assignments or custom roles instead of a policy-based denial.

How to eliminate wrong answers

Option B is wrong because Azure Blueprints are used for orchestrating and deploying environments (e.g., role assignments, resource groups, policies) but do not themselves enforce runtime access control; they cannot dynamically deny actions based on the user's role. Option C is wrong because assigning the 'Microsoft Sentinel Contributor' role to all users at the subscription level would grant excessive permissions, violating the principle of least privilege and not enforcing the requirement that only specific users can create/edit rules. Option D is wrong because a custom role that denies write access to analytics rules would be ineffective; Azure RBAC roles grant permissions (allow), not deny, and a custom role with 'deny' actions is not a supported pattern—Azure Policy is the correct tool for explicit denial.

Practice this question →

126

Multi-Selecthard

Which THREE components are required to use Microsoft Sentinel's automation rules to automatically respond to incidents?

Select 3 answers

A.A playbook created in Azure Logic Apps.

B.An analytics rule generating alerts.

C.The appropriate permissions to run playbooks.

D.An automation rule with conditions and actions.

E.A Microsoft Sentinel workspace.

AnswersC, D, E

To execute a Logic Apps playbook from an automation rule, Sentinel invokes the Azure Resource Manager trigger using the identity of the user or service principal, which must hold Microsoft.Logic/workflows/triggers/run/action permission, often granted by the Sentinel Responder role. Without those permissions the playbook action is blocked and the automation rule reports a failure. Even if a playbook exists, the rule cannot trigger it unless the required permissions are assigned, so permissions are a required component.

Why this answer

Automation rules require appropriate permissions (e.g., Microsoft Sentinel Contributor or Automation Contributor) to execute playbooks. Without these permissions, the automation rule cannot invoke the playbook when an incident is created or updated, even if the rule and playbook are properly configured.

Exam trap

The trap here is that candidates often assume a playbook (Option A) or an analytics rule (Option B) is mandatory for automation rules, but Microsoft Sentinel automation rules can function without either—they only require a workspace, the rule itself, and appropriate permissions to execute actions.

Practice this question →

127

Multi-Selecteasy

Which TWO actions can be taken directly from the Microsoft Defender XDR incident queue? (Select TWO.)

Select 2 answers

A.Isolate a device involved in the incident

B.Modify a data connector's log collection

C.Change the incident status to 'In progress'

D.Create a new analytics rule

E.Create an automation rule

AnswersA, C

From the Microsoft Defender XDR incident queue, you can directly initiate isolation of a device involved in the incident, provided the device is onboarded to Microsoft Defender for Endpoint. This action is available through the device details pane or 'Take actions' menu, allowing an analyst to contain a compromised endpoint immediately. This capability is part of Defender's integrated response tools and does not require Sentinel.

Why this answer

The Microsoft Defender XDR incident queue provides direct actions, including device isolation, to contain threats without navigating to separate device management consoles. This capability is built into the incident investigation pane, allowing security analysts to quickly isolate a device involved in an incident from the unified queue.

Exam trap

The trap here is that candidates confuse the Defender XDR incident queue with the broader Microsoft Sentinel workspace, assuming all security operations tasks (like creating rules or modifying data connectors) are available from the incident queue, when in fact only incident-specific response actions are permitted.

Practice this question →

128

MCQhard

Your organization uses Microsoft Purview Compliance Manager to manage compliance activities. You need to assign a specific improvement action to a colleague for implementation. What should you do?

A.In the 'Improvement actions' tab, select the action and click 'Assign'

B.Create a new alert policy to notify the colleague

C.Modify the assessment to include the colleague as an owner

D.Use the 'Assessments' tab to delegate tasks

AnswerA

In Compliance Manager, an improvement action is the individual task that maps to a specific control or family of controls. Selecting the action and clicking 'Assign' lets you directly designate a user as the responsible party, which is the only built-in way to delegate accountability for that action. Once assigned, the action appears in the colleague's 'My improvement actions' list so they can track, update, and submit evidence for it.

Why this answer

In Microsoft Purview Compliance Manager, improvement actions are the specific tasks that need to be completed to meet compliance controls. Each improvement action can be directly assigned to a colleague by selecting the action in the 'Improvement actions' tab and clicking the 'Assign' button, which allows you to specify the assignee and due date. This is the intended workflow for delegating implementation responsibilities within Compliance Manager.

Exam trap

Microsoft often tests the distinction between assigning a specific improvement action versus modifying assessment ownership or using alert policies, so candidates mistakenly choose options that involve broader permissions or unrelated notification mechanisms instead of the direct assignment feature.

How to eliminate wrong answers

Option B is wrong because alert policies in Microsoft Purview are used to detect and notify about specific activities or threats (e.g., data loss prevention or insider risk events), not to assign improvement actions; they cannot delegate tasks. Option C is wrong because modifying an assessment to add a colleague as an owner changes the ownership of the entire assessment, not the assignment of a specific improvement action; this would give them broad control over the assessment rather than a single task. Option D is wrong because the 'Assessments' tab is used to manage assessments and their controls, not to delegate individual improvement actions; there is no task delegation feature in that tab.

Practice this question →

129

MCQmedium

Refer to the exhibit. You are a security analyst reviewing a KQL query in Microsoft Sentinel. The query is intended to show the count of high-severity malware alerts in the last 24 hours. However, the query returns results only for alerts with exact severity string 'High', but you also need to include 'Informational' severity alerts that are related to malware. What should you modify?

A.Remove the 'summarize' and 'order by' clauses.

B.Remove the 'where AlertName contains "malware"' condition.

C.Change the 'where AlertSeverity == "High"' to 'where AlertSeverity in ("High", "Informational")'.

D.Change 'ago(24h)' to 'ago(48h)'.

AnswerC

Changing the equality filter to use the 'in' operator with a set of allowed values is the correct fix because it explicitly instructs the query to include rows where AlertSeverity is either "High" or "Informational". The original predicate 'where AlertSeverity == "High"' only passes rows with that exact value, so anything marked Informational is discarded before aggregation. Using 'in' with both severity levels preserves the malware-name filter and the 24-hour timeframe while expanding the severity scope to match the investigation's requirement to review both High and Informational alerts.

Why this answer

The query currently filters only for alerts where AlertSeverity equals 'High', but the requirement is to also include 'Informational' severity alerts related to malware. By changing the condition to 'where AlertSeverity in ("High", "Informational")', the query will return both severity levels while keeping the malware-related filter and the 24-hour time window intact.

Exam trap

The trap here is that candidates may think the issue is with the time range (Option D) or the aggregation (Option A), when the actual problem is a simple missing filter condition for the 'Informational' severity level, which is a common oversight when requirements specify multiple severity values.

How to eliminate wrong answers

Option A is wrong because removing the 'summarize' and 'order by' clauses would only affect the aggregation and sorting of results, not the filtering of severity levels; the query would still exclude 'Informational' alerts. Option B is wrong because removing the 'where AlertName contains "malware"' condition would include all alerts regardless of whether they are related to malware, which violates the requirement to focus on malware alerts. Option D is wrong because changing 'ago(24h)' to 'ago(48h)' would expand the time window to 48 hours, but the requirement specifies the last 24 hours, and this change does not address the missing 'Informational' severity alerts.

Practice this question →

130

MCQmedium

You are a security operations analyst for a company that uses Microsoft Sentinel. The SOC wants to receive a Microsoft Teams notification whenever a high-severity incident is created. You need to configure this with the least administrative effort. What should you do?

A.Create an automation rule that triggers on incident creation, with a condition on severity, and an action to run a playbook that posts a message to Microsoft Teams.

B.Use the Microsoft Sentinel incident page and manually configure each analytics rule to send an email to a Teams channel.

C.Create a scheduled playbook that queries the SecurityIncident table for high-severity incidents every 5 minutes and posts new ones to Microsoft Teams.

D.Configure a Microsoft Sentinel workbook that displays high-severity incidents and set up a scheduled email subscription to the workbook.

AnswerA

Automation rules can trigger on incident creation and condition on severity. They can run a playbook, which can use the Microsoft Teams connector to post a message. This leverages native integration and requires minimal effort, as you only need to create the playbook and the automation rule.

Why this answer

The most efficient way to notify Teams on high-severity incident creation is to use an automation rule that triggers on incident creation, filters by severity, and runs a playbook. The playbook can use the Microsoft Teams connector to post a message. This is event-driven, immediate, and uses native integration, minimizing administrative effort.

Exam trap

The trap here is assuming that analytics rules can directly post to Teams or that workbooks provide real-time alerting, when a playbook triggered by an automation rule is required.

Practice this question →

131

Multi-Selectmedium

Which TWO actions should you take to improve the performance of Microsoft Sentinel analytics rules that are running slowly? (Choose two.)

Select 2 answers

A.Assign a higher severity to the rule

B.Reduce the query time window

C.Use summarized data in the query

D.Increase the rule run frequency

E.Add additional entity mapping

AnswersB, C

Reducing the query time window directly narrows the amount of log data that must be scanned by the detection rule, which lowers I/O and compute costs. For example, changing from 7 days to 24 hours can cut the data volume by roughly a factor of seven for a single execution, dramatically reducing latency and improving overall throughput without changing the query logic.

Why this answer

Reducing the query time window (Option B) directly limits the volume of data the analytics rule must process per execution, which reduces query latency and overall rule execution time. This is a common performance optimization because Sentinel analytics rules run KQL queries against the Log Analytics workspace, and smaller time ranges mean fewer log records to scan.

Exam trap

The trap here is that candidates often confuse rule configuration settings (like severity or frequency) with query performance optimizations, mistakenly thinking that increasing frequency or adding mappings will somehow speed up execution, when in fact they degrade it.

Practice this question →

132

MCQhard

Your organization uses Microsoft Defender XDR and Microsoft Sentinel. You need to create a custom detection rule that triggers when a user is added to a privileged role in Microsoft Entra ID and within 5 minutes performs a mass download from SharePoint. Which approach should you use?

A.Create an advanced hunting query in Microsoft Defender XDR

B.Use a custom detection rule in Microsoft 365 Defender

C.Use a Microsoft Purview insider risk policy

D.Create a scheduled query rule in Microsoft Sentinel

AnswerD

A Microsoft Sentinel scheduled query rule is correct because Sentinel is a cloud-native SIEM that can ingest logs from both Microsoft Defender XDR (via the Defender XDR connector) and Microsoft 365/Purview (via the Office 365 and Microsoft 365 connectors). Using KQL, you can join these multiple tables on a common field like user principal name within a defined time window; the rule then runs on a schedule, applies detection logic, and raises an alert that can trigger incident creation and SOAR playbooks, enabling cross-workload correlation that Defender and Purview tools alone cannot provide.

Why this answer

The detection requires correlating events across Microsoft Entra ID (privileged role assignment) and SharePoint (mass download) within a 5-minute window. Microsoft Sentinel's scheduled query rules can ingest data from multiple sources (e.g., AuditLogs for Entra ID and SharePoint via Office 365 connector) and use KQL to join these events with a time constraint, making it the only native solution for cross-domain, time-bound custom detections.

Exam trap

The trap here is that candidates assume Microsoft 365 Defender (now Defender XDR) can correlate all Microsoft 365 data, but its custom detection rules are restricted to Defender XDR tables, not Entra ID or SharePoint audit logs, which are only available in Sentinel via dedicated connectors.

How to eliminate wrong answers

Option A is wrong because advanced hunting queries in Microsoft Defender XDR are limited to data within the Defender ecosystem (e.g., device, identity, email signals) and cannot natively query Microsoft Entra ID audit logs or SharePoint activity logs. Option B is wrong because Microsoft 365 Defender custom detection rules (now part of Defender XDR) only support data from Defender XDR tables (e.g., IdentityLogonEvents, CloudAppEvents) and cannot directly ingest Entra ID role assignment events or SharePoint download events with the required granularity. Option C is wrong because Microsoft Purview insider risk policies are designed for user behavior analytics and risk scoring based on predefined indicators, not for creating custom, time-bound correlation rules with specific event thresholds.

Practice this question →

133

MCQmedium

Your company is deploying Microsoft Sentinel in a multi-tenant environment using Azure Lighthouse. You need to ensure that SOC analysts can triage incidents across all tenants from a single workspace. What is the minimum configuration required?

A.Create a second Sentinel workspace in the managing tenant and configure cross-workspace queries.

B.Configure Azure AD B2B collaboration to grant external users access to each tenant's Sentinel workspace.

C.Use Azure Policy to enforce a standard analytics rule across all tenants.

D.Onboard each tenant as a delegated resource under Azure Lighthouse, then route all logs to a single Sentinel workspace in the managing tenant.

AnswerD

Onboarding each tenant with Azure Lighthouse grants the managing tenant's users delegated access to administer resources, including configuring diagnostic settings and data connectors to route logs centrally. By sending all logs into a single Sentinel workspace in the managing tenant, events and alerts are consolidated and correlated in one analytical store, and Sentinel generates a unified incident queue for SOC analysts. This gives a single pane of glass for triage and response without the need to switch between tenants or manually craft cross-workspace KQL queries, which keeps the data fragmented.

Why this answer

Azure Lighthouse enables multi-tenant management by delegating subscriptions or resource groups from each tenant as delegated resources to the managing tenant. Once delegated, you can configure a single Microsoft Sentinel workspace in the managing tenant to ingest logs from all delegated tenants via diagnostic settings, allowing SOC analysts to triage incidents centrally without needing separate workspaces or cross-workspace queries.

Exam trap

The trap here is that candidates often confuse cross-workspace queries (Option A) as a valid centralized solution, but they fail to realize that Azure Lighthouse's delegated resource model is the minimum configuration required to route all logs into a single workspace without additional overhead.

How to eliminate wrong answers

Option A is wrong because creating a second Sentinel workspace in the managing tenant and using cross-workspace queries still requires maintaining multiple workspaces and does not centralize incident management into a single pane of glass; it only allows querying across workspaces, not unified triage. Option B is wrong because Azure AD B2B collaboration grants external user access to each tenant's Sentinel workspace individually, but it does not consolidate logs or incidents into a single workspace; analysts would still need to switch between tenants to triage incidents. Option C is wrong because Azure Policy enforces compliance rules (e.g., analytics rule deployment) but does not route logs or provide centralized incident triage; it is a governance tool, not a data ingestion or workspace unification solution.

Practice this question →

134

MCQmedium

Your security operations team uses Microsoft Sentinel workbooks to monitor security posture. You notice that a workbook query is timing out when run against a large workspace. What is the best way to optimize the query without changing its results?

A.Remove some filter conditions to simplify the query.

B.Add a summarize operator at the end of the query.

C.Use the workspace() function to query specific workspaces only.

D.Reduce the time range of the query.

AnswerC

Using the workspace() function, such as workspace('ContosoSOC'), explicitly constrains the query to named Log Analytics workspaces, which lets the execution engine skip irrelevant workspace partitions entirely. In Microsoft Sentinel workbooks, this is a standard way to avoid querying all accessible workspaces when the security data of interest is known. It reduces the data volume analyzed, improves query response time, and preserves the intended results as long as the targeted workspace holds the needed tables.

Why this answer

The `workspace()` function in KQL allows you to explicitly scope a query to specific workspaces, reducing the data scanned and improving performance. By targeting only the necessary workspaces, you avoid the overhead of querying the entire large workspace, which is the root cause of the timeout. This optimization does not alter the query logic or results, as it simply restricts the data source.

Exam trap

The trap here is that candidates often confuse query optimization with result modification, choosing to reduce the time range or remove filters, which changes the data returned, rather than using workspace scoping to limit the data source without affecting the query logic.

How to eliminate wrong answers

Option A is wrong because removing filter conditions would likely increase the data volume scanned, worsening performance, and it would change the query results by including more rows. Option B is wrong because adding a `summarize` operator at the end of the query does not reduce the initial data scan; it aggregates results after retrieval, which can actually increase processing time and memory usage. Option D is wrong because reducing the time range changes the query results by excluding older data, which violates the requirement to keep results unchanged.

Practice this question →

135

MCQhard

Your company uses Microsoft Defender for Cloud Apps to monitor cloud applications. You have discovered that a user is accessing a sanctioned cloud storage app from an IP address that belongs to a known malicious botnet. You need to automatically block the user's access to the app and require them to re-authenticate. You have already configured session policies in Defender for Cloud Apps. What should you do next?

A.Create an access policy in Defender for Cloud Apps to block the user.

B.Create an app governance policy in Microsoft Purview to block the app.

C.Configure a session policy in Defender for Cloud Apps with the action 'Block' and 'Require re-authentication'.

D.Create a device compliance policy in Microsoft Intune to block the device.

AnswerC

A session policy in Defender for Cloud Apps, when combined with Conditional Access App Control, can inspect and control app sessions in real time using a reverse proxy. Setting the action to 'Block' and 'Require re-authentication' immediately terminates the current session and forces the user to sign in again, thereby meeting the requirement of both blocking access and enforcing fresh authentication. This is the only option that provides both capabilities together, distinguishing it from access policies that lack the re-authentication action.

Why this answer

Session policies in Defender for Cloud Apps can enforce real-time controls on sanctioned apps. By configuring a session policy with the actions 'Block' and 'Require re-authentication', you can immediately terminate the user's session and force them to re-authenticate, which effectively blocks access from the malicious IP while ensuring the user re-verifies their identity.

Exam trap

The trap here is confusing session policies with access policies; access policies only block or allow at the app level without session-level controls like re-authentication, while session policies provide the granular, real-time actions needed for this scenario.

How to eliminate wrong answers

Option A is wrong because access policies in Defender for Cloud Apps control access based on user, device, or location but cannot enforce re-authentication within an active session; they only allow or block access at the app level. Option B is wrong because app governance policies in Microsoft Purview are designed for managing app permissions and compliance in Microsoft 365, not for blocking user access to cloud storage apps based on IP reputation. Option D is wrong because device compliance policies in Microsoft Intune enforce device-level security requirements (e.g., encryption, OS version) and cannot block access to a specific cloud app based on IP address or require re-authentication.

Practice this question →

136

MCQhard

Your SOC uses Microsoft Sentinel and Microsoft Defender XDR. You need to ensure that all incidents from Defender XDR are automatically synchronized to Sentinel. You have enabled the Defender XDR connector. However, some incidents are not appearing. What should you check first?

A.Check the connector's data filter settings for severity or status.

B.Confirm that the incident is displayed in a Sentinel workbook.

C.Ensure that alert grouping is enabled in Sentinel.

D.Verify that the Microsoft Defender XDR license is active.

AnswerA

The Microsoft Defender XDR connector in Sentinel exposes data filter settings that directly dictate which incidents are ingested based on severity and status. If an incident is missing, the most likely culprit is that its severity or status value is filtered out at the connector level. This filter operates before the incident ever reaches Sentinel, so no other workspace component would have a chance to ingest it.

Why this answer

The Defender XDR connector in Microsoft Sentinel allows filtering of incidents based on severity and status during configuration. If incidents are not appearing, the most common cause is that the connector's data filter settings are excluding them—for example, filtering out 'Informational' severity or 'Resolved' status incidents. This is the first thing to check because the connector is enabled and working, but the filter is preventing synchronization of certain incidents.

Exam trap

The trap here is that candidates assume the connector is fully functional once enabled, overlooking the granular filter settings that control which incidents are actually ingested.

How to eliminate wrong answers

Option B is wrong because Sentinel workbooks are visualization tools that display data already ingested; they do not control incident ingestion or synchronization. Option C is wrong because alert grouping in Sentinel is a feature for grouping related alerts into incidents, but it does not affect the initial ingestion of incidents from Defender XDR. Option D is wrong because if the Defender XDR license were inactive, the connector would likely fail entirely or show a connection error, not selectively miss some incidents.

Practice this question →

137

MCQhard

Your organization uses Microsoft Defender for Cloud Apps. You need to block downloads from unmanaged devices for a specific cloud app. What should you configure?

A.Create a file policy with a governance action.

B.Create a session policy with device tag condition.

C.Create an app permissions policy.

D.Create an anomaly detection policy.

AnswerB

This is correct because Defender for Cloud Apps session policies leverage conditional access app control to enforce real-time session restrictions based on contextual conditions like device tags. By configuring a condition that targets unmanaged devices (using the device tag), the policy can explicitly block or warn on downloads within the user's active browser session. This works by routing the session through the reversing proxy in Defender for Cloud Apps, which inspects and controls actions such as file downloads, uploads, and copy/paste before they reach the user's endpoint.

Why this answer

Session policies in Microsoft Defender for Cloud Apps allow you to control user activities in real time based on device tags. By configuring a session policy with a device tag condition (e.g., 'Device tag equals Unmanaged'), you can enforce actions like blocking downloads from unmanaged devices for a specific cloud app, leveraging reverse proxy architecture to inspect and control traffic.

Exam trap

The trap here is that candidates often confuse session policies (real-time proxy control) with file policies (data-at-rest governance) or anomaly detection (behavioral alerts), failing to recognize that device tag conditions are exclusive to session policies for conditional access on unmanaged devices.

How to eliminate wrong answers

Option A is wrong because file policies are designed to detect and govern data at rest (e.g., files stored in cloud apps) using content inspection and governance actions like quarantine or apply label, not to control real-time download actions from unmanaged devices. Option C is wrong because app permissions policies govern OAuth app permissions (e.g., third-party app access to cloud app data), not device-based download blocking. Option D is wrong because anomaly detection policies identify suspicious user or entity behavior (e.g., impossible travel, mass download) but cannot enforce device-specific conditional access like blocking downloads from unmanaged devices.

Practice this question →

138

MCQmedium

Your organization uses Microsoft Defender for Cloud and you need to ensure that security recommendations are automatically remediated for non-compliant resources. You have enabled 'Auto provisioning' for the Log Analytics agent. What additional step is required to enable automatic remediation?

A.No additional step is required; auto provisioning automatically remediates

B.Configure manual remediation in Defender for Cloud

C.Enable the 'DeployIfNotExists' policy for specific recommendations

D.Create a custom Azure Policy initiative with audit effect

AnswerC

The DeployIfNotExists policy effect is the correct method because it automatically deploys a required configuration or resource when Azure Policy evaluates a resource as non-compliant. When you assign such a policy for a specific Defender for Cloud recommendation, it performs the remediation task on the spot and continuously in subsequent evaluations. This makes it the only automated approach listed that actually fixes the underlying issue.

Why this answer

Enabling 'Auto provisioning' for the Log Analytics agent only ensures the agent is installed on VMs, but does not automatically remediate security recommendations. To achieve automatic remediation, you must enable the 'DeployIfNotExists' effect on specific Azure Policy definitions (e.g., 'System updates should be installed on your machines'), which triggers remediation tasks when resources are non-compliant. This is a separate step in Defender for Cloud's 'Security policy' blade under 'Settings & monitoring'.

Exam trap

The trap here is that candidates confuse 'Auto provisioning' (which only deploys the Log Analytics agent) with automatic remediation of all security recommendations, leading them to incorrectly select Option A.

How to eliminate wrong answers

Option A is wrong because 'Auto provisioning' only handles agent deployment, not remediation of recommendations; it does not automatically fix non-compliant resources. Option B is wrong because 'manual remediation' requires human intervention to apply fixes, which contradicts the goal of automatic remediation. Option D is wrong because creating a custom Azure Policy initiative with 'audit' effect only logs non-compliance without taking any corrective action; you need 'DeployIfNotExists' or 'Modify' effects for automatic remediation.

Practice this question →

139

MCQmedium

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

A.Configure the Microsoft 365 Defender data connector.

B.Configure the Azure Activity data connector.

C.Create a custom log table and a PowerShell script to push alerts.

D.Configure the Microsoft Defender for Cloud data connector (Legacy).

AnswerD

The Microsoft Defender for Cloud data connector (Legacy) directly ingests security alerts from Defender for Cloud into Microsoft Sentinel via the Azure Resource Graph API, satisfying the requirement for automatic ingestion without manual forwarding. This connector specifically handles cloud security alerts, not broader signals, aligning with the stem’s constraint of ingesting all cloud security alerts from Defender for Cloud into Sentinel.

Why this answer

The Microsoft Defender for Cloud data connector (Legacy) is the correct choice because it specifically ingests security alerts from Microsoft Defender for Cloud into Microsoft Sentinel. This connector ensures that all alerts generated by Defender for Cloud's security policies and threat detection are automatically streamed into Sentinel for centralized monitoring and incident response.

Exam trap

The trap here is that candidates often confuse the Microsoft 365 Defender data connector (which handles endpoint and office alerts) with the Defender for Cloud data connector (which handles cloud security alerts), leading them to select option A incorrectly.

How to eliminate wrong answers

Option A is wrong because the Microsoft 365 Defender data connector ingests alerts from Microsoft 365 Defender (e.g., Defender for Endpoint, Defender for Office 365), not from Microsoft Defender for Cloud. Option B is wrong because the Azure Activity data connector ingests subscription-level operational logs (e.g., resource creation, policy changes) from the Azure Activity Log, not security alerts from Defender for Cloud. Option C is wrong because creating a custom log table and a PowerShell script is an inefficient, manual workaround that bypasses the native, automated integration provided by the Defender for Cloud data connector; it is not the recommended or supported method for this requirement.

Practice this question →

140

MCQmedium

You are a security analyst for a company that uses Microsoft Defender for Office 365. You receive an incident indicating that a user reported a phishing email. You need to investigate the email and determine if it was delivered to other users. You also need to ensure that similar emails are blocked in the future. What should you do?

A.Use Threat Explorer to search for similar emails and delete them.

B.Submit the email to Microsoft for analysis and quarantine it.

C.Create a Safe Links policy to block URLs in the email.

D.Run a simulated phishing attack to test user awareness.

AnswerA

Threat Explorer in Microsoft 365 Defender provides deep email search across mailboxes and enables bulk remediation actions such as soft/hard delete. By filtering on sender, subject, or URL, you can identify every instance of this phishing campaign and purge them directly, which immediately contains the threat and prevents further user exposure.

Why this answer

Threat Explorer in Microsoft Defender for Office 365 allows you to search for and take bulk action on emails matching specific criteria, such as sender, subject, or URL. By using Threat Explorer, you can identify all instances of the reported phishing email across your tenant and delete them from user mailboxes, which directly addresses the need to determine if the email was delivered to other users and to remediate it. This tool is designed for hunting and remediation, making it the correct choice for this investigation.

Exam trap

The trap here is that candidates often confuse the investigative and remediation capabilities of Threat Explorer with the policy-based prevention features of Safe Links or Safe Attachments, leading them to choose a policy creation option (C) instead of the correct hunting and removal tool (A).

How to eliminate wrong answers

Option B is wrong because submitting the email to Microsoft for analysis is a reactive step that helps improve detection but does not immediately identify other recipients or remove the email from their mailboxes; quarantine is a separate action that may not cover all delivery scenarios. Option C is wrong because creating a Safe Links policy blocks URLs in future emails but does not help investigate whether the current phishing email was delivered to other users or remove it from their inboxes. Option D is wrong because running a simulated phishing attack tests user awareness but does not investigate the current incident or block similar emails in the future.

Practice this question →

141

Multi-Selecteasy

Which TWO features are available in Microsoft Sentinel to automate incident response?

Select 2 answers

A.Playbooks based on Azure Logic Apps.

B.Workbooks.

C.Kusto Query Language (KQL) queries.

D.UEBA.

E.Automation rules.

AnswersA, E

Playbooks built on Azure Logic Apps provide the orchestration engine in Microsoft Sentinel, running multi-step response workflows triggered manually or by automation rules. They connect to Microsoft Entra ID, Defender and third-party tools, satisfying the requirement for automated incident response actions such as enrichment, notification and remediation.

Why this answer

Playbooks based on Azure Logic Apps (A) are the core automation mechanism in Microsoft Sentinel: they are Logic Apps workflows triggered by analytics rules or incidents that can run actions such as blocking an IP, posting to Teams, or opening a ticket, so they directly automate incident response. Automation rules (E) are also correct because they let you centrally manage and orchestrate incident handling — assigning owners, changing severity or status, tagging, and triggering playbooks — without writing code, which is exactly automation of incident response. Workbooks (B) are only for visualization and reporting dashboards, and KQL queries (C) are the query language used for hunting and analytics, not an automation feature.

UEBA (D) provides behavioral analytics and entity insights to enrich detection, but it does not itself automate response actions.

Exam trap

The trap here is that candidates often confuse detection or analysis tools (Workbooks, KQL, UEBA) with automation tools, failing to recognize that only Playbooks and Automation Rules provide the actual execution of response actions in Sentinel.

Practice this question →

142

MCQeasy

You are a security operations analyst for a company that uses Microsoft Sentinel. You need to create a workbook that displays the top 10 most common alert types over the last 7 days. The workbook will be used by the SOC manager to identify trends. You have already created a new workbook and added a query step. Which KQL query should you use in the query step?

A.AlertInfo | where TimeGenerated > ago(7d) | project AlertName

B.AlertInfo | where TimeGenerated > ago(7d) | project AlertName, count()

C.AlertInfo | where TimeGenerated > ago(7d) | summarize Count = count() by AlertName | top 10 by Count desc | render barchart

D.AlertInfo | where TimeGenerated > ago(7d) | summarize count() by bin(TimeGenerated, 1d) | render timechart

AnswerC

This query filters alerts from the last 7 days, then groups them by AlertName using summarize to count occurrences per alert type. The top 10 operator sorts the aggregated counts in descending order and returns the ten alert names with the highest frequencies, and render barchart visualizes the result as a bar chart. This satisfies the requirement to display the top 10 alert names by count.

Why this answer

It uses the `summarize` operator to count alerts by `AlertName`, then `top 10 by Count desc` to return the ten most frequent alert types, and `render barchart` to visualize the data in the workbook. This directly meets the requirement to display the top 10 most common alert types over the last 7 days.

Exam trap

The trap here is that candidates often confuse the `project` operator with `summarize`, mistakenly thinking they can use `count()` in a `project` clause, or they choose a query that shows alert volume over time instead of the top alert types by name.

How to eliminate wrong answers

Option A is wrong because it only projects the `AlertName` column without any aggregation, so it would return a list of all individual alerts rather than a count of the most common types. Option B is wrong because `project AlertName, count()` is invalid syntax; `count()` is an aggregation function that must be used within a `summarize` operator, not in a `project` clause. Option D is wrong because it summarizes by `bin(TimeGenerated, 1d)`, which groups alerts by day rather than by alert name, and renders a timechart showing alert volume over time, not the top 10 alert types.

Practice this question →

143

MCQmedium

Refer to the exhibit. You are configuring a Microsoft Sentinel Windows Security Events via AMA connector using an ARM template. After deployment, you notice that no Windows events are being ingested. The AMA agent is installed on the Windows servers. What is the most likely issue?

A.The WindowsEvent and SecurityEvent data types are disabled.

B.The Azure Monitor Agent is not installed on the servers.

C.The data collection rule is not associated with the virtual machines.

D.The workspace ID is missing from the template.

AnswerC

An Azure Monitor Agent only collects events once it is linked to a data collection rule (DCR), and that DCR must be explicitly associated with each virtual machine in its scope. The template likely creates the DCR object and defines the WindowsEvent and SecurityEvent data sources, but without a scope assignment or association to the target VMs, the agent receives no instruction on what to collect. This perfectly explains why the tables exist and the agent is installed, yet no Windows security events appear in Sentinel.

Why this answer

The most likely issue is that the data collection rule (DCR) is not associated with the virtual machines. Even when the Azure Monitor Agent (AMA) is installed, it will not send any Windows security events to Microsoft Sentinel unless a DCR is linked to the VM. The DCR defines which events to collect and where to send them; without this association, the agent has no instructions and remains idle.

Exam trap

The trap here is that candidates often assume installing the agent is sufficient for data ingestion, but Microsoft Sentinel requires the explicit link of a Data Collection Rule to the VM to define what events to collect and where to send them.

How to eliminate wrong answers

Option A is wrong because the WindowsEvent and SecurityEvent data types are not 'disabled' in the ARM template context; they are schema tables in the Log Analytics workspace, and the DCR controls which events are collected, not a toggle on the data types themselves. Option B is wrong because the question explicitly states 'The AMA agent is installed on the Windows servers,' so the agent is present and this is not the issue. Option D is wrong because the workspace ID is a required parameter in the ARM template for the DCR destination, and if it were missing, the template deployment would fail outright, not result in silent ingestion failure after deployment.

Practice this question →

144

Multi-Selecteasy

Your organization plans to implement Microsoft Sentinel. Which THREE components are required for a basic deployment? (Choose three.)

Select 3 answers

A.User and Entity Behavior Analytics (UEBA) enabled.

B.Analytics rules to generate incidents.

C.At least one data connector enabled.

D.Bookmarks for incident investigations.

E.A Log Analytics workspace.

AnswersB, C, E

Analytics rules are the core detection mechanism in Microsoft Sentinel that turn raw alerts into actionable incidents. To generate incidents, you must configure at least one analytics rule with incident creation enabled, using a KQL query to match threats. Without these rules, even with data ingested, Sentinel cannot automatically create security incidents.

Why this answer

Analytics rules are required to generate incidents from the data ingested into Microsoft Sentinel. Without analytics rules, the raw log data remains unprocessed and no security incidents are created, making the deployment non-functional for detection and response.

Exam trap

The trap here is that candidates often mistake optional advanced features like UEBA or bookmarks as required components, when in fact only the workspace, a data connector, and analytics rules are necessary to establish a basic, functional Sentinel deployment.

Practice this question →

145

MCQhard

You are a security operations architect for a company that uses Microsoft Sentinel in a hybrid environment with multiple workspaces. The company has a central SOC team that needs to view incidents from all workspaces in a single pane of glass. Each workspace belongs to a different business unit and has its own retention and access policies. You need to design a solution that provides centralized incident management without duplicating data or requiring users to switch workspaces. You also need to ensure that the SOC team can perform actions on incidents across workspaces. What should you do?

A.Create a playbook that copies incidents from all workspaces to a central workspace.

B.Use Microsoft Sentinel incident multi-view to connect all workspaces.

C.Use the Microsoft Sentinel data connector to connect all workspaces to a central workspace.

D.Create a new Log Analytics workspace that ingests data from all workspaces via diagnostic settings.

AnswerB

Microsoft Sentinel incident multi-view natively connects all workspaces by allowing a single dedicated workspace to display incidents from every workspace in a resource scope through the Incidents interface. This provides a centralized incident queue without moving or duplicating log data; analysts can triage and assign incidents across the enterprise while maintaining the original workspace context. It is the correct approach for centralized incident management in a distributed Sentinel deployment.

Why this answer

Microsoft Sentinel incident multi-view allows SOC teams to view and manage incidents across multiple workspaces from a single interface without duplicating data. This feature provides a centralized pane of glass while respecting each workspace's independent retention and access policies, and it enables cross-workspace incident actions without requiring users to switch contexts.

Exam trap

The trap here is that candidates often confuse data connectors or workspace aggregation with incident-level cross-workspace management, failing to realize that incident multi-view is the only native feature that provides a single pane of glass without data duplication or policy compromise.

How to eliminate wrong answers

Option A is wrong because creating a playbook to copy incidents duplicates data, increases storage costs, and violates the requirement to avoid data duplication; it also introduces latency and complexity. Option C is wrong because the Microsoft Sentinel data connector ingests log data into a central workspace, which duplicates data and merges retention/access policies, contradicting the requirement for each workspace to maintain its own policies. Option D is wrong because creating a new Log Analytics workspace that ingests data via diagnostic settings duplicates all log data, incurs additional ingestion and storage costs, and does not provide native incident management capabilities across workspaces.

Practice this question →

146

MCQmedium

Your organization uses Microsoft Sentinel and Microsoft Defender XDR. You need to ensure that a new SOC analyst can triage incidents without being able to delete or modify analytics rules. Which role should you assign?

A.Security Reader

B.Microsoft Sentinel Reader

C.Global Reader

D.Security Operator

AnswerB

The Microsoft Sentinel Reader role is an Azure RBAC scoped to the Sentinel workspace, providing full read-only visibility into incidents, analytics rules, workbooks, and threat intelligence. It allows you to view all Sentinel data and configuration settings without permitting any edits, making it the appropriate role for a user who only needs to monitor security events. Because it is purpose-built for Sentinel, it grants direct access to analytics rules and incident details that other read-only Azure roles lack.

Why this answer

Microsoft Sentinel Reader provides read-only access to Sentinel data, including incidents, workbooks, and analytics rules, but explicitly prevents any modifications or deletions. This role is ideal for SOC analysts who need to triage incidents without altering detection configurations. Security Reader and Global Reader lack Sentinel-specific incident triage permissions, while Security Operator allows modification of incidents, which exceeds the required scope.

Exam trap

The trap here is that candidates often confuse Security Reader (which provides broad read-only access across security services) with Sentinel Reader (which is Sentinel-specific), or they assume Security Operator is sufficient because it allows incident management, but it does not grant the Sentinel-specific read permissions needed to view analytics rules without modification capabilities.

How to eliminate wrong answers

Option A is wrong because Security Reader provides read-only access to security configurations and alerts in Microsoft Defender XDR but does not include the Sentinel-specific permissions needed to triage incidents in the Sentinel portal. Option C is wrong because Global Reader grants read-only access across all Azure services, including Sentinel, but it is overly broad and not scoped to Sentinel incident triage; it also does not provide the precise Sentinel Reader permissions required. Option D is wrong because Security Operator allows management of incidents (e.g., changing status, assigning ownership) in Microsoft Defender XDR, which would permit modifications beyond triage, and it does not grant the Sentinel-specific read-only access needed for analytics rules.

Practice this question →

147

Multi-Selecteasy

You are investigating a phishing incident in Microsoft Defender for Office 365. Which THREE pieces of information are available in the Threat Explorer?

Select 3 answers

A.Email body content

B.User's mailbox audit log

C.Sender IP address

D.Delivery action (e.g., blocked, delivered to Junk)

E.Email subject and sender address

AnswersC, D, E

In Threat Explorer, each message record exposes the SenderIP property, populated from transport-level message tracking data (e.g., MessageTrace). This property is directly filterable in the UI, enabling investigators to pivot on the exact IPv4 or IPv6 address that originated the message. Because the question asks which finding could be used to attribute the message to a source host, Sender IP is a legitimate and expected column in Threat Explorer.

Why this answer

Sender IP address is available in Threat Explorer because it is a core property of email message trace data in Microsoft Defender for Office 365. Threat Explorer captures the originating IP address from the SMTP session header, which is essential for identifying the source of a phishing attack and correlating with threat intelligence feeds.

Exam trap

The SC-200 exam often tests the misconception that Threat Explorer provides full email body content or mailbox audit logs, when in reality it only exposes metadata and delivery actions, not the actual message body or user-level audit events.

Practice this question →

148

MCQmedium

Your organization uses Microsoft Defender for Office 365. You need to ensure that when a user reports a phishing email via the built-in Outlook add-in, an automated investigation is triggered in Microsoft 365 Defender. What should you configure?

A.Define a safe links policy.

B.Enable user-reported message settings in the Microsoft 365 Defender portal.

C.Configure an anti-phishing policy.

D.Set up a safe attachments policy.

AnswerB

User-reported message settings in the Microsoft 365 Defender portal control how messages reported by end users via the Report Message or Report Phishing add-ins are processed. By enabling these settings and selecting the appropriate option, you can route reported messages to Microsoft or to a custom mailbox, and—critically—you can choose to automatically trigger an investigation and response (AIR) in Defender for Office 365 on those reports. This is the only setting among the options that directly ties user reporting to automated investigation.

Why this answer

Enabling user-reported message settings in the Microsoft 365 Defender portal allows messages reported via the built-in Outlook add-in to automatically trigger an automated investigation (AIR) in Microsoft 365 Defender. This configuration ties the user reporting action directly to the incident response workflow, enabling the system to analyze the reported email and initiate remediation steps without manual intervention.

Exam trap

The trap here is that candidates often confuse the configuration for automated investigation triggers with anti-phishing or safe links policies, not realizing that the user-reported message settings are the specific control that bridges user reporting to automated incident response.

How to eliminate wrong answers

Option A is wrong because a safe links policy protects users from malicious URLs in emails and Office documents, but it does not control how user-reported messages trigger automated investigations. Option C is wrong because an anti-phishing policy defines protection against phishing attempts (e.g., impersonation, spoofing) but does not configure the automated investigation trigger for user-reported emails. Option D is wrong because a safe attachments policy scans email attachments for malicious content using detonation in a sandbox, but it does not enable the automated investigation flow from user-reported messages.

Practice this question →

149

MCQmedium

Your organization is using Microsoft Defender for Identity (MDI) and Microsoft Sentinel. The security team wants to correlate alerts from MDI with other data sources in Sentinel. What is the recommended approach?

A.Export MDI logs manually to Sentinel

B.Configure MDI to send syslog to Sentinel

C.Create a playbook to pull MDI alerts

D.Enable the Microsoft Defender for Identity data connector in Sentinel

AnswerD

Enabling the Microsoft Defender for Identity data connector is the correct method because it establishes an automated, native ingestion pipeline between MDI and Microsoft Sentinel. Once connected, MDI alerts and related entities are streamed into the Sentinel `SecurityAlert` and `IdentityLogonEvents` tables, enabling detection rules, hunting, and incident correlation. The connector uses the Microsoft Graph security API and requires appropriate permissions on the MDI instance, but after configuration it runs continuously without manual intervention.

Why this answer

The Microsoft Defender for Identity data connector in Microsoft Sentinel is the recommended approach because it provides native, out-of-the-box integration that automatically ingests MDI alerts and events into Sentinel without requiring additional infrastructure or manual configuration. This connector leverages the Microsoft Graph Security API to pull alerts, enabling seamless correlation with other data sources for unified threat detection and investigation.

Exam trap

The trap here is that candidates may overcomplicate the solution by thinking a custom integration (like a playbook or syslog) is needed, when Microsoft provides a native connector that handles ingestion automatically and is the simplest, most reliable method.

How to eliminate wrong answers

Option A is wrong because manually exporting MDI logs to Sentinel is inefficient, error-prone, and not scalable; Sentinel is designed for automated ingestion via connectors, not manual uploads. Option B is wrong because MDI does not natively support syslog export; it uses its own sensor and cloud service, and syslog would require a custom forwarder or third-party tool, adding complexity and potential data loss. Option C is wrong because creating a playbook to pull MDI alerts is an unnecessary workaround; the built-in data connector already handles ingestion automatically, and playbooks are for automated response, not data collection.

Practice this question →

150

MCQeasy

Refer to the exhibit. A SOC analyst runs this KQL query in Microsoft Sentinel. What is the purpose of this query?

A.Detect brute force attempts by finding users with many failed sign-ins from a single IP

B.List all successful sign-ins in the last hour

C.Identify users who successfully signed in from multiple IPs

D.Find users with more than 5 failed sign-ins from an IP address in the last hour

AnswerD

This is the correct interpretation. The query groups the sign-in log by UserPrincipalName and IPAddress, counts the rows within the last hour, and then uses a filter to keep only groups with a count greater than 5. Because the source data is filtered to failed sign-ins, the result is exactly a list of users who have more than 5 failed sign-ins from the same IP address within that time window, which is a common brute-force detection pattern.

Why this answer

The KQL query filters for events where the result type is 'Failure' (failed sign-ins), then groups by account and IP address, counting occurrences. The `where count_ > 5` clause ensures only accounts with more than 5 failed sign-ins from a single IP are returned, which is a classic indicator of a brute force attack. This directly matches option D.

Exam trap

The trap here is that candidates may confuse 'failed sign-ins from a single IP' (option D) with 'many failed sign-ins' (option A), missing the explicit threshold of >5 in the query.

How to eliminate wrong answers

Option A is wrong because the query specifically counts failed sign-ins per IP and user, not just any user with many failed sign-ins from a single IP—it requires more than 5 failures, not just 'many'. Option B is wrong because the query filters for 'Failure' events, not successful sign-ins, and it groups by IP and user rather than listing all successful sign-ins. Option C is wrong because the query focuses on failed sign-ins, not successful ones, and it groups by single IP per user, not multiple IPs.

Practice this question →