Courseiva

CCNA Manage a security operations environment Questions

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

Practice these questionsDomain overviewAll questions
226
Multi-Selecthard

Your organization is implementing Microsoft Sentinel and needs to ensure that incident response activities are compliant with regulatory requirements. You need to track and document all changes made to analytics rules and playbooks. Which TWO features should you enable?

Select 2 answers
A.Sentinel workbooks
B.Automation rules
C.Activity logs (Azure Monitor)
D.Azure Resource Change History (Change tracking)
E.Microsoft Purview Compliance Manager
AnswersC, D

The Azure Activity log is the subscription-level platform log that records administrative operations on Azure resources, including every write (PUT, POST, PATCH) against Sentinel analytics rules, playbooks, and data connectors. Each entry captures the resource ID, the operation name, the initiating principal, and a timestamp, giving you a comprehensive compliance audit trail. To meet compliance requirements, you would enable diagnostic settings to export this log to a Log Analytics workspace for long-term retention and alerting.

Why this answer

Activity logs (Azure Monitor) record all management-plane operations, including changes to analytics rules and playbooks, while Azure Resource Change History (Change tracking) captures resource-level modifications. Together they provide comprehensive audit trails for regulatory compliance. Workbooks (A) are for visualization, Automation rules (B) trigger responses but don't log changes themselves, and Microsoft Purview (E) is for broader data governance, not operational change tracking.

Exam trap

Candidates often confuse automation rules or workbooks as change-tracking tools. Remember that only Azure-native logging services (Activity Logs and Change History) provide the audit trail required for regulatory compliance.

Practice this question →
227
MCQhard

You are configuring Microsoft Sentinel automation rules to handle incidents from multiple analytics rules. You need to ensure that incidents from a specific rule are automatically assigned to the 'SOC Tier 2' group and have a severity of 'High' regardless of the original severity. What should you do?

A.Use a logic app trigger to change severity
B.Create a playbook to modify the incident properties
C.Create a separate analytics rule to override the incident
D.Configure an automation rule with 'Add tag' and 'Set severity' actions, plus 'Assign owner'
AnswerD

Automation rules in Microsoft Sentinel natively support incident property modification through actions like 'Add tag', 'Set severity', and 'Assign owner'. You can configure these rules with conditions scoped to specific analytics rules, yet they run automatically when an incident is generated or updated, so the severity and owner are set at creation time without manual intervention or external tooling. This is the recommended, built-in mechanism for incident property management, and it avoids the complexity of playbooks while also preventing duplicate incidents.

Why this answer

Automation rules in Microsoft Sentinel can directly modify incident properties such as severity and owner without requiring external logic apps or playbooks. Option D correctly uses the 'Set severity' action to override the original severity to 'High' and the 'Assign owner' action to assign the incident to the 'SOC Tier 2' group, fulfilling both requirements in a single, efficient rule.

Exam trap

The trap here is that candidates often confuse automation rules with playbooks, assuming that any property modification requires a playbook, when in fact automation rules natively support 'Set severity' and 'Assign owner' actions for simple, rule-based changes.

How to eliminate wrong answers

Option A is wrong because a logic app trigger is used to initiate automated workflows, but it cannot directly modify incident properties within Sentinel; it would require a playbook to change severity, making this an indirect and unnecessary step. Option B is wrong because a playbook is designed for complex, multi-step automation and is overkill for simple property changes; automation rules are the native, simpler solution for such tasks. Option C is wrong because creating a separate analytics rule to override an incident is not possible; analytics rules generate incidents based on detection logic, not modify existing incidents' properties.

Practice this question →
228
MCQeasy

You are configuring Microsoft Sentinel to send email notifications to the security team when high-severity incidents are created. Which feature should you use?

A.Automation rule
B.Watchlist
C.Analytics rule
D.Workbook
AnswerA

Automation rules in Microsoft Sentinel are designed to centralize and automate incident handling, and one of their primary actions is to run playbooks (Azure Logic Apps). A playbook can include a step that sends an email through a mail connector, such as Office 365 Outlook or SendGrid, allowing a notification to be dispatched immediately after certain conditions are met. Because automation rules are the only construct among these choices that can directly trigger a playbook that performs an external action like email, this is the correct mechanism for configuring email notifications.

Why this answer

Automation rules in Microsoft Sentinel allow you to define automated responses to incidents, including sending email notifications to specified recipients when incidents meet certain criteria, such as high severity. This feature directly supports the requirement to notify the security team when high-severity incidents are created, without requiring additional logic or manual steps.

Exam trap

The trap here is that candidates often confuse analytics rules with automation rules, assuming that analytics rules can directly send notifications, when in fact they only create alerts/incidents and require automation rules or playbooks for notification actions.

How to eliminate wrong answers

Option B is wrong because watchlists are collections of data (e.g., IP addresses, usernames) used for correlation and enrichment in analytics rules, not for triggering actions like email notifications. Option C is wrong because analytics rules generate alerts and incidents based on query results, but they do not natively send email notifications; they rely on automation rules or playbooks for that purpose. Option D is wrong because workbooks are visualization tools that display data from queries and logs, not mechanisms for sending notifications or triggering automated responses.

Practice this question →
229
MCQeasy

You are a Microsoft Security Operations Analyst. Your organization recently deployed Microsoft Defender for Cloud Apps. You need to ensure that alerts generated by Defender for Cloud Apps are automatically forwarded to Microsoft Sentinel. What should you configure?

A.In Microsoft Sentinel, create an analytics rule with a query that pulls data from Defender for Cloud Apps API.
B.In Microsoft Defender for Cloud Apps, configure SIEM integration.
C.In Microsoft Sentinel, configure a playbook to retrieve alerts from Defender for Cloud Apps.
D.In Microsoft Sentinel, add the Microsoft Defender for Cloud Apps data connector.
AnswerD

The Microsoft Defender for Cloud Apps data connector is the Microsoft-supported method for ingesting cloud app alerts, Cloud Discovery logs, and other security events directly into Microsoft Sentinel's Log Analytics workspace. This connector automatically streams data using the underlying Microsoft 365 Defender or standalone Defender for Cloud Apps APIs, making the information immediately available for analytics rules and workbooks. It provides the native schema and ensures proper correlation with other security data sources in Sentinel.

Why this answer

The Microsoft Defender for Cloud Apps data connector in Microsoft Sentinel is the native integration that automatically forwards alerts and cloud discovery logs from Defender for Cloud Apps into Sentinel. This connector uses the Microsoft Graph Security API to ingest alerts without requiring additional configuration in Defender for Cloud Apps, enabling seamless correlation and investigation within Sentinel.

Exam trap

The trap here is that candidates confuse the generic SIEM integration in Defender for Cloud Apps (which uses syslog or REST for third-party SIEMs) with the purpose-built Microsoft Sentinel data connector, leading them to select Option B.

How to eliminate wrong answers

Option A is wrong because creating an analytics rule with a query that pulls data from the Defender for Cloud Apps API is not a supported method for automatic ingestion; analytics rules analyze data already in Sentinel, not pull external data. Option B is wrong because configuring SIEM integration in Defender for Cloud Apps is used to forward alerts to generic SIEMs via syslog or REST API, not to Microsoft Sentinel, which requires the dedicated data connector. Option C is wrong because a playbook is an automated response workflow triggered after data is already in Sentinel, not a mechanism to retrieve alerts from Defender for Cloud Apps.

Practice this question →
230
MCQhard

Your organization uses Microsoft Defender for Cloud Apps and Microsoft Sentinel. You need to ensure that anomalous behavior alerts from Defender for Cloud Apps are automatically converted to incidents in Sentinel. What should you configure?

A.Enable the Microsoft Defender for Identity data connector in Microsoft Sentinel.
B.Enable the Microsoft 365 data connector in Microsoft Sentinel.
C.Create a playbook that triggers on Defender for Cloud Apps alerts and creates incidents in Sentinel.
D.Enable the Microsoft Defender for Cloud Apps data connector in Microsoft Sentinel.
AnswerD

The Microsoft Defender for Cloud Apps data connector is the native Microsoft Sentinel integration designed to ingest alerts from Defender for Cloud Apps, including impossible travel, activity from anonymous IP addresses, and suspicious cloud application usage. It uses the MDCA API to automatically pull these alerts and create corresponding incidents in Sentinel without requiring custom Logic Apps or playbook orchestration. Enabling this connector is the correct configuration to satisfy the requirement of having Defender for Cloud Apps alerts appear as Sentinel incidents.

Why this answer

The Microsoft Defender for Cloud Apps data connector in Microsoft Sentinel is specifically designed to ingest alerts and anomalies from Defender for Cloud Apps and automatically create SecurityIncident records in Sentinel. Enabling this connector ensures that anomalous behavior alerts are converted to incidents without requiring custom playbooks or additional logic.

Exam trap

The trap here is that candidates often confuse the purpose of data connectors—assuming any Microsoft security connector (like Defender for Identity or Microsoft 365) will ingest all security alerts, when in fact each connector is scoped to its specific product's data source.

How to eliminate wrong answers

Option A is wrong because the Microsoft Defender for Identity data connector ingests alerts from on-premises Active Directory signals, not from Defender for Cloud Apps. Option B is wrong because the Microsoft 365 data connector ingests logs from Office 365 services (e.g., Exchange, SharePoint) but does not process Defender for Cloud Apps alerts. Option C is wrong because while a playbook could manually create incidents, the native data connector provides automatic and seamless incident creation without the overhead of custom automation.

Practice this question →
231
MCQmedium

Your organization uses Microsoft Sentinel in a hybrid environment with on-premises servers and Azure VMs. You need to ensure that all Windows servers forward their security events to Sentinel. The security team wants to use Windows Security Events via AMA connector. Windows servers are not domain-joined and are managed by a third-party RMM tool. What is the most efficient way to deploy the AMA agent?

A.Use Group Policy Objects (GPO) to push the agent installation.
B.Onboard the servers to Azure Arc and deploy the AMA agent via policy or script.
C.Use Microsoft Intune to deploy the AMA agent to all servers.
D.Manually install the agent on each server using the setup wizard.
AnswerB

Onboarding the servers to Azure Arc registers each physical or virtual machine as a first-class Azure resource, giving it an identity and the ability to be managed via Azure Policy. Once the AzureConnectedMachine agent is installed, you can use the built-in Azure Policy definition 'Configure Windows machines to run Azure Monitor Agent' to automatically deploy the AMA at scale, or invoke a script that uses the Azure portal-created install command. Because Arc works regardless of domain membership, this is the correct and recommended path for non-domain-joined servers in a hybrid scenario.

Why this answer

Azure Arc provides a control plane for non-Azure and on-premises servers, enabling them to be managed like Azure resources. Once onboarded to Azure Arc, you can deploy the Azure Monitor Agent (AMA) via Azure Policy or custom scripts, which is the most efficient method for non-domain-joined servers managed by a third-party RMM tool, as it avoids manual intervention and leverages Azure's centralized management.

Exam trap

The trap here is that candidates assume GPO or Intune are universal deployment tools, but the question's key constraint—'not domain-joined'—disqualifies GPO, and Intune requires Azure AD join or enrollment, which is not stated; Azure Arc is the correct answer because it specifically enables management of non-Azure, non-domain-joined servers via Azure policies.

How to eliminate wrong answers

Option A is wrong because Group Policy Objects (GPO) require Active Directory domain-joined computers; the servers are explicitly not domain-joined, so GPO cannot be applied. Option C is wrong because Microsoft Intune is designed for managing mobile devices and cloud-managed endpoints, not on-premises servers that are not enrolled in Intune or Azure AD joined; it cannot deploy agents to servers managed by a third-party RMM tool. Option D is wrong because manually installing the agent on each server is inefficient, error-prone, and does not scale, contradicting the requirement for the 'most efficient' deployment method.

Practice this question →
232
Multi-Selectmedium

Which THREE components are required to collect syslog messages from a network appliance into Microsoft Sentinel using the Azure Monitor Agent?

Select 3 answers
A.A syslog daemon (e.g., rsyslog) on the log collector server to receive messages.
B.The Azure Monitor Agent installed on a log collector server.
C.The Log Analytics agent (MMA) installed on the appliance.
D.The Syslog data connector in Microsoft Sentinel.
E.A Data Collection Rule (DCR) specifying the syslog facilities and severities.
AnswersA, B, E

The syslog daemon (typically rsyslog) is the foundational listener that binds to UDP/TCP port 514 on the log collector server and receives raw syslog messages forwarded by network appliances. Without this daemon, incoming syslog packets would have no process to capture them, so the Azure Monitor Agent would have nothing to read and no data would reach Sentinel. The daemon must be configured to accept remote input and write messages to a local log file that the agent can monitor.

Why this answer

Syslog messages are sent over UDP (or TCP) by network appliances, and a syslog daemon like rsyslog must be running on the log collector server to listen on port 514 (or a custom port) and receive those messages. Without this daemon, the Azure Monitor Agent cannot ingest the raw syslog data, as the agent relies on the local syslog daemon to capture and forward the logs to its event pipeline.

Exam trap

The trap here is that candidates often confuse the Syslog data connector (a configuration blade in Sentinel) as a required component, when in fact it is just a UI helper; the actual collection relies on the syslog daemon, AMA, and a DCR, which are the three components explicitly tested.

Practice this question →
233
MCQhard

Refer to the exhibit. You are reviewing an analytics rule in Microsoft Sentinel. The rule is enabled but has not generated any alerts in the past 24 hours. What is the most likely cause?

A.The triggerThreshold is set to 0, which means no alerts will be generated
B.Suppression is enabled with a duration of 6 hours, which may be suppressing new alerts after the first one
C.The queryFrequency is 1 hour and the queryPeriod is 7 days, which is a mismatch
D.The query uses 'Location == Unknown' but the actual sign-in location is not 'Unknown'
AnswerD

The filter 'Location == Unknown' makes the rule alert only when the sign-in location is reported as Unknown, which is a data-quality attribute. If the actual sign-in location is, say, 'United States,' the query simply returns no records and the rule remains silent—this is the rule working as designed, not a misconfiguration. If you are expecting an alert for a known-location sign-in, this rule was never meant to cover it; and if unknown-location sign-ins did occur, suppression, not the location filter, would prevent duplicates.

Why this answer

The rule has generated no alerts because the query condition 'Location == Unknown' does not match any actual sign-in locations. Suppression only suppresses alerts after an initial alert has been generated; it does not prevent the first alert. With zero alerts, the most likely cause is that the query returns no results, not suppression.

Exam trap

Be careful: suppression does not stop the first alert from being generated; it only suppresses subsequent matching results for the configured duration. A rule with no alerts in the past 24 hours means the query likely returned no results or the rule isn't running, not that suppression is suppressing everything.

How to eliminate wrong answers

Option A is wrong because the triggerThreshold is set to 0, which in Microsoft Sentinel analytics rules means that an alert is generated for every query result (i.e., no minimum threshold), so alerts would be generated, not suppressed. Option C is wrong because a queryFrequency of 1 hour and a queryPeriod of 7 days is a valid and common configuration for rules that look back over a longer window to detect patterns, and this mismatch does not prevent alerts from being generated. Option D is wrong because the query condition 'Location == Unknown' is a filter that would only match sign-ins where the location is explicitly 'Unknown'; if no sign-ins with that location occurred, the query would return zero results, but this is a data issue, not a rule configuration issue, and the question asks for the most likely cause given the rule is enabled and has not generated alerts.

Practice this question →
234
MCQmedium

Your SOC team uses Microsoft Sentinel with multiple workspaces across regions. You need to implement a solution that allows analysts to query all workspaces from a single location without moving data. Which feature should you configure?

A.Use cross-workspace queries with workspace() expressions in KQL.
B.Export data to Azure Data Explorer and query there.
C.Create a single Log Analytics workspace and have all data sources send logs there.
D.Configure Azure Lighthouse to manage all workspaces.
AnswerA

The workspace() expression lets a single KQL query reference tables in other Microsoft Sentinel workspaces, returning results without ingesting or replicating data. This satisfies the requirement to query all regional workspaces from one location while leaving data resident in its original region.

Why this answer

Cross-workspace queries using the `workspace()` expression in KQL allow analysts to query multiple Log Analytics workspaces from a single query context without moving or centralizing the data. This is the native Microsoft Sentinel feature designed for multi-workspace environments, enabling seamless querying across regions while keeping data in its original workspace.

Exam trap

The trap here is that candidates often confuse Azure Lighthouse (cross-tenant management) with cross-workspace querying, but Lighthouse does not provide the KQL-level query capability needed to query data across workspaces from a single query.

How to eliminate wrong answers

Option B is wrong because exporting data to Azure Data Explorer requires moving data out of Log Analytics, which contradicts the requirement of querying without moving data, and adds latency and cost for data transfer. Option C is wrong because creating a single Log Analytics workspace would require all data sources to send logs to that one location, which violates the requirement of keeping data in multiple workspaces across regions. Option D is wrong because Azure Lighthouse provides cross-tenant management capabilities but does not enable querying across multiple workspaces from a single KQL query; it only allows managing resources across tenants, not querying data across workspaces.

Practice this question →
235
MCQeasy

Your organization uses Microsoft Defender for Endpoint. You need to ensure that when a high severity alert is generated, an automated investigation is launched immediately. What is the correct configuration?

A.Create a custom indicator in Microsoft Defender for Endpoint.
B.Use advanced hunting to create a custom detection rule.
C.In Microsoft Defender for Endpoint, set up an alert suppression rule.
D.In Microsoft 365 Defender, configure automated investigation and response settings to automatically investigate alerts.
AnswerD

