Courseiva

CCNA Manage a security operations environment Questions

75 of 464 questions · Page 1/7 · Manage a security operations environment · Answers revealed

Practice these questionsDomain overviewAll questions
1
MCQeasy

Your SOC team uses Microsoft Sentinel incident investigation. An analyst needs to quickly see all related entities (users, IPs, machines) for an incident. Which feature should the analyst use?

A.Incident timeline
B.Hunting blade
C.Entity behavior analytics page
D.Incident investigation graph
AnswerD

The Incident investigation graph is the correct choice because it presents an interactive, visual map of all entities (e.g., IPs, hosts, accounts, and files) related to the incident, along with the edges representing their relationships. This graph helps you quickly identify potential attack vectors and pivot between connected entities to understand the full scope of the incident, fulfilling the SOC team's requirement to see all related entities in one view.

Why this answer

The Incident investigation graph in Microsoft Sentinel provides a visual, interactive map of all entities (users, IPs, machines) linked to an incident, allowing analysts to quickly see relationships and pivot between entities. This is the dedicated feature for entity-centric incident exploration, unlike other options that serve different purposes.

Exam trap

Microsoft often tests the distinction between a chronological timeline (incident timeline) and a relational graph (investigation graph), leading candidates to confuse the incident timeline's alert sequence with the entity relationship view.

How to eliminate wrong answers

Option A is wrong because the Incident timeline shows a chronological list of alerts and activities within an incident, not a visual graph of related entities. Option B is wrong because the Hunting blade is used for proactive threat hunting with KQL queries, not for viewing entities tied to an existing incident. Option C is wrong because the Entity behavior analytics page provides behavioral insights and anomalies for a single entity over time, not a consolidated view of all entities related to an incident.

Practice this question →
2
MCQeasy

Refer to the exhibit. You are running a PowerShell script to enable the Anomalies setting in Microsoft Sentinel. After running the script, you check the Sentinel settings in the portal and see that Anomalies is still disabled. What is the most likely reason?

A.The cmdlet 'Set-AzSentinelSetting' does not exist in the Az module.
B.The user does not have Contributor permissions on the workspace.
C.The script requires the -PassThru parameter to apply changes.
D.The workspace was not retrieved correctly because the name is misspelled.
AnswerA

The non-existence of 'Set-AzSentinelSetting' in the Az module directly explains why the Anomalies setting remains disabled. PowerShell scripts fail when attempting to invoke cmdlets that are not recognised or do not exist within the loaded modules. This scenario indicates the script encountered an execution error because the specified cmdlet for modifying Sentinel settings was not found, preventing the intended configuration change from being applied.

Why this answer

The cmdlet 'Set-AzSentinelSetting' does not exist in the official Az.SecurityInsights module. Microsoft Sentinel settings, including Anomalies, are managed via the REST API or the 'Update-AzSentinelSetting' cmdlet (part of the Az.SecurityInsights preview module). Running a non-existent cmdlet would produce an error, not apply any changes, leaving Anomalies disabled in the portal.

Exam trap

The trap here is that candidates assume all Azure PowerShell cmdlets follow the 'Set-*' naming convention, but Microsoft Sentinel settings specifically use 'Update-*' in the Az.SecurityInsights module, leading to the mistaken belief that 'Set-AzSentinelSetting' is valid.

How to eliminate wrong answers

Option B is wrong because Contributor permissions on the workspace are sufficient to modify Sentinel settings; the issue is the cmdlet itself, not permissions. Option C is wrong because the -PassThru parameter is used to output the result object but is not required for the change to apply; its absence does not prevent the setting from being saved. Option D is wrong because even if the workspace name were misspelled, the script would fail with a 'workspace not found' error, not silently leave Anomalies disabled; the question states the script ran, implying no retrieval error.

Practice this question →
3
MCQhard

Your organization uses Microsoft Sentinel with UEBA enabled. You need to identify anomalous user behavior that indicates a potential compromise. Which entity behavior analytics feature should you use?

A.Automation rules
B.Hunting queries
C.Entity behavior analytics peer comparison
D.Anomaly rules in analytics
AnswerC

Entity behavior analytics in Microsoft Sentinel uses UEBA to build a historical behavioral profile for each user, host, or other entity, including attributes like sign-in times, accessed apps, and resource usage. It then performs peer comparison by grouping entities with similar roles or attributes and statistically identifies when an individual's current behavior deviates from the group's baseline, such as an unusual location or impossible travel. This automated, baseline-driven peer comparison is precisely how UEBA detects anomalies, making it the correct answer.

Why this answer

Entity behavior analytics peer comparison (option C) is the correct feature because it uses UEBA to compare a user's activities against their historical baseline and peer group behavior to detect anomalies indicative of compromise. This directly addresses the requirement to identify anomalous user behavior, as peer comparison highlights deviations like unusual access patterns or data exfiltration attempts that single-entity baselines might miss.

Exam trap

The trap here is that candidates often confuse anomaly rules in analytics (option D) with UEBA peer comparison, but anomaly rules are generic detection mechanisms that do not inherently use peer-group baselines, whereas peer comparison is a dedicated UEBA capability for entity-specific anomaly detection.

How to eliminate wrong answers

Option A is wrong because automation rules are used to automate incident response actions (e.g., assigning tasks or triggering playbooks) based on alerts, not to analyze entity behavior for anomalies. Option B is wrong because hunting queries are proactive KQL-based searches for threats across log data, not a built-in UEBA feature that continuously compares entity behavior against peers. Option D is wrong because anomaly rules in analytics are scheduled or near-real-time detection rules that flag anomalies based on static thresholds or machine learning models, but they do not specifically leverage peer comparison for entity behavior analytics.

Practice this question →
4
MCQeasy

Your organization uses Microsoft Sentinel and Microsoft Defender XDR. You need to ensure that all incidents from Microsoft Defender XDR are synchronized to Microsoft Sentinel with the same status (e.g., 'Active', 'Resolved'). What should you configure?

A.Create a custom playbook to poll Defender XDR API and update Sentinel incidents.
B.Connect Microsoft Defender XDR to Microsoft Sentinel using the official data connector.
C.Manually update status in both systems.
D.Disable the Microsoft Defender XDR connector and use separate connectors for each workload.
AnswerB

Ingesting Microsoft Defender XDR incidents through its official data connector is the supported first-party integration path and the only method that provides bi-directional synchronization natively. After you enable the connector, incidents created in Defender XDR appear in Sentinel and any analyst status update—such as resolved or closed—is written back to Defender XDR, and vice versa, through an automated sync mechanism. This approach preserves the full incident context and correlation across Defender workloads instead of just importing raw alerts.

Why this answer

The official Microsoft Defender XDR data connector in Microsoft Sentinel automatically synchronizes incidents, including their status (e.g., 'Active', 'Resolved'), bidirectionally. This ensures that any status change in either system is reflected in the other without manual intervention or custom scripting. Option B is correct because it leverages the built-in integration that handles the synchronization natively.

Exam trap

The trap here is that candidates may think a custom playbook or API polling is required for synchronization, not realizing that the official connector already handles bidirectional status updates natively.

How to eliminate wrong answers

Option A is wrong because creating a custom playbook to poll the Defender XDR API is unnecessary and introduces complexity, latency, and potential for errors; the official connector already provides real-time bidirectional synchronization. Option C is wrong because manually updating status in both systems is inefficient, error-prone, and defeats the purpose of automated security operations; it does not scale and violates the principle of a single pane of glass. Option D is wrong because disabling the Microsoft Defender XDR connector and using separate connectors for each workload would break the unified incident correlation and status synchronization that the single connector provides, leading to fragmented incident management.

Practice this question →
5
MCQhard

Your SOC uses Microsoft Sentinel and Microsoft Defender XDR. An incident is created from a Defender for Endpoint alert about a malware detection on a device. The incident has low priority, but you want to automatically isolate the device from the network if the alert is confirmed as a true positive by the SOC. What is the recommended approach?

A.Create a separate analytics rule that triggers on the same alert and uses a playbook to isolate the device.
B.Use automatic attack disruption in Microsoft Defender XDR to isolate the device automatically.
C.Configure an automated response in Defender for Endpoint to isolate the device immediately when an alert is generated.
D.Create an automation rule in Microsoft Sentinel that triggers a playbook with an approval step before executing device isolation.
AnswerD

An automation rule in Microsoft Sentinel runs when an incident is created or updated and can trigger a playbook that includes an approval action—for example, a Microsoft Teams adaptive card or Outlook email requiring a SOC analyst to click Approve. Only after that approval is received does the Logic App continue to the Defender for Endpoint device-isolation step, ensuring a human has actively confirmed the containment decision. This approach also records every action in the playbook's run history and complies with the SOC's requirement to confirm before isolating.

Why this answer

It aligns with the recommended SOC workflow: an automation rule in Microsoft Sentinel triggers a playbook that includes an approval step, ensuring that device isolation only occurs after the SOC confirms the alert as a true positive. This approach maintains human oversight for low-priority incidents while leveraging automation for the response action.

Exam trap

The trap here is that candidates often confuse automated response capabilities (like immediate isolation in Defender for Endpoint) with the need for human approval in a SOC workflow, leading them to choose Option C without considering the 'confirmed as a true positive' requirement.

How to eliminate wrong answers

Option A is wrong because creating a separate analytics rule that triggers on the same alert would duplicate incident generation and bypass the existing incident's lifecycle, leading to unnecessary noise and potential race conditions. Option B is wrong because automatic attack disruption in Microsoft Defender XDR is designed for high-confidence, automated containment of active attacks, not for low-priority alerts that require SOC confirmation before isolation. Option C is wrong because configuring an automated response in Defender for Endpoint to isolate the device immediately would execute without any SOC validation, which contradicts the requirement to isolate only after confirmation of a true positive.

Practice this question →
6
MCQmedium

Your security team receives frequent false positive alerts from Microsoft Defender for Cloud Apps. You need to reduce noise without disabling any threat detection policies. What should you do?

A.Disable the built-in anomaly detection policies that generate false positives.
B.Configure suppression rules based on user, IP, or app to automatically dismiss matching alerts.
C.Adjust the alert severity thresholds in the policy settings.
D.Create custom detection policies to override default rules.
AnswerB

Suppression rules are the correct approach because they operate at the alert-dismissal stage rather than the detection stage. In Microsoft Defender for Cloud Apps, you can define suppression based on entity attributes such as user, IP address, or app, so alerts that match the rule are automatically closed or hidden before they reach the analyst. This directly addresses false positives by removing known-benign patterns (e.g., a service account that legitimately performs anomalous-looking bulk downloads) while keeping the underlying policy active for genuinely suspicious activity. Crucially, this does not weaken detection coverage and is fully auditable, making it the recommended operational response to alert fatigue.

Why this answer

Suppression rules in Microsoft Defender for Cloud Apps allow you to automatically dismiss alerts that match specific criteria (e.g., user, IP address, or app) without disabling the underlying threat detection policy. This reduces false positive noise while keeping the detection engine active for genuine threats. Disabling policies or adjusting severity thresholds would either remove detection entirely or fail to address the root cause of false positives.

Exam trap

The trap here is that candidates often confuse 'suppression' with 'disabling' or 'tuning' policies, assuming that reducing noise requires altering detection logic or severity, rather than using the dedicated suppression feature that automatically dismisses matching alerts without affecting detection.

How to eliminate wrong answers

Option A is wrong because disabling built-in anomaly detection policies would remove threat detection capabilities entirely, contradicting the requirement to not disable any threat detection policies. Option C is wrong because adjusting alert severity thresholds only changes the classification of alerts (e.g., from high to medium) but does not suppress or dismiss them, so false positives would still appear in the console. Option D is wrong because creating custom detection policies adds new rules but does not reduce noise from existing default policies; it would not suppress false positives generated by the built-in policies.

Practice this question →
7
MCQhard

A SOC manager wants to implement a new workflow where high-severity Microsoft Defender for Cloud Apps alerts are automatically sent to a Teams channel for immediate action. The solution must not require custom code. What should the manager configure?

A.Use Microsoft Power Automate to monitor the alerts and send a Teams message
B.Configure a rule in Microsoft Defender XDR to send email notifications
C.Create an automation rule in Microsoft Sentinel with a playbook that posts to Teams
D.Configure Microsoft Entra ID to send the alerts to Teams
AnswerC

The recommended approach is to ingest Defender for Cloud Apps alerts into Microsoft Sentinel using the Defender for Cloud Apps data connector, which normalizes the alerts as Sentinel incidents. Once ingested, a Sentinel automation rule can be created to run when an incident is generated, triggering an Azure Logic Apps-based playbook that posts a formatted message to a Microsoft Teams channel. This pipeline is fully integrated, leverages Sentinel's native threat intelligence and incident management, and can include enrichment steps before the Teams notification is sent.

Why this answer

Microsoft Sentinel's automation rules can trigger a playbook (built on Azure Logic Apps) when a high-severity alert is generated, and the playbook can post a message to a Teams channel without requiring custom code. This directly meets the requirement of automatically sending high-severity Microsoft Defender for Cloud Apps alerts to Teams for immediate action, leveraging built-in connectors.

Exam trap

The trap here is that candidates may confuse Microsoft Defender XDR's email notification rules with the ability to send Teams messages, or assume Power Automate is the correct low-code solution, but the question's requirement for no custom code and direct integration with Microsoft Defender for Cloud Apps alerts points specifically to Sentinel's automation rules with playbooks.

How to eliminate wrong answers

Option A is wrong because Microsoft Power Automate does not natively integrate with Microsoft Defender for Cloud Apps alerts to trigger on them directly; it would require custom connectors or workarounds, and the question explicitly states no custom code is allowed. Option B is wrong because configuring a rule in Microsoft Defender XDR to send email notifications only sends emails, not Teams messages, and does not meet the requirement of sending alerts to a Teams channel. Option D is wrong because Microsoft Entra ID (formerly Azure AD) is an identity and access management service and does not have the capability to send alerts from Microsoft Defender for Cloud Apps to Teams.

Practice this question →
8
MCQeasy

Your organization is planning to deploy Microsoft Sentinel. You need to ensure that security events from on-premises servers are sent to Sentinel. Which connector should you use?

A.Install the Log Analytics agent (MMA) on the servers and connect to Sentinel workspace.
B.Use the Microsoft Defender for Cloud (MDC) connector to stream security events.
C.Enable Azure Arc on the servers and use the Arc agent to forward events.
D.Install the Azure Monitor Agent (AMA) on the servers and configure a Data Collection Rule (DCR) to send events to Sentinel.
AnswerD

The correct approach is to install the Azure Monitor Agent (AMA) on each server, because it is the current, fully supported agent for sending logs to Azure Monitor and Microsoft Sentinel. You then define a Data Collection Rule (DCR) that specifies which security event logs — such as the Windows Security log, Sysmon, or Linux syslog — are collected and routed to the Sentinel workspace. The DCR can also apply filtering to reduce noise and control which event IDs are ingested, giving you precise and scalable collection.

Why this answer

The Azure Monitor Agent (AMA) is the current recommended agent for collecting security events from on-premises servers and forwarding them to Microsoft Sentinel. By installing AMA and configuring a Data Collection Rule (DCR), you can specify which security events (e.g., Windows Security Event logs) to collect and send directly to the Sentinel workspace, ensuring efficient and modern data ingestion.

Exam trap

The trap here is that candidates often confuse the deprecated Log Analytics agent (MMA) with the current Azure Monitor Agent (AMA), or mistakenly believe that Azure Arc alone can forward security events, when in fact it requires an additional agent like AMA for log collection.

How to eliminate wrong answers

Option A is wrong because the Log Analytics agent (MMA) is deprecated and no longer recommended for new deployments; Microsoft has announced its retirement and advises using AMA instead. Option B is wrong because the Microsoft Defender for Cloud (MDC) connector is used to ingest security alerts and findings from Defender for Cloud, not to directly stream raw security events from on-premises servers to Sentinel. Option C is wrong because Azure Arc enables management and governance of on-premises servers but does not natively forward security events to Sentinel; the Arc agent is not designed for log collection and requires additional configuration (e.g., AMA) to send events.

Practice this question →
9
MCQmedium

The exhibit shows a Conditional Access policy configuration in Microsoft Entra ID. The policy is intended to require MFA and compliant device for all users accessing all applications from trusted locations. However, users are reporting that they are being prompted for MFA even when accessing from the office (which is a trusted location). What is the most likely issue?

A.The policy should target specific applications instead of 'All applications'.
B.The grant controls should be 'Require MFA' only, not 'Require compliant device'.
C.The policy should exclude the 'All Users' group and instead assign specific users.
D.The location condition should include 'All untrusted locations' and exclude 'All trusted locations'.
AnswerD

The location condition is the root cause of the MFA prompt because it is set to include 'All trusted locations,' causing the policy to force MFA even when users connect from the corporate network. To require MFA only on untrusted connections, the policy should either include 'All untrusted locations' or include 'Any location' and then exclude 'All trusted locations.' Excluding trusted locations from the policy's scope ensures that sign-ins from the office aren't challenged, while still protecting access from unknown or risky networks.

Why this answer

The policy is configured to require MFA and compliant device for 'All users' accessing 'All applications' from 'Trusted locations'. However, users are being prompted for MFA from the office, which is a trusted location. The most likely issue is that the location condition is inverted: the policy should target 'All untrusted locations' (i.e., require MFA when not in a trusted location) and exclude 'All trusted locations' to avoid prompting from trusted IPs.

Option D correctly identifies this misconfiguration.

Exam trap

The trap here is that candidates often confuse 'include' vs. 'exclude' logic for location conditions, thinking that including trusted locations will exempt them, when in fact it applies the policy to those locations.

How to eliminate wrong answers

Option A is wrong because targeting 'All applications' is not the issue; the policy is intended to cover all applications, and the problem is with the location condition, not the application scope. Option B is wrong because requiring both MFA and compliant device is a valid and common requirement for untrusted locations; removing 'Require compliant device' would not fix the location-based prompting issue. Option C is wrong because excluding 'All Users' and assigning specific users would not resolve the location condition misconfiguration; the policy is intended for all users, and the problem is that trusted locations are being treated as untrusted.

Practice this question →
10
MCQmedium

You are managing a Microsoft Sentinel environment. You need to ensure that only security analysts with specific roles can modify automation rules. The solution must use least privilege. What should you do?

A.Use Azure Policy to restrict access to automation rules.
B.Assign the 'Microsoft Sentinel Contributor' role to all security analysts.
C.Assign the 'Microsoft Sentinel Reader' role to the analysts and grant them 'Automation' permissions via a separate policy.
D.Create a custom role with 'Microsoft Sentinel Automation Contributor' permission and assign it to the analysts.
AnswerD

Creating a custom role that includes the Microsoft Sentinel Automation Contributor permission is the correct approach because it provides the least-privilege access needed to read, create, edit, and delete automation rules, playbooks, and automation rule actions without granting full control over all Sentinel resources. The Microsoft Sentinel Automation Contributor role (often the built-in role or a custom role based on it) scopes permissions specifically to automation rule management, including the ability to trigger playbooks, while avoiding broader Sentinel management rights. Assigning this custom role only to the security analysts ensures they can perform their required tasks without exposing sensitive configurations or other security operations features. This aligns with Azure RBAC best practices and the principle of least privilege, making it the technically correct solution.

Why this answer

Microsoft Sentinel provides a built-in 'Microsoft Sentinel Automation Contributor' role that grants granular permissions to manage automation rules without granting broader Contributor access. This adheres to the least privilege principle by limiting modifications to only the necessary automation-related actions, such as creating, editing, or deleting automation rules, while preventing changes to other Sentinel resources like analytics rules or data connectors.

Exam trap

The trap here is that candidates often confuse Azure Policy with RBAC, assuming a policy can grant permissions, or they incorrectly think that the 'Contributor' role is the only way to allow modifications, overlooking the existence of purpose-built custom or built-in roles like 'Microsoft Sentinel Automation Contributor'.

How to eliminate wrong answers

Option A is wrong because Azure Policy is used for governance and compliance enforcement (e.g., auditing or denying resource configurations), not for granting granular RBAC permissions to specific users for modifying automation rules. Option B is wrong because the 'Microsoft Sentinel Contributor' role grants full write access to all Sentinel resources, including analytics rules, workbooks, and data connectors, which violates the least privilege principle by providing excessive permissions beyond automation rules. Option C is wrong because the 'Microsoft Sentinel Reader' role only allows read access, and there is no separate 'Automation' policy in Azure RBAC that can grant write permissions to automation rules; RBAC permissions are assigned via roles, not policies.

Practice this question →
11
MCQmedium

You have deployed Microsoft Defender for Endpoint and integrated it with Microsoft Sentinel. You notice that alerts from Defender for Endpoint are not appearing in Sentinel. What should you check first?

A.Verify that the Microsoft 365 Defender connector in Sentinel is enabled and configured.
B.Confirm that Defender for Endpoint is licensed for all users.
C.Check that the alert severity is not being filtered out by analytics rules.
D.Ensure that all devices are onboarded to Defender for Endpoint.
AnswerA

The Microsoft 365 Defender connector is the data plane that carries M365 Defender alerts, including those from Defender for Endpoint, into Microsoft Sentinel. If this connector is not enabled in Sentinel's content hub and configured with the correct Microsoft 365 Defender workspace setting, no alerts will be streamed to the workspace. Since the symptoms point to missing alerts, verifying the connector's status and configuration is the primary and most direct troubleshooting step.

Why this answer

The Microsoft 365 Defender connector in Microsoft Sentinel is the specific data connector responsible for ingesting alerts from Microsoft Defender for Endpoint (and other Defender products). If this connector is not enabled or misconfigured, alerts will not flow into Sentinel regardless of licensing, device onboarding, or analytics rules. This is the first and most direct check because the connector acts as the ingestion pipeline.

Exam trap

The trap here is that candidates often jump to troubleshooting device onboarding or licensing, forgetting that the Sentinel connector is the explicit integration point that must be verified first.

How to eliminate wrong answers

Option B is wrong because licensing for Defender for Endpoint is a prerequisite for generating alerts, but it does not control the data ingestion pipeline into Sentinel; even with full licensing, alerts will not appear if the connector is disabled. Option C is wrong because analytics rules in Sentinel process events that have already been ingested; if alerts are not arriving, filtering by severity is irrelevant. Option D is wrong because device onboarding is necessary for Defender for Endpoint to generate alerts, but it does not affect the Sentinel connector's ability to receive those alerts; onboarded devices with alerts still require the connector to be enabled.

Practice this question →
12
Multi-Selecteasy

Which TWO actions can a Microsoft Sentinel automation rule perform when an incident is created?

Select 2 answers
A.Create a new analytics rule
B.Query Log Analytics workspaces
C.Run a playbook
D.Change the incident severity
E.Ingest data from a new source
AnswersC, D

Running a playbook is a supported action for an automation rule: the rule can invoke a Microsoft Sentinel playbook, which is a Logic Apps workflow, as its action and pass contextual data such as incident ID, alert ID, or analytics rule ID to the logic app. This enables automatic investigative and remediation steps such as blocking an IP, checking threat intelligence, or creating a support ticket. The playbook must be configured with the correct permissions, either through the automation rule's managed identity or a service principal, and must have the appropriate Microsoft Sentinel role assignments.

Why this answer

Microsoft Sentinel automation rules can trigger actions when an incident is created, including running a playbook (Option C) and changing the incident severity (Option D). Playbooks are automated workflows based on Azure Logic Apps that can perform complex response actions, while severity changes allow dynamic triage based on incident properties.

Exam trap

The trap here is that candidates may confuse automation rule actions with analytics rule capabilities, incorrectly assuming automation rules can create rules or query workspaces directly, when in fact those are separate functions within Sentinel.

Practice this question →
13
MCQmedium

Your organization uses Microsoft Defender for Cloud Apps and Microsoft Sentinel. You notice that a large number of log entries from Defender for Cloud Apps are being dropped at ingestion due to 'malformed data' errors. The data connector shows a healthy status. What is the most likely cause?

A.The log type is not supported by Sentinel.
B.The Log Analytics workspace key has expired.
C.The data volume exceeds the workspace's ingestion capacity, causing data truncation.
D.The Defender for Cloud Apps connector is blocked by a firewall.
AnswerC

Log Analytics workspaces enforce ingestion rate limits (for example, 500 MB per minute or a 100 GB per-day cap depending on the pricing tier). When the combined volume from all sources exceeds these thresholds, the platform throttles ingestion and drops or truncates the excess data, which can result in partially written JSON records that appear as malformed logs. This specifically explains why a high data volume scenario would produce parsing or truncation errors without any authentication or connectivity issues.

Why this answer

When the data volume exceeds the Log Analytics workspace's ingestion capacity, Defender for Cloud Apps log entries can be truncated mid-record, causing them to be malformed and dropped. The connector status remains healthy because the connector itself is still connected and receiving data, but the workspace's ingestion rate limit (typically 500 MB/min per workspace or 2 GB/min per workspace depending on pricing tier) causes truncation, not a connectivity or authentication failure.

Exam trap

The trap here is that candidates see a 'healthy' connector status and assume the issue must be with the log format or connectivity, but Microsoft deliberately tests the nuance that ingestion rate limits can cause data truncation without breaking the connector's health status.

How to eliminate wrong answers

Option A is wrong because Defender for Cloud Apps sends supported log types (e.g., CloudAppEvents, McasShadowItReporting) that are natively ingested by Sentinel; unsupported log types would not appear as 'malformed data' but would simply not be available in the connector schema. Option B is wrong because an expired Log Analytics workspace key would cause the connector to show a 'disconnected' or 'error' status, not a healthy status, and would result in no data ingestion rather than malformed data. Option D is wrong because a firewall blocking the connector would prevent any data from reaching Sentinel, resulting in a 'disconnected' or 'failed' connector status, not a healthy status with partial data drops.

Practice this question →
14
MCQeasy

Your organization uses Microsoft Defender for Cloud to manage security posture. You need to assign a custom initiative to a specific management group to track compliance. Which two components must you create?

A.An Azure Blueprint and a role assignment.
B.A policy definition and an initiative definition.
C.An Azure RBAC role and a Log Analytics workspace.
D.An Azure Monitor workbook and an alert rule.
AnswerB

A custom policy initiative requires at least one policy definition and an initiative definition that references those policies. The initiative definition is a JSON document containing metadata, parameters, and an array of policy definition IDs, all grouped for a shared compliance goal. Without both elements, there is no logical grouping to assign or evaluate in Azure Policy. Therefore, this pair is the minimal and correct set of components needed to create a custom initiative.

Why this answer

To track compliance for a custom initiative in Microsoft Defender for Cloud, you must first create a custom policy definition that specifies the rules or effects to enforce. Then, you must create an initiative definition (a group of policy definitions) that can be assigned to a management group. This assignment enables Defender for Cloud to evaluate resources against the custom initiative and report compliance.

Exam trap

The trap here is that candidates confuse Azure Blueprints (which also group resources) with policy initiatives, or they think a Log Analytics workspace is required to store compliance data, when in fact compliance data is stored and reported by Defender for Cloud itself without needing a separate workspace.

How to eliminate wrong answers

Option A is wrong because Azure Blueprints are used for deploying repeatable environments and templates, not for creating custom compliance initiatives in Defender for Cloud; role assignments control permissions, not policy definitions. Option C is wrong because Azure RBAC roles manage access control, and Log Analytics workspaces store monitoring data, but neither component defines the compliance rules required for a custom initiative. Option D is wrong because Azure Monitor workbooks and alert rules are for visualizing and responding to telemetry, not for defining or assigning compliance policies.

Practice this question →
15
MCQmedium

Your security operations team receives an alert from Microsoft Sentinel about a suspicious sign-in from an unfamiliar IP address. You need to investigate the alert by correlating it with user activity and device information. Which data sources should you query first?

A.Microsoft Purview audit logs and Microsoft Intune device compliance
B.Microsoft 365 Defender alerts and Microsoft Sentinel incidents
C.Microsoft Entra ID sign-in logs and Microsoft Defender for Endpoint device events
D.Azure Activity Logs and Azure Firewall logs
AnswerC

Microsoft Entra ID sign-in logs are the authoritative source for user authentication events, containing details such as sign-in time, IP address, location, conditional access policies, MFA result, and risk detection—all essential for analyzing a sign-in anomaly. Microsoft Defender for Endpoint device events provide host-level telemetry like process execution, network connections, and attack behavior, allowing the analyst to correlate the sign-in activity with what is happening on the device used to authenticate. Together, these sources let you establish whether the sign-in is truly abnormal and whether the device itself is compromised, enabling a data-driven investigation.

Why this answer

Investigating a suspicious sign-in requires correlating the sign-in event with user activity and device context. Microsoft Entra ID sign-in logs provide the authentication details (IP address, timestamp, user), while Microsoft Defender for Endpoint device events supply device-level telemetry (processes, network connections, logged-on users). This combination directly enables the correlation needed to validate whether the sign-in was legitimate or malicious.

Exam trap

The trap here is that candidates often confuse aggregated alert sources (like Microsoft 365 Defender alerts) with raw telemetry sources (like sign-in logs and device events), leading them to pick Option B instead of the correct raw data sources needed for correlation.

How to eliminate wrong answers

Option A is wrong because Microsoft Purview audit logs focus on data governance and compliance events (e.g., file access, eDiscovery), not real-time sign-in or device activity; Intune device compliance checks device policy adherence but lacks the granular sign-in and process-level events needed for alert correlation. Option B is wrong because Microsoft 365 Defender alerts and Sentinel incidents are aggregated alert outputs, not raw data sources; querying them first would only re-consume the same alert without underlying telemetry for correlation. Option D is wrong because Azure Activity Logs track control-plane operations (e.g., resource creation) and Azure Firewall logs capture network traffic, neither of which provides user sign-in details or device process-level events required for this investigation.

Practice this question →
16
Multi-Selecteasy

Which TWO of the following are valid data connectors in Microsoft Sentinel? (Select two.)

Select 2 answers
A.Windows Defender Firewall
B.Office 365
C.Microsoft Forms
D.Azure DevOps
E.Azure Activity
AnswersB, E

The Office 365 connector is a first-party, built-in data connector in Microsoft Sentinel. It ingests audit logs from Exchange Online, SharePoint Online, Microsoft Teams, and other Microsoft 365 workloads through the Microsoft 365 Management Activity API, and you enable it by simply connecting an Office 365 tenant on the connectors page. This is one of the standard, valid connectors.

Why this answer

Office 365 is a valid Microsoft Sentinel data connector because it ingests audit logs from Exchange Online, SharePoint Online, Teams, and other Office 365 services via the Office 365 Management Activity API. This connector enables security monitoring of user and admin activities across the Microsoft 365 tenant, making it a core data source for insider threat detection and compliance scenarios.

Exam trap

The trap here is that candidates often confuse 'Windows Defender Firewall' with the 'Windows Firewall' logs that can be collected via the Windows Security Events connector, but there is no dedicated Sentinel data connector named 'Windows Defender Firewall'.

Practice this question →
17
MCQhard

Your organization uses Microsoft Defender for Cloud Apps to monitor SaaS applications. You discover that a user is downloading a large number of files from SharePoint Online to an unmanaged device. You need to automatically block the download and require the user to acknowledge a policy violation. Which action should you configure in a session policy?

A.Set the action to 'Monitor only'.
B.Set the action to 'Redirect to Microsoft Entra ID conditional access'.
C.Set the action to 'Block' and enable 'Notify user' with a customized message.
D.Set the action to 'Block' and enable 'Custom block message'.
AnswerC

Setting the action to 'Block' instructs Defender for Cloud Apps to deny the request at the reverse proxy when the download is attempted, effectively preventing the file from being transferred. Enabling 'Notify user' with a customized message displays an interactive notification that the user must read and acknowledge, which warns the user and leaves an audit record of the acknowledgment. This combination of a hard block and an acknowledged, personalized message meets both the download-prevention and user-notification requirements.

Why this answer

A session policy in Microsoft Defender for Cloud Apps can enforce real-time controls on SaaS app traffic. Setting the action to 'Block' stops the download immediately, and enabling 'Notify user' with a customized message both blocks the action and requires the user to acknowledge the policy violation, satisfying the requirement to automatically block and obtain acknowledgment.

Exam trap

The trap here is that candidates confuse 'Custom block message' (a static notification) with 'Notify user' (which includes an interactive acknowledgment), leading them to select Option D instead of the correct Option C.

How to eliminate wrong answers

Option A is wrong because 'Monitor only' only logs the activity without blocking it, failing to meet the requirement to automatically block the download. Option B is wrong because 'Redirect to Microsoft Entra ID conditional access' redirects the session for additional authentication or device compliance checks but does not block the download or require acknowledgment of a policy violation. Option D is wrong because 'Block' with 'Custom block message' blocks the download but does not require the user to acknowledge the violation; it simply displays a message without an interactive acknowledgment step.

Practice this question →
18
MCQhard

Refer to the exhibit. You are configuring an automation rule in Microsoft Sentinel. The rule is enabled but never runs. The playbook exists and is in the same resource group. What is the most likely cause?

A.The condition uses 'Contains' operator, but 'AlertProvider' requires 'Equals'.
B.The automation rule is in a 'Disabled' state.
C.The trigger type is incorrect; it should be 'Microsoft.SecurityInsights/Alert'.
D.The playbookId is missing the subscription ID.
AnswerC

Sentinel automation rules must specify a valid trigger type: 'Microsoft.SecurityInsights/Alert' for alert-triggered rules or 'Microsoft.SecurityInsights/Incident' for incident-triggered rules. The exhibit shows 'Microsoft.SecurityInsights/AlertRule', which is not a recognized trigger type in the automation rule schema, so the rule will not fire as intended. This invalid trigger type is the actual defect preventing the rule from working.

Why this answer