Configuring automated investigation and response in Microsoft 365 Defender directly satisfies the requirement to launch investigations on alerts. AIR settings let you toggle automatic investigation for specific alert severities, so high severity alerts trigger investigations immediately without manual intervention, unlike device groups or custom detections.

Why this answer

Microsoft 365 Defender's automated investigation and response (AIR) capabilities allow you to configure automatic investigation for alerts of specific severity levels. By enabling this setting for high severity alerts, Defender for Endpoint will immediately launch an investigation when such an alert is generated, without requiring manual intervention.

Exam trap

The trap here is that candidates often confuse custom detection rules (advanced hunting) or custom indicators with the ability to trigger automated investigations, when in fact the correct configuration is a simple toggle in the automated investigation and response settings within Microsoft 365 Defender.

How to eliminate wrong answers

Option A is wrong because custom indicators (IOCs) are used to define entities like files, IPs, or domains for detection, alerting, or blocking—they do not control automated investigation launch behavior. Option B is wrong because advanced hunting custom detection rules create custom alerts based on KQL queries, but they do not configure the automatic investigation trigger for existing high severity alerts. Option C is wrong because alert suppression rules are designed to suppress or hide alerts based on criteria, not to initiate automated investigations.

Practice this question →
236
MCQmedium

Your organization has Microsoft Defender for Office 365 enabled. Users report that phishing emails are being delivered to their inboxes. You need to improve the filtering. What should you do first?

A.Increase the spam confidence level threshold.
B.Review phishing emails in Threat Explorer and adjust anti-phishing policies.
C.Disable third-party email connectors.
D.Enable the 'Secure by default' setting in Exchange Online.
AnswerB

Threat Explorer in Microsoft 365 Defender provides granular visibility into phishing detections, including message traces, delivery actions, sender/receiver details, and threat types, so you can identify whether legitimate mail was misclassified or real phishing evaded detection. Using that evidence, you can fine-tune anti-phishing policies to apply stronger impersonation protection, spoof intelligence, and mailbox intelligence for affected users and domains. This combines investigation and policy adjustment, which is the correct remediation workflow in Defender for Office 365.

Why this answer

Reviewing the Threat Explorer in Defender for Office 365 allows you to analyze detected phishing emails and understand why they were delivered, then adjust policies accordingly. Option A is wrong because increasing spam confidence level might block legitimate email. Option C is wrong because disabling third-party connectors doesn't help.

Option D is wrong because enabling secure by default is already enabled.

Practice this question →
237
MCQeasy

Your SOC uses Microsoft Defender for Office 365. You need to configure a policy that automatically moves malicious email attachments to quarantine before they reach user mailboxes. What should you configure?

A.Create an anti-phishing policy to detect phishing attempts.
B.Create an anti-spam policy with a high confidence spam filter.
C.Create an anti-malware policy in the Microsoft 365 Defender portal.
D.Create a Safe Attachments policy in the Microsoft 365 Defender portal.
AnswerD

A Safe Attachments policy in the Microsoft 365 Defender portal is the correct solution because it is specifically designed to handle email attachments by routing them through a detonation sandbox. When an email has an attachment that matches policy conditions, the attachment is opened in a virtualized environment to observe its behavior, and the verdict (malicious or benign) determines whether the message is delivered or quarantined. Safe Attachments provides zero-day protection against malware that traditional signature-based scanning misses, and it integrates with other Defender for Office 365 features like time-of-click protection. This policy directly addresses the requirement to quarantine malicious attachments.

Why this answer

Safe Attachments is a Microsoft Defender for Office 365 feature specifically designed to detonate email attachments in a virtual sandbox environment before delivery. By creating a Safe Attachments policy in the Microsoft 365 Defender portal, you can automatically quarantine malicious attachments, preventing them from reaching user mailboxes. This directly addresses the requirement to handle malicious attachments, not phishing or spam.

Exam trap

The trap here is that candidates often confuse anti-malware policies (which use static signatures) with Safe Attachments (which uses dynamic sandbox analysis), leading them to select Option C instead of D.

How to eliminate wrong answers

Option A is wrong because anti-phishing policies protect against deceptive email messages designed to steal credentials, not against malicious attachments; they do not perform attachment sandboxing. Option B is wrong because anti-spam policies filter bulk or unwanted email based on content and sender reputation, not on attachment malware analysis; high confidence spam filters do not quarantine attachments. Option C is wrong because while an anti-malware policy can detect known malware via signature-based scanning, it does not provide the advanced sandbox detonation and zero-day protection that Safe Attachments offers; anti-malware policies are more basic and may miss polymorphic threats.

Practice this question →
238
MCQhard

Your organization uses Microsoft Defender for Cloud to monitor hybrid workloads. You need to ensure that security alerts from on-premises servers running Windows Server 2022 are forwarded to Microsoft Sentinel. The servers are not yet onboarded to Azure Arc. What should you do first?

A.Install the Azure Monitor Agent on the servers.
B.Deploy Azure Policy to enable Defender for Cloud on the servers.
C.Onboard the servers to Azure Arc and enable Defender for Cloud.
D.Install Microsoft Defender for Endpoint on the servers.
AnswerC

Azure Arc enrolment is the prerequisite: it projects the on-premises Windows Server 2022 machines into Azure as connected resources, which Defender for Cloud requires before its agent can stream security alerts into Microsoft Sentinel. Without Arc, the servers remain invisible to the connector.

Why this answer

On-premises servers must first be onboarded to Azure Arc to establish a management identity and connectivity with Azure. Without Azure Arc, Defender for Cloud cannot apply its security policies or forward alerts to Microsoft Sentinel. Enabling Defender for Cloud on the servers after Arc onboarding allows security alerts to be collected and forwarded to Sentinel.

Exam trap

The trap here is that candidates often assume installing an agent (AMA or MDE) is sufficient to forward alerts to Sentinel, but Microsoft requires Azure Arc as the foundational onboarding step to bring non-Azure servers into the Azure management plane before Defender for Cloud can generate and forward security alerts.

How to eliminate wrong answers

Option A is wrong because the Azure Monitor Agent (AMA) can collect telemetry but does not enable Defender for Cloud's security alert generation or forwarding to Sentinel; AMA is a data collection agent, not a prerequisite for Defender for Cloud integration. Option B is wrong because Azure Policy can enforce configurations only on resources already managed by Azure; without Azure Arc, the on-premises servers are not visible to Azure Policy. Option D is wrong because Microsoft Defender for Endpoint (MDE) provides endpoint detection and response but does not, by itself, forward security alerts to Sentinel; MDE integration with Sentinel requires the servers to be onboarded to Azure Arc or have a direct data connector configured.

Practice this question →
239
MCQmedium

Your organization uses Microsoft Sentinel and Microsoft Defender for Cloud Apps to monitor cloud application usage. You have a custom analytics rule that detects multiple failed login attempts from different IP addresses for the same user within 5 minutes. This rule generates an incident. The security team wants to automatically suspend the user in Microsoft Entra ID (formerly Azure AD) when such an incident is created, but only if the user is not a member of the 'Emergency Access' group. You need to implement this automation. You have already created the analytics rule. What should you do next?

A.Modify the analytics rule to include a condition that checks the user's group membership using KQL.
B.Create an automation rule that suspends the user directly using a condition on the incident.
C.Create an automation rule that triggers on incident creation and runs a playbook that suspends the user.
D.Create a playbook that uses the Microsoft Entra ID connector to check if the user is a member of the 'Emergency Access' group. If not, suspend the user. Then create an automation rule that runs this playbook on incident creation.
AnswerD

A playbook performs the conditional group check and suspension, satisfying the requirement to exclude Emergency Access members. The automation rule triggers it on incident creation, since analytics rules alone cannot execute remediation actions or query group membership dynamically.

Why this answer

The requirement has two parts: conditional logic (check Emergency Access group membership) and an action (suspend the user). Playbooks are the only Sentinel component that can run arbitrary logic and call the Microsoft Entra ID connector to both check group membership and disable the account. The automation rule then binds that playbook to incident creation, giving the correct end-to-end flow.

Exam trap

SC-200 often tests the boundary between automation rules (which can only trigger playbooks or set incident metadata) and playbooks (which perform the actual API actions), so candidates wrongly pick an automation rule that 'suspends the user directly'.

How to eliminate wrong answers

Option A is wrong because KQL in an analytics rule can filter which events generate incidents but cannot query Entra ID group membership or perform a remediation action. Option B is wrong because automation rules can trigger playbooks or apply lightweight incident actions (severity, status, tags, assignment) but cannot directly call the Entra ID API to suspend a user. Option C is wrong because it omits the group-membership check, so it would suspend Emergency Access accounts and lock out the tenant.

Option D is correct because it combines the conditional check and the suspend action inside a playbook and wires it to incident creation via an automation rule.

Practice this question →
240
Multi-Selecthard

Your organization uses Microsoft Defender XDR. You need to delegate incident management tasks to a team of analysts without granting full global admin permissions. Which THREE roles in Microsoft 365 Defender should you assign?

Select 3 answers
A.Security Administrator
B.Security Operator
C.Security Analyst
D.Security Reader
E.Compliance Administrator
AnswersA, B, D

Security Administrator is a privileged Microsoft Entra ID role that grants broad control over security settings in Microsoft 365 Defender, including the ability to modify threat policies, manage role groups, and read/respond to incidents. In Defender XDR, this role can triage, edit, and resolve incidents while also adjusting tenant-wide security configurations, making it a valid choice for the requirement. It goes beyond mere triage by allowing administrative changes to the security posture.

Why this answer

Security Administrator is correct because this role in Microsoft 365 Defender provides full access to incident management features, including the ability to investigate, respond to, and resolve incidents, while not granting full global admin permissions. It allows analysts to manage alerts, perform advanced hunting, and configure security settings within the Defender portal, making it suitable for delegated incident management tasks.

Exam trap

The trap here is that candidates may confuse the non-existent 'Security Analyst' role with the actual 'Security Operator' role, or incorrectly assume that 'Compliance Administrator' includes incident management permissions due to overlapping security and compliance concepts.

Practice this question →
241
MCQhard

You are a SOC analyst at Contoso. The environment includes Microsoft Sentinel in a single workspace, Microsoft Defender XDR (including Defender for Endpoint, Defender for Office 365, Defender for Identity, and Defender for Cloud Apps), Microsoft Entra ID, and Microsoft Intune. You need to design a solution to automatically triage and respond to phishing incidents detected by Defender for Office 365. The requirements are: 1) When a phishing alert is generated with high confidence, an incident should be automatically created in Sentinel. 2) The incident should be assigned to the 'Phishing' team and have a severity of High. 3) A playbook should run that will send a Teams message to the Phishing team and also block the sender in Exchange Online. 4) The incident should be automatically closed if the playbook successfully executes. What should you do?

A.Use the Office 365 connector to ingest alerts, then create an analytics rule to generate incidents, and use automation rules to assign and run playbooks.
B.Enable the Microsoft 365 Defender connector to synchronize incidents, create an automation rule triggered on incident creation with conditions for 'Phishing' and high confidence, assigning to 'Phishing' team, running a playbook, and enabling auto-closure.
C.Use a Logic App to continuously poll Defender for Office 365 APIs for alerts, create incidents via the Sentinel API, and assign them.
D.Create a custom analytics rule with KQL to detect phishing in Defender for Office 365 logs, generate incidents, and use automation rules.
AnswerB

This is the recommended approach because the Microsoft 365 Defender connector synchronizes existing Defender for Office 365 incidents into Microsoft Sentinel as incidents. An automation rule can be configured to trigger on incident creation, with conditions for 'Phishing' and 'High' confidence, which assigns the incident to the Phishing team and runs a playbook for automated investigation. Enabling auto-closure ensures that incidents resolved in Defender are automatically closed in Sentinel, maintaining end-to-end fidelity.

Why this answer

It leverages the Microsoft 365 Defender connector to synchronize incidents from Defender for Office 365 into Microsoft Sentinel, which is the recommended approach for ingesting high-confidence phishing alerts. An automation rule triggered on incident creation with conditions for 'Phishing' and high confidence can assign the incident to the 'Phishing' team, run a playbook to send a Teams message and block the sender in Exchange Online, and enable auto-closure upon successful playbook execution.

Exam trap

The trap here is that candidates often confuse the Office 365 connector (which ingests raw alerts) with the Microsoft 365 Defender connector (which synchronizes incidents), leading them to choose Option A, which requires an extra analytics rule and does not natively support high-confidence phishing incident synchronization.

How to eliminate wrong answers

Option A is wrong because the Office 365 connector ingests raw alerts, not incidents, and requires an analytics rule to generate incidents, which adds unnecessary complexity and does not directly synchronize Defender for Office 365 incidents with high-confidence phishing detection. Option C is wrong because using a Logic App to continuously poll Defender for Office 365 APIs is inefficient, introduces latency, and bypasses the native incident synchronization provided by the Microsoft 365 Defender connector, which is the designed pattern for automated triage. Option D is wrong because creating a custom analytics rule with KQL to detect phishing in Defender for Office 365 logs is redundant and error-prone, as Defender for Office 365 already generates high-confidence phishing alerts that should be synchronized as incidents via the Microsoft 365 Defender connector, not re-detected through log queries.

Practice this question →
242
MCQmedium

Your organization uses Microsoft Sentinel and has deployed multiple analytics rules. You need to evaluate the effectiveness of these rules by identifying which rules generate the most incidents and have the highest false positive rate. What should you use?

A.Incidents view in Microsoft Sentinel filtered by analytics rule
B.Hunting view in Microsoft Sentinel
C.MITRE ATT&CK view in Microsoft Sentinel
D.Entity behavior analytics view in Microsoft Sentinel
AnswerA

The Incidents view in Microsoft Sentinel is the dedicated operational workspace where alerts are grouped into incidents and linked back to their originating analytics rule. By filtering on a specific rule, you can directly see how many incidents that rule generated, their current status (new, in progress, resolved), and the classification assigned during triage, such as true positive, false positive, or benign positive. This is the authoritative place to review rule effectiveness because it reflects real detection outcomes and allows analysts to take corrective action on noisy or high-fidelity rules.

Why this answer

The Incidents view in Microsoft Sentinel allows you to filter incidents by analytics rule, enabling you to see the count of incidents generated per rule and assess their effectiveness. By reviewing the incident details, you can identify which rules produce the most incidents and, by analyzing the closed or resolved incidents, determine the false positive rate. This directly addresses the requirement to evaluate rule effectiveness based on incident volume and false positives.

Exam trap

The trap here is that candidates may confuse the Hunting view (used for proactive searches) with the Incidents view (used for post-detection analysis), or assume the MITRE ATT&CK view provides rule-level performance metrics when it only maps incidents to attack techniques.

How to eliminate wrong answers

Option B is wrong because the Hunting view is designed for proactive threat hunting using KQL queries to find suspicious activity, not for retrospective analysis of incident generation or false positive rates from analytics rules. Option C is wrong because the MITRE ATT&CK view maps incidents to MITRE techniques but does not provide a breakdown of incident counts or false positive rates per analytics rule. Option D is wrong because Entity behavior analytics view focuses on user and entity behavior anomalies (UEBA) to detect compromised entities, not on evaluating the performance of analytics rules in terms of incident volume or false positives.

Practice this question →
243
MCQeasy

Your organization uses Microsoft Sentinel. You need to automatically assign incidents to the appropriate SOC tier based on severity. What should you create?

A.A data connector to Microsoft Teams
B.A scheduled analytics rule
C.A playbook in Microsoft Power Automate
D.An automation rule with an owner assignment action
AnswerD

Automation rules in Microsoft Sentinel trigger on incident creation and can execute an owner assignment action, setting the incident's owner to the relevant SOC tier. This directly satisfies the requirement to assign incidents automatically based on severity, using the severity condition within the rule's trigger criteria.

Why this answer

Automation rules in Microsoft Sentinel allow you to automatically assign incidents to specific owners based on conditions like severity, using the 'Assign owner' action. This directly meets the requirement to route incidents to the appropriate SOC tier without manual intervention, leveraging Sentinel's native incident management capabilities.

Exam trap

The trap here is that candidates often confuse automation rules with playbooks, assuming that any automated response requires a playbook, when in fact simple owner assignment is a native automation rule action that does not need a separate playbook or Power Automate workflow.

How to eliminate wrong answers

Option A is wrong because a data connector to Microsoft Teams is used to ingest collaboration data (e.g., chat logs) into Sentinel for analysis, not to automate incident assignment based on severity. Option B is wrong because a scheduled analytics rule generates alerts from log data based on a query schedule, but it does not perform post-incident actions like owner assignment; it only creates incidents or alerts. Option C is wrong because a playbook in Microsoft Power Automate (or Azure Logic Apps) can automate response actions, but it is typically triggered by an automation rule or analytics rule, not directly used for initial owner assignment; the native 'Assign owner' action in automation rules is the correct, simpler method for this specific requirement.

Practice this question →
244
MCQeasy

Your organization uses Microsoft Sentinel and you have a playbook that sends an email notification when a high-severity incident is created. You want to ensure that the playbook only runs for incidents that are not already assigned to a user. What should you configure?

A.Set the playbook trigger to 'When an incident is created' and add a condition inside
B.Add a condition in the playbook to check if the incident is assigned
C.Configure the automation rule trigger to include a condition for 'Incident owner equals null'
D.Modify the analytics rule to only generate unassigned incidents
AnswerC