The exhibit shows the trigger type set to 'Microsoft.SecurityInsights/Incident', but the playbook is designed to run on alerts, not incidents. Automation rules in Microsoft Sentinel require the trigger type to match the data type the playbook expects; for alert-triggered playbooks, the trigger must be 'Microsoft.SecurityInsights/Alert'. Since the rule is enabled and the playbook exists in the same resource group, the mismatch in trigger type is the most likely reason the rule never runs.

Exam trap

The trap here is that candidates assume any enabled automation rule with a valid playbook will run, overlooking the critical requirement that the trigger type must exactly match the playbook's intended data source (alert vs. incident).

How to eliminate wrong answers

Option A is wrong because the 'Contains' operator is valid for string conditions in automation rules; 'AlertProvider' does not require 'Equals' exclusively. Option B is wrong because the question explicitly states the rule is enabled, so a 'Disabled' state cannot be the cause. Option D is wrong because the playbookId in an automation rule does not require the subscription ID to be included; the resource ID format is sufficient as long as the playbook is in the same resource group.

Practice this question →
19
MCQhard

Your organization uses Microsoft Defender for Cloud to assess security posture. You need to ensure that any new Azure subscription automatically has Microsoft Defender for Cloud enabled with the 'Defender for Cloud (CSPM)' plan active. What should you do?

A.Create an automation account that runs a PowerShell script daily to check and enable Defender for Cloud.
B.Configure Azure Arc to enforce the plan on new subscriptions.
C.Assign a built-in Azure Policy initiative that deploys Microsoft Defender for Cloud configuration to subscriptions.
D.Use Microsoft Sentinel's 'Subscription Migration' playbook.
AnswerC

The correct answer is to assign the built-in Azure Policy initiative that deploys Microsoft Defender for Cloud configuration, such as the 'Microsoft Defender for Cloud' initiative, to the root management group or subscription scope. This initiative uses DeployIfNotExists and Modify effects to automatically enable the Defender plans, configure data collection, and remediate any drift. Because policy inheritance flows to all child scopes, every new subscription is continuously assessed and brought into compliance without manual or scheduled intervention, providing a fully governed, auditable enforcement mechanism.

Why this answer

Azure Policy can enforce compliance at scale by assigning the built-in initiative 'Deploy Microsoft Defender for Cloud configuration' to a management group or subscription. This initiative includes policies that automatically enable Microsoft Defender for Cloud and activate the 'Defender for Cloud (CSPM)' plan on new subscriptions, ensuring consistent security posture without manual intervention.

Exam trap

The trap here is that candidates may confuse Azure Arc (which extends Azure management to non-Azure environments) with Azure Policy (which enforces configurations on Azure subscriptions), leading them to incorrectly select Option B.

How to eliminate wrong answers

Option A is wrong because using an automation account with a PowerShell script that runs daily introduces a delay (up to 24 hours) and is not a native, real-time enforcement mechanism; Azure Policy provides immediate, idempotent enforcement at resource creation. Option B is wrong because Azure Arc is designed to manage hybrid and multi-cloud servers, not to enforce Azure subscription-level plans like Defender for Cloud CSPM; it does not have a policy or capability to enable Defender plans on new subscriptions. Option D is wrong because Microsoft Sentinel's 'Subscription Migration' playbook is intended for migrating Sentinel resources between subscriptions, not for enabling Defender for Cloud plans; it does not address the requirement of automatically enabling CSPM on new subscriptions.

Practice this question →
20
MCQhard

You are configuring an automated investigation and response (AIR) playbook in Microsoft Sentinel. The playbook should automatically block a user in Microsoft Entra ID when a high-severity incident is created. Which action should you include in the playbook?

A.Use the 'Block user' action from the Microsoft Entra ID connector in Azure Logic Apps.
B.Call the Microsoft Graph API to update the user's accountEnabled property to false.
C.Add a 'Block IP' action from the Azure Firewall connector.
D.Add a 'Change incident status' action to close the incident.
AnswerB

Calling the Microsoft Graph API to set the user's accountEnabled property to false is the correct method because this property controls whether the user can authenticate. A PATCH request to /users/{id} with body {"accountEnabled": false} immediately disables the account across Microsoft 365 services, effectively blocking the user's access. This approach is also what documented playbooks for automated response recommend.

Why this answer

The 'Block user' action is not available in the Microsoft Entra ID connector for Azure Logic Apps; instead, you must call the Microsoft Graph API to update the user's `accountEnabled` property to `false`. This directly disables the user account in Microsoft Entra ID, effectively blocking their access. The playbook in Microsoft Sentinel uses Azure Logic Apps, and the Graph API is the appropriate method to perform this action programmatically.

Exam trap

The trap here is that candidates assume a 'Block user' action exists in the Microsoft Entra ID connector, but Microsoft Sentinel playbooks rely on Logic Apps connectors, which lack that specific action, forcing the use of the Graph API instead.

How to eliminate wrong answers

Option A is wrong because the Microsoft Entra ID connector in Azure Logic Apps does not include a 'Block user' action; it only supports actions like 'Get user' or 'Update user', and blocking requires a Graph API call. Option C is wrong because a 'Block IP' action from the Azure Firewall connector blocks network traffic from an IP address, not a user account in Microsoft Entra ID, which is irrelevant for blocking a user identity. Option D is wrong because changing the incident status to closed does not perform any blocking action; it only updates the incident's lifecycle in Microsoft Sentinel, leaving the user unblocked.

Practice this question →
21
Multi-Selecthard

Which TWO permissions are required to create and manage automation rules in Microsoft Sentinel?

Select 2 answers
A.Microsoft Sentinel Reader
B.Microsoft Sentinel Automation Contributor
C.Microsoft Sentinel Responder
D.Log Analytics Contributor
E.Microsoft Sentinel Contributor
AnswersC, E

Cannot manage automation rules.

Why this answer

Microsoft Sentinel Contributor (E) is correct because it grants full management of Microsoft Sentinel resources, including creating, editing, and deleting automation rules. Microsoft Sentinel Responder (C) is also correct because it can manage incidents, run playbooks, and create and edit automation rules. Microsoft Sentinel Automation Contributor (B) is not sufficient for a user to create or manage automation rules; it is used to allow the Microsoft Sentinel service to run playbooks triggered by automation rules.

Microsoft Sentinel Reader (A) only allows viewing data and incidents, so it cannot create or modify automation rules. Log Analytics Contributor (D) manages the underlying Log Analytics workspace but does not grant the Sentinel-specific permissions needed for automation rules.

Exam trap

The trap is confusing the Microsoft Sentinel Automation Contributor role with the ability to author automation rules. Automation Contributor is for allowing the Microsoft Sentinel service to run playbooks, not for creating or managing automation rules. The roles that allow a user to create and manage automation rules are Microsoft Sentinel Contributor and Microsoft Sentinel Responder.

Practice this question →
22
Multi-Selectmedium

Which THREE components are part of the Microsoft Sentinel SOAR capabilities? (Select THREE.)

Select 3 answers
A.Connectors
B.Workbooks
C.Playbooks
D.Analytics rules
E.Automation rules
AnswersA, C, E

Connectors are the integration layer that enables Sentinel to ingest threat intelligence, alerts, and other data from external sources, and also to take outbound actions across connected systems like ServiceNow, Teams, or Azure Active Directory. In the SOAR context, connectors provide the input triggers and output actions that playbooks rely on to orchestrate response workflows beyond Sentinel's native data. Without connectors, automated response would be limited to internal Sentinel data, making them an essential component of the SOAR architecture.

Why this answer

Connectors are part of Microsoft Sentinel's SOAR capabilities because they enable the ingestion of security alerts and events from various sources, which is the foundational step for triggering automated responses. Without connectors, Sentinel cannot receive the data needed to initiate playbooks or automation rules, making them an essential component of the SOAR workflow.

Exam trap

The trap here is that candidates often confuse Workbooks (visualization) or Analytics rules (detection) with SOAR components, because they are all part of Sentinel's core features, but only connectors, playbooks, and automation rules directly enable orchestration and automated response.

Practice this question →
23
MCQeasy

You are a security analyst at a company that uses Microsoft 365 Defender. You receive an automated email indicating that a user has been flagged for possible credential theft. The email includes a link to investigate the alert in the Microsoft 365 Defender portal. Which role is responsible for sending this email?

A.A mail flow rule in Exchange Online configured to forward alerts.
B.Microsoft 365 Defender email notification settings.
C.Microsoft Defender for Cloud Apps notification settings.
D.A Microsoft Sentinel analytics rule configured to send email notifications.
AnswerB

Microsoft 365 Defender (formerly Microsoft Defender for Endpoint) provides built-in email notification settings under Incidents & alerts, allowing you to configure email alerts for new incidents or updated severity levels. These notifications are sent directly by the Defender platform itself, using its internal alert engine to trigger the email—no external workflow or additional licensing is required. This option correctly explains the source of the email in question because Defender has native, out-of-the-box alert notification capabilities that deliver standardized incident updates to specified recipients.

Why this answer

The automated email alerting a user about possible credential theft is sent by Microsoft 365 Defender's built-in email notification settings. These settings allow security teams to configure notifications for specific alert severities or categories, such as credential theft, directly from the Microsoft 365 Defender portal. The email includes a link to investigate the alert, which aligns with the notification functionality within Microsoft 365 Defender.

Exam trap

The trap here is that candidates may confuse the source of the alert (Microsoft 365 Defender) with other Microsoft security tools like Microsoft Defender for Cloud Apps or Microsoft Sentinel, which have their own notification settings but are not responsible for this specific credential theft alert.

How to eliminate wrong answers

Option A is wrong because a mail flow rule in Exchange Online is used to route, filter, or modify email messages based on conditions like sender or content, not to generate security alerts from Microsoft 365 Defender. Option C is wrong because Microsoft Defender for Cloud Apps notification settings are specific to cloud app security alerts, such as anomalous activity in SaaS apps, not credential theft alerts from Microsoft 365 Defender. Option D is wrong because a Microsoft Sentinel analytics rule can send email notifications, but Sentinel is a separate SIEM tool; the question explicitly states the alert originates from Microsoft 365 Defender, not Sentinel.

Practice this question →
24
MCQmedium

Your organization is using Microsoft Sentinel and has deployed the Microsoft Entra ID (Azure AD) connector. You need to create an analytics rule that triggers an incident when a user from a specific IP address is assigned the Global Administrator role. The IP address is not in your trusted IP list. Which KQL query should you use as the rule logic?

A.AuditLogs | where ActivityDisplayName == 'Add member to role' and TargetResources[0].displayName == 'Global Administrator' and InitiatedBy.app.ipAddress == '10.0.0.1'
B.AuditLogs | where ActivityDisplayName == 'Add member to role' and TargetResources[0].displayName == 'Global Administrator' and InitiatedBy.app.ipAddress !in (dynamic(['10.0.0.1', '10.0.0.2']))
C.AuditLogs | where ActivityDisplayName == 'Add member to role' and TargetResources[0].displayName == 'Global Administrator' and InitiatedBy.app.ipAddress !has '10.0.'
D.AuditLogs | where ActivityDisplayName == 'Add member to role' and TargetResources[0].displayName == 'Global Administrator' and InitiatedBy.app.ipAddress !in ('trusted IP list')
AnswerB

This is correct because it uses the !in operator with a dynamic array literal containing the trusted IP addresses, which properly excludes any events initiated from either 10.0.0.1 or 10.0.0.2 while still capturing all other IPs performing Global Administrator role assignments. The dynamic array syntax is the proper KQL way to represent a list of values for membership testing.

Why this answer

It uses the `!in` operator to filter out specific IP addresses from the `InitiatedBy.app.ipAddress` field, ensuring that only events from IP addresses not in the trusted list trigger an incident. The query correctly targets `AuditLogs` with `ActivityDisplayName == 'Add member to role'` and checks that the role assigned is `Global Administrator` via `TargetResources[0].displayName`. This logic matches the requirement to alert when a user from a specific IP address (10.0.0.1) that is not in the trusted list is assigned the Global Administrator role.

Exam trap

The trap here is that candidates often confuse the `!has` operator (which checks for substring containment) with the `!in` operator (which checks for exact membership in a list), leading them to select Option C which would incorrectly exclude entire IP subnets rather than specific trusted IPs.

How to eliminate wrong answers

Option A is wrong because it uses `== '10.0.0.1'` which would only trigger when the IP address exactly matches that single IP, not when the IP is not in the trusted list; the requirement is to trigger for any IP not in the trusted list, not just a specific one. Option C is wrong because `!has '10.0.'` is a string containment operator that would incorrectly exclude any IP starting with '10.0.' (e.g., 10.0.0.1, 10.0.1.5), which is too broad and does not match the specific trusted IP list requirement. Option D is wrong because `!in ('trusted IP list')` treats the string literal 'trusted IP list' as a single value, not as a dynamic array of IPs, and would not evaluate against actual IP addresses; KQL requires a dynamic array or a list of values for the `in` operator.

Practice this question →
25
Multi-Selecteasy

Which TWO data sources are natively supported by Microsoft Sentinel for ingesting security events? (Choose two.)

Select 2 answers
A.Salesforce audit logs
B.GitHub audit logs
C.Google Cloud Platform (GCP) logs
D.Windows Security Events
E.Azure Activity Logs
AnswersD, E

Windows Security Events are natively supported through the 'Windows Security Events via AMA' or legacy 'Windows Security Events' connector, which uses the Log Analytics agent (or Azure Monitor Agent) to collect security event logs from Windows machines. This built-in, first-party connector requires no custom development and is a standard source for detecting threats, making it one of the two correct answers.

Why this answer

Windows Security Events are natively supported by Microsoft Sentinel via the Windows Security Events via AMA connector or the legacy Log Analytics agent. This connector ingests security event logs (e.g., Event ID 4625 for failed logons) directly into Sentinel without requiring a third-party parser or custom data connector. Azure Activity Logs are also natively supported through the Azure Activity connector, which streams subscription-level operational events (e.g., resource creation, policy changes) into Sentinel at no additional cost.

Exam trap

The trap here is that candidates often confuse 'natively supported' with 'available via a connector in the content hub,' but Microsoft Sentinel defines native support as built-in data connectors that require no additional custom code or third-party services, excluding connectors that rely on Azure Functions or partner solutions.

Practice this question →
26
MCQmedium

Your team uses Microsoft Sentinel to investigate incidents. You need to create a custom analytic rule that triggers an incident when a user signs in from an unfamiliar location. What is the most efficient way to achieve this?

A.Create a playbook triggered by Microsoft Entra ID alerts.
B.Write a custom KQL query using SigninLogs.
C.Configure a Microsoft Purview insider risk policy.
D.Use a built-in Anomalous Sign-in Location rule template.
AnswerD

The built-in Anomalous Sign-in Location rule template in Microsoft Sentinel is the most direct solution. It uses Microsoft Sentinel's UEBA (User and Entity Behavior Analytics) to baseline user behavior and flag sign-ins from unusual geographic locations or IP addresses. This template is ready to enable, requires no custom KQL, and automatically maps entities and generates alerts that feed into incidents—exactly what is needed for investigating sign-in anomalies.

Why this answer

Microsoft Sentinel provides a built-in 'Anomalous Sign-in Location' rule template that leverages Microsoft Entra ID Identity Protection data to detect sign-ins from unfamiliar locations. This template is pre-configured with the necessary KQL logic and alerting, making it the most efficient method without requiring custom development or additional data sources.

Exam trap

The trap here is that candidates may assume a custom KQL query (Option B) is the most flexible and efficient approach, overlooking that Sentinel's built-in templates are pre-optimized and require no manual logic for defining 'unfamiliar' locations.

How to eliminate wrong answers

Option A is wrong because playbooks are automated response actions (e.g., sending emails or blocking users) triggered by alerts, not the mechanism to create detection rules for unfamiliar location sign-ins. Option B is wrong because while a custom KQL query using SigninLogs could detect unfamiliar locations, it requires manual logic to define 'unfamiliar' (e.g., comparing against historical geolocation data) and is less efficient than using the built-in template. Option C is wrong because Microsoft Purview insider risk policies focus on detecting risky user activities like data exfiltration or policy violations, not sign-in location anomalies.

Practice this question →
27
Multi-Selectmedium

You are a security operations analyst using Microsoft Sentinel. You need to configure a playbook that automatically posts a message to a Microsoft Teams channel when a high-severity incident is created. Which two actions must you perform? (Choose two.)

Select 2 answers
A.Create a playbook that uses the Office 365 Outlook connector and sends an email to the SOC team.
B.Create a playbook that uses the Microsoft Sentinel connector and retrieves incident details.
C.Create an automation rule that triggers when an incident is created and has a condition for severity equals High.
D.Create a playbook that uses the Microsoft Teams connector and posts a message to the desired channel.
E.Create an automation rule that triggers when an incident is updated and has a condition for severity equals High.
AnswersC, D

This is correct because to automatically run a playbook based on incident creation and severity, you need an automation rule. The automation rule can have a condition to check the severity and then an action to run the playbook. This ensures the playbook only runs for high-severity incidents.

Why this answer

To automatically post a message to Microsoft Teams when a high-severity incident is created in Microsoft Sentinel, you need an automation rule that triggers on incident creation, checks the severity, and runs a playbook. The playbook must use the Microsoft Teams connector to post the message to the desired channel. The automation rule provides the trigger and condition, while the playbook performs the action.