This is the correct approach because Microsoft Sentinel automation rules can be configured with trigger conditions based on incident properties, including the Incident owner field. By setting a condition such as 'Incident owner equals null', the automation rule will only execute when the incident is unassigned, ensuring that any associated playbook runs only for those incidents. This leverages Sentinel's native conditional logic, avoids unnecessary playbook executions, and is the recommended pattern for automating responses based on incident ownership status.

Why this answer

Automation rules in Microsoft Sentinel can include conditions that filter which incidents trigger a playbook. By configuring the automation rule with a condition for 'Incident owner equals null', the playbook will only run for incidents that are unassigned, ensuring that already assigned incidents are not processed. This approach is efficient and avoids unnecessary execution of the playbook.

Exam trap

The trap here is that candidates may think a condition inside the playbook is sufficient, but Microsoft Sentinel automation rules are designed to filter incidents before triggering the playbook, making the automation rule condition the correct and more efficient choice.

How to eliminate wrong answers

Option A is wrong because setting the playbook trigger to 'When an incident is created' and adding a condition inside the playbook would still cause the playbook to be triggered for every incident, including assigned ones, leading to unnecessary runs and potential performance issues; the condition should be applied at the automation rule level to filter before triggering. Option B is wrong because adding a condition inside the playbook to check if the incident is assigned does not prevent the playbook from being triggered for all incidents, which wastes resources and may cause unwanted email notifications for assigned incidents. Option D is wrong because modifying the analytics rule to only generate unassigned incidents is not feasible; analytics rules generate incidents based on detection logic, not assignment status, and assignment is a post-creation action.

Practice this question →
245
Multi-Selecthard

Which THREE permissions are required for a user to manage Microsoft Sentinel playbooks using Azure Logic Apps? (Choose three.)

Select 3 answers
A.Microsoft Sentinel Contributor
B.Log Analytics Contributor
C.Global Administrator in Microsoft Entra ID
D.Reader on the Logic App
E.Contributor on the resource group containing the Logic App
AnswersA, B, E

Microsoft Sentinel Contributor is the primary role required to interact with Sentinel playbooks through the portal, APIs, or automation rules. It grants the ability to read and trigger playbooks, as well as view and manage Sentinel incidents and analytics rules. Without this role, the user would not be able to attach playbooks to detections or manually run them from the Sentinel interface, even if they have access to the underlying Logic App.

Why this answer

Microsoft Sentinel Contributor is required because it grants the necessary permissions to create, update, and delete playbooks within Microsoft Sentinel, which are built on Azure Logic Apps. This role allows the user to manage playbooks as part of the security operations environment, including assigning playbooks to automation rules and incident triggers.

Exam trap

The trap here is that candidates often assume Global Administrator is needed for any automation in Sentinel, but Microsoft specifically scopes playbook management to resource group-level Contributor roles to enforce least privilege and avoid granting tenant-wide admin rights.

Practice this question →
246
MCQmedium

Your organization has recently deployed Microsoft Sentinel and wants to ensure that all critical Azure resources are monitored for security misconfigurations. You have already enabled Microsoft Defender for Cloud on all subscriptions. You need to configure a solution that will automatically create a Sentinel incident whenever a new security recommendation with severity 'High' is generated in Defender for Cloud. The incident should be assigned to the 'Infrastructure' team. Additionally, you want to run a playbook that will open a ticket in your IT Service Management (ITSM) tool. What should you do?

A.Use the Azure Activity connector to ingest recommendations, then create an analytics rule to generate incidents.
B.Enable the Defender for Cloud connector and create a workbook to monitor recommendations.
C.Create a custom analytics rule that queries the SecurityRecommendation table in the Log Analytics workspace.
D.Enable the Defender for Cloud connector, then create an automation rule that triggers on incident creation from the connector, assigns to 'Infrastructure', and runs a playbook.
AnswerD

Enabling the Defender for Cloud connector is the prerequisite to bring security recommendations and leading alerts into Sentinel as incidents through its built-in analytics rule. A subsequent automation rule that triggers when an incident is created can be configured to assign the incident to the Infrastructure team (using a specific owner or group) and run a playbook to automate the recommended remediation. This design fully satisfies the requirement: data is ingested, incidents are generated, and an automated response is applied based on the recommendation.

Why this answer

The Defender for Cloud connector in Microsoft Sentinel ingests security recommendations and alerts as incidents. By creating an automation rule that triggers on incident creation from this connector, you can automatically assign incidents to the 'Infrastructure' team and run a playbook to open a ticket in your ITSM tool, fulfilling all requirements without custom queries or workbooks.

Exam trap

The trap here is that candidates often think they need to write a custom analytics rule (Option C) or use the Azure Activity connector (Option A) to ingest Defender for Cloud data, when in fact the Defender for Cloud connector already provides incident creation and automation rules handle assignment and playbook execution natively.

How to eliminate wrong answers

Option A is wrong because the Azure Activity connector ingests operational logs (e.g., resource creation/deletion), not security recommendations from Defender for Cloud; it cannot generate incidents from recommendations. Option B is wrong because enabling the Defender for Cloud connector and creating a workbook only visualizes data—it does not automatically generate incidents or trigger playbooks. Option C is wrong because while the SecurityRecommendation table exists, creating a custom analytics rule to query it is unnecessary and less efficient; the Defender for Cloud connector already ingests these recommendations as incidents, and automation rules provide the required assignment and playbook execution without custom KQL.

Practice this question →
247
MCQeasy

Refer to the exhibit. You have a Microsoft Sentinel playbook created as shown. When you test the playbook manually, it sends an email successfully. However, when an incident triggers the playbook via an automation rule, the email is not sent. What is the most likely cause?

A.The playbook does not have permission to read incidents.
B.The playbook uses an HTTP trigger instead of a Microsoft Sentinel trigger.
C.The email action is not configured correctly.
D.The Office 365 connection is not authorized.
AnswerB

Microsoft Sentinel automation rules can only invoke Logic Apps that start with a Microsoft Sentinel trigger—either the 'Microsoft Sentinel Incident' trigger or the 'Microsoft Sentinel Alert' trigger—because those triggers receive the incident/alert payload and register the playbook as a Sentinel playbook. The exhibit shows an HTTP trigger ('When a HTTP request is received'), which is a generic Logic Apps trigger; although it can be tested manually by sending an HTTP POST to the endpoint, it is not registered with Microsoft Sentinel as a playbook and therefore is not available for selection in an automation rule. Replacing the HTTP trigger with a Microsoft Sentinel Incident trigger would make the playbook eligible for automation-rule use.

Why this answer

The exhibit shows a playbook that begins with an HTTP trigger, not a Microsoft Sentinel trigger. When an incident triggers the playbook via an automation rule, Sentinel expects the playbook to start with a Microsoft Sentinel trigger (e.g., 'When a response to a Microsoft Sentinel incident is triggered'). An HTTP trigger requires an external HTTP request to start the playbook, which the automation rule does not provide, so the playbook never executes the email action.

Exam trap

The trap here is that candidates assume any playbook can be triggered by an automation rule, overlooking that the playbook must use the dedicated Microsoft Sentinel trigger connector, not a generic HTTP trigger.

How to eliminate wrong answers

Option A is wrong because the playbook successfully sends an email when tested manually, indicating it has sufficient permissions to read incidents; the issue is the trigger type, not permissions. Option C is wrong because the email action works correctly during manual testing, so the configuration is not the problem. Option D is wrong because the Office 365 connection is authorized and functional, as proven by the successful manual test.

Practice this question →
248
MCQhard

You are a security operations analyst at a company that uses Microsoft Defender XDR and Microsoft Sentinel. You have configured a custom detection rule in Microsoft Defender XDR that uses a KQL query to detect suspicious PowerShell activity. The rule triggers an alert, but you want to automatically create an incident in Microsoft Sentinel and run a playbook that isolates the affected device. You have already set up the Microsoft Defender XDR connector in Sentinel and enabled incident creation from Defender XDR alerts. However, the playbook does not run automatically when a Defender XDR incident is created. You have verified that the playbook is properly configured and has the correct permissions. What should you do?

A.Create an automation rule in Microsoft Defender XDR to run the playbook.
B.Create an automation rule in Microsoft Sentinel that triggers on incident creation and runs the playbook.
C.Modify the Microsoft Defender XDR data connector in Sentinel to enable playbook execution.
D.Modify the custom detection rule in Defender XDR to include a 'run playbook' action.
AnswerB

Microsoft Sentinel's automation rules provide the exact trigger mechanism needed here: you define a rule that fires on incident creation and set an action to run the specified Azure Logic Apps playbook. When Sentinel ingests Defender incidents via the Microsoft Defender XDR connector, the automation rule evaluates the incident creation event and invokes the playbook with the relevant incident data. This is the supported, intended pattern for automating playbook execution when an incident is created in Sentinel, making this option correct.

Why this answer

In Microsoft Sentinel, automation rules are the mechanism to trigger playbooks automatically when incidents are created or updated. Since the Defender XDR connector is already enabled and creating incidents in Sentinel, the missing piece is an automation rule in Sentinel that runs the playbook on incident creation. The playbook itself is properly configured, so the automation rule bridges the gap between incident creation and playbook execution.

Exam trap

The trap here is that candidates may assume playbooks can be triggered directly from Defender XDR or via the connector settings, but Sentinel automation rules are the only way to automatically run a playbook when a Defender XDR incident is created in Sentinel.

How to eliminate wrong answers

Option A is wrong because Microsoft Defender XDR does not support automation rules to run playbooks; playbook execution is managed within Microsoft Sentinel. Option C is wrong because the Defender XDR data connector in Sentinel does not have a setting to enable playbook execution; its role is to ingest alerts and create incidents, not to trigger playbooks. Option D is wrong because custom detection rules in Defender XDR cannot include a 'run playbook' action; playbooks are a Sentinel concept and must be triggered via Sentinel automation rules.

Practice this question →
249
MCQhard

Your SOC team uses Microsoft Sentinel and Microsoft Defender XDR. You have configured automated responses using playbooks. However, some playbooks fail to execute when triggered from Microsoft Defender XDR incidents. You need to ensure that the playbooks run successfully. What should you verify?

A.Confirm that the playbook is stored in the same resource group as Microsoft Sentinel.
B.Verify that the playbook is connected to Microsoft Teams for approval.
C.Ensure that the automation rule that triggers the playbook has the correct 'incident provider' set to 'Microsoft Defender XDR'.
D.Check that the service principal has global administrator role in Microsoft Entra ID.
AnswerC

The 'incident provider' condition in an automation rule filters which incidents can trigger the playbook. Incidents created from Microsoft Defender XDR alerts have their provider set to 'Microsoft Defender XDR', so the rule must explicitly include this provider in its condition; otherwise, the rule will silently skip those incidents. This setting is the most likely cause when Defender XDR incidents do not trigger the playbook while other incident providers, such as 'Azure Security Center' or 'Microsoft Sentinel', still work.

Why this answer

Microsoft Defender XDR incidents that are synchronized to Microsoft Sentinel include an 'incident provider' property. Automation rules in Sentinel must have the 'incident provider' set to 'Microsoft Defender XDR' to trigger playbooks specifically for those incidents. If this property is not configured correctly, the automation rule will not match the incoming incidents, causing the playbook to fail to execute.

Exam trap

The trap here is that candidates often assume playbook failures are due to permissions or resource location, but the SC-200 exam specifically tests the understanding that automation rules require the correct 'incident provider' filter to match incidents from Microsoft Defender XDR.

How to eliminate wrong answers

Option A is wrong because playbooks are Azure Logic Apps resources that can reside in any resource group; they do not need to be in the same resource group as Microsoft Sentinel. Option B is wrong because Microsoft Teams integration is not a prerequisite for playbook execution; it is an optional action within a playbook for manual approval steps. Option D is wrong because the service principal used for playbook authentication requires only the 'Microsoft Sentinel Contributor' role on the relevant resource group or subscription, not the global administrator role in Microsoft Entra ID.

Practice this question →
250
Multi-Selecthard

Which THREE of the following are capabilities of Microsoft Defender XDR's automated investigation and response (AIR) that can be enabled or configured by a security operations analyst? (Choose three.)

Select 3 answers
A.Automatically block an email message or attachment.
B.Automatically isolate a compromised device.
C.Automatically modify Data Loss Prevention policies.
D.Automatically suspend a user account.
E.Automatically create new analytics rules based on incident patterns.
AnswersA, B, D

Automated Investigation and Response (AIR) in Microsoft Defender for Office 365 can automatically remediate email-borne threats by soft-deleting or blocking malicious messages and attachments identified during an investigation. This is a core remediation action that stops phishing campaigns and malware delivery directly at the mailbox, without requiring manual intervention.

Why this answer

Microsoft Defender XDR's automated investigation and response (AIR) allows security operations analysts to configure automatic actions such as blocking an email message or attachment. This is a core capability of AIR, which uses playbooks to automatically remediate threats by applying actions like soft-delete or quarantine to malicious emails or attachments based on investigation results.

Exam trap

The trap here is that candidates often confuse the capabilities of Microsoft Defender XDR's AIR with those of Microsoft Sentinel's automation rules or other Microsoft 365 compliance features, leading them to select options like modifying DLP policies or creating analytics rules, which are not part of AIR's predefined action set.

Practice this question →
251
Multi-Selectmedium

Which TWO of the following are required to enable user and entity behavior analytics (UEBA) in Microsoft Sentinel?

Select 2 answers
A.Microsoft Entra ID diagnostic logs must be streamed.
B.Azure subscription diagnostic logs must be enabled.
C.Windows Security Events via AMA must be ingested.
D.Microsoft Defender XDR connector must be configured.
E.UEBA must be enabled in the Sentinel settings.
AnswersC, E

Windows Security Events collected via the Azure Monitor Agent are a core UEBA data source because they supply authentication, process, and privilege-use activity for on-premises users and computers. The AMA writes these events into the 'SecurityEvent' table, which the UEBA service queries to enrich entities and generate behavioral baselines. Without this ingestion, UEBA cannot monitor desktops or servers that participate in user behavior.

Why this answer

Windows Security Events ingested via the Azure Monitor Agent (AMA) provide the necessary user and entity activity data (e.g., logon events, process creation) that UEBA analyzes to establish behavioral baselines and detect anomalies. Without this data source, UEBA lacks the raw security events required for user and entity profiling.

Exam trap

The trap here is that candidates assume UEBA requires premium connectors like Microsoft Defender XDR or Entra ID diagnostic logs, when in fact the core requirement is enabling UEBA in settings and ingesting a supported data source such as Windows Security Events via AMA.

Practice this question →
252
MCQhard

Your organization uses Microsoft Sentinel and has deployed the Microsoft Sentinel Solution for Microsoft Defender XDR. You need to correlate alerts from Microsoft Defender for Endpoint with Microsoft Defender for Office 365 in a single incident. What is the recommended approach?

A.Ingest alerts from both products separately and use a KQL query in an analytics rule to correlate them.
B.Use the Microsoft 365 Defender connector to ingest unified incidents from Microsoft 365 Defender, which already correlates alerts from both products.
C.Create a workbook that displays alerts from both products side by side.
D.Use a Microsoft Sentinel fusion rule to correlate the alerts.
AnswerB

The Microsoft 365 Defender connector ingests already-correlated incidents from the Microsoft 365 Defender portal, which automatically fuses alerts from Microsoft Defender for Endpoint and Microsoft Defender for Office 365 into a single incident. This native correlation consolidates the attack story, affected entities, and automated investigation state so security operations can manage one unified event instead of chasing separate alert streams. The connector also synchronizes incident status and updates from Microsoft 365 Defender back to Sentinel, keeping investigation actions consistent. This is the recommended approach because it leverages Microsoft's built-in correlation and eliminates the need for custom detection logic.

Why this answer

The Microsoft 365 Defender connector ingests unified incidents from Microsoft 365 Defender, which natively correlates alerts from Microsoft Defender for Endpoint and Microsoft Defender for Office 365 into a single incident. This is the recommended approach as it leverages the built-in correlation engine in Microsoft 365 Defender, eliminating the need for custom analytics rules or manual correlation.

Exam trap

The trap here is that candidates may think a fusion rule is the best way to correlate alerts from different sources, but the Microsoft 365 Defender connector is the recommended and more efficient approach because it ingests pre-correlated incidents from the unified XDR platform.

How to eliminate wrong answers

Option A is wrong because ingesting alerts separately and using a KQL query in an analytics rule to correlate them is inefficient and not recommended; it introduces latency and complexity, and Microsoft 365 Defender already provides native correlation. Option C is wrong because creating a workbook that displays alerts side by side does not correlate them into a single incident; workbooks are for visualization, not incident creation or correlation. Option D is wrong because a Microsoft Sentinel fusion rule is designed to correlate alerts from multiple sources into a single incident, but it is not the recommended approach when the Microsoft 365 Defender connector is available, as the connector provides pre-correlated incidents with higher fidelity and lower overhead.

Practice this question →
253
Multi-Selecteasy

Which TWO of the following are required to enable Microsoft Sentinel to receive alerts from Microsoft Defender for Cloud? (Choose two.)

Select 2 answers
A.Deploy the Log Analytics agent on all VMs.
B.Connect a non-Azure machine using Azure Arc.
C.Install the 'Microsoft Defender for Cloud' data connector in Microsoft Sentinel.
D.Enable Microsoft Defender for Cloud on the Azure subscription.
E.Assign an Azure Policy to enable Defender for Cloud.
AnswersC, D