Exam trap

The trap here is confusing the trigger condition (incident created vs. updated) or using the wrong connector (Outlook instead of Teams).

Practice this question →
28
MCQhard

You manage a Microsoft Sentinel workspace that ingests logs from multiple sources. You notice that the workspace is approaching its daily ingestion quota, and some data sources are being dropped. You need to ensure that security-related logs are prioritized and that non-critical logs are not ingested. What should you configure?

A.Create analytic rules with entity mapping to prioritize alerts
B.Use data collection rules (DCRs) to filter log ingestion
C.Set a daily cap on the Log Analytics workspace
D.Configure diagnostic settings to exclude certain logs
AnswerB

Data collection rules (DCRs) provide a pipeline-level mechanism to control what gets ingested into a Log Analytics workspace. By defining a KQL transformation in a DCR, you can filter out unwanted records or fields from specific data sources before they are stored, which directly enables selective ingestion and cost control. Because this processing occurs during the collection phase, it is the correct tool for filtering log ingestion in Sentinel.

Why this answer

Data collection rules (DCRs) allow you to define transformations that filter logs before they are ingested into a Log Analytics workspace. By configuring a DCR with a KQL-based transformation, you can drop non-critical logs while ensuring security-related logs are always ingested, preventing them from being dropped when the daily quota is approached.

Exam trap

The trap here is that candidates often confuse data collection rules (which filter at ingestion) with diagnostic settings (which control log routing) or daily caps (which stop all ingestion), failing to recognize that DCRs provide the granular control needed to prioritize specific log types.

How to eliminate wrong answers

Option A is wrong because analytic rules with entity mapping are used to generate alerts and correlate events, not to control which logs are ingested or to prioritize ingestion. Option C is wrong because setting a daily cap on the Log Analytics workspace stops all ingestion when the cap is reached, including security logs, which does not prioritize critical data. Option D is wrong because diagnostic settings control which logs are sent from Azure resources to destinations like Log Analytics, but they do not provide granular filtering or prioritization within a single workspace; they either include or exclude entire log categories.

Practice this question →
29
MCQhard

You are reviewing an analytics rule in Microsoft Sentinel. The rule is supposed to alert when a Confidential sensitivity label file is accessed. However, no alerts have been generated despite known accesses. What is the most likely reason?

A.The suppression duration is set to 5 hours, which suppresses alerts.
B.The required data connector for Microsoft Purview Information Protection is not connected.
C.The query frequency and period are too short to capture the events.
D.The trigger condition is set to 'GreaterThan' 0, which should fire on any event.
AnswerB

The `SensitivityLabelEvent` table is populated only when the Microsoft Purview Information Protection data connector is connected to Microsoft Sentinel. Without that connector, the table remains empty in the Log Analytics workspace, so the query for this analytics rule returns zero rows even if label consumption events are happening across the organization. This is the root cause because the rule's logic and trigger are sound, but the underlying telemetry is never ingested—so the alert never fires.

Why this answer

The query should reference the MicrosoftPurviewInformationProtection table (populated by the Microsoft Purview Information Protection data connector), not a nonexistent 'SensitivityLabelEvent' table. With the connector disconnected, that table is empty, which is why the rule's query returns zero rows and no alert fires despite the query logic, schedule, and trigger threshold all being otherwise correct.

Exam trap

Microsoft often tests the misconception that a rule's logic or scheduling is the root cause, when in fact the underlying data source is missing or misconfigured — candidates overlook the prerequisite of having the correct data connector enabled.

How to eliminate wrong answers

Option A is wrong because suppression duration only temporarily hides alerts after a match is triggered; it does not prevent the rule from firing in the first place. Option C is wrong because query frequency and period affect how often the rule runs and how far back it looks, but if the events are never ingested, no query will find them. Option D is wrong because 'GreaterThan' 0 is a correct trigger condition that would fire on any positive match; the issue is that no matches exist due to missing data.

Practice this question →
30
MCQeasy

Your team uses Microsoft Sentinel workbooks to visualize security data. You want to allow team members to customize a workbook without affecting the original. What should you do?

A.Edit the original workbook to add personalization
B.Assign the team the Microsoft Sentinel Reader role
C.Create a copy of the workbook and save it as a custom workbook
D.Share the workbook directly with the team
AnswerC

Creating a copy of the workbook and saving it as a custom workbook gives each user an independent Azure Workbooks resource that they can personalize without affecting the shared template. In Sentinel, selecting Save As typically prompts you to choose the resource group and name for the new workbook, creating a separate item in Workbooks that only the owner or granted users can edit. This approach satisfies the personalization requirement because modifications are stored in each user's own workbook resource, while the original template remains unchanged.

Why this answer

Creating a copy of the workbook and saving it as a custom workbook allows team members to modify their own version without altering the original. In Microsoft Sentinel, workbooks are based on Azure Monitor Workbooks, and saving a copy creates an independent resource with its own settings and queries. This preserves the original workbook for reference or reuse while enabling customization.

Exam trap

The trap here is that candidates may confuse the Microsoft Sentinel Reader role with the ability to customize workbooks, not realizing that Reader only allows viewing, not editing or saving copies, which requires at least Contributor permissions on the workbook resource.

How to eliminate wrong answers

Option A is wrong because editing the original workbook directly would modify the shared resource, affecting all users who access it, which contradicts the requirement to avoid impacting the original. Option B is wrong because the Microsoft Sentinel Reader role grants read-only access to Sentinel resources, including workbooks, but does not allow any customization or saving of copies. Option D is wrong because sharing the workbook directly with the team provides only read access by default; users cannot customize or save changes unless they have contributor permissions on the workbook resource, which still modifies the original.

Practice this question →
31
Multi-Selecteasy

You are a security analyst at a company that uses Microsoft Sentinel. You need to create a custom analytics rule that detects failed logon attempts from multiple IP addresses within 5 minutes. Which two KQL operators should you use?

Select 2 answers
A.where
B.project
C.bin
D.join
E.summarize
AnswersC, E

bin (sometimes called floor) rounds numeric values down to the nearest multiple of a specified bin size, creating discrete time buckets such as bin(timestamp, 1h). This function is essential for time-window grouping because it assigns each event to a specific bucket, which can then be used as a grouping key in summarize. By itself, bin does not aggregate; it only produces a grouping value. When combined with summarize, it enables time-series aggregations like count per hour, making it the correct choice for creating time windows.

Why this answer

The `bin` operator is correct because it groups timestamps into fixed-size time buckets (e.g., 5-minute intervals), which is essential for detecting patterns like failed logon attempts from multiple IPs within a specific time window. The `summarize` operator is correct because it aggregates data (e.g., counting distinct IP addresses) per each time bucket, enabling the rule to identify when the count exceeds a threshold.

Exam trap

The trap here is that candidates often confuse `where` or `project` as sufficient for time-window analysis, failing to recognize that only `bin` with `summarize` can group events into fixed intervals and aggregate distinct IPs per interval.

Practice this question →
32
MCQhard

A security analyst receives a high-severity incident in Microsoft Sentinel for a user who is suspected of lateral movement. The analyst wants to automatically run a playbook that isolates the user's machine and disables their account when such an incident is created. What is the most efficient way to achieve this?

A.Configure a Logic Apps trigger to poll for new incidents every minute
B.Train analysts to manually run the playbook when they see the incident
C.Create an analytics rule that runs a playbook as part of its alert generation
D.Create an automation rule that triggers the playbook when the incident is created
AnswerD

Creating an automation rule that triggers the playbook when the incident is created is the correct, documented approach in Microsoft Sentinel. Automation rules use a trigger condition (incident creation) to run a playbook automatically, and they provide a simple, event-driven integration with Logic Apps. This ensures the playbook executes immediately and consistently for every matching incident, without the need for manual intervention or custom polling logic.

Why this answer

Automation rules in Microsoft Sentinel are designed to trigger playbooks automatically when an incident is created, based on conditions like severity or rule name. This provides the most efficient, event-driven response without polling or manual intervention, directly addressing the requirement to isolate the machine and disable the account upon incident creation.

Exam trap

The trap here is confusing analytics rules (which generate alerts) with automation rules (which respond to incidents), leading candidates to incorrectly choose option C because they think a playbook must be tied directly to the alert generation process.

How to eliminate wrong answers

Option A is wrong because polling with a Logic Apps trigger every minute introduces latency and unnecessary overhead, and it is less efficient than an event-driven trigger. Option B is wrong because manual execution defeats the purpose of automation, increases response time, and is not efficient for a high-severity incident requiring immediate action. Option C is wrong because analytics rules generate alerts, not incidents; while a playbook can be run as part of alert generation, this approach does not directly respond to incident creation and may not cover all incident creation scenarios (e.g., from other sources).

Practice this question →
33
MCQmedium

Refer to the exhibit. A SOC analyst runs the KQL query in Microsoft Sentinel to identify the top 10 alert names by count. They notice the results include alerts with low severity that are not relevant. What should they add to the query to focus on high-severity alerts only?

A.Add 'order by Severity' to the query.
B.Add 'where Severity == "High"' after the summarize clause.
C.Change the time range to last 24 hours.
D.Add 'where Severity == "High"' before the summarize clause.
AnswerD

Adding `where Severity == "High"` before the summarize clause is the correct approach because it pushes the predicate as far upstream as possible in the query pipeline. KQL first restricts the alert stream to only High-severity rows, and then the summarize operator only sees and aggregates those filtered rows, reducing both I/O and aggregation cost. This aligns with Kusto best practice to filter early, and it is particularly important in Microsoft Sentinel where alert tables can contain millions of rows.

Why this answer

In KQL, the `where` clause must be placed before the `summarize` clause to filter raw events before aggregation. Placing `where Severity == "High"` before `summarize` ensures that only high-severity alerts are counted, preventing low-severity alerts from appearing in the top 10 results. This is a fundamental KQL query execution order: filtering first reduces the dataset for aggregation, improving both accuracy and performance.

Exam trap

The trap here is that candidates mistakenly think a `where` clause can be placed after `summarize` to filter aggregated results, but KQL requires filtering on raw columns before aggregation, and the `where` clause after `summarize` only works on aggregated columns (e.g., `count_`) unless the original column is explicitly included in the `summarize` output.

How to eliminate wrong answers

Option A is wrong because `order by Severity` only sorts the results after aggregation, it does not filter out low-severity alerts; the top 10 by count would still include low-severity alerts if they have high counts. Option B is wrong because adding `where Severity == "High"` after the `summarize` clause would attempt to filter aggregated results, but `Severity` is a field from the raw events and is not available after summarization unless explicitly projected; this would cause a query error or no filtering effect. Option C is wrong because changing the time range to last 24 hours does not filter by severity; it only limits the time window, so low-severity alerts within that period would still be included.

Practice this question →
34
MCQhard

Your organization is implementing Microsoft Sentinel in a multi-tenant environment using Azure Lighthouse. The SOC team needs to investigate incidents across all tenants from a single interface. Which configuration is required?

A.Use Azure AD B2B to grant users from other tenants access to the workspace.
B.Create a single workspace and have all tenants send logs to it.
C.Assign custom roles in each tenant's Sentinel workspace.
D.Onboard multiple workspaces to Azure Lighthouse and use a central workspace for investigation.
AnswerD

Onboarding multiple Sentinel workspaces to Azure Lighthouse is the proper approach because it enables delegated resource management across tenant boundaries. Once each tenant's workspace is delegated to the central management tenant, security analysts can use Azure Lighthouse to access all workspaces in a single browser session and leverage Sentinel's built-in multi-workspace views, such as unified incident management and cross-workspace hunting. This preserves each tenant's data ownership and isolation while giving the central SOC operational visibility, and it supports a dedicated central workspace for aggregating alerts and managing investigations across the enterprise.

Why this answer

Azure Lighthouse enables cross-tenant management by allowing the SOC team to delegate access to multiple Sentinel workspaces from a single control plane. This configuration lets investigators view and manage incidents across all tenants without needing separate sign-ins or duplicating data, which is essential for a multi-tenant SOC environment.

Exam trap

The trap here is that candidates often confuse Azure AD B2B (external user access) with Azure Lighthouse (delegated resource management), assuming that granting external identities access to a single workspace is sufficient for multi-tenant incident investigation, when in fact Lighthouse is required to project multiple workspaces into a single management plane.

How to eliminate wrong answers

Option A is wrong because Azure AD B2B provides external user access to a single tenant's resources but does not aggregate incidents from multiple tenants into one interface; each tenant would still require separate workspace access. Option B is wrong because sending logs from all tenants to a single workspace violates data residency and isolation requirements, and Microsoft Sentinel does not support ingesting logs from external tenants into a workspace without proper delegation. Option C is wrong because assigning custom roles in each tenant's Sentinel workspace still requires the SOC team to switch between tenants to investigate incidents, failing to provide a unified investigation interface.

Practice this question →
35
MCQhard

You have a Microsoft Sentinel workspace that uses Customer-Managed Keys (CMK). A security audit requires that all data at rest be encrypted with the CMK. You recently onboarded a new data connector that sends logs to a Log Analytics workspace in a different region. You need to ensure the new workspace uses CMK. What should you do?

A.Associate the new Log Analytics workspace with an Azure Key Vault containing the CMK before ingesting data.
B.Update the data connector settings to enable CMK at the source.
C.Use Azure Policy to enforce CMK on the new workspace.
D.Configure CMK on the new workspace's tables individually.
AnswerA

CMK configuration must occur before any data is written because Log Analytics binds the customer-managed key to the workspace's encryption context at provisioning time. After ingestion, the key association cannot be retroactively changed; enabling CMK on a workspace with existing data is not supported. Therefore, you must create the new workspace, associate it with the Key Vault key, and only then connect data sources.

Why this answer

Customer-Managed Keys (CMK) for Log Analytics workspaces must be configured at workspace creation time or before any data is ingested. The CMK is associated with the workspace via an Azure Key Vault, and once data is written, the encryption key cannot be changed. Therefore, to ensure the new workspace in a different region uses CMK, you must associate it with the Key Vault containing the CMK before any logs are ingested.

Exam trap

The trap here is that candidates may think CMK can be applied after data ingestion or per table, but Microsoft Sentinel requires CMK to be configured before any data is written to the workspace.

How to eliminate wrong answers

Option B is wrong because data connectors do not have settings to enable CMK at the source; CMK is a workspace-level encryption configuration, not a connector property. Option C is wrong because Azure Policy can enforce compliance but cannot retroactively apply CMK to a workspace that already has data; the policy must be assigned before data ingestion. Option D is wrong because CMK is applied at the workspace level, not per table; individual table encryption is not supported in Log Analytics.

Practice this question →
36
Multi-Selecthard

Your organization uses Microsoft Sentinel and Microsoft Copilot for Security. You want to improve incident response efficiency. Which THREE features should you implement? (Choose three.)

Select 3 answers
A.Enable Microsoft Copilot for Security to assist with incident investigations.
B.Use watchlists to track known malicious IP addresses.
C.Configure workbooks to display real-time incident trends.
D.Develop playbooks to automate response actions for common threats.
E.Create automation rules to automatically assign and triage incidents based on severity.
AnswersA, D, E

Microsoft Copilot for Security, embedded directly in Microsoft Sentinel, uses large language models to generate incident summaries and correlate evidence across alerts, logs, and threat intelligence. This enables analysts to ask natural-language questions about an attack and receive recommended next steps or response actions. By providing context-aware guidance and automating the initial investigative narrative, Copilot reduces the time to understand and act on a security incident.

Why this answer

Microsoft Copilot for Security integrates directly with Microsoft Sentinel to provide AI-driven natural language assistance for incident investigations, enabling analysts to query data, summarize incidents, and generate KQL queries without manual scripting. This directly improves incident response efficiency by reducing investigation time and cognitive load.

Exam trap

The trap here is that candidates confuse passive features (watchlists, workbooks) with active response features (Copilot, automation rules, playbooks), leading them to select options that provide visibility rather than efficiency improvements in incident handling.

Practice this question →
37
MCQeasy

You are a security operations analyst at a company that uses Microsoft Sentinel. You need to ensure that when a specific analytics rule generates an incident, a playbook is automatically triggered to post a message in a Microsoft Teams channel. What should you configure?

A.A workflow in Microsoft Teams that monitors the Sentinel incident queue.
B.A playbook that is triggered by the analytics rule directly.
C.An automation rule that triggers the playbook when the incident is created.
D.A scheduled query rule in Azure Monitor that detects the incident and calls the playbook.
AnswerC

Automation rules in Microsoft Sentinel can trigger playbooks based on incident creation. By creating an automation rule that runs when the specific analytics rule generates an incident, you can automatically invoke the playbook that posts to Microsoft Teams. This is the correct method to achieve the required automation.

Why this answer

To automatically trigger a playbook when a specific analytics rule creates an incident, you need an automation rule. Automation rules in Microsoft Sentinel respond to incident creation and can invoke playbooks. The playbook can then use the Microsoft Teams connector to post a message.

This is the standard and supported method for this automation.

Exam trap