Install the 'Microsoft Defender for Cloud' data connector in Microsoft Sentinel. — To route Defender for Cloud alerts into Sentinel, you must install and configure the Microsoft Defender for Cloud data connector in the Sentinel workspace. This connector establishes the API integration and subscription selection that streams alerts into the SecurityAlert table. Without this connector, Sentinel has no pipeline to receive those alerts, even if Defender for Cloud is enabled.

Why this answer

The 'Microsoft Defender for Cloud' data connector in Microsoft Sentinel is the specific integration point that ingests security alerts from Defender for Cloud into Sentinel. Without installing and configuring this connector, Sentinel cannot receive the alerts, even if Defender for Cloud is enabled on the subscription.

Exam trap

The trap here is that candidates often confuse enabling Defender for Cloud at the subscription level (which is required) with deploying agents or policies, thinking those are prerequisites for alert ingestion, when in fact the connector handles the ingestion independently of agent deployment.

Practice this question →
254
MCQmedium

Your incident response team uses Microsoft Sentinel. You need to automatically assign incidents to the appropriate analyst based on the incident category. What should you configure?

A.Create an automation rule that runs a playbook to assign the incident.
B.Create an analytics rule that sets the owner field.
C.Create a custom incident label for each category.
D.Create a workbook that filters incidents by category.
AnswerA

An automation rule can be configured to respond to incident creation or update events and launch a playbook built with Azure Logic Apps. The playbook uses the Microsoft Sentinel connector's update-incident action to set the owner (assigned-to) field, making it the correct native mechanism for programmatic ownership assignment.

Why this answer

Automation rules in Microsoft Sentinel can trigger a playbook when an incident is created or updated. By configuring an automation rule with a condition based on the incident category, you can invoke a playbook that uses the Microsoft Sentinel API or Logic Apps to set the incident's owner field, thereby assigning it to the appropriate analyst. This is the correct approach because automation rules are designed to run automated responses, including playbooks, on incidents.

Exam trap

The trap here is that candidates often confuse analytics rules (which create incidents) with automation rules (which act on existing incidents), leading them to incorrectly select option B thinking the rule itself can assign ownership during incident creation.

How to eliminate wrong answers

Option B is wrong because analytics rules generate alerts and incidents from log data; they do not have the capability to set the owner field on an incident—owner assignment is a post-creation action. Option C is wrong because custom incident labels are used for tagging and filtering, not for automated assignment or ownership changes. Option D is wrong because workbooks are visualization tools that display data; they cannot modify or assign incidents.

Practice this question →
255
MCQhard

Your organization uses Microsoft Sentinel with Azure Policy. You need to ensure that new Log Analytics workspaces are automatically connected to Sentinel and configured with a standard set of data connectors. What should you use?

A.Deploy an ARM template to each new workspace manually.
B.Use Sentinel automation rules to configure new workspaces.
C.Develop a Logic App that runs on a schedule to check for new workspaces.
D.Create Azure Policy definitions that deploy Sentinel and data connectors.
AnswerD

Azure Policy definitions with the DeployIfNotExists effect automatically enable Sentinel on Log Analytics workspaces by deploying the Sentinel solution, and can embed ARM templates to install data connectors, using a system-assigned managed identity for role assignment. This is the recommended at-scale governance approach because it continuously evaluates new and existing workspaces, auto-remediates non-compliant resources, and reports compliance status in Azure Policy.

Why this answer

Azure Policy can be used to automatically deploy and configure Microsoft Sentinel and its data connectors on new Log Analytics workspaces. By creating policy definitions with 'DeployIfNotExists' or 'Modify' effects, you ensure that any new workspace is automatically onboarded to Sentinel and has the required data connectors installed, meeting the requirement for automated, consistent configuration at scale.

Exam trap

The trap here is confusing automation rules (which handle incident response within Sentinel) with Azure Policy (which handles resource provisioning and compliance), leading candidates to incorrectly choose option B.

How to eliminate wrong answers

Option A is wrong because manually deploying an ARM template to each new workspace does not provide automated enforcement or scalability; it requires human intervention for every new workspace. Option B is wrong because Sentinel automation rules operate on incidents and alerts within an already-configured Sentinel workspace, not on the provisioning or configuration of the workspace itself. Option C is wrong because a scheduled Logic App would introduce latency and complexity, and it is not a native, policy-driven approach; Azure Policy provides real-time, event-driven enforcement without custom polling logic.

Practice this question →
256
Multi-Selecthard

Which TWO actions should you take to reduce the cost of Microsoft Sentinel while maintaining security coverage?

Select 2 answers
A.Remove data connectors for non-critical sources.
B.Reduce the retention period of tables that do not require long-term storage.
C.Ingest verbose logs (e.g., DNS events) into Basic Logs tier.
D.Disable analytics rules that generate low-severity incidents.
E.Switch the workspace pricing tier from Capacity Reservations to Pay-as-you-Go.
AnswersB, C

Each Log Analytics table in the Sentinel workspace has its own retention setting, and data beyond that interactive retention period can be moved to long-term archive at lower cost or purged if not needed. For high-volume, low-value tables such as network session logs or performance counters, trimming retention from two years to, say, 90 days directly reduces Azure storage billing and archived-log management overhead. This preserves the recent data needed for active detection and investigation, pairs well with short-lived alerting workflows, and is a proven cost optimization that does not degrade detection coverage.

Why this answer

Reducing the retention period for tables that do not require long-term storage directly lowers the data storage costs in Microsoft Sentinel. Sentinel charges per GB of data stored, and by shortening retention (e.g., from 90 days to 30 days) for non-critical tables, you reduce the volume of data retained without affecting security monitoring or incident investigation for the shortened period.

Exam trap

The trap here is that candidates often confuse reducing data ingestion (Option A) with reducing storage costs, but the question explicitly requires maintaining security coverage, so removing data connectors would break that requirement.

Practice this question →
257
Multi-Selecthard

Which THREE of the following are capabilities of Microsoft Copilot for Security?

Select 3 answers
A.Manage Azure Policy assignments.
B.Summarize incidents from Microsoft Defender XDR.
C.Automatically configure conditional access policies.
D.Generate KQL queries for Microsoft Sentinel.
E.Analyze scripts for malicious intent.
AnswersB, D, E

Security Copilot ingests alert and incident data from Microsoft Defender XDR—including device, identity, and email evidence—and generates a natural-language executive summary with estimated scope, impacted assets, and high-level attack chain. This allows the analyst to triage from the incident queue without manually pivoting across alerts, and the same summary can be exported for reporting. Because it is grounded in the live incident graph, the summary reflects current detections rather than static intel.

Why this answer

Microsoft Copilot for Security can summarize incidents from Microsoft Defender XDR, providing a concise overview of alerts, affected assets, and attack chains. This capability leverages natural language processing to parse incident data and generate human-readable summaries, aiding analysts in rapid triage.

Exam trap

The trap here is that candidates may confuse Copilot for Security's analytical and summarization capabilities with broader management or automation features of other Azure services, such as Azure Policy or Conditional Access, which are not part of Copilot's scope.

Practice this question →
258
Multi-Selectmedium

Which TWO actions can reduce the cost of Microsoft Sentinel while maintaining security coverage?

Select 2 answers
A.Remove unused data connectors.
B.Switch to a pay-as-you-go workspace.
C.Configure some tables to use Basic Logs tier.
D.Move older logs to Azure Storage archive tier.
E.Reduce workspace retention to 30 days for all tables.
AnswersC, D

Configuring some tables to use Basic Logs tier reduces cost because Basic Logs are offered at a significantly lower ingestion price than Analytics Logs (up to 75% cheaper). This tier is ideal for high-volume, verbose tables used for debugging or troubleshooting, not for security analytics requiring advanced queries and alerts. However, Basic Logs have a shorter retention period and limited query capabilities, so they should only be used for tables that do not drive detection rules.

Why this answer

Configuring tables to use the Basic Logs tier reduces ingestion costs for high-volume, verbose logs (e.g., from firewalls or DNS servers) while still retaining the data for security analysis. Basic Logs are stored at a lower cost per GB but have reduced query capabilities (e.g., no interactive full-text search, limited to KQL summarization). This allows you to keep security coverage by retaining the logs for detection and investigation, albeit with a different query pattern.

Exam trap

The trap here is that candidates often confuse reducing retention (Option E) with cost savings, but Microsoft explicitly warns that deleting logs can break detection rules and incident investigations, whereas tiering (Basic Logs or archive) preserves data for compliance and hunting at a lower cost.

Practice this question →
259
MCQhard

Refer to the exhibit. You have a Logic Apps playbook that triggers on Microsoft Sentinel alerts. The playbook is not posting messages to Teams. What is the most likely cause?

A.The playbook is using the wrong trigger type.
B.The Teams connector is not authenticated.
C.The trigger body is not referencing the correct alert ID.
D.The JSON syntax is invalid.
AnswerA

The playbook is using the wrong trigger type. A Logic Apps playbook designed for Microsoft Sentinel automation must use the 'When a Microsoft Sentinel alert is created' trigger (or the incident trigger in newer implementations), not a generic HTTP, schedule, or manual trigger. With the wrong trigger, the runtime does not supply the Sentinel alert schema, so all subsequent references to alert properties—such as the alert ID or title—resolve to empty values and the playbook fails before any Teams action executes. The fix is to replace the trigger with the Sentinel-specific trigger so the correct alert payload is bound to the workflow.

Why this answer

The playbook is triggered on Microsoft Sentinel alerts, but Logic Apps requires a specific trigger type to process these alerts correctly. The most likely cause is that the playbook uses a generic HTTP trigger instead of the 'Microsoft Sentinel Incident' or 'Microsoft Sentinel Alert' trigger, which is designed to parse the alert payload and provide the necessary context for downstream actions like posting to Teams. Without the correct trigger, the playbook may not receive the alert data or may fail to execute the Teams connector properly.

Exam trap

The trap here is that candidates often assume authentication issues (Option B) are the default cause for Teams failures, but the question's context of 'not posting messages' without errors points to a trigger mismatch rather than a connectivity problem.

How to eliminate wrong answers

Option B is wrong because if the Teams connector were not authenticated, the playbook would typically fail with an authentication error, not silently fail to post messages; the question implies no error is reported, so authentication is likely valid. Option C is wrong because the trigger body not referencing the correct alert ID would cause a data mapping issue, but the playbook would still attempt to run and likely produce an error or incorrect output, not a complete failure to post. Option D is wrong because invalid JSON syntax would cause the playbook to fail at design time or trigger a validation error, preventing it from running at all, whereas the playbook is running but not posting messages.

Practice this question →
260
MCQhard

You are a security operations analyst for a company that uses Microsoft Sentinel. You need to ensure that all incidents created in the workspace are automatically enriched with threat intelligence indicators from Microsoft Defender Threat Intelligence. What should you configure?

A.The Microsoft Defender Threat Intelligence data connector in Microsoft Sentinel.
B.A playbook that queries the Microsoft Defender Threat Intelligence API and adds indicators as comments to the incident.
C.A workbook that visualizes threat intelligence matches for incidents.
D.A scheduled analytics rule that runs every hour to match incidents with threat intelligence.
AnswerA

Microsoft Sentinel includes a data connector for Microsoft Defender Threat Intelligence (MDTI) that ingests threat intelligence indicators into the workspace. Once connected, these indicators are automatically used to enrich incidents, matching entities in incidents against the indicators. This provides native enrichment without custom automation. Configuring this connector is the correct method to ensure all incidents are enriched with MDTI indicators.

Why this answer

The Microsoft Defender Threat Intelligence data connector in Microsoft Sentinel ingests threat intelligence indicators into the workspace. Once enabled, Microsoft Sentinel automatically matches these indicators against incident entities, enriching incidents with relevant threat intelligence. This is the native and intended method for automatic enrichment.

Exam trap

The trap here is thinking that a playbook or analytics rule is needed for enrichment, when the built-in MDTI connector provides automatic enrichment without custom automation.

Practice this question →
261
Multi-Selecthard

Which TWO are valid methods to ingest logs into Microsoft Sentinel from a non-Azure virtual machine? (Select TWO.)

Select 2 answers
A.Azure Monitor Agent (AMA) with Azure Arc
B.Log Analytics agent (MMA) – legacy
C.Microsoft Sentinel agent (standalone)
D.Azure Monitor Agent (AMA) without Azure Arc
E.Log Analytics agent (OMS) – deprecated
AnswersA, B

Azure Monitor Agent (AMA) with Azure Arc is the current, recommended ingestion path for non-Azure virtual machines. AMA itself is a unified agent that collects telemetry from VMs, but for machines outside Azure, the agent must be deployed and configured through Azure Arc's management plane. Arc enables you to install AMA, assign Data Collection Rules (DCRs), and route the data into a Log Analytics workspace, which Microsoft Sentinel then ingests. Without Arc, AMA cannot be centrally managed on hybrid machines, so this pairing is a fully valid method for bringing logs into Sentinel.

Why this answer

Azure Arc bridges non-Azure VMs into Azure's management plane, allowing the Azure Monitor Agent (AMA) to be installed and managed as if the VM were native Azure. This enables log ingestion into Microsoft Sentinel without requiring direct Azure connectivity or a VPN, using the same AMA data collection rules (DCRs) as Azure VMs.

Exam trap

The trap here is that candidates confuse the deprecated OMS agent with the still-supported MMA legacy agent, or assume AMA can be installed on non-Azure VMs without Azure Arc, when Arc is mandatory for management plane integration.

Practice this question →
262
MCQeasy

Your security team needs to assign a custom role in Microsoft Sentinel that allows read and write access to incidents but not to analytics rules. Which built-in role should you use as a base for the custom role?

A.Microsoft Sentinel Responder
B.Microsoft Sentinel Reader
C.Microsoft Sentinel Contributor
D.Global Administrator
AnswerA

Microsoft Sentinel Responder is the correct built-in role when the job requires actively working incidents: it lets the analyst view, triage, assign, update, and comment on incidents, as well as perform investigation actions like running queries. Critically, it omits write rights to analytics rules, automation rules, and data connectors, so an analyst can respond to threats without accidentally weakening detection logic. This aligns with least privilege for a pure incident-response duty.

Why this answer

The Microsoft Sentinel Responder role is the correct base because it grants read and write access to incidents while explicitly excluding write permissions to analytics rules. This aligns with the requirement for incident management without allowing modifications to detection logic.

Exam trap

The trap here is that candidates often confuse 'Contributor' as the default for any write access, overlooking that it grants broader permissions than needed, while 'Responder' is specifically scoped to incident operations without analytics rule modification.

How to eliminate wrong answers

Option B is wrong because Microsoft Sentinel Reader provides read-only access to all Sentinel data, including incidents and analytics rules, but does not allow write access to incidents. Option C is wrong because Microsoft Sentinel Contributor includes full write access to analytics rules, which violates the requirement to restrict such permissions. Option D is wrong because Global Administrator is a broad Azure AD role that grants full access to all Azure resources, including Sentinel, and is not a Sentinel-specific built-in role; it would allow unrestricted modifications to analytics rules.

Practice this question →
263
MCQhard

You are responsible for Microsoft Defender for Cloud Apps. The security team reports that they are not receiving alerts for suspicious activities from a specific connected app (Salesforce). You verify that the app is connected and the log collection is working. What should you check next?

A.Review the IP address ranges configured for the Salesforce app.
B.Ensure that the anomaly detection policy for Salesforce is enabled in Defender for Cloud Apps.
C.Check if the Salesforce app connector is properly configured in Microsoft Entra ID.
D.Verify that the Salesforce tenant is licensed for Microsoft Entra ID P2.
AnswerB

You must explicitly enable an anomaly detection policy that targets Salesforce in Microsoft Defender for Cloud Apps because these policies are not automatically applied to every connected app. The 'Anomalous activity' policy, for example, can be customized per app family, and if Salesforce is not included or the policy is disabled, no alerts will be raised for unusual sign-ins, downloads, or admin actions in that tenant. Enabling the policy under Policies > Anomaly detection and confirming the Salesforce app is listed as a filter or data source is the direct prerequisite to receive the alert you are investigating.

Why this answer

Since the app is connected and log collection is verified, the issue is likely that the anomaly detection policy for Salesforce is disabled. Defender for Cloud Apps uses built-in anomaly detection policies to generate alerts for suspicious activities; if the policy is turned off, no alerts will be raised even though data flows correctly. Enabling the policy ensures that behavioral baselines and threat detection are applied to the Salesforce logs.

Exam trap

The trap here is that candidates assume connectivity and log collection guarantee alert generation, but they overlook that the anomaly detection policy is a separate toggle that must be explicitly enabled for each connected app.

How to eliminate wrong answers

Option A is wrong because reviewing IP address ranges for Salesforce would affect access control or location-based policies, not the generation of suspicious activity alerts; the core issue is policy enablement, not network configuration. Option C is wrong because the Salesforce app connector in Microsoft Entra ID is for SSO and identity federation, not for the log collection and alerting pipeline in Defender for Cloud Apps; the connector is already verified as connected. Option D is wrong because Microsoft Entra ID P2 licensing is required for Identity Protection and Privileged Identity Management features, not for Defender for Cloud Apps anomaly detection; Defender for Cloud Apps licensing is separate and does not depend on Entra ID P2 for alert generation.

Practice this question →
264
MCQhard

Your organization uses Microsoft Sentinel with Azure Monitor Agent (AMA) to collect Windows security events. You need to collect process creation events (Event ID 4688) and include command-line information. The current Data Collection Rule (DCR) collects only basic security events. What should you modify?