The trap here is thinking that an analytics rule can directly trigger a playbook or that a Teams workflow can monitor Sentinel incidents, bypassing the need for an automation rule.

Practice this question →
38
Multi-Selecteasy

Which TWO actions can you perform in the Microsoft Defender XDR unified alert queue? (Select TWO.)

Select 2 answers
A.Link the alert to an existing incident
B.Assign an alert to a SOC analyst
C.Create a hunting query from the alert details
D.Edit the analytics rule that generated the alert
E.Run a playbook to automatically remediate the alert
AnswersA, B

In the Microsoft Defender XDR alert queue, you can take an alert and associate it with an existing incident by selecting the 'Link to incident' action. This consolidates related alerts into a single incident, allowing the SOC team to manage and investigate the full scope of an attack from one place. The linkage is stored so that the alert's lifecycle becomes tied to the incident's status, ensuring proper tracking and correlation.

Why this answer

In the Microsoft Defender XDR unified alert queue, you can link an alert to an existing incident to consolidate related alerts into a single investigation. This action is supported directly from the alert queue interface, allowing analysts to manage incident correlation without leaving the queue. Linking alerts helps reduce alert fatigue and streamlines the incident management workflow.

Exam trap

The trap here is that candidates often confuse the unified alert queue with the incident queue, mistakenly thinking that actions like running playbooks or editing rules are available directly from the alert queue, when in fact those actions are tied to incidents or separate configuration interfaces.

Practice this question →
39
MCQeasy

You manage Microsoft Sentinel. You need to ensure that an automated response is triggered when a specific type of incident is created. The response should send an email to the on-call security engineer. What should you use?

A.Use a watchlist to map incident types to email addresses and configure a scheduled query.
B.Create an automation rule that runs a playbook when an incident is created.
C.Modify the analytics rule to include an email action in the rule settings.
D.Create a workbook that alerts via email when new incidents appear.
AnswerB

Automation rules are Sentinel's built-in incident orchestration engine; they evaluate triggers like incident creation and can invoke playbooks. A playbook is an Azure Logic Apps workflow that can send email through connectors such as Outlook or Office 365. This design cleanly separates detection from response and supports re-use of the same playbook across multiple rules.

Why this answer

Automation rules in Microsoft Sentinel can trigger a playbook (an Azure Logic Apps workflow) when an incident is created. The playbook can include an action to send an email to the on-call security engineer, providing the automated response required by the scenario.

Exam trap

The trap here is that candidates often confuse automation rules with analytics rule settings or workbooks, mistakenly thinking that email actions can be configured directly in the analytics rule or that workbooks can send alerts, when in fact only automation rules with playbooks provide the necessary automated response capability.

How to eliminate wrong answers

Option A is wrong because watchlists are used for correlation and enrichment of data in queries, not for triggering automated email responses; a scheduled query can generate alerts but does not directly send emails based on incident types. Option C is wrong because analytics rules do not have a built-in email action in their settings; they generate alerts or incidents, but email notifications must be handled by automation rules or playbooks. Option D is wrong because workbooks are visualization tools that do not send alerts via email; they display data but cannot trigger automated responses like email notifications.

Practice this question →
40
MCQmedium

A security incident in Microsoft Sentinel has been classified as a true positive and remediated. According to your SOC playbook, the incident should be closed with a classification of 'True Positive' and a sub-classification of 'Confirmed activity'. What is the correct way to close the incident in Microsoft Sentinel?

A.In the Microsoft Sentinel incident, set Status to 'Closed', Classification to 'True Positive', and Sub-classification to 'Confirmed activity'.
B.Close the incident in Microsoft Defender XDR and let it sync to Microsoft Sentinel.
C.Change the incident status to 'Closed' without adding a classification.
D.Use the Microsoft Security Graph API to close the incident with the appropriate classification.
AnswerA

In the Microsoft Sentinel incident pane, set Status to 'Closed', Classification to 'True Positive', and Sub-classification to 'Confirmed activity'. This exact combination satisfies the SOC playbook's closure criteria and writes the triage verdict into the incident metadata for Microsoft Sentinel analytics and reporting. Closing directly in Sentinel ensures that any automation rules triggered by incident closure run with the expected values, preserving the audit trail for compliance.

Why this answer

Using the Microsoft Security Graph API to close the incident is unnecessary and out of scope here: the scenario calls for a single incident to be manually closed per the SOC playbook's exact classification and sub-classification values, which is done directly in the Microsoft Sentinel incident pane. The Graph API is useful for bulk/programmatic incident updates, but that is not what this scenario requires, so it is not the correct choice here.

Exam trap

The trap here is that candidates may assume closing an incident in Microsoft Defender XDR will sync all details to Sentinel, but in reality, Sentinel requires direct closure within its own interface to apply classification and sub-classification fields.

How to eliminate wrong answers

Option B is wrong because closing an incident in Microsoft Defender XDR does not automatically sync the classification and sub-classification to Microsoft Sentinel; Sentinel incidents must be closed within Sentinel to set these fields. Option C is wrong because changing the status to 'Closed' without adding a classification leaves the incident without a proper closure reason, which violates the SOC playbook and hinders accurate reporting and auditing. Option D is wrong because while the Microsoft Security Graph API can be used to close incidents, it is not the correct or recommended method for this scenario; the Sentinel portal provides the direct and intended way to set classification and sub-classification fields.

Practice this question →
41
Multi-Selecthard

Which THREE capabilities are provided by Microsoft Defender for Cloud's Cloud Security Posture Management (CSPM) plan? (Select THREE.)

Select 3 answers
A.Compliance dashboard that shows your posture against regulatory standards.
B.Continuous assessment of your cloud resources against security best practices.
C.Endpoint detection and response for on-premises machines.
D.Secure score calculation based on implemented security controls.
E.Integrated vulnerability assessment for virtual machines.
AnswersA, B, D

The compliance dashboard in Microsoft Defender for Cloud provides a continuous view of your regulatory compliance posture, mapping security assessments to standards such as CIS Controls, NIST SP 800-53, and Azure CIS. It tracks compliance against these frameworks over time, shows which controls are failing, and lets you download evidence for audits. This is a core Cloud Security Posture Management (CSPM) capability, distinct from individual workload protections.

Why this answer

Microsoft Defender for Cloud's CSPM plan includes a compliance dashboard that continuously assesses your cloud resources against regulatory standards such as SOC 2, ISO 27001, and PCI DSS. This dashboard provides a real-time view of your compliance posture, mapping security controls to specific regulatory requirements and highlighting non-compliant resources.

Exam trap

The trap here is that candidates often confuse the CSPM plan's compliance and secure score capabilities with workload protection features like vulnerability assessment or EDR, which belong to separate Defender plans (e.g., Defender for Servers or Defender for Endpoint).

Practice this question →
42
MCQmedium

Your organization has Microsoft Defender for Cloud Apps (MDA) connected to Microsoft Sentinel. The SOC team wants to receive alerts when a user accesses a sanctioned cloud app from an anonymous IP address. What should you configure?

A.Create a file policy in Defender for Cloud Apps.
B.Create an activity policy in Defender for Cloud Apps and connect it to Sentinel.
C.Enable the Defender for Cloud Apps connector in Sentinel without additional configuration.
D.Create a session policy in Defender for Cloud Apps.
AnswerB

Anonymised IP access is a user activity signal, not a Microsoft Sentinel analytics rule condition. Defender for Cloud Apps activity policies evaluate app sessions against risk factors such as anonymous proxy usage, then forward matching alerts into Microsoft Sentinel through the connected data connector, satisfying the SOC's alerting requirement.

Why this answer

An activity policy in Defender for Cloud Apps can be configured to trigger alerts on specific user activities, such as accessing a sanctioned app from an anonymous IP address. This policy can then be connected to Microsoft Sentinel via the Defender for Cloud Apps data connector, which ingests alerts as incidents for SOC review. File policies (A) focus on file-level actions like sharing or malware detection, not user access events, while session policies (D) control real-time access but do not generate alerts for historical or post-access monitoring.

Exam trap

The trap here is that candidates confuse file policies with activity policies, assuming any policy in Defender for Cloud Apps can detect access events, but only activity policies are designed to monitor user sign-in and access behaviors against IP-based conditions.

How to eliminate wrong answers

Option A is wrong because file policies monitor file-related activities (e.g., sharing, upload, download) and cannot detect user access events like logging into an app from an anonymous IP. Option C is wrong because simply enabling the Defender for Cloud Apps connector in Sentinel without additional configuration only ingests default alerts (e.g., from anomaly detection policies), not custom activity-based alerts for anonymous IP access. Option D is wrong because session policies are designed for real-time access control and monitoring during a user session (e.g., blocking downloads), not for generating alerts on access events that have already occurred.

Practice this question →
43
MCQmedium

You are configuring automated responses in Microsoft Sentinel. You have created an automation rule that runs a playbook when an incident is created. The playbook performs actions in Microsoft Entra ID and Microsoft Defender for Cloud. However, the playbook fails with a permissions error. What should you do?

A.Assign the managed identity of the playbook the required roles in Microsoft Entra ID and Defender for Cloud.
B.Enable 'Allow playbooks to use managed identity' in the Sentinel settings.
C.Configure the Microsoft Entra ID connector in Sentinel with delegated permissions.
D.Grant the security analyst's account Contributor permissions on the automation rule.
AnswerA

The playbook runs under its own system-assigned managed identity in Microsoft Entra ID rather than under a user account. For automated responses to succeed, that identity must be explicitly assigned Azure RBAC roles—such as Security Reader or Security Admin on the relevant subscriptions/resource groups—and matching roles in Defender for Cloud. Without these assignments, the Logic App's API calls to fetch alerts or trigger actions are denied, causing the automation rule to fail.

Why this answer

The playbook fails with a permissions error because it uses a managed identity to authenticate to Microsoft Entra ID and Microsoft Defender for Cloud, but that identity has not been granted the necessary Azure RBAC roles (e.g., Security Reader, Security Admin) on the target resources. Assigning the required roles to the managed identity directly resolves the authorization failure.

Exam trap

The trap here is that candidates often confuse enabling the managed identity feature (Option B) with actually assigning the necessary RBAC roles to that identity, assuming the setting alone grants permissions.

How to eliminate wrong answers

Option B is wrong because 'Allow playbooks to use managed identity' is a setting that enables the use of managed identities for authentication, but it does not grant the actual permissions needed to perform actions in Entra ID or Defender for Cloud; permissions must be assigned separately via RBAC. Option C is wrong because configuring the Microsoft Entra ID connector with delegated permissions is used for user-based authentication (OAuth 2.0 authorization code flow), not for a playbook’s managed identity; the playbook uses a system-assigned or user-assigned managed identity, not delegated permissions. Option D is wrong because granting the security analyst's account Contributor permissions on the automation rule does not affect the permissions of the playbook’s managed identity; the playbook runs under its own identity, not the analyst’s account.

Practice this question →
44
MCQmedium

Your security team uses Microsoft Defender for Cloud to assess the security posture of Azure resources. You need to ensure that all virtual machines have endpoint protection enabled. Which policy initiative should you assign?

A.Enable encryption on Azure VMs
B.Deploy Microsoft Defender for Endpoint
C.Deploy Windows Defender Exploit Guard
D.Azure Security Benchmark
AnswerB

Deploy Microsoft Defender for Endpoint is a built-in policy initiative in Microsoft Defender for Cloud that contains definitions such as 'Configure machines to automatically onboard to Microsoft Defender for Endpoint' and 'Endpoint protection solution should be installed on virtual machines.' This initiative actually installs and deploys the Defender for Endpoint agent to Azure VMs, enabling EDR, real-time antimalware protection, and vulnerability management. Because it directly fulfills the regulatory goal of deploying endpoint protection, it is the correct initiative to assign for this requirement.

Why this answer

The 'Deploy Microsoft Defender for Endpoint' policy initiative is specifically designed to ensure that all Azure VMs have endpoint protection enabled. This initiative deploys the Microsoft Defender for Endpoint agent to VMs that are missing it, directly addressing the requirement for endpoint protection. Other options focus on encryption, exploit guard configuration, or general security benchmarks, not the deployment of endpoint protection.

Exam trap

The trap here is that candidates often confuse 'deploying endpoint protection' with 'configuring security features' (like Exploit Guard) or 'applying broad benchmarks' (like Azure Security Benchmark), rather than recognizing that only the specific 'Deploy Microsoft Defender for Endpoint' initiative installs the endpoint protection agent.

How to eliminate wrong answers

Option A is wrong because 'Enable encryption on Azure VMs' addresses disk encryption (e.g., Azure Disk Encryption), not endpoint protection. Option C is wrong because 'Deploy Windows Defender Exploit Guard' configures attack surface reduction rules and exploit protection settings, but it does not deploy the endpoint protection agent itself. Option D is wrong because 'Azure Security Benchmark' is a broad set of security recommendations and compliance controls, not a policy initiative that deploys endpoint protection agents.

Practice this question →
45
MCQmedium

Your organization is using Microsoft Sentinel and you are responsible for managing the security operations environment. You need to ensure that a new security analyst can triage incidents but cannot modify analytics rules. Which role should you assign?

A.Microsoft Sentinel Responder
B.Microsoft Sentinel Reader
C.Microsoft Sentinel Contributor
D.Microsoft Sentinel Contributor with a custom role denying rule modification
AnswerA

Microsoft Sentinel Responder is the correct choice because it grants the ability to triage incidents directly—changing their status, assigning ownership, and adding comments—without any write permissions to analytics rules. This precisely matches the requirement to act on incidents while being prohibited from modifying detection rules. The Responder role is a built-in Azure RBAC role designed exactly for this job, providing least privilege and avoiding any unnecessary Sentinel management capabilities.

Why this answer

The Microsoft Sentinel Responder role provides the necessary permissions to triage incidents (view, investigate, respond) while explicitly excluding write access to analytics rules. This matches the requirement for a security analyst who needs to handle incidents but cannot modify detection logic.

Exam trap

The trap here is that candidates often confuse 'Responder' with 'Reader' or assume 'Contributor' is needed for any interactive work, but Microsoft specifically designed the Responder role for incident triage without rule modification permissions.

How to eliminate wrong answers

Option B (Microsoft Sentinel Reader) is wrong because it only allows read access to all Sentinel data, including incidents, but does not permit any response actions like changing incident status or assigning ownership. Option C (Microsoft Sentinel Contributor) is wrong because it grants full write access to all Sentinel resources, including the ability to create, modify, or delete analytics rules, which exceeds the required permissions. Option D (Microsoft Sentinel Contributor with a custom role denying rule modification) is wrong because it is unnecessarily complex and not a built-in role; the Responder role already provides the exact permissions needed without custom role creation.

Practice this question →
46
MCQeasy

Your team uses Microsoft Sentinel to monitor multiple Azure subscriptions. You need to grant a junior analyst the ability to view incidents and run playbooks, but not modify analytics rules or data connectors. Which built-in role should you assign?

A.Microsoft Sentinel Contributor
B.Automation Contributor
C.Microsoft Sentinel Reader
D.Microsoft Sentinel Responder
AnswerD

Microsoft Sentinel Responder is the built-in incident-response role that can view, triage, and manage incidents while also being able to execute playbooks directly from those incidents. Its permission set includes Microsoft.SecurityInsights/incidents/read, /write, and /playbooks/execute, allowing a responder to run the playbook and update the incident without granting broader SIEM configuration rights like altering analytics rules or connectors. This role is the correct least-privilege assignment because it specifically enables the requested playbook execution while still maintaining separation of duties from administrative Sentinel tasks.

Why this answer

Microsoft Sentinel Responder is the correct built-in role because it grants the junior analyst the ability to view incidents and run playbooks, while explicitly preventing modifications to analytics rules or data connectors. This role provides the exact permissions needed for incident response tasks without allowing changes to the security configuration.

Exam trap

The trap here is that candidates often confuse 'Responder' with 'Reader' or 'Contributor', assuming that running playbooks requires Contributor-level access, when in fact the Responder role is specifically designed for incident response actions without broader management rights.

How to eliminate wrong answers

Option A is wrong because Microsoft Sentinel Contributor has full write access to Sentinel resources, including the ability to modify analytics rules and data connectors, which exceeds the required permissions. Option B is wrong because Automation Contributor only allows management of Azure Automation resources (like runbooks and jobs) but does not grant any permissions to view or manage Sentinel incidents. Option C is wrong because Microsoft Sentinel Reader is read-only and cannot run playbooks, which requires the 'Microsoft.SecurityInsights/incidents/runPlaybook/action' permission.

Practice this question →
47
Multi-Selecteasy

Which TWO are supported data sources for Microsoft Sentinel?

Select 2 answers
A.Google Cloud VPC Flow Logs
B.Windows Server 2008 event logs
C.Microsoft Entra ID audit logs
D.AWS CloudTrail
E.On-premises syslog-ng
AnswersC, D

Microsoft Entra ID audit logs are a correct, natively supported data source for Microsoft Sentinel. Sentinel's Microsoft Entra ID connector (formerly Azure AD) ingests sign-in logs, audit logs, and provisioning logs into the workspace for identity-based detection and investigation. This connector is first-party and uses the Microsoft Graph API or diagnostic settings, making it a standard supported source.

Why this answer

Microsoft Entra ID audit logs (Option C) are a native data source for Microsoft Sentinel because Sentinel is built on Azure Monitor Logs and directly ingests Entra ID (formerly Azure AD) diagnostic settings via the Azure portal or API. This integration requires no additional connectors or agents, as Entra ID audit logs are automatically forwarded to a Log Analytics workspace when configured under 'Diagnostic settings' in the Entra ID blade.

Exam trap

The trap here is that candidates often assume any syslog source (like syslog-ng) is directly supported, but Microsoft Sentinel only supports syslog via the Linux agent or AMA, not the syslog-ng daemon itself as a distinct data source.

Practice this question →
48
MCQmedium

Your organization uses Microsoft Sentinel and has enabled UEBA. You notice that many low-severity incidents are being created from high-volume informational alerts. You want to reduce noise without disabling data connectors. What should you do?

A.Create an automation rule that closes low-severity incidents immediately.
B.Increase the incident creation threshold in the analytics rule.
C.Modify the analytics rule query to exclude the high-volume informational events using KQL.
D.Disable the Microsoft 365 Defender connector for those data sources.
AnswerC

Modify the KQL query behind the analytics rule to exclude the high-volume informational events, e.g., by filtering out event IDs, specific log sources, or task categories with a `where` clause. This stops those events from ever being selected for alert generation, reducing incident noise and storage/ingestion costs at the source. It preserves detection coverage for all other event types and is the recommended approach for tuning noisy analytics rules.

Why this answer

Modifying the analytics rule query to exclude high-volume informational events using KQL directly addresses the root cause: the rule is generating low-severity incidents from noisy informational data. This approach preserves the data connectors and UEBA functionality while filtering out the specific events that cause alert fatigue. Unlike automation rules that close incidents after creation, query modification prevents the incidents from being generated in the first place.

Exam trap

The trap here is that candidates often choose automation rules (Option A) because they seem like a quick fix to close incidents, but they fail to realize that the incidents are still created and consume resources, whereas modifying the query prevents generation entirely.

How to eliminate wrong answers

Option A is wrong because closing incidents immediately with an automation rule still generates the incident, consuming storage and processing resources, and does not address the underlying issue of noisy analytics rules; it also bypasses proper triage. Option B is wrong because increasing the incident creation threshold in the analytics rule would suppress all low-severity incidents, potentially missing legitimate threats that match the same severity level, and it does not differentiate between high-volume informational events and other low-severity events. Option D is wrong because disabling the Microsoft 365 Defender connector would stop all data ingestion from that source, including critical security signals, and is an overly aggressive measure that violates the requirement to not disable data connectors.

Practice this question →
49
MCQmedium

Your organization uses Microsoft Defender for Identity. The security team wants to monitor for suspected DCSync attacks. Which Windows Event ID should you monitor to detect DCSync activity?

A.Event ID 4776: The domain controller attempted to validate the credentials for an account.
B.Event ID 4662: An operation was performed on an object.
C.Event ID 4648: A logon was attempted using explicit credentials.
D.Event ID 4624: An account was successfully logged on.
AnswerB

Event ID 4662 logs when an operation is performed on an Active Directory object, including directory replication operations. In the context of DCSync, you would look for 4662 events where the operation includes control access rights like DS-Replication-Get-Changes or DS-Replication-Get-Changes-All. These rights are required to perform replication and, when requested from a non-domain-controller source, are a strong indicator of a DCSync attempt. This makes 4662 the correct event to monitor for this attack.

Why this answer

Event ID 4662 logs any operation performed on an Active Directory object, including the directory service access control entry for the DS-Replication-Get-Changes-All extended right (control access right 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2). A DCSync attack uses this right to replicate domain credentials from a domain controller, so monitoring 4662 with the specific object type and access mask for replication is the correct detection method.

Exam trap

The trap here is that candidates confuse authentication events (4776, 4624) or credential use events (4648) with the directory replication operation that DCSync actually performs, leading them to choose a logon-related event ID instead of the object access event that captures the replication request.

How to eliminate wrong answers

Option A is wrong because Event ID 4776 logs credential validation attempts by the domain controller, which is a normal authentication event and does not indicate the replication of directory data required for DCSync. Option C is wrong because Event ID 4648 logs logons using explicit credentials (e.g., RunAs), which is unrelated to the directory replication process that DCSync exploits. Option D is wrong because Event ID 4624 logs successful logon events, which are too generic and do not capture the specific directory service access or replication operations that characterize a DCSync attack.

Practice this question →
50
MCQmedium

Your SOC team uses Microsoft Defender XDR. You want to ensure that all incidents are automatically classified and determined by the built-in AI before any manual review. What should you configure?

A.Create a custom detection rule in Microsoft Defender XDR.
B.Enable the incident summarization and classification feature in Microsoft Defender XDR.
C.Enable automation rules in Microsoft Sentinel to classify incidents.
D.Configure a workbook in Microsoft Sentinel to analyze incidents.
AnswerB

The incident summarization and classification feature in Microsoft Defender XDR is a built-in AI capability that automatically analyzes the alert and incident evidence, generates a natural-language summary, and assigns a classification (e.g., true positive, false positive, informational) and determination to each incident. Enabling this feature meets the stated objective because it activates the platform's native machine learning reasoning to pre-classify incidents before human review, significantly reducing analyst workload.

Why this answer

Microsoft Defender XDR includes a built-in AI-driven incident summarization and classification feature that automatically assigns a classification (e.g., true positive, false positive) and determination (e.g., malicious, clean) to each incident before manual review. This feature leverages machine learning models trained on Microsoft's global threat intelligence to reduce alert fatigue and streamline SOC workflows.

Exam trap

The trap here is that candidates may confuse the AI-driven incident classification in Defender XDR with automation rules in Microsoft Sentinel, which are for response actions, not for the built-in AI classification and determination of incidents.

How to eliminate wrong answers

Option A is wrong because custom detection rules in Microsoft Defender XDR are used to create custom alerts based on specific query logic, not to automatically classify or determine incidents via AI. Option C is wrong because automation rules in Microsoft Sentinel are designed for automated incident response and orchestration (e.g., assigning ownership, changing status), not for the built-in AI classification and determination of incidents within Defender XDR. Option D is wrong because workbooks in Microsoft Sentinel are visualization tools for analyzing data and metrics, not a configuration that enables automatic AI-driven incident classification.

Practice this question →
51
MCQeasy

You are configuring a Microsoft Sentinel analytics rule to detect failed logons from multiple IP addresses. The rule should trigger an incident only when the same user account has failed logons from more than three distinct IP addresses within 5 minutes. Which rule setting should you configure?

A.Set the 'Alert threshold' to 'Custom' and define a condition on distinct IP count.
B.Set the 'Group by' field to 'Account' and 'IP address'.
C.Set the 'Event grouping' to 'Group all events into a single alert'.
D.Set the 'Suppression' to '5 minutes' after an alert is generated.
AnswerA

Setting the Alert threshold to Custom lets you specify an aggregation condition on the query results, such as dcount(IP_Address) greater than a numeric value. This matches the required detection of a single account being accessed from many distinct IPs, which indicates distributed brute-force activity. The rule will fire only when the distinct IP count crosses the defined threshold.

Why this answer

The requirement is to trigger an incident only when the same user account has failed logons from more than three distinct IP addresses within 5 minutes. In Microsoft Sentinel analytics rules, the 'Alert threshold' set to 'Custom' allows you to define a condition on the count of distinct values (e.g., distinct IP addresses) aggregated over the rule's query window, which directly matches the scenario.

Exam trap

The trap here is that candidates often confuse 'Group by' (which splits alerts by field values) with the ability to count distinct values across those groups, leading them to select Option B instead of recognizing that a custom threshold on distinct count is required.

How to eliminate wrong answers

Option B is wrong because setting 'Group by' to 'Account' and 'IP address' would create separate alerts for each combination of account and IP address, not aggregate distinct IPs per account. Option C is wrong because 'Group all events into a single alert' would combine all failed logon events into one alert regardless of distinct IP count, failing to enforce the 'more than three distinct IPs' threshold. Option D is wrong because 'Suppression' pauses alert generation after an alert fires, but does not control the condition for triggering the alert based on distinct IP count within a time window.

Practice this question →
52
MCQhard

Your organization uses Microsoft Sentinel and has multiple workspaces for different regions. The security team wants to use a single workbook to display data from all workspaces. What is the correct approach?

A.Create a workbook with cross-workspace queries using the workspace() expression
B.Export data from all workspaces to a single Azure Data Lake
C.Create a workbook in one workspace and configure it to use Azure Lighthouse
D.Create a workbook in each workspace and merge them manually
AnswerA

The workspace() expression lets a single workbook query tables in other Microsoft Sentinel workspaces, satisfying the requirement to display data from all regional workspaces in one view. It bypasses the default single-workspace scope without duplicating workbooks or exporting data.

Why this answer

Microsoft Sentinel workbooks support cross-workspace queries using the `workspace()` expression in Kusto Query Language (KQL). This allows a single workbook to aggregate and display data from multiple Sentinel workspaces without moving or duplicating the data, meeting the security team's requirement efficiently.

Exam trap

The trap here is that candidates may confuse Azure Lighthouse (which is for cross-tenant management) with cross-workspace querying, or assume that data must be centralized (e.g., via Data Lake) before it can be visualized in a single workbook.

How to eliminate wrong answers

Option B is wrong because exporting data to Azure Data Lake requires additional services (e.g., Azure Data Factory or Event Hubs) and does not provide a native way to query the data in a Sentinel workbook; it also incurs extra cost and latency. Option C is wrong because Azure Lighthouse enables cross-tenant management but does not allow a single workbook to query multiple workspaces within the same tenant; workbooks still need explicit cross-workspace queries. Option D is wrong because creating separate workbooks in each workspace and manually merging them is not a scalable or automated solution, and it defeats the purpose of a single unified view.

Practice this question →
53
MCQeasy

You are setting up Microsoft Sentinel for the first time. You need to ingest Windows security events from on-premises servers using the Azure Monitor Agent. Which data connector should you enable in Microsoft Sentinel?

A.Common Event Format (CEF) via AMA
B.Windows Security Events via AMA
C.Syslog via AMA
D.DNS via AMA
AnswerB

Windows Security Events via AMA is the correct connector because it uses the Azure Monitor Agent to collect security-relevant events directly from the Windows Event Log (Security, System, Application). This connector gives you the audit trail needed for detection rules, UEBA, and incident investigation—covering events like 4624 logon successes, 4625 failures, and 4688 process creation. As AMA is the supported replacement for the legacy Log Analytics agent, this is the standard, first-party choice for Windows security telemetry in Sentinel.

Why this answer

The Windows Security Events via AMA data connector is specifically designed to collect Windows security events (e.g., Event ID 4625, 4688) from on-premises servers using the Azure Monitor Agent (AMA). This connector leverages the AMA's Data Collection Rules (DCRs) to filter and ingest security-relevant logs directly into Microsoft Sentinel, making it the correct choice for this scenario.

Exam trap

The trap here is that candidates often confuse 'Syslog via AMA' with Windows event collection, but Syslog is a Linux-centric protocol (UDP/TCP 514) and cannot natively read Windows Event Log files.

How to eliminate wrong answers

Option A is wrong because Common Event Format (CEF) via AMA is used for ingesting logs from security appliances (e.g., firewalls, IDS/IPS) that output CEF-formatted syslog messages, not native Windows security events. Option C is wrong because Syslog via AMA is designed for Linux-based syslog data (RFC 3164/5424) and does not natively collect Windows Event Log data. Option D is wrong because DNS via AMA is a specialized connector for collecting DNS query/response logs from Windows DNS servers, not general Windows security events.

Practice this question →
54
MCQeasy

Your organization uses Microsoft Defender XDR. You need to ensure that all cloud app alerts are forwarded to Microsoft Sentinel for correlation. What should you configure?

A.Create an analytics rule in Sentinel that queries Defender for Cloud Apps API.
B.Configure Microsoft Defender for Cloud Apps to export alerts to Azure Event Hubs.
C.In Microsoft Sentinel, enable the data connector for Microsoft Defender for Cloud Apps.
D.In Microsoft Sentinel, enable the data connector for Microsoft Defender for Endpoint.
AnswerC

Enabling the Defender for Cloud Apps data connector in Microsoft Sentinel establishes a native, one-click ingestion pipeline that automatically imports alerts and incidents from the cloud app security service into Log Analytics. This connector uses Microsoft Graph Security API to synchronize alert data, allowing security analysts to investigate cloud application threats alongside other signals in Sentinel. Once enabled, alerts become available in the SecurityAlert table, and you can then build analytics rules or workbooks on top of them.

Why this answer

The Microsoft Defender for Cloud Apps data connector in Microsoft Sentinel is specifically designed to ingest alerts and cloud discovery logs from Defender for Cloud Apps. Enabling this connector ensures that all cloud app alerts are automatically forwarded to Sentinel for correlation without requiring custom API queries or external export pipelines.

Exam trap

The trap here is that candidates may confuse the purpose of data connectors for different Microsoft Defender products, mistakenly selecting the Defender for Endpoint connector when the question specifically targets cloud app alerts.

How to eliminate wrong answers

Option A is wrong because creating an analytics rule that queries the Defender for Cloud Apps API would require custom logic and does not provide automated, continuous ingestion of alerts; analytics rules are for detection, not data ingestion. Option B is wrong because exporting alerts to Azure Event Hubs is an alternative method for custom integration, but it is not the standard or recommended configuration for forwarding all cloud app alerts to Sentinel; the built-in data connector is simpler and directly supported. Option D is wrong because the Microsoft Defender for Endpoint data connector ingests endpoint detection and response alerts, not cloud app alerts; it addresses a different security domain.

Practice this question →
55
Multi-Selectmedium

Which TWO actions are valid ways to integrate on-premises firewall logs into Microsoft Sentinel for analysis?

Select 2 answers
A.Enable the Office 365 connector.
B.Configure the firewall to send Common Event Format (CEF) logs to a syslog server running Azure Monitor Agent.
C.Install the Windows DNS Server connector.
D.Connect the Azure Activity log connector.
E.Use the Microsoft Sentinel Data Collector API to send custom logs.
AnswersB, E

This is a standard, supported integration path for firewall appliances that emit Common Event Format (CEF) messages over syslog. The firewall sends CEF to a log collector/forwarder that has the Azure Monitor Agent installed; AMA forwards the events to a Log Analytics workspace using a data collection rule, populating the CommonSecurityLog table in Microsoft Sentinel. This method preserves normalized fields such as source/destination IP, port, and action, making it directly usable by analytics rules.

Why this answer

On-premises firewall logs can be forwarded in Common Event Format (CEF) over syslog to a server running the Azure Monitor Agent (AMA), which then ingests them into Microsoft Sentinel. CEF is a standard log format supported by many security appliances, and the AMA replaces the older Log Analytics Agent for this purpose. This setup allows Sentinel to parse and analyze the firewall events for security monitoring.

Exam trap

The trap here is that candidates often confuse the Azure Activity log connector (which only covers Azure resource operations) with a general-purpose log ingestion method, or they mistakenly think the Office 365 connector can handle any external log source.

Practice this question →
56
MCQmedium

Your organization uses Microsoft Defender XDR. You need to investigate a potential ransomware incident that has affected multiple devices. The security team wants to identify the initial access vector. Which advanced hunting table should you query to find the process that initiated the encryption?

A.DeviceRegistryEvents
B.DeviceFileEvents
C.DeviceNetworkEvents
D.DeviceProcessEvents
AnswerD

DeviceProcessEvents captures every process creation, along with the file name, command line, and parent process PID, enabling analysts to build a process tree from the initial point of execution. This table is the authoritative source for tracking the initial process — such as a malicious binary launched from an Office macro — because it records the moment the process became active. By querying DeviceProcessEvents, incident responders can trace the parent process chain and determine exactly which executable initiated the encryption.

Why this answer

DeviceProcessEvents logs process creation events, including the command line and parent process details. To identify the initial access vector in a ransomware incident, you need to trace the process tree back to the executable that launched the encryption process, which is precisely what this table captures.

Exam trap

The trap here is that candidates confuse the artifact of encryption (file changes in DeviceFileEvents) with the action that caused it (process creation in DeviceProcessEvents), leading them to choose DeviceFileEvents instead of the correct table for tracing the initial access vector.

How to eliminate wrong answers

Option A is wrong because DeviceRegistryEvents logs registry modifications, not process creation or execution details, so it cannot show which process initiated encryption. Option B is wrong because DeviceFileEvents logs file creation, modification, and deletion events, but does not capture the parent-child process relationships needed to trace the initial access vector. Option C is wrong because DeviceNetworkEvents logs network connections and traffic, which can show C2 communication but not the local process that started the encryption.

Practice this question →
57
MCQeasy

Your organization uses Microsoft Defender for Office 365. You need to ensure that suspicious email messages are automatically moved to quarantine and an incident is raised in Microsoft Sentinel. What should you configure?