A.Upgrade the AMA to the latest version.
B.Enable the 'Include command line in process creation events' policy in Windows Group Policy.
C.Modify the DCR to include Event ID 4688 in the data source.
D.Switch to the Windows Security Events via Legacy Agent connector.
AnswerB

This is the correct fix because Windows does not record command-line arguments in Event ID 4688 unless the 'Include command line in process creation events' policy is enabled. The setting is located under Computer Configuration > Administrative Templates > System > Audit Process Creation and, when set to Enabled, adds the Process Command Line field to each generated 4688 event. Without this Group Policy (or local security policy) change, Microsoft Sentinel receives the event but the command-line field remains empty, which severely degrades process-investigation and hunting value.

Why this answer

Event ID 4688 (process creation) can include command-line arguments, but this data is not captured by default. The 'Include command line in process creation events' Group Policy setting must be enabled on the Windows machines to populate the CommandLine field in the security event log. Without this policy, the AMA and DCR will collect the event but the command-line information will be empty.

Exam trap

The trap here is that candidates assume modifying the DCR to include the event ID is sufficient, but they overlook the prerequisite Windows policy that must be enabled to populate the command-line data within the event itself.

How to eliminate wrong answers

Option A is wrong because upgrading the AMA version does not enable command-line capture; the AMA already supports collecting Event ID 4688 with command-line data if the underlying event contains it. Option C is wrong because modifying the DCR to include Event ID 4688 will collect the event, but the command-line field will remain blank unless the Group Policy setting is enabled first. Option D is wrong because switching to the legacy agent connector does not solve the command-line requirement; the legacy agent also relies on the same Group Policy setting to populate the command-line data.

Practice this question →
265
MCQeasy

Your organization wants to use Microsoft Sentinel's built-in threat intelligence feeds to enrich alerts. Which data connector should you enable?

A.Office 365 connector.
B.Threat Intelligence - TAXII connector.
C.Microsoft 365 Defender connector.
D.Microsoft Defender for Cloud connector.
AnswerB

The Threat Intelligence - TAXII connector is the built-in Sentinel connector designed to pull structured threat indicators (STIX objects) from TAXII 2.0/2.1 feeds, such as those from trusted providers. It automatically ingests observables and indicators of compromise into the ThreatIntelligenceIndicator table, enabling analytics rules, threat hunting, and workbooks to reference up-to-date external threat intel. This directly meets the requirement for ingesting external threat intelligence feeds.

Why this answer

The Threat Intelligence - TAXII connector is the correct choice because it ingests threat intelligence feeds from STIX/TAXII servers, which are the standard protocol (Trusted Automated eXchange of Intelligence Indicator) used by built-in threat intelligence feeds. This connector allows Microsoft Sentinel to pull indicators of compromise (IOCs) from external threat intelligence sources, enriching alerts with context like malicious IPs, domains, or hashes.

Exam trap

The trap here is that candidates confuse 'threat intelligence feeds' with 'security alerts from Microsoft products,' leading them to choose the Microsoft 365 Defender or Defender for Cloud connectors, which ingest alerts but not the external threat intelligence indicators used for enrichment.

How to eliminate wrong answers

Option A is wrong because the Office 365 connector ingests audit logs and activity data from Exchange Online, SharePoint, and Teams, not threat intelligence feeds. Option C is wrong because the Microsoft 365 Defender connector ingests incidents and alerts from Defender products (e.g., Defender for Endpoint), not external threat intelligence feeds. Option D is wrong because the Microsoft Defender for Cloud connector ingests security alerts and recommendations from Azure and hybrid workloads, not threat intelligence feeds.

Practice this question →
266
Multi-Selecteasy

You are configuring Microsoft Sentinel analytics rules. Which THREE of the following are valid types of analytics rules in Microsoft Sentinel?

Select 3 answers
A.Fusion rule
B.Microsoft Security rule
C.Watchlist rule
D.Scheduled query rule
E.Playbook rule
AnswersA, B, D

Fusion rules are the correct answer here because they represent a built-in analytics rule type that uses advanced machine learning to correlate multiple low-severity signals across data sources, detecting multi-stage attacks in near real-time. Existing note: Fusion rules use advanced detection; this applies directly to the question's analytics rule configuration context.

Why this answer

In Microsoft Sentinel, the analytics rule types available when creating a rule include Scheduled query rules (D), which run KQL queries on a defined frequency and trigger alerts based on results; Fusion rules (A), which use Microsoft's machine-learning correlation engine to detect multi-stage attacks across signals; and Microsoft Security rules (B), which create incidents from alerts generated by Microsoft security products like Defender and Microsoft 365. These three are the standard rule types offered in the Sentinel analytics rule wizard. Watchlist rule (C) is not a rule type — watchlists are data sources used to enrich queries and can be referenced inside scheduled rules, not a standalone analytics rule.

Playbook rule (E) is also not a rule type — playbooks are Logic Apps used for automated response and are triggered by automation rules or analytics rules, not created as analytics rules themselves.

Exam trap

The trap here is that candidates confuse watchlists and playbooks with actual analytics rule types, as they are prominent features in Microsoft Sentinel but serve different purposes (data enrichment and automated response, respectively) rather than generating alerts or incidents.

Practice this question →
267
MCQhard

Your security operations center uses Microsoft Sentinel and Microsoft Defender XDR. A new type of attack involves a user receiving a malicious email that triggers a macro, which then executes PowerShell to download a payload. You need to create a detection that correlates email, process creation, and network connection events from multiple Microsoft 365 Defender sources. What should you use?

A.Advanced hunting in Microsoft 365 Defender
B.Scheduled query rule in Microsoft Sentinel
C.Custom detection rule in Microsoft 365 Defender
D.Fusion rule in Microsoft Sentinel
AnswerA

Advanced hunting is the Kusto Query Language (KQL)-based hunting environment natively embedded in Microsoft 365 Defender, allowing you to query raw, already-collected data across email, process, network, and identity tables in a single portal. Unlike Sentinel scheduled queries, it does not require you to first configure data connectors or build a Log Analytics pipeline, and it provides the full raw schema optimized for investigative hunting. This is the correct starting point for cross-domain hunting.

Why this answer

Advanced hunting in Microsoft 365 Defender is the correct choice because it allows you to write Kusto Query Language (KQL) queries that can join data across multiple tables from different Microsoft 365 Defender sources, such as EmailEvents, DeviceProcessEvents, and DeviceNetworkEvents. This enables correlation of the email receipt, macro-triggered PowerShell process creation, and subsequent network connection to a malicious IP or domain in a single query, which is exactly what the scenario requires.

Exam trap

The trap here is that candidates often confuse the scope of custom detection rules in Microsoft 365 Defender, mistakenly believing they can cross-correlate multiple data sources, when in fact they are limited to a single table or entity type, whereas advanced hunting is designed for cross-table joins.

How to eliminate wrong answers

Option B is wrong because a scheduled query rule in Microsoft Sentinel operates on data ingested into the Log Analytics workspace, which may have latency and does not natively support real-time cross-product correlation across Microsoft 365 Defender tables without additional data connectors and schema mapping. Option C is wrong because a custom detection rule in Microsoft 365 Defender is limited to a single data source (e.g., only device events or only email events) and cannot join tables from different domains like EmailEvents and DeviceProcessEvents in one rule. Option D is wrong because a Fusion rule in Microsoft Sentinel is a prebuilt, machine-learning-based correlation that detects multistage attacks by combining alerts from multiple security products, but it cannot be customized to write a specific KQL query that joins raw event tables from Microsoft 365 Defender.

Practice this question →
268
Multi-Selectmedium

Your organization uses Microsoft Defender XDR and Microsoft Sentinel. You need to ensure that high-severity incidents are automatically escalated to the on-call security engineer via Microsoft Teams. Which three components should you configure?

Select 3 answers
A.A playbook that uses a condition to check severity and then sends a Teams message.
B.An automation rule in Microsoft Sentinel that triggers on incident creation with high severity.
C.A Microsoft Teams connector in the playbook to post a message to a channel.
D.An analytics rule that sends a Teams message when a high-severity alert fires.
E.A workbook that displays high-severity incidents for manual escalation.
AnswersA, B, C

A Microsoft Sentinel playbook is an Azure Logic Apps workflow that can inspect an incident's properties, such as severity, using a condition action. Once the condition evaluates that the severity meets the threshold, a subsequent action using the Teams connector posts the message to the specified channel. This is correct because playbooks are the automation components that run conditional logic and initiate external actions.

Why this answer

A playbook in Microsoft Sentinel can contain a condition action that evaluates the incident severity. If the severity is 'High', the playbook then uses a Microsoft Teams connector to send a message to the on-call security engineer, automating the escalation process.

Exam trap

The trap here is that candidates may confuse analytics rules with automation rules, thinking an analytics rule can directly send Teams messages, when in fact analytics rules only generate alerts and require a separate automation rule and playbook to perform actions like messaging.

Practice this question →
269
MCQhard

Your Microsoft Sentinel workspace has multiple analytics rules generating incidents. You need to ensure that when an incident is created from a specific rule, a Teams message is sent to the security team. What should you configure?

A.Configure a workbook to send an email when an incident appears
B.Modify the incident creation rule in Microsoft 365 Defender
C.Add a custom analytics rule that triggers on incident creation
D.Create an automation rule that runs a playbook when the incident is created
AnswerD

An automation rule triggers a playbook on incident creation, satisfying the requirement to send a Teams message when a specific analytics rule generates an incident. The automation rule’s condition filters by the originating rule’s identifier, ensuring only incidents from that rule invoke the playbook, which uses a Teams connector to post the message.

Why this answer

Automation rules in Microsoft Sentinel can trigger on incident creation and execute a playbook, which can be configured to send a Teams message via a connector. This provides a native, low-code way to automate notifications without custom code or external tools.

Exam trap

The trap here is that candidates often confuse workbooks (visualization) or analytics rules (alert generation) with automation rules, which are the correct mechanism for triggering response actions like Teams messages on incident creation.

How to eliminate wrong answers

Option A is wrong because workbooks are visualization tools for dashboards and analytics, not for sending notifications or triggering actions like Teams messages. Option B is wrong because incident creation rules in Microsoft 365 Defender govern alert-to-incident correlation in the Defender portal, not in Sentinel, and cannot be modified to send Teams messages. Option C is wrong because custom analytics rules generate alerts from log data, not from incident creation events; they cannot directly trigger on incident creation or run playbooks.

Practice this question →
270
MCQhard

Your organization uses Microsoft Defender XDR and Microsoft Sentinel. You need to configure a solution that automatically blocks a user's account when a high-severity incident is generated. The solution must use built-in capabilities without custom code. What should you do?

A.Create an automation rule that triggers on incident creation with severity high, and runs a playbook that uses the 'Update user' action to disable the account.
B.Use a scheduled analytics rule that runs every hour and disables accounts found in the results.
C.Configure Microsoft Entra ID to automatically apply a conditional access policy blocking sign-ins when a high-severity alert is raised.
D.Create a playbook that uses the 'Run a query' action to find the device and then uses Microsoft Defender for Endpoint to isolate the device.
AnswerA

Automation rules in Microsoft Defender XDR can be configured to trigger immediately upon incident creation when the severity is high. The associated playbook (built on Azure Logic Apps) invokes the 'Update user' action, which calls the Microsoft Graph API to disable the specified Entra ID (Azure AD) account. This is the correct approach because it directly addresses the user account as the containment target and executes automatically without manual intervention.

Why this answer

Microsoft Sentinel automation rules can trigger on incident creation with a condition of severity equals high, and then run a playbook. The playbook can use the Microsoft Entra ID connector's 'Update user' action to disable the user account, which is a built-in capability requiring no custom code. This directly meets the requirement to automatically block a user's account when a high-severity incident is generated.

Exam trap

The trap here is that candidates may confuse device isolation (Microsoft Defender for Endpoint) with user account blocking (Microsoft Entra ID), or incorrectly assume that conditional access policies can be triggered by external alerts, when in fact they require specific risk signals from Microsoft Entra ID Protection.

How to eliminate wrong answers

Option B is wrong because scheduled analytics rules are designed to generate alerts based on log queries, not to perform remediation actions like disabling accounts; they lack the ability to directly execute actions on users. Option C is wrong because Microsoft Entra ID conditional access policies cannot be automatically triggered by a high-severity alert from Microsoft Sentinel or Defender XDR; they rely on risk signals from Microsoft Entra ID Protection or session controls, not external incident severity. Option D is wrong because it focuses on isolating a device using Microsoft Defender for Endpoint, which does not block a user's account; the question specifically requires blocking the user account, not the device.

Practice this question →
271
MCQeasy

Your organization uses Microsoft Sentinel and you need to ensure that incidents are automatically closed when a related playbook completes successfully. What should you configure?

A.Create an automation rule that triggers after the playbook runs and closes the incident
B.Add a 'Close incident' action in the playbook
C.Configure the analytics rule to close incidents automatically
D.Use a workbook to manually close incidents
AnswerA

An automation rule is a native Sentinel capability that can be configured with the 'When incident is updated' trigger and a condition that matches the playbook's execution context, such as a tag the playbook added. After that condition is met, the rule's 'Change status' action can set the incident to 'Closed', giving you a declarative, no-code closure path that runs immediately after the playbook finishes. This keeps the closure logic outside the Logic App, so you can modify or reuse it without redeploying the playbook.

Why this answer

Automation rules in Microsoft Sentinel can be configured to trigger after a playbook completes, and one of the available actions is to close an incident. This ensures that the incident is automatically closed only when the playbook has successfully finished, providing a reliable and automated closure mechanism without manual intervention.

Exam trap

The trap here is that candidates often think adding a 'Close incident' action inside the playbook is sufficient, but they overlook that this action closes the incident immediately when executed, not after the entire playbook completes, which can lead to premature closure if the playbook has subsequent steps that fail.

How to eliminate wrong answers

Option B is wrong because adding a 'Close incident' action directly inside the playbook would close the incident immediately when that action runs, not necessarily after the entire playbook completes successfully; if the playbook fails later, the incident would already be closed, which is incorrect. Option C is wrong because analytics rules in Microsoft Sentinel are used to generate alerts and incidents based on data queries, not to close incidents automatically after a playbook runs. Option D is wrong because workbooks are visualization tools for data analysis and reporting, not for automating incident closure; they require manual action to close incidents.

Practice this question →
272
Multi-Selectmedium

Which THREE are valid incident management features in Microsoft Sentinel?

Select 3 answers
A.Incident merging
B.Incident creation from analytics rules
C.Incident comments
D.Incident tasks
E.Incident templates
AnswersB, C, D

Analytics rules are the primary engine that creates Microsoft Sentinel incidents. When a rule's query detects a security signal and its trigger conditions are met, the rule generates an incident that appears in the Incidents blade. This incident creation is the standard path through which most detections become actionable, and it is the core incident-management feature the question asks about.

Why this answer

Incident creation from analytics rules is a core feature in Microsoft Sentinel. When an analytics rule detects a threat or suspicious activity, it automatically generates an incident, which serves as the primary object for investigation and response. This automation is fundamental to Sentinel's security orchestration, automation, and response (SOAR) capabilities.

Exam trap

The trap here is that candidates may confuse 'incident merging' with the ability to link related incidents or alerts, but Sentinel does not have a native 'merge' operation—it only supports grouping alerts under a single incident or manually linking incidents via the 'Add related incidents' action.

Practice this question →
273
MCQeasy

You are deploying an ARM template to create a saved search in a Log Analytics workspace. The template fails with an error that the resource type is not valid for Microsoft Sentinel. What is the most likely reason?

A.The query is invalid KQL.
B.The apiVersion is incorrect.
C.The resource type should be Microsoft.SecurityInsights/alertRules, not OperationalInsights/workspaces/savedSearches.
D.The name format is incorrect.
AnswerC

To create a Microsoft Sentinel analytics rule, the template must use Microsoft.SecurityInsights/alertRules as the resource type, because scheduled analytics rules are owned by the SecurityInsights resource provider, not by Log Analytics. A saved search only stores a reusable KQL query and returns results manually; it does not generate alerts or run on a schedule. Deploying Microsoft.OperationalInsights/workspaces/savedSearches therefore creates the query artifact but never satisfies the requirement to provision a Sentinel alert rule, making this the correct diagnosis.

Why this answer

Microsoft Sentinel does not use the OperationalInsights/workspaces/savedSearches resource type for its analytics rules. Instead, Sentinel uses the Microsoft.SecurityInsights/alertRules resource type to define detection rules. The ARM template fails because the resource type specified is not recognized as valid for Sentinel deployments.

Exam trap

The trap here is that candidates confuse Log Analytics saved searches with Microsoft Sentinel analytics rules, assuming both use the same resource type, when in fact Sentinel requires the Microsoft.SecurityInsights/alertRules type.

How to eliminate wrong answers

Option A is wrong because an invalid KQL query would cause a validation or runtime error, not a 'resource type not valid' error. Option B is wrong because an incorrect apiVersion would produce an 'Unsupported api-version' error, not a resource type validation error. Option D is wrong because an incorrect name format would result in a naming validation error, not a resource type error.

Practice this question →
274
MCQmedium

Your organization uses Microsoft Defender for Identity (MDI) to monitor on-premises Active Directory. You want to forward MDI alerts to Microsoft Sentinel. What should you configure?

A.Microsoft 365 Defender connector
B.Azure Advanced Threat Protection connector
C.Microsoft Defender for Cloud Apps connector
D.Microsoft Defender for Identity connector
AnswerD

The Microsoft Defender for Identity connector is the direct and supported data connector in Sentinel for ingesting identity security alerts from Microsoft Defender for Identity. It authenticates to the MDI API and pulls raw alerts—including suspected lateral movement, account enumeration, and domain controller compromise—into the SecurityAlert table with the provider name 'MicrosoftDefenderForIdentity', making it the correct choice for this organization.

Why this answer

Microsoft Defender for Identity (MDI) alerts are forwarded to Microsoft Sentinel by configuring the Microsoft Defender for Identity data connector. This connector ingests MDI security alerts, such as suspicious Kerberos activity or lateral movement attempts, directly into Sentinel for advanced correlation and incident response. The connector uses the Microsoft Graph Security API to pull alerts from the MDI service, enabling seamless integration without additional agents.

Exam trap

The trap here is that candidates confuse the Microsoft Defender for Identity connector with the Microsoft 365 Defender connector, assuming the unified portal connector is the correct way to forward MDI alerts, but the exam expects the specific product-named connector for direct integration.

How to eliminate wrong answers

Option A is wrong because the Microsoft 365 Defender connector ingests alerts from the unified Microsoft 365 Defender portal (which includes MDI, MDE, and MDCA), but it is not the specific connector for forwarding MDI alerts directly; using it would require enabling the broader M365D integration, which may include unrelated data. Option B is wrong because Azure Advanced Threat Protection (Azure ATP) is the predecessor to Microsoft Defender for Identity; the current product is MDI, and the connector name has been updated to reflect the rebranding, so selecting this option indicates confusion with the legacy name. Option C is wrong because the Microsoft Defender for Cloud Apps connector is designed to ingest alerts from Microsoft Defender for Cloud Apps (formerly Microsoft Cloud App Security), not from MDI; it handles shadow IT and SaaS app anomalies, not on-premises Active Directory threats.

Practice this question →
275
MCQmedium

Your organization uses Microsoft Defender for Identity. You need to monitor for potential lateral movement attacks using pass-the-hash techniques. Which entity type in Microsoft Defender for Identity should you focus on in the security alert timeline?

A.IP address
B.Account
C.Device
D.Computer
AnswerB

This is the correct answer because Defender for Identity's pass-the-hash detection is specifically designed to identify the identity (user account) whose NTLM hash was captured and then replayed to authenticate to another machine. The alert entry shows the compromised account as the primary entity, with supporting details such as the source and destination computers, protocols, and timestamps. The investigation should focus on resetting that account's credentials and hunting for other activities performed by it, since the account itself is the root of the lateral movement.

Why this answer

In Microsoft Defender for Identity, lateral movement attacks using pass-the-hash (PtH) techniques are tracked at the account entity level because the attacker reuses a stolen NTLM hash to authenticate as a specific user account across multiple devices. The security alert timeline groups related activities by the compromised account, enabling analysts to trace the attacker's steps from the initial breach to subsequent resource access. Focusing on the account entity provides the clearest view of the authentication attempts and successful logons that indicate PtH behavior.

Exam trap

The trap here is that candidates often choose 'Device' or 'Computer' because they think lateral movement is about moving between machines, but Microsoft explicitly tracks the stolen credential (account) as the primary entity in PtH alerts, since the attack follows the user identity, not the hardware.

How to eliminate wrong answers

Option A is wrong because an IP address is a network-layer identifier that can change or be spoofed; Defender for Identity correlates PtH alerts to the account that performed the authentication, not the ephemeral source IP. Option C is wrong because a device entity represents a specific machine, but PtH attacks follow the stolen credential (account) across multiple devices, so focusing on a single device would miss lateral movement to other hosts. Option D is wrong because 'Computer' is essentially synonymous with 'Device' in this context and suffers from the same limitation—it does not capture the cross-device credential reuse that defines PtH lateral movement.

Practice this question →
276
MCQmedium

Your organization uses Microsoft Defender for Cloud Apps. You need to create a policy that alerts when a user downloads more than 10 files from SharePoint in 5 minutes. What type of policy should you create?

A.Activity policy
B.App permissions policy
C.Session policy
D.Anomaly detection policy
AnswerA

In Microsoft Defender for Cloud Apps, an activity policy is a policy type that lets you create custom detection rules based on specific user activities, with thresholds and parameters you define. For example, you can set a threshold for multiple failed sign-ins or unusual file downloads, and it triggers alerts when those conditions are met. Unlike built-in anomaly detection which uses machine learning, activity policies are fully customizable by the administrator to match your organization's risk requirements.

Why this answer

An Activity policy in Microsoft Defender for Cloud Apps is designed to monitor and respond to specific user activities, such as file downloads from SharePoint, based on predefined thresholds. By configuring the policy with a threshold of more than 10 downloads within 5 minutes, it triggers an alert when the activity exceeds this limit, enabling detection of potential data exfiltration or anomalous user behavior.

Exam trap

The trap here is that candidates often confuse Activity policies with Anomaly detection policies, assuming any threshold-based alert is 'anomaly detection,' but Activity policies use explicit, static thresholds while Anomaly detection policies use dynamic, machine-learned baselines.

How to eliminate wrong answers

Option B is wrong because an App permissions policy governs the permissions granted to third-party apps (e.g., OAuth apps) and does not monitor real-time user activities like file downloads. Option C is wrong because a Session policy controls user sessions in real time (e.g., blocking downloads or requiring authentication) but is not designed for threshold-based alerting on cumulative activities over a time window. Option D is wrong because an Anomaly detection policy uses machine learning to detect deviations from a user's baseline behavior, not a fixed threshold like 10 downloads in 5 minutes, and would not trigger on a simple count-based rule.

Practice this question →
277
MCQmedium

You are a security operations analyst for a company that uses Microsoft Sentinel. The SOC manager wants to reduce alert fatigue by automatically closing incidents that are known false positives. The incidents are created from a custom analytics rule that generates a specific alert name, 'Suspicious PowerShell Download'. You need to create an automation rule that automatically closes these incidents with a classification of 'BenignPositive'. What should you do?

A.Use a workbook to monitor incidents with that alert name and manually close them in bulk.
B.Modify the analytics rule to set the incident severity to 'Informational' and enable automatic closure after 24 hours.
C.Create an automation rule with the condition 'Alert name' contains 'Suspicious PowerShell Download', and set the action to 'Close incident' with classification 'BenignPositive'.
D.Create a playbook that uses the 'Close incident' action and attach it to the analytics rule that generates the alert.
AnswerC

Automation rules in Microsoft Sentinel can trigger on incident creation and evaluate conditions such as alert name. Setting the action to close the incident with a specific classification directly addresses the requirement to auto-close known false positives. This reduces manual effort and ensures consistent handling of these incidents, aligning with the SOC manager's goal.

Why this answer

Automation rules in Microsoft Sentinel are designed to automate incident handling tasks such as assignment, status changes, and classification. By creating an automation rule that triggers on incident creation and uses a condition based on the alert name, you can automatically close incidents with the desired classification. This is the most efficient and native method to achieve the SOC manager's objective.

Exam trap

The trap here is assuming that playbooks are required for incident closure, but automation rules can directly close incidents without a playbook.

Practice this question →
278
MCQhard

Your organization uses Microsoft Defender for Cloud Apps to monitor SaaS application usage. You need to generate an alert when a user performs more than 50 failed login attempts in 10 minutes, and the alert must be based on a built-in anomaly detection policy. What should you do?

A.Create a data loss prevention (DLP) policy in Microsoft Purview that triggers on failed logins.
B.Deploy a session policy in Defender for Cloud Apps that blocks after 50 failed logins.
C.Configure an app connector for each SaaS app and then create a custom activity policy.
D.Enable the 'Multiple failed login attempts' anomaly detection policy in Defender for Cloud Apps.
AnswerD

The 'Multiple failed login attempts' policy is a built-in anomaly detection policy in Defender for Cloud Apps that uses machine learning/UEBA to establish a per-user or per-tenant baseline and then flags abnormal spikes in failed sign-ins. Enabling this template automatically generates alerts when the anomaly is detected, and you can tune sensitivity and notification recipients. This is the correct, native way to meet the requirement without building custom activity rules or DLP policies.

Why this answer

Microsoft Defender for Cloud Apps includes a built-in anomaly detection policy named 'Multiple failed login attempts' that specifically monitors for a high volume of failed logins from a single user within a short time window. This policy is enabled by default and can be customized to trigger alerts when the threshold (e.g., more than 50 failed attempts in 10 minutes) is exceeded, without requiring any additional configuration or custom policy creation.

Exam trap

The trap here is that candidates often confuse the purpose of session policies (which control real-time access) with anomaly detection policies (which detect behavioral patterns), leading them to incorrectly select Option B, or they assume a custom policy is always required (Option C) when a built-in policy already exists for this exact scenario.

How to eliminate wrong answers

Option A is wrong because data loss prevention (DLP) policies in Microsoft Purview are designed to detect and protect sensitive information (e.g., credit card numbers, PII) in content, not to monitor or alert on failed login attempts. Option B is wrong because session policies in Defender for Cloud Apps control real-time access and actions during a user session (e.g., blocking downloads), but they cannot be used to block after a specific number of failed logins; that logic belongs to anomaly detection policies. Option C is wrong because while app connectors are required to collect activity logs from SaaS apps, creating a custom activity policy would require manual definition of the detection logic; the question explicitly asks for a built-in anomaly detection policy, making a custom policy unnecessary and incorrect.

Practice this question →
279
MCQmedium

Refer to the exhibit. You are reviewing an Azure Security Center automation (now Microsoft Defender for Cloud) that should automatically trigger a Logic App when an alert is generated. However, the automation is not triggering. What is the most likely cause?

A.The action type is incorrect; it should be 'EventHub'
B.The logicAppResourceId is missing
C.The apiVersion is invalid
D.The automation is missing the 'triggers' property to filter on specific alert types
AnswerD

The automation is missing the `triggers` property, which is mandatory in Microsoft.Security/automations to filter on specific alert types or other conditions. Without a trigger, the automation has no event criteria to evaluate, so it will never fire the Logic App. The `triggers` property defines which alerts, severities, or states activate the action, making it essential for the rule to function.

Why this answer

Microsoft Defender for Cloud automation requires a 'triggers' property to define which alert types should invoke the Logic App. Without this property, the automation is created but never fires, as it has no conditions to match incoming alerts. The exhibit shows the automation resource is configured, but missing the triggers array means no alerts will trigger the Logic App.

Exam trap

The trap here is that candidates assume the automation will trigger on all alerts by default, but Microsoft Defender for Cloud requires explicit trigger conditions; otherwise, the automation exists but never fires.

How to eliminate wrong answers

Option A is wrong because the action type 'LogicApp' is correct for invoking a Logic App; 'EventHub' would be used to send alerts to an event hub, not to trigger a Logic App. Option B is wrong because the logicAppResourceId is present in the exhibit (it is a required property and shown in the JSON), so its absence is not the issue. Option C is wrong because the apiVersion '2019-01-01-preview' is a valid and supported version for Microsoft Defender for Cloud automation resources; an invalid apiVersion would cause a deployment error, not a silent failure to trigger.

Practice this question →
280
MCQeasy

You are configuring Microsoft Defender for Cloud Apps session controls for a SharePoint site containing sensitive data. Which condition must be met to apply real-time monitoring?

A.The SharePoint site must be added as a custom app in Defender for Cloud Apps.
B.Users must access the site through Microsoft Entra ID application proxy.
C.A browser extension must be installed on all client devices.
D.Users must be configured with Conditional Access policies from Microsoft Entra ID.
AnswerD

Session controls in Microsoft Defender for Cloud Apps are implemented through the Conditional Access session control pipeline in Microsoft Entra ID. When a user is subject to a Conditional Access policy that includes 'Use Conditional Access App Control' as a session control, the user's session is redirected through the Defender for Cloud Apps reverse proxy. Without this policy, the proxy never intercepts the request, so session-level monitoring and restrictions (e.g., download blocking) will not be enforced for SharePoint Online.

Why this answer

Microsoft Defender for Cloud Apps session controls for SharePoint require users to be routed through the Cloud App Security proxy, which is invoked by Conditional Access policies in Microsoft Entra ID. Conditional Access app controls apply session policies to traffic when users access SharePoint, enabling real-time monitoring. The Microsoft Entra ID application proxy is designed for on-premises apps, not for SaaS apps like SharePoint Online.

Therefore, the correct prerequisite is having Conditional Access policies configured.

Exam trap

Candidates often confuse the Microsoft Entra ID application proxy with the Cloud App Security proxy. For SharePoint Online session controls, Conditional Access policies trigger the Cloud App Security proxy, not the application proxy.

How to eliminate wrong answers

Option A is wrong because SharePoint is already a recognized app in Defender for Cloud Apps; adding it as a custom app is unnecessary and does not enable session controls. Option B is correct as explained. Option C is wrong because session controls for SharePoint do not require a client-side browser extension; the proxy handles interception server-side.

Option D is wrong because while Conditional Access policies are used to route traffic to the session control, they are not the condition that enables real-time monitoring—the proxy is the prerequisite.

Practice this question →
281
MCQhard

Your Microsoft Defender XDR environment is experiencing high false positive rates for a specific type of alert. You need to reduce the noise without completely disabling the alert. What is the most effective method?

A.Create a custom detection rule to tune the detection logic.
B.Create a suppression rule for the alert.
C.Use an automation rule to automatically close the false positive incidents.
D.Disable the built-in detection rule.
AnswerA

Creating a custom detection rule in Microsoft 365 Defender lets you modify the underlying KQL query, schedule, and thresholds that govern when an alert triggers. This fine-grained approach directly addresses the detection logic responsible for false positives while preserving the rule’s intended coverage. Unlike suppression or automation, this reduces alert noise at the source, ensuring only relevant events generate incidents, and it keeps the original built-in rule available for baseline comparison.

Why this answer

Creating a custom detection rule allows you to refine the detection logic by adding specific conditions, such as excluding known benign processes or IP addresses, thereby reducing false positives while retaining the alert's core detection capability. This approach directly tunes the detection mechanism rather than masking or disabling it, aligning with the goal of reducing noise without completely disabling the alert.

Exam trap

The trap here is that candidates often confuse suppression rules (which hide alerts) with tuning the detection logic itself, leading them to choose Option B because they think hiding the alert is equivalent to reducing noise, but it does not reduce the underlying detection rate or resource consumption.

How to eliminate wrong answers

Option B is wrong because a suppression rule hides the alert from the console but does not prevent the underlying detection logic from firing, meaning the false positive alert is still generated and consumes resources, just not displayed. Option C is wrong because an automation rule that automatically closes false positive incidents only addresses the aftermath (incident lifecycle) without reducing the underlying detection rate, so the alert still fires and creates unnecessary workload. Option D is wrong because disabling the built-in detection rule completely eliminates the alert, which contradicts the requirement to reduce noise without completely disabling the alert.

Practice this question →
282
MCQmedium

Your company uses Microsoft Defender for Endpoint (MDE) and Microsoft Sentinel. You need to ensure that when a device is determined to be compromised, the device is automatically isolated from the network and a Sentinel incident is updated with the isolation status. What is the most efficient way to achieve this?

A.Have the SOC analyst manually isolate the device from the MDE console and update the incident in Sentinel
B.Configure Microsoft Intune to automatically isolate the device when a compliance policy is violated
C.Use Microsoft Defender XDR conditional access to block the device
D.Create a Microsoft Sentinel automation rule with a playbook that isolates the device and updates the incident
AnswerD

A Sentinel automation rule can be configured to trigger on incident creation or update, and an associated playbook—an Azure Logic Apps workflow—calls the Microsoft Defender for Endpoint connector to perform a device isolation action while simultaneously updating the Sentinel incident with the isolation status and any analyst notes. This replaces manual steps with orchestration, enabling a consistent and auditable response that eliminates the delay separating detection from containment. The rule can be scoped by severity, entity type, or other conditions, and the playbook can also add a comment to the incident so the SOC can track that the isolation was executed automatically.

Why this answer

It leverages Microsoft Sentinel's automation capabilities to respond to security incidents without manual intervention. By creating an automation rule that triggers a playbook (an Azure Logic Apps workflow), you can automatically isolate a compromised device via Microsoft Defender for Endpoint APIs and simultaneously update the Sentinel incident with the isolation status. This provides the most efficient, end-to-end automated response directly within the security operations workflow.

Exam trap

The trap here is that candidates may confuse Microsoft Intune compliance policies or conditional access with automated incident response actions, not realizing that only a Sentinel automation rule with a playbook can directly orchestrate both device isolation and incident update in a single, efficient workflow.

How to eliminate wrong answers

Option A is wrong because manual isolation and incident update are inefficient, error-prone, and do not meet the requirement for an automated response. Option B is wrong because Microsoft Intune compliance policies are designed for device configuration and health checks, not for real-time incident response to a compromise detected by Defender for Endpoint; Intune cannot trigger isolation based on a Defender alert. Option C is wrong because Microsoft Defender XDR conditional access controls access to cloud apps based on risk, but it does not perform network isolation of a device or update a Sentinel incident; it is a conditional access policy, not an automated response action.

Practice this question →
283
MCQmedium

Your security team receives alerts from Microsoft Defender for Cloud. You need to configure automated response to remediate a specific alert type. What should you create in Microsoft Sentinel?

A.An analytics rule
B.A workbook
C.A watchlist
D.An automation rule
AnswerD