A.Configure the Microsoft Defender for Office 365 data connector in Sentinel.
B.Configure the Microsoft Defender for Cloud data connector in Sentinel.
C.Use the Microsoft Defender for Identity data connector.
D.Enable the Microsoft Defender for Endpoint data connector.
AnswerA

The Microsoft Defender for Office 365 data connector in Sentinel is the appropriate choice because it directly ingests rich Office 365 security signals, including alerts for phishing, malware, malicious URLs, and user-reported email threats, as well as unified incidents. This connector enables you to automatically collect these alerts and correlate them with other analytics in Sentinel, providing complete visibility into email, Teams, and compliance-related threats. No other connector provides native, purpose-built ingestion of Office 365 protection data.

Why this answer

The Microsoft Defender for Office 365 data connector in Microsoft Sentinel ingests email-related alerts and events (e.g., phishing, malware, spam) from Defender for Office 365. When you configure automated investigation and response (AIR) policies in Defender for Office 365 to move suspicious emails to quarantine, and enable the connector in Sentinel, those quarantine actions trigger corresponding incidents in Sentinel. This integration ensures that email threats are both remediated (quarantined) and tracked as security incidents for further analysis.

Exam trap

The trap here is that candidates often confuse the purpose of data connectors—thinking any 'Defender' connector (e.g., Defender for Cloud or Defender for Endpoint) can ingest email security events, when in fact only the specific Office 365 connector handles email quarantine and incident generation for Defender for Office 365.

How to eliminate wrong answers

Option B is wrong because the Microsoft Defender for Cloud data connector focuses on security alerts from cloud workloads (e.g., VMs, containers, SQL) and does not ingest email-related events from Defender for Office 365. Option C is wrong because the Microsoft Defender for Identity data connector ingests alerts related to on-premises Active Directory identity threats (e.g., pass-the-hash, lateral movement) and has no capability to process email quarantine actions. Option D is wrong because the Microsoft Defender for Endpoint data connector ingests endpoint detection and response (EDR) alerts from devices (e.g., malware detections, suspicious processes) and cannot handle email quarantine events from Defender for Office 365.

Practice this question →
58
MCQeasy

Your organization uses Microsoft Sentinel. You need to ensure that incident investigation is efficient by automatically grouping related alerts into incidents. Which configuration should you use?

A.Create an automation rule to group alerts
B.Configure alert grouping in the analytics rule wizard
C.Use a playbook to merge incidents
D.Define a watchlist to consolidate alerts
AnswerB

The analytics rule wizard includes a dedicated 'Incident settings' tab where you can enable alert grouping, making it the correct and native mechanism for consolidating alerts into incidents. When enabled, you can configure grouping based on entity matching (e.g., same account, host, or IP address) and set a time window for how far back to look for matching alerts. You can also choose to limit grouping to specific entities or include custom details to refine the grouping logic. This configuration is applied automatically during incident creation, so no additional automation or manual steps are needed.

Why this answer

Microsoft Sentinel's analytics rule wizard includes a dedicated 'Alert grouping' configuration that allows you to specify how alerts from the same analytics rule are automatically combined into a single incident. This setting is essential for efficient incident investigation, as it reduces alert noise by grouping related alerts based on criteria such as matching entities, time windows, or custom alert details, ensuring that security analysts work with consolidated incidents rather than individual alerts.

Exam trap

The trap here is that candidates often confuse automation rules (which operate on existing incidents) with the alert grouping feature (which operates during incident creation), leading them to incorrectly select Option A.

How to eliminate wrong answers

Option A is wrong because automation rules in Microsoft Sentinel are used to trigger automated responses (e.g., changing incident status, assigning owners) after an incident is created, not to group alerts into incidents during the creation process. Option C is wrong because playbooks are automated workflows (often using Azure Logic Apps) that respond to incidents or alerts after they exist; they cannot merge incidents or group alerts at the point of incident creation. Option D is wrong because watchlists are collections of data (e.g., IP addresses, hostnames) used for correlation, enrichment, or filtering within analytics rules, not for consolidating alerts into incidents.

Practice this question →
59
Multi-Selecthard

Your organization uses Microsoft Defender XDR and Microsoft Sentinel. You need to ensure that when a user reports a phishing email in Microsoft 365 Defender, the incident in Microsoft Sentinel is automatically updated with the user's comments. Which THREE components are required?

Select 3 answers
A.A logic app in Azure that is triggered by the Microsoft 365 Defender alert.
B.The Microsoft 365 Defender data connector in Microsoft Sentinel.
C.The Microsoft Entra ID data connector in Microsoft Sentinel.
D.A playbook in Microsoft Sentinel that updates the incident with the user's comments.
E.An automation rule in Microsoft Sentinel that triggers the playbook when an incident is created from a Microsoft 365 Defender alert.
AnswersB, D, E

The Microsoft 365 Defender data connector in Microsoft Sentinel is essential because it ingests alerts and raw events from Defender XDR into the Log Analytics workspace. This connector creates the SecurityAlert and SecurityIncident tables that Sentinel uses to generate incidents, and without it, no Microsoft 365 Defender alert would ever reach Sentinel to trigger any automation. This is why it is the correct component to include, as it is the foundational source of the incident data.

Why this answer

The Microsoft 365 Defender data connector in Microsoft Sentinel is required because it ingests alerts and incidents from Microsoft 365 Defender into Sentinel. Without this connector, the phishing email report from Microsoft 365 Defender would not create an incident in Sentinel, making it impossible to automatically update that incident with user comments.

Exam trap

The trap here is that candidates often think a logic app triggered directly by the alert (Option A) is sufficient, but the required flow must use a Sentinel playbook triggered by an automation rule to ensure the incident update occurs within Sentinel's context.

Practice this question →
60
MCQmedium

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

A.Configure the Azure Active Directory data connector
B.Configure the Microsoft Defender for Cloud data connector
C.Create an Azure Event Hub and push Defender for Cloud alerts to Sentinel via a custom connector
D.Configure the Microsoft 365 Defender data connector
AnswerB

The Microsoft Defender for Cloud data connector is the native, purpose-built integration that ingests Defender for Cloud security alerts, recommendations, and incidents directly into Microsoft Sentinel. It requires no extra infrastructure or custom code, automatically streaming alerts from Azure, on-premises, and other cloud workloads protected by Defender for Cloud, and it supports bidirectional status synchronization. This is the correct connector because it directly satisfies the requirement to ingest Defender for Cloud incidents into Sentinel.

Why this answer

The Microsoft Defender for Cloud data connector is the correct choice because it is specifically designed to ingest security alerts and incidents from Defender for Cloud into Microsoft Sentinel. This connector enables automatic synchronization of Defender for Cloud's security findings, ensuring that incidents are created in Sentinel without manual intervention or custom infrastructure.

Exam trap

The trap here is that candidates often confuse the Microsoft Defender for Cloud data connector with the Microsoft 365 Defender data connector, mistakenly thinking that all 'Defender' services are covered by a single connector, when in fact each has its own dedicated connector for specific alert sources.

How to eliminate wrong answers

Option A is wrong because the Azure Active Directory data connector ingests sign-in logs and audit logs, not security incidents from Defender for Cloud. Option C is wrong because while an Event Hub can be used for custom data ingestion, it is unnecessary and overly complex; the native Defender for Cloud data connector provides a direct, supported integration without custom development. Option D 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 Defender for Cloud.

Practice this question →
61
MCQmedium

You are a security analyst at a company that uses Microsoft Defender XDR. You receive an alert about a potential ransomware activity on a workstation. The alert is generated by Microsoft Defender for Endpoint. You need to contain the threat by isolating the workstation from the network while allowing forensic analysis to proceed. You want to use Microsoft Defender XDR's built-in actions. What should you do?

A.Create a firewall rule in Microsoft Defender for Cloud Apps to block the device's IP.
B.Use the 'Isolate device' action from the Microsoft Defender XDR portal.
C.Unenroll the device from Microsoft Intune.
D.Disable the network adapter on the workstation remotely.
AnswerB

Use the 'Isolate device' action from the Microsoft Defender XDR portal, which invokes Defender for Endpoint's machine isolation and breaks the attack chain by severing all inbound and outbound network traffic, except traffic between the device and the MDE cloud service plus any forensic processes you explicitly allow. This preserves the agent's ability to receive future commands and send telemetry, enabling continued investigation while the threat actor loses connectivity. It is the direct, built-in containment action for an endpoint in an incident.

Why this answer

The 'Isolate device' action in Microsoft Defender XDR (specifically from the Microsoft Defender for Endpoint component) disconnects the device from all network traffic except for the Defender for Endpoint service and a few authorized services (such as Windows Update and the Microsoft Update Service). This allows forensic analysis tools (like Live Response) to continue communicating with the device while preventing the ransomware from spreading laterally or communicating with command-and-control servers. This is the built-in, recommended containment action for such scenarios.

Exam trap

The trap here is that candidates may confuse network isolation with other security controls (like blocking an IP in a CASB or unenrolling from MDM) and fail to recognize that Microsoft Defender XDR's 'Isolate device' is the only built-in action that both contains the threat and preserves forensic access.

How to eliminate wrong answers

Option A is wrong because Microsoft Defender for Cloud Apps (MCAS) is a cloud access security broker that controls access to cloud applications, not a tool for isolating a workstation from the network; blocking an IP in MCAS would not isolate the device itself. Option C is wrong because unenrolling the device from Microsoft Intune removes management and policy enforcement, but does not contain the threat—it actually removes the ability to perform any further actions on the device and does not stop network communication. Option D is wrong because disabling the network adapter remotely is not a built-in action in Microsoft Defender XDR; it would require separate remote management tools (e.g., PowerShell, RMM) and would also cut off the forensic analysis channel, preventing Live Response or any other remote investigation.

Practice this question →
62
Multi-Selecteasy

Which TWO are valid methods to connect a non-Azure Windows server to Microsoft Sentinel? (Choose two.)

Select 2 answers
A.Install the Azure Monitor Agent (AMA)
B.Install the Azure Security Center agent
C.Configure Windows Event Forwarding (WEF) and point it to Sentinel
D.Install the Log Analytics agent (MMA)
E.Configure the server to forward syslog to Sentinel
AnswersA, D

The Azure Monitor Agent (AMA) is the current, unified agent for collecting telemetry from both Azure and non-Azure resources, including Windows servers outside Azure. After you install AMA and associate it with your Log Analytics workspace, you define collection rules via Data Collection Rules (DCRs) to capture security events such as 4624/4625, performance counters, and custom logs for Microsoft Sentinel. For a non-Azure Windows server, you install AMA with an onboarding script or via a management tool, and Sentinel then ingests the data from the Log Analytics workspace as its underlying telemetry source.

Why this answer

The Azure Monitor Agent (AMA) is the current, recommended agent for collecting data from non-Azure Windows servers and sending it to Microsoft Sentinel. It replaces the older Log Analytics agent and supports data collection via Data Collection Rules (DCRs), which allow granular control over which events and performance counters are ingested. Option D is correct because the Log Analytics agent (MMA) was the original method to connect Windows servers to Sentinel, and while it is being phased out in favor of AMA, it remains a valid supported method for existing deployments.

Exam trap

The trap here is that candidates may confuse Windows Event Forwarding (WEF) as a direct data connector to Sentinel, when in fact WEF only centralizes events on a collector server, which still requires an agent to forward to Sentinel, making it an indirect method not listed as a direct connection option.

Practice this question →
63
MCQeasy

Your organization has deployed Microsoft Sentinel. You need to ensure that user and entity behavior analytics (UEBA) is enabled for all data sources. What is the minimum role required to enable UEBA in Microsoft Sentinel?

A.Microsoft Sentinel Contributor
B.Global Administrator
C.Security Reader
D.Log Analytics Contributor
AnswerA

The Microsoft Sentinel Contributor role is the minimal built-in Azure RBAC role that provides full access to Sentinel resources, including the ability to enable UEBA. It grants write permissions to Sentinel settings, such as turning on User and Entity Behavior Analytics from the Settings blade. This role is scoped to the Sentinel workspace or resource group, ensuring least-privilege access for security operators. Because it specifically targets Sentinel's control plane, no additional tenant-level permissions are needed.

Why this answer

To enable UEBA in Microsoft Sentinel, you need the Microsoft Sentinel Contributor role because it includes the necessary permissions to manage Sentinel settings, including turning on UEBA for all data sources. This role allows you to access the UEBA configuration blade and modify the analytics settings, which is the minimum privilege required for this task.

Exam trap

The trap here is that candidates often assume a higher-privilege role like Global Administrator is needed for any security configuration, but Microsoft Sentinel has its own granular RBAC roles, and the exam tests knowledge of these specific permissions.

How to eliminate wrong answers

Option B (Global Administrator) is wrong because it is overprivileged for this task; while it can enable UEBA, it is not the minimum role required, and using it violates the principle of least privilege. Option C (Security Reader) is wrong because it only provides read-only access to security configurations and cannot modify settings like enabling UEBA. Option D (Log Analytics Contributor) is wrong because it grants permissions to manage Log Analytics workspaces but lacks the specific Sentinel-level permissions needed to configure UEBA, which is a Sentinel-specific feature.

Practice this question →
64
MCQmedium

Refer to the exhibit. You run the PowerShell command against Microsoft Defender for Endpoint. What is the result?

A.The investigation package is collected.
B.An antivirus scan runs on the device.
C.The device is isolated from the network.
D.A Live Response session is started.
AnswerB

The ActionType 'RunAntiMalwareScan' sends a command through the Defender for Endpoint sensor to the antimalware engine, instructing it to execute a scan on the endpoint. This is a non-interactive, one-time response action that can be a full or quick scan depending on device policy, with results reported back to the console. It does not require isolation or a Live Response session.

Why this answer

The `Start-MpScan` cmdlet initiates a Microsoft Defender Antivirus scan on the device. The `-ScanType` parameter with value `QuickScan` specifies a quick scan of common malware locations, not a full scan. This is a direct antivirus action, not an investigation package collection, isolation, or Live Response session.

Exam trap

The trap here is that candidates confuse the `Start-MpScan` cmdlet with other Defender for Endpoint actions like investigation package collection or device isolation, because all are available under the 'Actions' menu in the portal, but each uses a distinct PowerShell cmdlet or API call.

How to eliminate wrong answers

Option A is wrong because collecting an investigation package requires the `Start-MpInvestigation` cmdlet or the `CollectInvestigationPackage` action via Microsoft Defender for Endpoint API, not `Start-MpScan`. Option C is wrong because device isolation is performed using the `Isolate-Device` cmdlet or the corresponding API action, not a scan command. Option D is wrong because starting a Live Response session requires the `Start-MpLiveResponse` cmdlet or initiating a session via the Defender portal, not a scan cmdlet.

Practice this question →
65
Multi-Selecteasy

Which TWO permissions are required for a user to manage Microsoft Sentinel playbooks?

Select 2 answers
A.Microsoft Sentinel Reader
B.Logic App Contributor
C.Microsoft Sentinel Contributor
D.Automation Operator
E.Global Administrator
AnswersB, C

Logic App Contributor is one of the two required permissions because Sentinel playbooks are implemented as Azure Logic Apps. This role provides full management authority over Logic Apps, enabling users to create, edit, and execute the workflows that playbooks depend on. Without it, even with Sentinel-level permissions, the underlying playbook logic cannot be altered or run, making it essential for managing playbooks.

Why this answer

Microsoft Sentinel playbooks are built on Azure Logic Apps, so managing them requires the Logic App Contributor role to create, edit, and delete the underlying logic app resources. Additionally, Microsoft Sentinel Contributor is needed to attach playbooks to analytics rules or automation rules within Sentinel, as this involves modifying Sentinel-specific configurations. Without both roles, a user cannot fully manage playbooks in the Sentinel context.

Exam trap

The trap here is that candidates often assume only a Sentinel-specific role (like Microsoft Sentinel Contributor) is sufficient, forgetting that playbooks are built on Azure Logic Apps and thus require the Logic App Contributor role for direct management of the playbook resource itself.

Practice this question →
66
MCQmedium

A security analyst reports that a scheduled analytics rule in Microsoft Sentinel has stopped generating incidents after a recent update. The rule still runs but produces no alerts. What should you check first?

A.Verify that the rule is enabled and not paused.
B.Check the entity mapping configuration for missing fields.
C.Review the rule's query logic for changes or syntax errors.
D.Ensure that the automation rule triggering the incident is still active.
AnswerC

Scheduled analytics rules only raise an alert for each row returned by their KQL query. If the query logic was recently changed—adding an overly restrictive where clause, altering the time range, referencing a renamed table or column—or contains a syntax error, the query can return zero results or fail before producing output. That directly explains why the rule runs on schedule yet no alerts are generated, making query review the first diagnostic step.

Why this answer

The most likely cause of a scheduled analytics rule running but producing no alerts is a change or error in the KQL query logic. Since the rule still executes, the issue is not with the rule being disabled or paused, but rather with the query failing to return results due to syntax errors, schema changes, or logic flaws introduced during the update.

Exam trap

The trap here is that candidates assume a rule that 'still runs' is functioning correctly, but Microsoft tests the distinction between execution and result generation—a rule can execute its query yet produce zero alerts due to query logic issues, not configuration or automation problems.

How to eliminate wrong answers

Option A is wrong because the rule is explicitly stated to still run, so it is enabled and not paused; checking this would not resolve the issue. Option B is wrong because entity mapping configuration affects how alerts are structured, not whether alerts are generated; missing fields would cause mapping errors, not a lack of alerts. Option D is wrong because automation rules trigger actions after an incident is created; if no alerts are generated, no incidents exist to trigger automation rules, so checking automation rules is premature.

Practice this question →
67
MCQmedium

Your organization uses Microsoft Sentinel and Microsoft Defender XDR. You are responsible for managing the security operations environment. Recently, the SOC team reported that incidents from Microsoft Defender for Endpoint are not appearing in Microsoft Sentinel. You have already configured the data connector for Microsoft Defender XDR and verified that logs are flowing into the 'SecurityAlert' table. However, incidents are not being created in Sentinel. What should you do?

A.Enable 'Create incidents from Microsoft 365 Defender' in the Microsoft Defender XDR data connector.
B.Create an analytics rule that queries the SecurityAlert table and generates incidents.
C.Verify the Azure Sentinel solution is installed and enable the streaming of incidents.
D.Configure the Microsoft Defender for Endpoint data connector.
AnswerA

Enabling 'Create incidents from Microsoft 365 Defender' on the Microsoft Defender XDR data connector is the designated method for ingesting already-correlated incidents into Microsoft Sentinel. This toggle allows the connector to pull Defender XDR incidents directly from the Microsoft Graph Security API, ensuring Sentinel receives the full incident with its related alerts, entities, and attack story. Without this setting, the connector would only ingest raw alerts, leaving you to rebuild the correlation that Defender XDR already performed, which defeats the purpose of unified incident management.

Why this answer

Enabling 'Create incidents from Microsoft 365 Defender' in the Microsoft Defender XDR data connector (A) is the correct action. This setting allows Microsoft Sentinel to automatically create incidents from alerts generated by Microsoft Defender XDR, including those from Defender for Endpoint. Even though alerts are flowing into the SecurityAlert table, incident creation requires this specific toggle to be enabled.

Exam trap

SC-200 often tests the distinction between data ingestion and incident creation, causing candidates to focus on analytics rules or other connectors when the missing step is enabling the incident creation toggle in the Defender XDR connector.

How to eliminate wrong answers

Option B is wrong because creating an analytics rule that queries SecurityAlert would generate incidents, but it is not the native integration method and may duplicate or miss incidents; the built-in connector setting is the intended solution. Option C is wrong because the Azure Sentinel solution installation and streaming of incidents is not the correct configuration for this scenario; the data connector already exists. Option D is wrong because configuring the Microsoft Defender for Endpoint data connector is unnecessary since the Defender XDR connector is already configured and logs are flowing.

Practice this question →
68
MCQeasy

You are a security operations analyst for a company that uses Microsoft Sentinel. You need to ensure that all incidents generated by a specific analytics rule are automatically assigned to a specific analyst group. What should you do?

A.Create a playbook that queries the incidents table for incidents from the analytics rule and uses the Microsoft Sentinel API to assign them to the analyst group on a schedule.
B.Create an automation rule that triggers when an incident is created, with a condition on the analytics rule name, and an action to assign the incident to the analyst group.
C.Configure a workbook that displays incidents filtered by the analytics rule and instruct the analyst group to monitor it and self-assign incidents.
D.Modify the analytics rule to include a custom entity mapping that specifies the analyst group as the owner.
AnswerB

Automation rules in Microsoft Sentinel can trigger on incident creation and evaluate conditions such as the analytics rule name. The 'Assign owner' action can set the incident owner to a user or group. This directly meets the requirement with minimal effort and is the native method for automatic assignment.

Why this answer

Microsoft Sentinel automation rules are purpose-built for automatic incident handling. By triggering on incident creation and conditioning on the analytics rule name, the rule can apply the 'Assign owner' action to route all relevant incidents to the specified analyst group. This is the native, low-effort method and ensures immediate assignment without custom code or manual intervention.

Exam trap

The trap here is confusing entity mapping with ownership assignment; entity mapping is for investigation entities, not for setting incident owners.

Practice this question →
69
MCQmedium

Your organization uses Microsoft Sentinel. You need to configure a playbook that automatically responds to incidents by creating a support ticket in ServiceNow. Which connector should you use?

A.HTTP connector
B.ServiceNow connector
C.Azure Monitor connector
D.Office 365 Outlook connector
AnswerB

The ServiceNow connector in Microsoft Sentinel provides a native, out-of-the-box integration that allows security operations teams to automatically create, update, and close incidents as ServiceNow tickets. It leverages the ServiceNow API with prebuilt authentication handling and a data collection rule, eliminating the need for custom code or manual API calls. This directly meets the requirement to configure the environment for ticket creation, making it the correct choice.

Why this answer

The ServiceNow connector is the correct choice because it provides a direct, pre-built integration between Microsoft Sentinel and ServiceNow, enabling automated creation of incidents or tickets in ServiceNow when a Sentinel incident is triggered. This connector uses the ServiceNow REST API to map Sentinel fields to ServiceNow ticket fields, eliminating the need for custom HTTP calls or additional middleware.

Exam trap

The trap here is that candidates may choose the HTTP connector thinking it is more flexible, but the ServiceNow connector is the purpose-built, supported solution that handles authentication and field mapping natively, making it the correct choice for this specific integration.

How to eliminate wrong answers

Option A is wrong because the HTTP connector is a generic connector that requires manual configuration of endpoints, authentication, and payload formatting, which is more complex and error-prone than using a dedicated ServiceNow connector. Option C is wrong because the Azure Monitor connector is designed to send data from Azure Monitor to other systems, not to create tickets in ServiceNow from Sentinel incidents. Option D is wrong because the Office 365 Outlook connector is used for email-based actions (e.g., sending notifications) and does not support direct integration with ServiceNow's ticketing system.

Practice this question →
70
MCQhard

Your organization uses Microsoft Sentinel in a multi-workspace environment with a central SOC. You need to create a single incident view across all workspaces while minimizing latency. What should you deploy?

A.Use cross-workspace queries in a workbook
B.Enable incident across workspaces in Microsoft Sentinel
C.Merge all workspaces into one Log Analytics workspace
D.Set up Azure Lighthouse and connect workspaces
AnswerB

The 'Enable incident across workspaces' feature in Microsoft Sentinel is a built-in capability that creates a central incident view by aggregating incidents from up to 100 Sentinel workspaces, typically spread across regions or tenants, into a single incident list. It leverages Azure Lighthouse for onboarding, but the key is that Sentinel's incident pipeline synchronizes incidents (by incident ARM ID) into a designated central workspace, preserving the original workspace context for each incident. This gives security operations teams a unified queue for detection, investigation, and response without migrating or re-ingesting any data.

Why this answer

Microsoft Sentinel's 'Incident across workspaces' feature (enabled via the 'SecurityIncident' table union) provides a single incident view across multiple workspaces with minimal latency by leveraging built-in cross-workspace incident synchronization. This avoids the overhead of manual queries or external orchestration, ensuring near-real-time incident correlation for a central SOC.

Exam trap

The trap here is that candidates often confuse Azure Lighthouse (which provides cross-workspace visibility through delegated access) with the native incident synchronization feature, not realizing that Lighthouse alone does not create a unified incident view and requires additional manual configuration to achieve the same low-latency result.

How to eliminate wrong answers

Option A is wrong because cross-workspace queries in a workbook are read-only and do not create a unified incident management view; they are for ad-hoc analysis, not operational incident handling, and introduce latency from repeated query execution. Option C is wrong because merging workspaces violates multi-workspace architecture requirements, causes data ingestion and retention cost bloat, and is not a scalable solution for a central SOC. Option D is wrong because Azure Lighthouse enables delegated resource management but does not natively provide a single incident view across workspaces; it requires additional configuration and does not minimize latency as effectively as the built-in incident synchronization.

Practice this question →
71
MCQeasy

You need to ensure that critical incidents in Microsoft Sentinel are automatically assigned to a senior security analyst. What should you configure?

A.Create an analytics rule with a custom schedule.
B.Configure a workbook to filter incidents by owner.
C.Add the analyst to a watchlist used in analytics rules.
D.Create an automation rule that assigns the incident to the analyst.
AnswerD

Automation rules are the only one of these options that directly acts on incident properties after an incident is created or updated. You can configure a rule with conditions like 'incident title contains critical' and an action of 'Assign to analyst,' which automatically sets the owner field to the chosen analyst. This is the intended, supported mechanism in Microsoft Sentinel for ensuring critical incidents are owned by a specific person.

Why this answer

Automation rules in Microsoft Sentinel allow you to automatically assign incidents to specific users or groups based on conditions like severity or title. By creating an automation rule that triggers on incident creation and sets the owner to the senior security analyst, you ensure critical incidents are assigned without manual intervention.

Exam trap

The trap here is that candidates confuse automation rules (which handle incident lifecycle actions like assignment) with analytics rules (which generate alerts), leading them to pick option A incorrectly.

How to eliminate wrong answers

Option A is wrong because analytics rules with custom schedules are used to generate alerts from log data, not to assign ownership of incidents. Option B is wrong because workbooks are visualization tools that display data, not mechanisms for assigning incident ownership. Option C is wrong because watchlists are used to correlate data or filter alerts in analytics rules, not to assign incidents to specific users.

Practice this question →
72
MCQeasy

Your organization uses Microsoft Purview Data Loss Prevention (DLP). You need to receive an alert when a user attempts to share a credit card number via email. What should you configure?

A.Create a sensitivity label that blocks sharing.
B.Create a DLP policy in Microsoft Purview with the credit card number sensitive info type.
C.Create a retention label that identifies credit card data.
D.Create a file policy in Microsoft Defender for Cloud Apps.
AnswerB

A DLP policy in Microsoft Purview is the correct control because it can be configured with the Credit Card Number sensitive info type, which uses pattern matching and checksum validation to detect this data in Exchange Online mail. The policy can specify an action to send an alert to the security team whenever the data is detected, meeting the alerting requirement precisely.

Why this answer

Microsoft Purview DLP policies can be configured to detect sensitive information types, such as credit card numbers, and trigger alerts when users attempt to share that data via email. By creating a DLP policy with the credit card number sensitive info type and setting an action to send an alert, you meet the requirement to receive an alert on such sharing attempts.

Exam trap

The trap here is that candidates often confuse sensitivity labels or retention labels with DLP policies, not realizing that only DLP policies can directly detect and alert on sensitive data in transit like email sharing.

How to eliminate wrong answers

Option A is wrong because sensitivity labels are used for classification and protection (e.g., encryption or visual markings) but do not natively generate alerts on sharing attempts; they require integration with DLP or other mechanisms for alerting. Option C is wrong because retention labels are designed to manage data lifecycle and retention policies, not to detect or alert on sharing of sensitive data. Option D is wrong because a file policy in Microsoft Defender for Cloud Apps focuses on monitoring and controlling cloud app usage, not directly on email sharing within Exchange Online; DLP policies in Purview are the correct tool for email-based sensitive data detection.

Practice this question →
73
MCQhard

Your company uses Microsoft Defender XDR. The security team needs to restrict access to the Microsoft Defender portal so that only analysts in the 'Security Operations' group can view incidents. What is the most efficient way to achieve this?

A.Assign the Security Operations group the Defender for Endpoint administrator role.
B.Configure Conditional Access policy to allow only Security Operations group to sign in to the Defender portal.
C.Assign the Security Operations group the Security Reader role in Microsoft Entra ID.
D.Create a custom role in the Microsoft Defender portal with permissions to view incidents and assign it to the Security Operations group.
AnswerD

Microsoft Defender XDR supports custom roles created in the portal with granular permissions, such as the specific 'View incidents' permission under the Security operations category. Assigning that custom role to the Security Operations group grants them exactly the read-only incident access they need without broadening to endpoint management or unrelated security workloads. This is the precise, least-privilege approach and aligns with Defender XDR's unified RBAC model for isolated access to alert and incident data.

Why this answer

Microsoft Defender XDR uses role-based access control (RBAC) within the portal itself. Creating a custom role with permissions to view incidents and assigning it to the Security Operations group directly controls access to incident data without affecting broader Azure AD roles or requiring Conditional Access policies. This is the most efficient method as it scopes permissions precisely to the Defender portal's incident management functionality.

Exam trap

The trap here is that candidates often confuse Azure AD roles (like Security Reader) with Defender portal RBAC roles, or assume Conditional Access can control data-level permissions, when in fact only custom Defender roles can restrict incident viewing to a specific group without granting broader privileges.

How to eliminate wrong answers

Option A is wrong because the Defender for Endpoint administrator role grants full administrative access to the Defender for Endpoint configuration and settings, not just incident viewing, which is overly permissive and violates the principle of least privilege. Option B is wrong because Conditional Access policies control authentication and sign-in access to the portal, not authorization to view specific data like incidents; they can block sign-in entirely but cannot restrict what a signed-in user sees within the portal. Option C is wrong because the Security Reader role in Microsoft Entra ID provides read-only access to security-related information across Azure services, but it does not grant granular permissions to view incidents specifically within the Microsoft Defender portal; it is a broad Azure AD role, not a Defender-specific RBAC role.

Practice this question →
74
MCQeasy

You are configuring Microsoft Sentinel SOAR capabilities. You need to create an automated response that, when a critical incident is created, triggers a playbook that sends a message to a Teams channel. Which connector should you use in the playbook?

A.Microsoft Exchange connector
B.Azure DevOps connector
C.Microsoft Teams connector
D.Microsoft Entra ID connector
AnswerC

The Microsoft Teams connector in Sentinel automation rules can post messages to a Teams channel or send adaptive cards, which is the standard way to notify analysts of incidents. It supports actions such as 'Post message (V3)' that can include incident details, and it also allows for approval flows via Teams. This aligns with the requirement to configure SOAR capabilities for messaging a team.

Why this answer

The Microsoft Teams connector is the correct choice because it enables the playbook to post messages directly to a Teams channel via an HTTP trigger and the Teams webhook action. This connector is specifically designed for sending notifications and messages to Teams, which aligns with the requirement to alert a channel when a critical incident is created.

Exam trap

The trap here is that candidates may confuse the Microsoft Teams connector with the Microsoft Exchange connector, assuming both can send notifications, but Exchange is strictly for email, not Teams messaging.

How to eliminate wrong answers

Option A is wrong because the Microsoft Exchange connector is used for email-related operations (e.g., sending emails, managing mailboxes), not for posting messages to Teams channels. Option B is wrong because the Azure DevOps connector is designed for managing work items, pipelines, and repositories in Azure DevOps, not for sending messages to Teams. Option D is wrong because the Microsoft Entra ID connector (formerly Azure AD) is used for identity and access management tasks (e.g., managing users, groups, and roles), not for sending messages to Teams channels.

Practice this question →
75
MCQeasy

Your organization uses Microsoft Sentinel and Microsoft Defender XDR. The security team wants to automatically create an incident in Microsoft Sentinel when a Microsoft Defender for Endpoint alert is triggered. What should you configure?

A.Enable the Microsoft Defender XDR connector in Microsoft Sentinel and select the incident creation settings.
B.Set up a Logic App custom connector to poll Defender alerts.
C.Configure the Security Events connector to forward Defender alerts.
D.Create analytics rules in Microsoft Sentinel for each Defender alert type.
AnswerA

Enabling the Microsoft Defender XDR connector streams Defender for Endpoint alerts into Microsoft Sentinel, where the "Create incidents" toggle governs automatic incident generation. This directly satisfies the requirement to auto-create Sentinel incidents from endpoint alerts, since the connector's incident creation setting is the mechanism controlling that behaviour.

Why this answer

The Microsoft Defender XDR connector in Microsoft Sentinel is specifically designed to ingest alerts and incidents from Microsoft Defender for Endpoint and other Defender products. By enabling this connector and configuring its incident creation settings, Sentinel automatically creates incidents when Defender for Endpoint alerts are triggered, without requiring custom logic or manual polling.

Exam trap

The trap here is that candidates often confuse the purpose of analytics rules (which generate alerts from raw data) with the connector's role (which ingests pre-existing alerts from external sources), leading them to incorrectly select Option D.

How to eliminate wrong answers

Option B is wrong because a Logic App custom connector would require building a custom polling mechanism, which is unnecessary and inefficient when the native Microsoft Defender XDR connector already provides automated, real-time incident ingestion. Option C is wrong because the Security Events connector is used to collect Windows security event logs (e.g., Event ID 4625) from on-premises or cloud-based systems, not Defender for Endpoint alerts. Option D is wrong because analytics rules in Sentinel are used to generate alerts from raw data sources (like Syslog or Windows Events), not to import existing alerts from Defender for Endpoint; the connector handles that ingestion automatically.

Practice this question →
Page 1 of 7 · 464 questions totalNext →

Ready to test yourself?

Try a timed practice session using only Manage a security operations environment questions.

Start 20-question session