An automation rule is the correct answer because it is specifically designed to centralize incident-handling automation in Microsoft Sentinel. When a Defender alert triggers incident creation, an automation rule can evaluate conditions and execute actions such as running an Azure Logic Apps playbook, assigning ownership, sending tags, or changing severity. Unlike analytics rules—which only detect—automation rules are incident-based triggers that orchestrate the response workflow. This directly satisfies the goal of automating responses to alerts.

Why this answer

In Microsoft Sentinel, automation rules are the correct mechanism to define automated responses triggered by alerts, including those from Microsoft Defender for Cloud. They allow you to run playbooks, change incident severity, assign ownership, or add comments when a specific alert type fires, enabling remediation without manual intervention.

Exam trap

The trap here is that candidates often confuse 'automation rule' with 'analytics rule', mistakenly thinking the rule that generates the alert can also handle the response, but Sentinel separates detection (analytics rules) from response (automation rules).

How to eliminate wrong answers

Option A is wrong because analytics rules are used to generate alerts or incidents from raw data (e.g., querying Log Analytics), not to automate responses to existing alerts. Option B is wrong because workbooks are interactive dashboards for visualizing data, not for triggering automated remediation actions. Option C is wrong because watchlists are collections of data (e.g., IP addresses or hostnames) used for correlation or filtering in queries, not for executing response actions.

Practice this question →
284
MCQmedium

Refer to the exhibit. You are creating a scheduled analytics rule in Microsoft Sentinel using the ARM template snippet. The rule runs every 5 minutes and queries the last 5 minutes of data. The rule is not generating alerts even though malware detections are occurring. What is the most likely issue?

A.The queryPeriod and queryFrequency are the same, causing overlapping windows.
B.The triggerThreshold is set to 0, which should always trigger.
C.The ARM template is missing the required 'kind' property.
D.The table DeviceEvents is not ingested into the Log Analytics workspace.
AnswerD

The rule queries DeviceEvents, so if that table is never ingested into the Log Analytics workspace, the query returns no rows and no alerts fire despite real malware activity. Missing ingestion is the constraint that silently breaks detection.

Why this answer

DeviceEvents is a table from Microsoft Defender for Endpoint, but it is not automatically available in Microsoft Sentinel's Log Analytics workspace. The data connector for Microsoft Defender for Endpoint must be configured and the table must be mapped to Sentinel's workspace. Without this, the query runs against an empty table, returning no results, so the rule never triggers (even with triggerThreshold of 0).

Option A is incorrect: having queryPeriod and queryFrequency both set to 5 minutes is standard for a rule that runs every 5 minutes looking at the last 5 minutes; it does not cause overlapping windows. Option B is incorrect: triggerThreshold of 0 means any result should trigger an alert, but if there are no results due to missing data, the rule won't fire. Option C is incorrect: the ARM template snippet would include the required 'kind' property for a scheduled rule; its absence is not the issue here.

Exam trap

Candidates may assume that any table referenced in a query is automatically available in the Log Analytics workspace, but custom or advanced hunting tables from Microsoft Defender require explicit data connectors to be enabled.

Practice this question →
285
MCQmedium

Your organization uses Microsoft Defender for Endpoint (MDE) and Microsoft Sentinel. You have configured the Microsoft Defender for Endpoint connector in Sentinel to ingest alerts and incidents. The security team wants to automatically create a Sentinel incident when an MDE alert of severity 'High' or 'Critical' is generated. Additionally, they want to assign the incident to a specific SOC tier based on the alert title. For example, if the alert title contains 'Ransomware', assign to Tier 3; otherwise assign to Tier 2. You need to implement this automation efficiently. You have already enabled the connector and verified that MDE alerts are flowing into Sentinel. What is the best approach?

A.Create an automation rule that triggers when an incident is created with a condition on alert severity, and set the owner to the appropriate group. Then create another automation rule for 'Ransomware' alerts.
B.Configure an automation rule with a condition on the alert title using KQL, then set the owner.
C.Create an automation rule that triggers on incident creation for High and Critical severity. The rule runs a playbook that uses Logic Apps to parse the alert title and assign the incident to the appropriate tier using the Microsoft Sentinel connector 'Update incident' action.
D.Modify the Microsoft Defender for Endpoint analytics rule to include a custom mapping that assigns the incident to a specific owner based on the alert title.
AnswerC

An automation rule fires on incident creation filtered to High and Critical severity, then invokes a playbook whose Logic Apps condition parses the alert title and assigns the tier via the Update incident action, meeting both routing requirements.

Why this answer

The requirement is conditional logic based on alert title ('Ransomware' → Tier 3, otherwise Tier 2), which cannot be expressed with simple automation-rule conditions alone. An automation rule can trigger on incident creation and filter by severity, then invoke a playbook; the playbook (Logic Apps) can parse the alert title and use the Microsoft Sentinel 'Update incident' action to set the owner to the correct tier. This combines Sentinel's native automation rule engine with Logic Apps' flexible conditional branching.

Exam trap

SC-200 often tests the boundary between automation rules and playbooks — candidates assume automation rules can do conditional string parsing or run KQL, but only playbooks (Logic Apps) can execute that kind of branching logic.

How to eliminate wrong answers

Option A is wrong because automation rules cannot natively branch on substring matching of the alert title to assign different owners — you would need two rules and even then the 'otherwise' fallback logic is awkward and error-prone. Option B is wrong because automation rule conditions do not support KQL queries against alert properties; conditions are limited to simple property comparisons (severity, title contains, etc.), and 'contains' alone cannot implement the if/else tier assignment. Option D is wrong because MDE analytics rules in Sentinel do not support custom owner mapping based on alert title — entity mapping and incident creation settings do not include dynamic owner assignment logic.

Practice this question →
286
MCQhard

You are the security operations lead for a multinational company using Microsoft Sentinel. You have deployed a custom analytics rule that uses a KQL query to detect anomalous outbound network traffic. The rule runs every hour and looks back 24 hours. Recently, the rule has been generating a high number of false positives. You need to tune the rule to reduce false positives without missing genuine threats. The rule currently triggers when the count of outbound connections to a single IP exceeds 100 in an hour. You analyze the data and find that legitimate cloud services often trigger the rule. What should you do?

A.Disable the rule and create a new one with a different query.
B.Increase the threshold to 200 connections per hour.
C.Configure a suppression rule to automatically close incidents from those IPs.
D.Modify the KQL query to exclude traffic to known benign IP ranges.
AnswerD

Excluding known benign IP ranges directly addresses the false positives caused by legitimate cloud services, since those destinations are the recurring trigger. Filtering them within the KQL query preserves detection of genuine anomalous outbound traffic to other IPs, satisfying the requirement to reduce noise without missing real threats.

Why this answer

The most effective way to reduce false positives without missing genuine threats is to refine the KQL query to exclude traffic to known benign IP ranges, such as those belonging to legitimate cloud services. This preserves the detection logic for suspicious IPs while eliminating noise from trusted sources. It is a targeted tuning approach that maintains threat coverage.

Exam trap

SC-200 often tests the difference between tuning (refining the query) and suppressing (hiding alerts) — candidates must recognize that suppression can create blind spots, while query refinement is the preferred method.

How to eliminate wrong answers

Option A is wrong because disabling the rule and creating a new one with a different query is disruptive and may lose detection capability; tuning is preferred over replacement. Option B is wrong because simply increasing the threshold to 200 connections per hour is a blunt adjustment that could allow genuine threats with 150 connections to slip through, and it does not address the root cause of benign cloud service traffic. Option C is wrong because configuring a suppression rule to automatically close incidents from those IPs would suppress alerts even if those IPs later become malicious, creating a blind spot.

Practice this question →
287
MCQhard

Your organization uses Microsoft Defender for Cloud with enhanced security features enabled. You need to ensure that all Azure subscriptions are covered by a single Defender for Cloud policy that enforces specific security standards. The policy must be automatically applied to new subscriptions. What should you do?

A.Enable the default Defender for Cloud policy from the Azure portal.
B.Manually assign the policy to each subscription using PowerShell.
C.Create a custom policy initiative and assign it to the root management group.
D.Configure the security contact email for each subscription.
AnswerC

Create a custom policy initiative—a group of custom policy definitions that expresses your organization's security requirements—and assign it at the root management group scope. Management-group assignments are inherited by every descendant management group and subscription, including subscriptions created later, giving tenant-wide enforcement from a single assignment. Defender for Cloud's regulatory compliance feature recognizes this custom initiative as a compliance standard and displays its results in the dashboard.

Why this answer

Assigning a custom policy initiative to the root management group ensures that the policy is inherited by all subscriptions under that management group, including new subscriptions as they are added. This approach enforces consistent security standards across the entire Azure environment without requiring manual intervention for each subscription.

Exam trap

The trap here is that candidates may think enabling the default Defender for Cloud policy (Option A) is sufficient for all subscriptions, but that only applies to the current subscription and does not enforce a custom standard or automatically cover new subscriptions.

How to eliminate wrong answers

Option A is wrong because enabling the default Defender for Cloud policy from the Azure portal only applies the built-in security policy to the current subscription, not to all subscriptions automatically, and does not enforce a single custom standard across multiple subscriptions. Option B is wrong because manually assigning the policy to each subscription using PowerShell does not automatically cover new subscriptions; each new subscription would require a separate manual assignment, defeating the requirement for automatic application. Option D is wrong because configuring the security contact email for each subscription only sets notification recipients for security alerts, not the enforcement of security standards or policies.

Practice this question →
288
MCQeasy

Your organization uses Microsoft Sentinel. You need to provide a SOC analyst with the ability to create and modify incident comments but not delete incidents. Which role should you assign?

A.Global Administrator
B.Microsoft Sentinel Contributor
C.Microsoft Sentinel Reader
D.Microsoft Sentinel Responder
AnswerD

Microsoft Sentinel Responder grants full incident management — assigning, changing status, and creating or editing comments — but cannot delete incidents, which only the Contributor role permits. This matches the analyst's required permissions exactly while enforcing least privilege.

Why this answer

The Microsoft Sentinel Responder role is designed for SOC analysts who need to manage incidents, including adding and modifying comments, but not delete incidents. Microsoft Sentinel Contributor can delete incidents, so it is too permissive. Microsoft Sentinel Reader is read-only and cannot create or modify comments.

Global Administrator has full access to all resources, including the ability to delete incidents, which is excessive for this requirement.

Practice this question →
289
MCQeasy

Your organization is implementing Microsoft Sentinel. You need to ensure that security events from AWS CloudTrail are collected. What should you configure?

A.Azure Policy to audit AWS resources.
B.AWS S3 connector in Sentinel.
C.Microsoft Defender for Cloud to monitor AWS.
D.A REST API connector to call CloudTrail API.
AnswerB

The AWS S3 connector in Microsoft Sentinel is the native, documented data connector specifically built to ingest AWS CloudTrail logs. It works by configuring an Amazon S3 bucket to receive CloudTrail logs, with Simple Queue Service (SQS) providing real-time notifications that Sentinel's connector consumes to pull log data. This connector automatically maps CloudTrail records to the AWSCloudTrail table, enabling standard KQL queries, analytics rules, and incident handling. Because it is purpose-built for this exact use case, it is the correct and recommended solution.

Why this answer

The AWS S3 connector in Microsoft Sentinel is the correct solution because AWS CloudTrail logs are stored in an S3 bucket. Sentinel's native AWS S3 connector ingests these logs by polling the S3 bucket for new CloudTrail events, parsing them into the Sentinel workspace for security monitoring. This is the designated method for collecting CloudTrail data into Sentinel, as documented by Microsoft.

Exam trap

The trap here is that candidates may confuse Microsoft Defender for Cloud's AWS monitoring capabilities (which focus on security posture and alerts) with the log ingestion needed for Sentinel, leading them to choose Option C instead of the dedicated S3 connector.

How to eliminate wrong answers

Option A is wrong because Azure Policy is used to enforce compliance rules on Azure resources, not to ingest logs from external cloud providers like AWS. Option C is wrong because Microsoft Defender for Cloud can monitor AWS resources via AWS Security Hub integration, but it does not directly collect CloudTrail logs into Sentinel; Sentinel requires the S3 connector for that purpose. Option D is wrong because while CloudTrail has a REST API, Sentinel does not have a generic REST API connector for CloudTrail; the specific S3 connector is designed to handle the batch log delivery from S3, not real-time API calls.

Practice this question →
290
MCQeasy

As a security operations analyst, you receive an alert from Microsoft Defender for Identity about a suspicious Kerberos activity. You need to investigate the alert and determine if it is a true positive. What should you use to pivot from the alert to the related user and device timeline?

A.Search for the user in Azure AD audit logs.
B.Open the alert in Microsoft Sentinel and use the investigation graph.
C.From the Microsoft 365 Defender portal, open the alert and click on the user or device name to view their timeline.
D.Use the Microsoft 365 compliance portal to run an eDiscovery search.
AnswerC

The Microsoft 365 Defender portal is the native home for Defender for Identity alerts, and the alert page includes a direct link to the affected user's or device's entity page. Clicking that name opens a comprehensive timeline of that entity's activities, including LDAP queries, Kerberos ticket requests, remote logons, directory object modifications, and any other related security alerts. This timeline lets you quickly trace the attack chain, determine the full blast radius, and pivot to associated resources without having to manually query other logs or export data.

Why this answer

In the Microsoft 365 Defender portal, when you open a Microsoft Defender for Identity alert, you can directly click on the user or device name to pivot to their timeline. This timeline provides a consolidated view of activities, including Kerberos events, authentication attempts, and other related signals, enabling you to quickly assess whether the suspicious Kerberos activity is a true positive without leaving the portal.

Exam trap

The trap here is that candidates may assume they need to use a separate tool like Microsoft Sentinel or Azure AD audit logs for deeper investigation, but the exam tests the knowledge that the Microsoft 365 Defender portal provides a built-in, integrated timeline for direct pivoting from Defender for Identity alerts.

How to eliminate wrong answers

Option A is wrong because Azure AD audit logs focus on directory-level administrative actions (e.g., user creation, password changes) and do not include detailed Kerberos authentication events or device timelines needed for this investigation. Option B is wrong because while Microsoft Sentinel has an investigation graph, the question specifically asks about pivoting from a Defender for Identity alert; the native integration within the Microsoft 365 Defender portal provides the most direct and efficient path to the user and device timeline without requiring a separate SIEM. Option D is wrong because the Microsoft 365 compliance portal and eDiscovery are designed for legal and compliance searches (e.g., mailbox, SharePoint content), not for real-time security event investigation of Kerberos activity.

Practice this question →
291
MCQmedium

You are a security analyst for a multinational company with Microsoft Sentinel deployed in a central workspace. You need to grant a team of analysts in the European branch the ability to view incidents and run queries, but they should not be able to modify analytics rules or data connectors. The team already has Microsoft Sentinel Reader role assigned. However, they report that they cannot run KQL queries in the Logs blade. You need to provide the minimum additional permissions. What should you do?

A.Assign the Log Analytics Contributor role to the team on the Sentinel workspace.
B.Assign the Microsoft Sentinel Contributor role to the team on the Sentinel workspace.
C.Assign the Log Analytics Reader role to the team on the Sentinel workspace.
D.Assign the Reader role to the team on the Sentinel workspace.
AnswerC

The Log Analytics Reader role grants the ability to read all data in the Log Analytics workspace and, crucially, to execute KQL queries against that data. Because Microsoft Sentinel stores its security logs in a Log Analytics workspace, this role provides exactly the query capability the hunting team needs. It is a read-only role that does not allow modifications to the workspace or its settings, making it the least-privileged assignment that satisfies the requirement.

Why this answer

The Microsoft Sentinel Reader role grants read access to Sentinel data, including incidents, but does not include the ability to run KQL queries in the Logs blade because that requires read permissions on the underlying Log Analytics workspace. The Log Analytics Reader role provides the necessary read access to log data and the ability to execute queries without granting write permissions to analytics rules or data connectors, fulfilling the requirement with minimal privileges.

Exam trap

The trap here is that candidates assume the Microsoft Sentinel Reader role is sufficient for all read operations, but they overlook that running KQL queries in the Logs blade requires separate Log Analytics read permissions, which is a common cross-service dependency tested in SC-200.

How to eliminate wrong answers

Option A is wrong because Log Analytics Contributor role includes write permissions to the Log Analytics workspace, which would allow modifying data connectors and other settings, exceeding the required minimal permissions. Option B is wrong because Microsoft Sentinel Contributor role grants full write access to Sentinel resources, including analytics rules and data connectors, which violates the requirement that the team should not be able to modify these components. Option D is wrong because the Reader role at the Sentinel workspace level does not include the Log Analytics Reader permissions needed to run KQL queries in the Logs blade; it only provides read access to Sentinel-specific resources like incidents and workbooks.

Practice this question →
292
MCQeasy

You are managing a Microsoft Sentinel environment. An analyst reports that a scheduled analytics rule is not generating alerts. The rule has been enabled for a week. What is the most likely cause?

A.The rule is disabled due to a cost threshold.
B.The rule has a short lookback period that misses data.
C.The rule's query does not match any events in the workspace.
D.The rule is configured as a real-time rule instead of scheduled.
AnswerC

A scheduled analytics rule only raises an alert when its KQL query returns one or more rows. If the query's conditions, such as event type, severity, or threshold, do not match any ingested data, the rule runs successfully but remains silent. Since it has been running for a week, the most probable reason for zero alerts is that no events satisfy the query. Test the query manually in Log Analytics over the same lookback period to confirm.

Why this answer

The most likely cause is that the rule's query does not match any events in the workspace. Since the rule has been enabled for a week, if the query logic is correct and data exists, alerts should have been generated. The absence of alerts strongly indicates that the query returns zero results, which is a common issue when the KQL query references tables, columns, or conditions that do not exist in the ingested data.

Exam trap

The trap here is that candidates may assume a rule is disabled or misconfigured due to cost or timing, but the core issue is almost always that the query itself does not match any data, which is the most straightforward and common cause for a rule not generating alerts.

How to eliminate wrong answers

Option A is wrong because Microsoft Sentinel does not disable scheduled analytics rules due to a cost threshold; cost management is handled through data ingestion retention and pricing tiers, not by disabling rules. Option B is wrong because a short lookback period would only affect how far back the rule looks for data, but if the rule has been enabled for a week, it would still evaluate recent data within that lookback window; the issue is not about missing data but about the query not matching any events. Option D is wrong because there is no 'real-time rule' type in Microsoft Sentinel; all analytics rules are either scheduled or Microsoft Security incident creation rules, and a scheduled rule cannot be misconfigured as a real-time rule.

Practice this question →
293
MCQmedium

You are a Microsoft Sentinel administrator for a company that ingests Microsoft Defender XDR incidents into Microsoft Sentinel. You create an automation rule to automatically assign incidents to a specific analyst. The rule uses the condition 'Analytics rule name contains 'Suspicious'' and the action 'Assign owner'. After deployment, you notice that incidents from Microsoft Defender XDR are not being assigned. What is the most likely cause?

A.Automation rules in Microsoft Sentinel can only be triggered by incidents created by analytics rules, not by incidents ingested from Microsoft Defender XDR.
B.The automation rule must be enabled for each Microsoft Defender XDR connector separately.
C.Automation rules require a playbook to be attached to perform the assignment action.
D.The condition 'Analytics rule name' is not populated for incidents that originate from Microsoft Defender XDR, so the rule condition never matches.
AnswerD

Incidents created by Microsoft Defender XDR integration do not have an associated analytics rule name because they are not generated by a Sentinel analytics rule. The 'Analytics rule name' property is only populated for incidents created by scheduled or near-real-time analytics rules. Therefore, the condition fails to match, and the assignment action never executes. Using a condition like 'Product name' or 'Title' would be appropriate instead.

Why this answer

The automation rule failed because incidents from Microsoft Defender XDR do not have an 'Analytics rule name' property. That property is only set for incidents created by Sentinel analytics rules. To assign these incidents, the condition should be based on a property that exists, such as 'Product name' or 'Title'.

This is a common pitfall when mixing incidents from different sources.

Exam trap

The trap here is assuming that all incidents have the same properties, when in fact incidents from different sources may lack certain fields like 'Analytics rule name'.

Practice this question →
294
MCQmedium

You are investigating a security incident in Microsoft Sentinel. You need to preserve a snapshot of the investigation including comments, bookmarks, and entities for future reference. What should you do?

A.Create an automation rule to tag the incident
B.Create a bookmark with the relevant data
C.Add the entities to a watchlist
D.Close the incident as a false positive
AnswerB

Creating a bookmark in Microsoft Sentinel captures a snapshot of a hunting query result, including the selected rows, entities, and any comments you add, and links it to the incident. Bookmarks persist the evidence as a standalone artifact that can be re-opened, shared, and investigated, making them the correct choice for preserving the incident data at a specific time. Unlike other options, a bookmark maintains the contextual provenance of how you found the evidence.

Why this answer

Bookmarks in Microsoft Sentinel allow you to preserve a snapshot of an investigation, including comments, bookmarks, and entities, for future reference. Bookmarks capture the state of an investigation at a specific point in time, enabling you to revisit and share the context later.

Exam trap

The trap here is that candidates often confuse bookmarks with watchlists or automation rules, thinking that static data storage or automated actions can preserve an investigation snapshot, but only bookmarks capture the full interactive context including comments and entities.

How to eliminate wrong answers

Option A is wrong because automation rules are used to automate incident response actions (e.g., assigning, changing severity, or triggering playbooks) and do not preserve a snapshot of investigation data like comments and entities. Option C is wrong because watchlists are used to store static data for correlation and matching against events, not to capture a dynamic investigation snapshot with comments and bookmarks. Option D is wrong because closing an incident as a false positive dismisses it without preserving the investigation context; it does not create a persistent record of comments, bookmarks, or entities.

Practice this question →
295
MCQeasy

Your organization uses Microsoft Defender for Office 365. You need to ensure that when a user reports a phishing email, the email is automatically analyzed and remediated. What should you configure?

A.Configure User Reported Message settings to use the built-in reporting tool and automated investigation.
B.Configure Anti-Phish policy to move messages to quarantine.
C.Enable Safe Attachments policy.
D.Enable Safe Links policy.
AnswerA

User Reported Message settings route user-reported phishing into the built-in reporting tool, which feeds automated investigation and response so the message is analysed and remediated without manual triage, meeting the automatic analysis and remediation requirement.

Why this answer

Configuring User Reported Message settings in Microsoft 365 Defender to use the built-in reporting tool and enable automated investigation ensures that when a user reports a phishing email, it is routed to Microsoft, analyzed, and remediated automatically (e.g., moved to quarantine, soft-deleted, or blocked for other recipients). This is the purpose-built feature for the scenario. It ties the user report directly into the automated investigation and response (AIR) pipeline.

Exam trap

The trap is selecting Safe Links or Safe Attachments because they are phishing-related controls — but the question is about user-reported messages triggering automated analysis and remediation, which is the User Reported Message settings feature.

How to eliminate wrong answers

Option B is wrong because an anti-phish policy moves messages to quarantine based on filter verdicts — it does not act on user-reported messages and does not provide the automated analysis/remediation workflow described. Option C is wrong because Safe Attachments detonates attachments in a sandbox at delivery time; it is a preventive control, not a user-report-driven remediation mechanism. Option D is wrong because Safe Links rewrites and checks URLs at click time; like Safe Attachments, it is preventive and does not process user-reported emails for automated investigation.

Practice this question →
296
MCQhard

You are responsible for Microsoft Sentinel pricing. You notice that data ingestion costs are high due to verbose logs from Windows security events. You need to reduce costs while still collecting critical security events. What should you do?

A.Use Common Event Format (CEF) connector instead of Windows Events
B.Change the table plan to Basic Logs
C.Increase the workspace retention period to archive warm data
D.Configure Windows Security Events via AMA connector with event filtering
AnswerD

Configuring Windows Security Events via the Azure Monitor Agent (AMA) connector with a data collection rule is the correct approach because it filters event IDs and event levels at the source before the data is transmitted to the workspace. You can select only high-signal security events such as 4624/4625 (logon) and 4688 (process creation) and suppress verbose or unneeded event categories, reducing billable ingestion volume. This directly lowers the Log Analytics/Sentinel ingestion cost while still keeping the security telemetry your analytics rules require.

Why this answer

The Azure Monitor Agent (AMA) connector for Windows Security Events allows granular filtering of event IDs and levels, enabling you to collect only critical security events (e.g., 4624, 4625) while excluding verbose logs like Event ID 5156 (Windows Filtering Platform permit connections). This reduces ingestion volume and cost without losing essential security visibility.

Exam trap

The trap here is that candidates confuse 'reducing costs' with 'changing retention' (Option C) or 'using a different connector' (Option A), when the real solution is to filter data at the source using the AMA's event filtering capability, which directly addresses ingestion volume.

How to eliminate wrong answers

Option A is wrong because the Common Event Format (CEF) connector is used for syslog-based appliances (e.g., firewalls, network devices), not for Windows Security Events; it does not reduce costs from Windows event logs. Option B is wrong because changing the table plan to Basic Logs reduces the log retention and query capabilities (no KQL full-text search, limited analytics), which is unsuitable for security events that require advanced hunting and detection rules. Option C is wrong because increasing the workspace retention period to archive warm data actually increases storage costs (warm data is interactive, not archived) and does not reduce ingestion costs; archiving cold data would reduce costs but is not relevant to ingestion volume.

Practice this question →
297
MCQeasy

Your organization uses Microsoft Sentinel to manage security incidents. The security team wants to automatically close low-severity incidents after 24 hours if no activity has occurred. Which feature should you use?

A.Playbooks
B.Automation rules
C.Watchlists
D.Analytics rules
AnswerA

Playbooks automate response actions triggered by alerts, but they lack a native scheduling mechanism to evaluate elapsed inactivity time and close incidents after a fixed 24-hour window. This scenario requires a time-based automation rule, which is provided by Microsoft Sentinel’s automation rules with expiry conditions. Playbooks are tempting because they can close incidents on-demand when invoked, and would be correct for orchestrating complex, multi-step responses to a specific alert type.

Why this answer

A playbook (Azure Logic App) built on a Recurrence trigger — not an incident trigger — is the correct mechanism. Automation rules only fire in response to a Sentinel incident event (created/updated) and have no built-in condition to detect elapsed inactivity time; they cannot poll on a schedule. A recurrence-triggered playbook, by contrast, can run periodically (e.g., hourly), query the Sentinel incidents REST API for Low-severity incidents that have had no updates in the last 24 hours, and close them automatically — this is Microsoft's documented pattern for automated stale-incident closure.

Exam trap

Candidates often confuse automation rules with playbooks, assuming automation rules can handle time delays. However, automation rules only perform immediate actions based on incident triggers; time-based scenarios require playbooks.

How to eliminate wrong answers

Option A is wrong because playbooks are automated workflows that run in response to alerts or incidents, but they require a trigger from an automation rule or analytics rule and do not natively support time-based conditions like 'after 24 hours of no activity' without custom logic. Option C is wrong because watchlists are collections of data (e.g., IP addresses, hostnames) used for correlation or enrichment in analytics rules, not for automating incident closure based on time or activity. Option D is wrong because analytics rules generate alerts or incidents based on query results from log data; they do not manage the lifecycle of existing incidents or apply time-based closure actions.

Practice this question →
298
MCQhard

Your SOC uses Microsoft Sentinel and Microsoft Defender for Identity (MDI). You have configured MDI to send alerts to Microsoft 365 Defender. From there, Microsoft Sentinel ingests the alerts via the Microsoft 365 Defender connector. You want to ensure that when MDI detects a suspicious activity, the incident in Microsoft Sentinel is created within 5 minutes. Which factors should you consider?

A.The latency is determined solely by the MDI sensor health and network speed.
B.The incident creation time is controlled by the Microsoft Defender for Cloud Apps connector.
C.The incident will be created within 5 minutes because MDI writes directly to Microsoft Sentinel.
D.The latency depends on the Microsoft 365 Defender connector's polling interval and the analytics rule's frequency.
AnswerD

The end-to-end latency for MDI incident creation in Microsoft Sentinel depends on two sequential factors: the Microsoft 365 Defender connector's polling interval, which determines how frequently alerts are fetched from the unified API, and the frequency of the analytics rule that converts those alerts into incidents. The connector typically polls every few minutes, but that interval is not instant, and the scheduled rule runs on its own cadence (e.g., every 5-15 minutes) based on the configured frequency. Therefore, the total delay is the sum of these intervals, not a fixed duration, and is the primary driver of when the incident appears.

Why this answer

The incident creation latency in this architecture depends on two factors: the Microsoft 365 Defender connector's polling interval (which retrieves alerts from Microsoft 365 Defender) and the frequency of the Microsoft Sentinel analytics rule that creates incidents from those ingested alerts. Even if MDI sends alerts quickly to Microsoft 365 Defender, the connector polls at a configurable interval (default every 5 minutes), and the analytics rule runs on its own schedule (typically every 5 minutes). Thus, the total time to incident creation is the sum of these intervals, not a fixed 5 minutes.

Exam trap

The trap here is that candidates assume MDI alerts flow directly into Microsoft Sentinel with minimal delay, overlooking the polling-based Microsoft 365 Defender connector and the scheduled analytics rule that together introduce cumulative latency.

How to eliminate wrong answers

Option A is wrong because latency is not solely determined by MDI sensor health and network speed; the Microsoft 365 Defender connector's polling interval and analytics rule frequency are the primary bottlenecks. Option B is wrong because the Microsoft Defender for Cloud Apps connector is not involved in this alert flow; MDI alerts go to Microsoft 365 Defender, not directly to Defender for Cloud Apps. Option C is wrong because MDI does not write directly to Microsoft Sentinel; alerts flow through Microsoft 365 Defender and the Microsoft 365 Defender connector, which introduces polling and rule processing delays.

Practice this question →
299
MCQmedium

You are a security operations analyst at a company that uses Microsoft Sentinel. You have enabled User and Entity Behavior Analytics (UEBA) to detect anomalies. A new alert fires indicating a user is logging in from an unusual location. However, the user is a known traveler. How can you reduce false positives without disabling the UEBA rule?

A.Add the user to the entity behavior analytics exclusion list.
B.Disable the UEBA anomaly rule for unusual locations.
C.Change the alert severity to Informational.
D.Increase the lookback period for the anomaly detection.
AnswerA

Adding the user to the entity behavior analytics exclusion list in Microsoft 365 Defender suppresses UEBA anomaly alerts for that specific entity only, leaving the 'unusual location' detection rule active for all other users. This is the targeted, least-privilege response for a legitimate traveler because it preserves the rule's ability to catch genuine account-compromise anomalies while preventing false positives tied to the known user's expected foreign sign-ins.

Why this answer

Microsoft Sentinel's UEBA allows you to add specific users to an entity behavior analytics exclusion list. This prevents the UEBA engine from generating alerts for that user's anomalous activities, such as logins from unusual locations, without disabling the underlying detection rule. This approach maintains detection coverage for other users while suppressing false positives for known travelers.

Exam trap

The trap here is that candidates may think disabling the rule or changing severity is the correct approach, but Microsoft specifically tests the ability to use entity-level exclusions to handle known exceptions without compromising overall detection coverage.

How to eliminate wrong answers

Option B is wrong because disabling the UEBA anomaly rule for unusual locations would stop all alerts for that anomaly type across all users, not just the known traveler, which is an overly broad and disruptive solution. Option C is wrong because changing the alert severity to Informational does not prevent the alert from being generated; it only changes its classification, so false positives would still clutter the security operations queue. Option D is wrong because increasing the lookback period for anomaly detection would make the UEBA model consider older baseline data, potentially making the detection less sensitive to recent changes and not specifically addressing the false positive for a single known traveler.

Practice this question →
300
MCQmedium

Your organization, Fabrikam, has a hybrid environment with on-premises Active Directory and Microsoft Entra ID. You are using Microsoft Sentinel and Microsoft Defender XDR. You have enabled Microsoft Defender for Identity (MDI) to protect on-premises Active Directory. Recently, you received an incident in Microsoft Sentinel indicating a potential DCSync attack from a domain controller. The incident was generated from an MDI alert. You need to investigate the incident and determine if the attack was successful. You have the following options: A) Use the Microsoft Sentinel incident investigation graph to view entities and relationships. Then query the IdentityDirectoryEvents table for the domain controller to see if any directory replication requests were made. B) Use the Microsoft Defender XDR advanced hunting to query the IdentityLogonEvents table for the domain controller. C) Use the Microsoft Sentinel workbook for MDI to visualize the attack timeline. D) Use the Microsoft Defender for Cloud Apps activity log to review the domain controller's activities. Which option should you choose?

A.Use the Microsoft Sentinel workbook for MDI to visualize the attack timeline.
B.Use the Microsoft Defender XDR advanced hunting to query the IdentityLogonEvents table for the domain controller.
C.Use the Microsoft Sentinel incident investigation graph to view entities and relationships. Then query the IdentityDirectoryEvents table for the domain controller to see if any directory replication requests were made.
D.Use the Microsoft Defender for Cloud Apps activity log to review the domain controller's activities.
AnswerC

To confirm the DCSync attack, first open the incident investigation graph to see how the compromised entity relates to the domain controller and other machines. Then query the IdentityDirectoryEvents table for the domain controller, filtering on action types that correspond to directory replication, such as the GetNCChanges operation. This table, sourced from Microsoft Defender for Identity, records replication requests and is exactly the data required to prove that an account attempted to replicate credentials from the domain controller. The investigation graph guides you to the right entity (the DC) and shows the attack path, while the IdentityDirectoryEvents query provides the forensic evidence.

Why this answer

A DCSync attack involves an attacker impersonating a domain controller to request directory replication via the MS-DRSR protocol. The IdentityDirectoryEvents table in Microsoft Defender for Identity captures directory service replication activities, including the DirectoryReplication request action. Querying this table for the domain controller allows you to confirm if unauthorized replication requests were made, directly indicating a successful DCSync attack.

Exam trap

The trap here is that candidates may confuse the IdentityLogonEvents table (logon events) with the IdentityDirectoryEvents table (directory service events), or assume a visualization workbook can replace direct querying for forensic evidence of a DCSync attack.

How to eliminate wrong answers

Option A is wrong because the Microsoft Sentinel workbook for MDI provides visualizations and timelines but does not allow direct querying of the IdentityDirectoryEvents table to confirm specific replication requests; it is a reporting tool, not an investigative query tool. Option B is wrong because the IdentityLogonEvents table tracks authentication events (logons), not directory replication activities; DCSync attacks are not logon events but directory service replication requests. Option D is wrong because Microsoft Defender for Cloud Apps activity log focuses on cloud application activities, not on-premises Active Directory replication events; it would not capture MS-DRSR replication requests from a domain controller.

Practice this question →
← PreviousPage 4 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