Courseiva

CCNA Manage a security operations environment Questions

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

Practice these questionsDomain overviewAll questions
301
MCQhard

Your organization uses Microsoft Sentinel with a Log Analytics workspace in the East US region. You have deployed the Microsoft Defender for Cloud connector. You notice that security alerts from Defender for Cloud are not appearing as incidents in Sentinel. You have confirmed that the connector is enabled and data is flowing. What is the most likely cause?

A.The Sentinel workspace does not have required permissions to create incidents.
B.There is a delay in incident creation; wait for 24 hours.
C.You need to create an analytics rule with a rule template that uses the SecurityAlert table.
D.The Microsoft Defender for Cloud connector is not properly configured.
AnswerC

Microsoft Sentinel does not automatically create incidents from ingested security alerts; it requires an analytics rule to generate them. The Microsoft Defender for Cloud connector only ingests alerts into the SecurityAlert table in the Log Analytics workspace. To create incidents, you must create or enable an analytics rule that queries the SecurityAlert table and defines the incident properties. Without such a rule, alerts remain as raw log data and never appear in the Incidents queue.

Why this answer

The Microsoft Defender for Cloud connector ingests security alerts into the Log Analytics workspace's SecurityAlert table, but incidents in Microsoft Sentinel are generated only by analytics rules. Without a configured analytics rule that queries the SecurityAlert table (such as the built-in 'Create incidents based on Microsoft Defender for Cloud alerts' template), no incidents will be created even if data is flowing. Option C correctly identifies this missing step.

Exam trap

The trap here is that candidates assume enabling the connector automatically creates incidents, but Microsoft Sentinel requires an explicit analytics rule to generate incidents from any data source, including Defender for Cloud alerts.

How to eliminate wrong answers

Option A is wrong because the Sentinel workspace uses a system-assigned managed identity with built-in permissions (e.g., 'Microsoft Sentinel Contributor') to create incidents; if data is flowing, permissions are sufficient. Option B is wrong because incident creation is not subject to a 24-hour delay; it occurs within minutes of an alert being ingested if an analytics rule is active. Option D is wrong because the connector is confirmed enabled and data is flowing, so the connector itself is properly configured; the issue lies in the absence of an analytics rule.

Practice this question →
302
MCQhard

Your company uses Microsoft Sentinel and has enabled the Microsoft Defender XDR connector. You notice that incidents from Microsoft Defender for Cloud Apps are not appearing in Microsoft Sentinel. All other Defender XDR incidents appear correctly. What is the most likely cause?

A.The security operations team does not have the appropriate permissions.
B.The Microsoft Defender XDR connector only ingests incidents from Microsoft Defender for Endpoint.
C.The Microsoft 365 E5 license is not assigned to the users.
D.The Microsoft Defender for Cloud Apps data connector is not enabled in Microsoft Sentinel.
AnswerD

Microsoft Defender for Cloud Apps has its own dedicated data connector in Microsoft Sentinel, and it must be explicitly enabled through the Sentinel data connectors page or content hub. Without this connector, Sentinel has no API subscription to Defender for Cloud Apps, so incidents, alerts, and cloud discovery logs are not imported. Enabling the Microsoft Defender XDR connector alone does not guarantee delivery of all Cloud Apps incidents—the two connectors subscribe to different data streams. Thus, the missing Cloud Apps incidents are exactly what would be observed when this connector has not been turned on.

Why this answer

The Microsoft Defender XDR connector ingests incidents from all Microsoft Defender products, including Defender for Cloud Apps, but only if the corresponding data connector is enabled in Microsoft Sentinel. Option D is correct because the Microsoft Defender for Cloud Apps data connector must be explicitly enabled to allow incident ingestion from that source; without it, incidents from Defender for Cloud Apps will not appear even though the XDR connector is active.

Exam trap

The trap here is that candidates assume the Microsoft Defender XDR connector automatically ingests incidents from all Defender products, but in reality, each product requires its own data connector to be enabled in Microsoft Sentinel.

How to eliminate wrong answers

Option A is wrong because permissions control who can view incidents, not whether incidents are ingested; if the XDR connector is working for other products, permissions are not the issue. Option B is wrong because the Microsoft Defender XDR connector ingests incidents from all Defender products (Endpoint, Office 365, Identity, Cloud Apps), not just Defender for Endpoint. Option C is wrong because the Microsoft 365 E5 license is required for Defender for Cloud Apps functionality, but the question states that the connector is enabled and other incidents appear, so licensing is not the cause of missing incidents.

Practice this question →
303
Multi-Selectmedium

Which TWO actions should you take to optimize cost in Microsoft Sentinel while maintaining security coverage? (Choose two.)

Select 2 answers
A.Enable continuous export for all tables.
B.Purchase a Pay-as-you-go commitment tier.
C.Adjust the interactive retention period for tables that don't need long-term interactive access.
D.Add more tables to ingest data.
E.Use Basic Logs for high-volume, low-value data sources.
AnswersC, E

Correct. Adjusting the interactive retention period lets you move data out of the expensive, fast-query interactive tier into lower-cost long-term retention or archive after a short time. For tables that rarely need immediate access or advanced analytics, shortening this period directly reduces your monthly storage cost without losing the ability to retrieve older data later. This is a table-level cost-control technique that aligns storage spending with actual query needs.

Why this answer

Reducing interactive retention for tables that do not require long-term, fast query access directly lowers storage costs. Microsoft Sentinel charges per GB for data stored in the interactive retention tier, while data moved to long-term retention (up to 12 years) is significantly cheaper. By tailoring retention periods to actual operational needs, you avoid paying premium rates for data that is rarely queried interactively.

Exam trap

The trap here is that candidates often confuse 'commitment tiers' (which reduce per-GB cost) with a direct cost-optimization action, but the question asks for specific actions you take, not pricing models; also, 'continuous export' sounds like a way to offload data, but it actually adds cost and complexity unless used for a specific purpose.

Practice this question →
304
MCQeasy

Your organization is implementing Microsoft Sentinel. You need to design a solution to automatically disable a user account in Microsoft Entra ID when a high-severity incident is triggered in Microsoft Sentinel related to that user. Which component should you use?

A.A playbook that uses the Microsoft Graph API to disable the user.
B.An analytics rule that includes a query to disable the user.
C.An automation rule that runs a PowerShell script on a hybrid worker.
D.A workbook that triggers a webhook to disable the user.
AnswerA

A playbook triggered by the incident calls the Microsoft Graph API to disable the user account in Microsoft Entra ID. Graph exposes the account management operation, and Logic Apps provides the automation, satisfying the requirement to disable the user automatically on high-severity incidents.

Why this answer

A playbook is the correct component because it is an automated workflow that can be triggered by a Microsoft Sentinel incident. By using the Microsoft Graph API within the playbook, you can programmatically disable a user account in Microsoft Entra ID, which is the required action for a high-severity incident. This aligns with the need for an automated response that integrates Sentinel with identity management.

Exam trap

The trap here is that candidates may confuse automation rules with playbooks, thinking that automation rules can directly execute scripts or API calls, when in fact automation rules only trigger playbooks or run actions like changing incident status, not performing external remediation.

How to eliminate wrong answers

Option B is wrong because an analytics rule is designed to generate alerts based on query results, not to execute remediation actions like disabling a user; it lacks the capability to perform API calls or modify Entra ID objects. Option C is wrong because an automation rule in Sentinel can trigger a playbook or run a script on a hybrid worker, but running a PowerShell script directly on a hybrid worker does not natively integrate with Microsoft Graph API to disable a user without additional custom logic; the standard pattern is to use a playbook for such actions. Option D is wrong because a workbook is a visualization tool for data analysis and reporting; it cannot trigger webhooks or execute actions to disable user accounts.

Practice this question →
305
MCQhard

Your organization has Microsoft Defender for Endpoint deployed. You need to configure automatic attack disruption for ransomware attacks. What should you enable?

A.Attack surface reduction rules.
B.Live Response capabilities.
C.Device discovery settings.
D.Automatic attack disruption in Microsoft 365 Defender.
AnswerD

Automatic attack disruption is the Microsoft 365 Defender incident response feature that continuously monitors correlated XDR signals—endpoint, identity, email, and cloud apps—for evidence of active hands-on-keyboard attacks, ransomware, or malware campaigns. When an active attack is detected, it automatically triggers containment actions such as isolating compromised devices, disabling user accounts, and blocking malicious indicators to stop lateral movement while responders intervene. This is exactly the capability that automatically contains compromised assets during an active attack.

Why this answer

Automatic attack disruption in Microsoft 365 Defender is the correct feature to enable because it uses advanced detection signals to automatically contain compromised assets during ransomware attacks, such as isolating devices or blocking accounts, without manual intervention. This capability is specifically designed to stop the spread of ransomware in real time by leveraging Microsoft's threat intelligence and behavioral analytics.

Exam trap

The trap here is that candidates often confuse preventive controls like Attack surface reduction rules with reactive automated response capabilities, assuming that blocking malware execution is equivalent to disrupting an active attack, but automatic attack disruption is a distinct, post-breach containment feature.

How to eliminate wrong answers

Option A is wrong because Attack surface reduction rules are a set of policies that block common malware behaviors (e.g., script execution, Office macro abuse) but do not provide automatic containment of an ongoing ransomware attack; they are preventive, not reactive. Option B is wrong because Live Response capabilities allow security analysts to remotely investigate and remediate devices via a command-line interface, but they require manual initiation and do not automatically disrupt attacks. Option C is wrong because Device discovery settings control how endpoints are identified and inventoried on the network (e.g., via passive or active scanning), which is unrelated to automatic attack disruption.

Practice this question →
306
MCQeasy

Your incident response team uses Microsoft Sentinel. You need to automatically assign incidents to the appropriate analyst based on the type of alert. What should you create?

A.An automation rule with an 'Assign owner' action
B.A playbook that runs when an incident is created
C.A watchlist containing analyst names
D.A hunting bookmark to track assignments
AnswerA

An automation rule with an 'Assign owner' action is correct because Sentinel automation rules run natively on incident creation or update and can evaluate conditions such as alert type, severity, or entity. The Assign owner action directly sets the incident's Owner property to a designated user or Azure AD group, enabling immediate assignment without requiring Azure Logic Apps. Unlike playbooks, this built-in action is low-latency and doesn't need an external connector.

Why this answer

Automation rules in Microsoft Sentinel allow you to define conditions (e.g., alert type) and corresponding actions, including 'Assign owner' to automatically route incidents to the appropriate analyst. This is the native, no-code mechanism for incident assignment based on alert properties, making it the correct choice for this requirement.

Exam trap

The trap here is that candidates often confuse playbooks (which can also assign owners via a Microsoft Teams or Azure Logic Apps connector) with the simpler, purpose-built automation rule action, leading them to choose the more complex option unnecessarily.

How to eliminate wrong answers

Option B is wrong because playbooks are designed for complex, multi-step automation (e.g., enrichment, remediation) and require additional logic to assign ownership, whereas automation rules provide a simpler, direct 'Assign owner' action. Option C is wrong because a watchlist is a static reference list used for correlation or enrichment, not a mechanism to automatically assign incidents to analysts. Option D is wrong because a hunting bookmark is used to save and track interesting queries or results during threat hunting, not to manage incident assignments.

Practice this question →
307
MCQhard

You are a security operations analyst for a company that uses Microsoft Sentinel. You need to ensure that when an incident is created from a Microsoft Defender for Identity alert, the incident is automatically assigned to the 'Identity Protection' team and a specific tag 'Identity' is added. You have already created an automation rule that triggers on incident creation and has the condition 'Product name' contains 'Azure Advanced Threat Protection'. What should you do next to meet the requirement?

A.Create a playbook that uses the Microsoft Sentinel API to assign the incident and add tags, then attach it to the automation rule.
B.Add actions to the automation rule: 'Assign owner' with the Identity Protection team, and 'Add tags' with 'Identity'.
C.Use a workbook to monitor incidents and manually assign them to the Identity Protection team and add tags.
D.Modify the analytics rule that generates the incident to include the assignment and tagging logic in its query.
AnswerB

Automation rules in Microsoft Sentinel support multiple actions, including assigning an owner and adding tags. By configuring these actions in the existing automation rule, you fulfill the requirement to automatically assign and tag incidents from Defender for Identity alerts. This is the most direct and efficient method.

Why this answer

Automation rules in Microsoft Sentinel can perform multiple actions on incidents, including assigning an owner and adding tags. Since the automation rule already triggers on the correct incidents, adding these actions directly satisfies the requirement without the need for additional playbooks or manual intervention.

Exam trap

The trap here is thinking that a playbook is needed for owner assignment and tagging, but automation rules natively support these actions.

Practice this question →
308
Multi-Selectmedium

Which THREE components are part of the Microsoft Defender XDR incident management process?

Select 3 answers
A.Entities
B.Alerts
C.User settings
D.Playbooks
E.Evidence
AnswersA, B, E

Entities are the discrete actors, assets, and resources involved in an incident—such as user accounts, devices, IP addresses, and mailboxes. In the Microsoft Defender XDR incident data model, these are not just attached labels; they are contextualized and linked to alerts and evidence to establish the attack's scope and blast radius. This makes them a foundational component for threat hunting and investigation because they, unlike alerts or evidence, represent the 'who' and 'what' that are impacted.

Why this answer

Entities are a core component of the Microsoft Defender XDR incident management process because they represent the assets (such as users, devices, mailboxes, and applications) that are involved in an incident. The incident graph automatically links related entities to provide a unified view of the attack story, enabling analysts to pivot from an alert to the affected resources for investigation and response.

Exam trap

The trap here is that candidates often confuse the components of the Microsoft Defender XDR incident management process (entities, alerts, evidence) with automation features like playbooks, which belong to Microsoft Sentinel, not Defender XDR.

Practice this question →
309
MCQmedium

You are a SOC analyst investigating a high-severity incident. The incident involves a user who received a phishing email and clicked a link. Microsoft Defender for Office 365 detected the email as phishing and blocked the URL at time of click, but a follow-up investigation reveals that the user's mailbox has suspicious forwarding rules. You need to ensure that similar incidents are automatically remediated in the future. What should you configure in Microsoft Sentinel?

A.Configure entity behavior analytics to automatically block the user.
B.Create an analytics rule that detects suspicious forwarding rules and automatically removes them.
C.Create an automation rule that triggers a playbook to remove the forwarding rule when an incident with the 'Phishing' tactic is created.
D.Add the user to a watchlist that triggers an automated investigation.
AnswerC

This is the correct approach because automation rules in Microsoft Sentinel are specifically designed to run when an incident is created (or updated), and they can trigger a playbook as a remediation action. The automation rule can match incidents with the 'Phishing' tactic and logically invoke a playbook that, for example, connects to Exchange Online PowerShell to remove the suspicious forwarding rule. This separation of concerns—analytics rule detects, automation rule orchestrates, playbook executes—is exactly how automated remediation should be implemented in Microsoft Sentinel.

Why this answer

Microsoft Sentinel automation rules can trigger a playbook (an Azure Logic Apps workflow) when an incident is created with a specific tactic, such as 'Phishing'. This allows automatic remediation of suspicious forwarding rules without manual intervention, ensuring similar incidents are handled consistently.

Exam trap

The trap here is that candidates confuse the detection capability of analytics rules (Option B) with the remediation capability of automation rules and playbooks, assuming that analytics rules can directly perform actions like removing rules, when in fact they only generate alerts.

How to eliminate wrong answers

Option A is wrong because entity behavior analytics (UEBA) in Microsoft Sentinel profiles user behavior and generates alerts, but it cannot automatically block a user or remove forwarding rules; it only provides insights. Option B is wrong because analytics rules in Sentinel detect threats and generate incidents, but they do not have the capability to automatically remove forwarding rules; remediation requires an automation rule with a playbook. Option D is wrong because adding a user to a watchlist can trigger alerts or investigations, but it does not directly automate the removal of forwarding rules; watchlists are for enrichment and correlation, not automated remediation.

Practice this question →
310
Multi-Selecteasy

Your organization plans to use Microsoft Sentinel for incident management. Which TWO are native incident management features in Sentinel?

Select 2 answers
A.Incident comments and collaboration
B.Incident assignment to specific analysts
C.Automated email notifications on incident creation
D.Integration with ServiceNow via out-of-the-box connector
E.Integration with Microsoft Teams for incident chat
AnswersA, B

Sentinel natively supports incident comments and collaboration through the Comments pane on the incident details page. Analysts can append notes, tag colleagues with @mentions, and preserve a chronological audit trail of investigation decisions without leaving the portal. This capability requires no additional connectors or playbooks, because it is part of the core incident management surface.

Why this answer

Microsoft Sentinel provides native incident comments and collaboration features that allow analysts to add notes, tag team members, and maintain a running audit trail directly within the incident record. This is a built-in capability, not requiring any external integration or additional licensing.

Exam trap

The trap here is that candidates confuse native features with integrations or automations that require additional configuration, such as email notifications or Teams chat, which are not built into Sentinel's core incident management.

Practice this question →
311
MCQmedium

A SOC analyst suspects a user account is compromised based on anomalous sign-in activity detected by Microsoft Entra ID Protection. The analyst needs to confirm and contain the threat. What is the first action the analyst should take?

A.Reset the user's password immediately
B.Review the user's risk level and sign-in logs in Microsoft Entra ID Protection
C.Disable the user account in Microsoft Entra ID
D.Block the user's sign-in from all locations
AnswerB

Reviewing the user's risk level and sign-in logs in Microsoft Entra ID Protection is the correct initial action because it provides aggregated risk detections and contextual details, such as impossible travel or unfamiliar sign-in properties, to confirm whether a compromise has actually occurred. This investigation-first approach enables you to make an informed decision about whether to require a password reset, revoke sessions, or take other containment steps.

Why this answer

The first step when investigating a potential account compromise is to review the user's risk level and sign-in logs in Microsoft Entra ID Protection. This allows the analyst to confirm the threat by examining risk detections, sign-in patterns, and contextual details before taking any containment actions. Prematurely resetting passwords or disabling accounts could disrupt legitimate user activity or alert the attacker without a full understanding of the scope.

Exam trap

The trap here is that candidates often jump to containment actions like resetting passwords or disabling accounts, but the SC-200 exam emphasizes the 'investigate before remediate' principle, where reviewing risk detections and sign-in logs in Entra ID Protection is the mandatory first step to confirm the threat.

How to eliminate wrong answers

Option A is wrong because resetting the user's password immediately without first reviewing the risk level and sign-in logs may lock out a legitimate user or fail to address the root cause, such as a token theft or MFA bypass. Option C is wrong because disabling the user account in Microsoft Entra ID is a containment step that should only be taken after confirming the compromise through risk investigation, as it could cause unnecessary service disruption. Option D is wrong because blocking the user's sign-in from all locations is a reactive containment measure that should follow confirmation of the threat, not precede it, and may not address risks like leaked credentials or session hijacking.

Practice this question →
312
Multi-Selectmedium

Your organization uses Microsoft Defender for Cloud and Microsoft Sentinel. You need to ensure that security alerts from Defender for Cloud are automatically synchronized to Sentinel and assigned to the cloud security team. Which three actions should you take?

Select 3 answers
A.Create an automation rule that sets the incident owner to the cloud security team.
B.Manually export alerts from Defender for Cloud to Sentinel daily.
C.Create a playbook that periodically pulls alerts from Defender for Cloud.
D.Enable the Microsoft Defender for Cloud data connector in Sentinel.
E.Configure the connector to create incidents automatically from alerts.
AnswersA, D, E

Assigning the incident owner via an automation rule is the correct approach because automation rules can perform built-in incident actions immediately after the incident is created. This rule can use conditions such as the alert being generated from Defender for Cloud to set the owner field to the cloud security team, ensuring proper routing without requiring a playbook. Automation rules run after the connector or analytics rule creates the incident, making them the precise mechanism for ownership assignment in the incident lifecycle.

Why this answer

Automation rules in Microsoft Sentinel allow you to automatically assign incident owners based on conditions such as alert severity or source connector. By creating an automation rule that sets the incident owner to the cloud security team, you ensure that every Defender for Cloud alert synchronized to Sentinel is immediately assigned to the appropriate team without manual intervention.

Exam trap

The trap here is that candidates may think a custom playbook or manual export is needed for synchronization, when in fact the native data connector handles ingestion automatically, and automation rules handle assignment without custom code.

Practice this question →
313
Multi-Selecthard

You are configuring Microsoft Defender for Cloud Apps with Cloud Discovery. You need to ensure that logs from your network proxies are processed correctly. Which THREE steps are required?

Select 3 answers
A.Upload the log files manually or configure automatic log upload using the log collector.
B.Install the Microsoft Defender for Cloud Apps connector in Sentinel.
C.Enable Azure Information Protection for labeling.
D.Ensure proxy logs are in a supported format such as Common Log Format (CLF).
E.Configure the source IP address ranges of your organization in Defender for Cloud Apps settings.
AnswersA, D, E

Defender for Cloud Apps Cloud Discovery has no visibility into your network traffic unless it receives the raw logs from your proxy, firewall, or other network appliances. You must either manually upload a flat log file through the Cloud Discovery 'Upload' dialog for an ad-hoc snapshot, or deploy the log collector to automate continuous ingestion, parsing, and forwarding. The log collector runs on Windows or Linux, receives logs via FTP/Syslog/HTTP, and is the standard for ongoing discovery. Without this step, no shadow IT analysis can occur, making it a required configuration action.

Why this answer

Microsoft Defender for Cloud Apps Cloud Discovery requires log data from network proxies to be ingested either by manually uploading log files or by configuring automatic log upload via the log collector. The log collector is a Docker-based container that parses and normalizes proxy logs before forwarding them to Defender for Cloud Apps, enabling shadow IT discovery without manual intervention.

Exam trap

The trap here is that candidates often confuse the log collector with the Sentinel connector, thinking both are required for log ingestion, but the Sentinel connector is for SIEM integration, not for Cloud Discovery log processing.

Practice this question →
314
MCQhard

Your organization uses Microsoft Sentinel with User and Entity Behavior Analytics (UEBA) enabled. You notice that the UEBA is not generating any anomalies for a particular user who has been inactive for 30 days. You have verified that the user's data is being ingested into the workspace. What is the most likely reason?

A.UEBA requires a minimum of 14 days of activity to establish a baseline.
B.The user's license does not include UEBA.
C.UEBA only works with Active Directory data, not Microsoft Entra ID.
D.UEBA is not enabled for the workspace.
AnswerA

UEBA in Microsoft Sentinel relies on machine learning to learn what 'normal' behavior looks like for each user or entity. A minimum of 14 days of historical activity must be ingested into the workspace before a reliable baseline is established; without that baseline, UEBA cannot differentiate anomalous activity from ordinary variations. Even though UEBA is enabled, the lack of detections within the initial period is expected and not due to configuration errors.

Why this answer

UEBA in Microsoft Sentinel requires a minimum of 14 days of historical data to build a behavioral baseline for each user. If a user has been inactive for 30 days, the baseline may have expired or never been established, so no anomalies are generated. The data ingestion is confirmed, but without recent activity, UEBA cannot compare current behavior against a meaningful profile.

Exam trap

The trap here is that candidates may assume data ingestion alone is sufficient for UEBA, but the feature specifically requires a minimum baseline period of 14 days of activity to generate anomalies, and inactivity beyond that period breaks the baseline.

How to eliminate wrong answers

Option B is wrong because UEBA is a feature of Microsoft Sentinel itself, not a separate user license; it is enabled at the workspace level and does not require individual user licenses. Option C is wrong because UEBA works with multiple data sources, including Microsoft Entra ID (formerly Azure AD), not just Active Directory; it ingests sign-in logs, audit logs, and activity logs from Entra ID. Option D is wrong because the question states UEBA is enabled, and the issue is specific to one user, not the entire workspace; if UEBA were disabled, no anomalies would be generated for any user.

Practice this question →
315
MCQmedium

Your organization uses Microsoft Sentinel and Microsoft Defender for Office 365. You have configured incident creation from Microsoft Defender for Office 365 alerts in Microsoft Sentinel. However, you notice that some alerts are not creating incidents. Which step should you take to troubleshoot this issue?

A.Examine the analytics rule that creates incidents from Microsoft Defender for Office 365 alerts and verify the severity threshold.
B.Check the Microsoft 365 Defender portal to confirm that the alerts are being generated.
C.Review the Microsoft Sentinel workbooks for any visualization errors.
D.Verify that the Microsoft Defender for Office 365 data connector in Microsoft Sentinel is connected and data is ingested.
AnswerA

The correct action is to examine the analytics rule that creates incidents from Microsoft Defender for Office 365 alerts, because Microsoft Sentinel does not automatically create incidents from every raw alert. Analytics rules use KQL queries to match incoming alerts and apply conditions, and if the rule's severity threshold (e.g., only Medium and higher) is too high, alerts with lower severity won't trigger an incident. Verifying the rule's query, alert grouping, and severity filter directly addresses the symptom of users receiving Microsoft 365 Defender alerts while Sentinel incidents are missing.

Why this answer

The analytics rule that maps Microsoft Defender for Office 365 alerts to incidents in Microsoft Sentinel includes a severity threshold filter. If the rule is configured to only create incidents for alerts with a severity of 'High' or 'Medium', alerts with 'Low' severity or 'Informational' will be silently dropped and not generate incidents. Verifying and adjusting this threshold directly addresses the root cause of missing incidents.

Exam trap

The trap here is that candidates often assume the issue is with data ingestion (Option D) or alert generation (Option B), but the actual cause is a misconfigured severity threshold within the analytics rule that silently filters out lower-severity alerts before they can become incidents.

How to eliminate wrong answers

Option B is wrong because checking the Microsoft 365 Defender portal only confirms that alerts are generated at the source, but it does not troubleshoot why those alerts fail to create incidents in Microsoft Sentinel; the issue is in the ingestion or rule logic, not in alert generation. Option C is wrong because Microsoft Sentinel workbooks are visualization tools that display data already ingested; they do not affect incident creation and cannot diagnose why alerts are not being turned into incidents. Option D is wrong because verifying the data connector status ensures data ingestion from Microsoft Defender for Office 365, but if the connector is connected and data is flowing, the problem lies in the analytics rule's configuration (e.g., severity threshold or rule logic), not in the connector itself.

Practice this question →
316
MCQhard

You are a security operations engineer for a company that uses Microsoft Defender XDR. You need to create a custom detection rule that alerts when a user performs more than 10 failed logon attempts within 5 minutes from different IP addresses. The rule should use the IdentityLogonEvents table. You have written the KQL query and now need to configure the rule settings in Microsoft 365 Defender. Which configuration should you use for the rule frequency and lookback period to minimize false positives while ensuring timely detection?

A.Run every 5 minutes with a 5-minute lookback.
B.Run every 5 minutes with a 1-hour lookback.
C.Run every 1 hour with no lookback.
D.Run every 24 hours with a 24-hour lookback.
AnswerA

Running every 5 minutes with a 5-minute lookback is optimal because the lookback exactly matches the execution interval, ensuring each event is evaluated exactly once within its own time window. This configuration minimizes detection latency to at most five minutes while avoiding both data gaps and overlapping evaluations. It's the standard baseline for near-real-time security alerting in tools like Microsoft Sentinel.

Why this answer

To detect more than 10 failed logons within 5 minutes, the rule should run every 5 minutes with a 5-minute lookback so it evaluates the most recent 5-minute window each time. This minimizes false positives by focusing on the exact time window and ensures timely detection.

Exam trap

The trap is assuming a longer lookback always improves detection, but it actually increases false positives and can duplicate alerts; candidates may pick 1-hour lookback thinking it catches more, but it violates the 5-minute condition.

How to eliminate wrong answers

Option B is wrong because a 1-hour lookback would include older events and could trigger on failures spread over an hour, increasing false positives and not matching the 5-minute condition. Option C is wrong because running every 1 hour with no lookback would miss the 5-minute window and delay detection. Option D is wrong because a 24-hour frequency and lookback is far too slow and broad, causing delayed alerts and many false positives.

Practice this question →
317
MCQeasy

Your organization uses Microsoft Sentinel. You need to ensure that an incident is automatically assigned to a specific analyst when it is created. What should you create?

A.An analytics rule with an output to a specific user.
B.A playbook triggered by incident creation.
C.An automation rule with an 'Assign incident' action.
D.A watchlist that maps incident types to owners.
AnswerC

An automation rule with an 'Assign incident' action is the intended, built-in method for automatically setting the incident owner when an incident is created. Automation rules run immediately after an incident is created (or updated) and support a dedicated action that writes the owner property, optionally based on a condition such as the incident's severity or its associated analytics rule. This makes it the simplest and most reliable way to ensure ownership is always assigned.

Why this answer

An automation rule in Microsoft Sentinel can be configured to run when an incident is created and includes an 'Assign incident' action that automatically assigns the incident to a specific analyst or group. This is the native, no-code method for incident assignment without requiring external logic or playbooks.

Exam trap

The trap here is that candidates may think a playbook is required for any automation, but Microsoft Sentinel's automation rules provide a native, code-free 'Assign incident' action that is the correct and simplest solution for this scenario.

How to eliminate wrong answers

Option A is wrong because analytics rules generate alerts or incidents based on queries, but they do not have an 'output to a specific user' action; they trigger playbooks or automation rules for post-creation actions. Option B is wrong because a playbook triggered by incident creation can assign incidents, but it is an overengineered solution requiring a Logic Apps instance and additional configuration; automation rules are the simpler, built-in mechanism for this task. Option D is wrong because a watchlist is a static reference table for correlating data, not an active mechanism to assign incidents to owners upon creation.

Practice this question →
318
MCQhard

A security operations center (SOC) uses Microsoft Sentinel for log management. The SOC manager wants to reduce storage costs by automatically archiving logs that are older than 90 days to long-term retention, but retains the ability to search them if needed. What should the manager configure?

A.Change the table plan to Basic Logs for logs older than 90 days
B.Create a retention policy that deletes logs older than 90 days
C.Configure a data archiving policy in the Log Analytics workspace to archive logs after 90 days
D.Export logs older than 90 days to an Azure Storage account
AnswerC

Configuring a data archiving policy in the Log Analytics workspace automatically moves logs from the interactive retention tier to an archive tier after a defined period, such as 90 days, while preserving the ability to search them through archived log search jobs. Archived data is retained at a lower cost and remains accessible for compliance and incident investigations, subject to a separate total retention duration and additional search costs. This is the intended native method for long-term, queryable log retention in Microsoft Sentinel.

Why this answer

Configuring a data archiving policy in the Log Analytics workspace automatically moves logs older than 90 days to long-term, low-cost storage while keeping them searchable via the search job or restore feature. This directly meets the SOC manager's requirement to reduce costs without losing the ability to query archived data.

Exam trap

The trap here is that candidates confuse 'archiving' with 'deleting' or 'exporting,' assuming that moving data to cheaper storage must mean losing queryability, whereas Microsoft Sentinel's archive tier preserves searchability through restore or search jobs.

How to eliminate wrong answers

Option A is wrong because changing the table plan to Basic Logs affects all data in the table, not just logs older than 90 days, and Basic Logs have reduced query capabilities and higher ingestion costs, not archival. Option B is wrong because a retention policy that deletes logs older than 90 days permanently removes the data, eliminating the ability to search them later. Option D is wrong because exporting logs to an Azure Storage account moves them out of Log Analytics, making them unsearchable via KQL without additional tooling and breaking the requirement for retained searchability.

Practice this question →
319
Multi-Selectmedium

Which TWO of the following are valid methods to reduce Microsoft Sentinel data ingestion costs?

Select 2 answers
A.Disable all analytics rules.
B.Switch all data sources to basic logs.
C.Configure basic logs for high-volume verbose data sources.
D.Increase the retention period for all tables.
E.Set a daily data ingestion cap.
AnswersC, E

Configuring Basic Logs for high-volume verbose data sources is a valid cost-reduction method because Basic Logs are billed at a lower ingestion rate and stored in a low-cost, high-volume tier compared to Analytics Logs. High-volume verbose sources (e.g., DNS query logs, firewall logs, or raw network traffic) that are useful for occasional threat hunting or compliance but not for continuous alerting can be sent to Basic Logs tables, dramatically reducing the cost of data that does not need full interactive analytics. This approach preserves detection capabilities for critical security data while offloading noisy, expensive data to a cheaper storage tier.

Why this answer

Microsoft Sentinel allows you to configure basic logs for high-volume, verbose data sources (e.g., DNS or firewall logs) to reduce costs. Basic logs are stored at a lower ingestion price and support only simple queries, making them ideal for debugging or compliance data that doesn't require advanced analytics.

Exam trap

The trap here is that candidates confuse 'reducing ingestion costs' with 'reducing storage costs' or assume disabling features like analytics rules affects ingestion volume, when in fact ingestion costs are driven by data volume and log type, not rule activity.

Practice this question →
320
MCQmedium

You are a security operations analyst for a company that uses Microsoft Defender XDR. You need to configure a custom detection rule that will trigger an alert when a specific process is executed on any device. The process name is 'malicious.exe'. You want the alert to be generated only when the process is executed with a command line containing '--encrypt'. Which query language should you use to define the custom detection rule?

A.Kusto Query Language (KQL) against the DeviceProcessEvents table.
B.SQL against the SecurityEvent table in Microsoft Sentinel.
C.PowerShell script that queries the Windows Event Log for process creation events.
D.Azure Resource Graph query against the Microsoft Defender for Endpoint resources.
AnswerA

Custom detection rules in Microsoft Defender XDR use KQL to query advanced hunting tables. The DeviceProcessEvents table contains process creation events, including process name and command line. Using KQL, you can filter for FileName == 'malicious.exe' and ProcessCommandLine contains '--encrypt' to trigger the alert as required.

Why this answer

Custom detection rules in Microsoft Defender XDR are created by writing KQL queries against advanced hunting tables. For process execution events, the DeviceProcessEvents table is appropriate. By filtering on the process file name and command line, you can precisely trigger alerts for the specified condition.

Exam trap

The trap here is confusing the query languages used by different Microsoft security products; Defender XDR custom detections use KQL, not SQL or PowerShell.

Practice this question →
321
MCQhard

You are designing an automation rule in Microsoft Sentinel that should automatically assign incidents to the appropriate analyst based on the incident type. However, the rule fails to assign correctly for some incidents. What should you verify?

A.The order of conditions in the automation rule; ensure more specific conditions are evaluated first.
B.That a playbook has been created to perform the assignment.
C.That the incident assignment rule in Microsoft Entra ID is configured correctly.
D.That the owner (analyst) has the required permissions in Microsoft Sentinel.
AnswerA

In Sentinel, automation rules evaluate conditions in top-down order; placing more specific conditions before general ones ensures that incidents matching a narrow scenario are handled by the intended rule before a broader rule can claim them. For example, if you have a rule assigning incidents from a specific asset to a specialized analyst, it must be listed before a rule that assigns all incidents to a general queue. This ordering is critical because the first matching rule takes action; otherwise, a generic rule may consume the incident first.

Why this answer

Automation rules in Microsoft Sentinel evaluate conditions in order, and the first matching condition triggers the associated action. If a broad condition (e.g., 'all incidents') is placed before a more specific condition (e.g., 'incident type equals Phishing'), the broad rule will match first and assign incorrectly, preventing the specific rule from ever running. Reordering conditions so that the most specific ones are evaluated first ensures correct assignment based on incident type.

Exam trap

Microsoft often tests the misconception that automation rules run in parallel or that all matching conditions are applied, when in fact they are evaluated sequentially and only the first match executes its action.

How to eliminate wrong answers

Option B is wrong because a playbook is not required for simple assignment; automation rules can directly set the owner (analyst) without invoking a playbook. Option C is wrong because Microsoft Entra ID (formerly Azure AD) does not have an 'incident assignment rule'—incident ownership is managed within Microsoft Sentinel, not via Entra ID configuration. Option D is wrong because the owner (analyst) does not need special permissions in Microsoft Sentinel to be assigned an incident; the automation rule itself runs with the system's permissions, and the assigned user only needs standard Sentinel reader/responder roles to interact with the incident.

Practice this question →
322
MCQmedium

Your organization uses Microsoft Defender for Identity. You receive an alert about a suspicious Kerberos ticket request. What is the most appropriate first step?

A.Disable the user account.
B.Investigate the alert in the Microsoft 365 Defender portal.
C.Reset the user's password.
D.Reset the krbtgt account password.
AnswerB

Investigating the alert in the Microsoft 365 Defender portal is the correct first step because it provides the full attack story, including the involved source and target entities, activity timelines, and evidence-based recommendations. The portal correlates signals from Microsoft Defender for Identity with identity and service events, letting you confirm whether the alert is a true positive and determine the scope of compromise. Only after this investigation should you choose a containment or remediation action such as resetting the password or disabling the account.

Why this answer

The first step when receiving any security alert, including a suspicious Kerberos ticket request from Microsoft Defender for Identity, is to investigate the alert in the Microsoft 365 Defender portal. This portal provides the unified security operations console where you can view the full alert details, related entities, and the MITRE ATT&CK mapping to understand the scope and severity before taking any remediation actions. Prematurely disabling accounts or resetting passwords without investigation can destroy forensic evidence and potentially disrupt legitimate user activity.

Exam trap

The trap here is that candidates often jump to immediate remediation actions like disabling accounts or resetting passwords, forgetting that the first step in any incident response process (as per NIST 800-61 and Microsoft's own guidance) is always investigation and triage to confirm the alert and understand the attack context.

How to eliminate wrong answers

Option A is wrong because disabling the user account without investigation may be premature; the alert could be a false positive or part of a larger attack chain that requires analysis before containment. Option C is wrong because resetting the user's password does not address the root cause of a suspicious Kerberos ticket request, which may involve ticket forgery (e.g., Golden Ticket or Silver Ticket) or Kerberoasting, and password reset alone will not invalidate already issued tickets. Option D is wrong because resetting the krbtgt account password is a drastic, high-impact action that should only be performed as part of a structured response to a confirmed domain compromise (e.g., KRBTGT reset procedure), not as a first step for a single suspicious ticket alert.

Practice this question →
323
MCQeasy

Your SOC team uses Microsoft Sentinel incident management. They want to automatically assign high-severity incidents to a senior analyst and send a notification to Microsoft Teams. What should you use?

A.Create an automation rule that triggers on incident creation, assigns the incident, and runs a playbook to post to Teams.
B.Create a playbook and attach it directly to the analytics rule.
C.Create a watchlist to define assignment rules and configure a workbook for notifications.
D.Create an analytics rule with incident grouping and assignment.
AnswerA

Automation rules are the native incident orchestration mechanism in Microsoft Sentinel. You can define a trigger on incident creation and add actions that assign the incident to an owner, set status/tags, and invoke a playbook—a Logic App—that posts a message to Teams. This directly meets both requirements and is the intended pattern for incident assignment and notification.

Why this answer

Automation rules in Microsoft Sentinel can trigger on incident creation (e.g., when severity is 'High'), automatically assign the incident to a specific owner (senior analyst), and then invoke a playbook (Azure Logic App) to post a message to Microsoft Teams. This combines assignment logic with automated notification in a single, manageable rule.

Exam trap

The trap here is that candidates confuse analytics rules (which only generate alerts) with automation rules (which handle post-creation actions like assignment and playbook execution), leading them to incorrectly select option B or D.

How to eliminate wrong answers

Option B is wrong because playbooks cannot be attached directly to analytics rules; they must be invoked via automation rules or as part of an incident trigger. Option C is wrong because watchlists are used for reference data (e.g., IP addresses) and workbooks are for visualization, not for automated assignment or notification. Option D is wrong because analytics rules generate alerts and can group incidents, but they do not support assignment or notification actions; those require automation rules or playbooks.

Practice this question →
324
Multi-Selectmedium

Which TWO conditions must be met to enable Microsoft Sentinel UEBA? (Choose two.)

Select 2 answers
A.Microsoft Entra ID P2 licenses must be assigned to users.
B.KQL queries must be created for entity behavior.
C.Microsoft Defender XDR must be onboarded.
D.The SecurityInsights solution must be installed in the workspace.
E.Azure SQL Database must be deployed.
AnswersA, D

Microsoft Entra ID P2 licenses are a hard prerequisite for UEBA because Sentinel derives user entity behavior across the identity plane from Microsoft Entra ID Protection, which only emits risk signals and rich user context under a P2 license (e.g., risk detections, risky sign-ins, and user risk history). Without P2, the identity baseline that Sentinel's UEBA machine-learning models rely on is never populated, so user-centric anomaly detection cannot be calculated even though other data sources are connected.

Why this answer

Microsoft Sentinel UEBA requires the SecurityInsights solution to be installed in the Log Analytics workspace, as this solution provides the UEBA data connectors and analytics rules. Additionally, Microsoft Entra ID P2 licenses are required because UEBA relies on the identity protection and risk detection capabilities that are only available with P2 licensing, enabling the enrichment of entity behavior profiles with risk data.

Exam trap

The trap here is that candidates often confuse enabling UEBA with simply having Sentinel deployed, overlooking the specific licensing requirement (Entra ID P2) and the need for the SecurityInsights solution to be installed, rather than assuming UEBA is automatically available with any Sentinel workspace.

Practice this question →
325
Multi-Selecthard

Which THREE are valid components of a Microsoft Sentinel automation rule?

Select 3 answers
A.Actions (e.g., Run playbook, Change severity)
B.Watchlist
C.KQL query
D.Conditions (e.g., If severity equals Medium)
E.Trigger (e.g., When incident is created)
AnswersA, D, E

Actions in a Microsoft Sentinel automation rule are the operational steps that execute when the rule's trigger and conditions are satisfied. These include invoking playbooks, modifying incident severity, assigning ownership, adding tags, or closing the incident. Actions run sequentially in the order defined in the rule and are the only components that actually change the state of the incident or perform external responses.

Why this answer

Automation rules in Microsoft Sentinel allow you to define actions such as running a playbook or changing the severity of an incident. These actions are executed automatically when the rule's trigger and conditions are met, enabling streamlined incident response without manual intervention.

Exam trap

The trap here is that candidates often confuse the components of an automation rule with those of an analytics rule, mistakenly selecting KQL queries or watchlists as valid automation rule components.

Practice this question →
326
MCQeasy

You are a SOC analyst using Microsoft Sentinel. You receive an incident with high severity. You need to quickly gather additional context about the affected user account, including recent sign-in logs and role assignments. Which feature should you use?

A.Sentinel Workbooks
B.Analytics rules
C.Entity pages
D.Hunting queries
AnswerC

Entity pages in Sentinel are the correct investigation surface because they aggregate everything known about a specific entity (user, host, IP, mailbox, etc.) into a single timeline, including related alerts, incidents, bookmarks, and anomalies. They leverage UEBA to present risk scores, behavioral insights, and peer anomaly comparisons, which are essential for understanding whether the entity is compromised or merely active. This entity-centric view directly supports the 'entity timeline' requirement that other tools lack.

Why this answer

Entity pages in Microsoft Sentinel provide a centralized, pre-built view of a specific entity (such as a user account), aggregating related alerts, incidents, and data from connected sources like Azure Active Directory sign-in logs and role assignments. This allows a SOC analyst to quickly gather contextual information without manually querying multiple data sources, making it the ideal feature for high-severity incidents requiring rapid investigation.

Exam trap

The trap here is that candidates confuse the investigative, entity-focused nature of Entity pages with the broader, dashboard-oriented purpose of Workbooks, leading them to choose Option A because both involve visual data presentation.

How to eliminate wrong answers

Option A is wrong because Sentinel Workbooks are customizable dashboards for visualizing data trends and metrics, not for drilling into a single entity's recent activity like sign-in logs or role assignments. Option B is wrong because Analytics rules are used to generate alerts and incidents based on predefined detection logic, not to investigate or retrieve context about an existing incident's affected user. Option D is wrong because Hunting queries are proactive, ad-hoc KQL searches for potential threats across historical data, not a structured, entity-specific context gathering tool for an active incident.

Practice this question →
327
MCQmedium

Your organization has Microsoft Defender for Office 365. You need to review a user's reported phishing email in Microsoft Defender XDR. Which section of the Microsoft Defender portal should you check?

A.Submissions
B.Threat Explorer
C.Alerts
D.Action center
AnswerA

The Submissions page in Microsoft Defender XDR is the centralized, dedicated queue for user-reported messages, surfaced through the Report Message and Report Phishing add-ins in Outlook. It provides security admins with the message details, report type, and source, and allows them to triage, analyze, and take remediation actions such as release, purge, or submit to Microsoft for analysis. This page is the only location specifically designed to display what users have manually flagged, making it the correct place to find user-reported messages.

Why this answer

The Submissions page in the Microsoft Defender portal is the dedicated section for reviewing user-reported phishing emails. It allows security operators to view, analyze, and take action on messages that users have reported as suspicious or malicious, directly integrating with Microsoft Defender for Office 365's threat intelligence pipeline.

Exam trap

The trap here is that candidates confuse the Submissions page (for user-reported messages) with Threat Explorer (for querying historical threat data), leading them to choose B instead of A.

How to eliminate wrong answers

Option B is wrong because Threat Explorer is a real-time investigation tool for querying email and collaboration data, not a repository for user-reported submissions. Option C is wrong because Alerts are generated by detection rules and policies, not by direct user reporting of phishing emails. Option D is wrong because Action center is used for managing remediation actions (like device isolation or automated investigation responses), not for reviewing user-reported messages.

Practice this question →
328
Multi-Selectmedium

Which THREE actions can be performed by automation rules in Microsoft Sentinel?

Select 3 answers
A.Modify a data connector to ingest more logs
B.Create a new analytics rule
C.Assign an incident to a specific owner
D.Run a playbook on an incident
E.Add a tag to an incident
AnswersC, D, E

Automation rules respond to incident creation by applying triage actions, and owner assignment is one of the supported operations. The rule can route an incident to a named analyst or group automatically, removing manual queue handling without invoking a logic app.

Why this answer

Automation rules in Microsoft Sentinel are designed to triage and manage incidents, so option C is correct because they can assign an incident to a specific owner (for example, setting the Owner field to a user or group) as part of incident handling. Option D is correct because automation rules can trigger a playbook on an incident, which is a core capability used to run automated response logic when an incident is created or updated. Option E is correct because automation rules can add tags to an incident, enabling classification, filtering, and later automation based on those tags.

Options A and B are not correct: automation rules cannot modify a data connector to ingest more logs, and they cannot create a new analytics rule; those are configuration tasks performed through the Sentinel data connectors and analytics rule creation interfaces, not through incident automation rules.

Exam trap

The trap here is that candidates may confuse automation rules with analytics rules or data connectors, assuming automation rules can modify data sources or create detection logic, when in fact automation rules are limited to post-ingestion incident management actions.

Practice this question →
329
Multi-Selectmedium

Which TWO actions are part of managing a security operations environment in Microsoft Sentinel? (Select two.)

Select 2 answers
A.Configuring physical access controls to the data center
B.Installing the Azure Monitor Agent on servers
C.Creating automation rules to triage incidents
D.Configuring data retention policies for Log Analytics workspaces
E.Creating Microsoft Purview sensitivity labels
AnswersC, D

Creating automation rules to triage incidents is a core security operations management task because it directly shapes how the SOC handles alerts. Automation rules can assign incidents to analysts, apply custom tags, suppress false positives automatically, and trigger playbooks for standardized response actions. By embedding triage decisions into Sentinel, the SOC reduces response time and ensures consistent handling according to established procedures.

Why this answer

Automation rules in Microsoft Sentinel allow you to automatically triage incidents by applying actions such as assigning ownership, changing severity, or running playbooks. This is a core operational task within the security operations environment to streamline incident response and reduce manual effort.

Exam trap

The trap here is that candidates confuse data collection or infrastructure security tasks with operational management actions, but the domain 'Manage a security operations environment' specifically focuses on incident handling, automation, and workspace configuration within Sentinel, not on data ingestion or physical security.

Practice this question →
330
Multi-Selecteasy

Which TWO Microsoft Sentinel features allow you to organize and prioritize incidents for better triage?

Select 2 answers
A.Entity mapping in analytics rules.
B.Automation rules with incident creation triggers.
C.Workbooks for dashboard reporting.
D.Incident assignment to analysts.
E.Incident classification and tagging.
AnswersD, E

Incident assignment to analysts is a core incident management feature that directly supports organization and triage by designating a specific owner for each incident. This establishes accountability, prevents duplicate overlapping work, and makes it clear who is responsible for investigation and resolution. Assignment is an operational state that structures workflow, unlike enrichment or reporting features.

Why this answer

Incident assignment allows security operations center (SOC) analysts to take ownership of specific incidents, ensuring accountability and preventing duplicate work. This feature directly supports triage by routing incidents to the appropriate team member based on skills or workload. Option E is correct because classification and tagging let analysts categorize incidents by severity, attack type, or status, enabling efficient filtering and prioritization across the incident queue.

Exam trap

The trap here is that candidates often confuse features that create or enrich incidents (like entity mapping or automation triggers) with features that organize and prioritize them after creation, leading them to select options A or B instead of the correct assignment and classification capabilities.

Practice this question →
331
MCQeasy

Your company uses Microsoft Defender for Office 365. You want to automatically take action on malicious emails that bypass the filter. What should you configure?

A.Enable anti-phishing policy.
B.Enable Safe Attachments policy.
C.Create a transport rule in Exchange.
D.Configure automated investigation and response (AIR) policies.
AnswerD

Automated investigation and response (AIR) policies in Defender for Office 365 use built-in playbooks triggered by security alerts to automatically investigate potentially malicious emails and take remediation actions. These actions include soft-deleting messages, quarantining suspicious content, blocking sender IPs or URLs, and disabling compromised accounts based on the investigation verdict. AIR is specifically designed for post-delivery response, making it the correct choice to automatically remediate a confirmed threat.

Why this answer

Automated investigation and response (AIR) policies in Microsoft Defender for Office 365 are specifically designed to automatically take action on malicious emails that bypass initial filters. AIR uses playbooks to investigate threats and automatically remediate, such as deleting or moving emails, without manual intervention. This directly addresses the requirement to automatically act on bypassed malicious emails.

Exam trap

The trap here is that candidates often confuse pre-delivery protection policies (like anti-phishing or Safe Attachments) with post-delivery automated response capabilities, assuming any security policy can automatically act on bypassed emails, but only AIR provides the automated investigation and remediation workflow for threats that have already evaded initial filters.

How to eliminate wrong answers

Option A is wrong because anti-phishing policies in Defender for Office 365 are preventive controls that block phishing attempts at the point of delivery, not reactive actions for emails that have already bypassed filters. Option B is wrong because Safe Attachments policies scan attachments in email in real-time to block malicious files, but they do not automatically take action on emails that have already bypassed the filter—they are a pre-delivery protection mechanism. Option C is wrong because transport rules in Exchange (mail flow rules) are used for custom routing, compliance, or filtering based on conditions, but they are not designed to automatically investigate and remediate malicious emails that bypassed Defender filters; they lack the automated investigation and response capabilities of AIR.

Practice this question →
332
MCQhard

Refer to the exhibit. You are reviewing an automation rule configuration in Microsoft Sentinel. Based on the JSON snippet, what will happen when a high-severity incident is created?

A.The rule will run a playbook when a high-severity incident is created
B.The rule will change the severity of the incident to Medium
C.The rule will assign the incident to the SOC manager
D.The rule will run the playbook when a new alert is created
AnswerA

This is the correct interpretation. The automation rule's trigger is set to 'When an incident is created,' and its condition filters for incidents with a severity equal to High. The only action defined is to run a specified playbook, so the rule's sole effect is to invoke that playbook for qualifying high-severity incidents.

Why this answer

The automation rule's trigger condition is set to 'When incident is created' and the condition filters for incidents with a severity of 'High'. When a high-severity incident is created, the rule will execute the associated playbook, which is a common use case for automated response in Microsoft Sentinel.

Exam trap

The trap here is that candidates may confuse the incident creation trigger with alert creation trigger, or assume that any rule with a condition automatically modifies the incident properties like severity or assignment, when in fact the rule only executes the defined actions (playbook) based on the condition.

How to eliminate wrong answers

Option B is wrong because the JSON snippet does not include any action to change the severity of the incident; it only triggers a playbook. Option C is wrong because there is no assignment action configured in the rule; the rule only runs a playbook, not reassigns ownership. Option D is wrong because the trigger is set to 'When incident is created', not 'When alert is created'; alerts are separate entities that can be correlated into incidents, but the rule specifically acts on incident creation.

Practice this question →
333
MCQeasy

You need to ensure that Microsoft Sentinel can access threat intelligence feeds from external sources like AlienVault OTX. Which data connector should you use?

A.Microsoft 365 Defender data connector
B.Microsoft Entra ID data connector
C.Amazon Web Services data connector
D.Threat Intelligence - TAXII data connector
AnswerD

The Threat Intelligence - TAXII data connector is the correct choice because it enables Sentinel to connect directly to TAXII 2.x servers and ingest STIX-formatted threat-intelligence indicators (e.g., IP addresses, URLs, file hashes). This connector supports feeds such as AlienVault OTX. Once ingested, the indicators are stored in the ThreatIntelligenceIndicator table and can be used by analytics rules to correlate against logs and trigger incidents.

Why this answer

The Threat Intelligence - TAXII data connector is the correct choice because it enables Microsoft Sentinel to ingest threat intelligence feeds from external sources that support the TAXII (Trusted Automated eXchange of Indicator Information) protocol, such as AlienVault OTX. This connector uses the STIX (Structured Threat Information Expression) standard to pull indicators of compromise (IOCs) like IP addresses, domains, and hashes directly into Sentinel for correlation and alerting.

Exam trap

The trap here is that candidates may confuse the 'Threat Intelligence - TAXII' connector with other data connectors that also deal with external data (like AWS or Microsoft 365), but only the TAXII connector is specifically designed to ingest structured threat intelligence feeds using the STIX/TAXII standard.

How to eliminate wrong answers

Option A is wrong because the Microsoft 365 Defender data connector ingests alerts and incidents from Microsoft 365 Defender (e.g., Defender for Endpoint, Defender for Office 365), not external threat intelligence feeds like AlienVault OTX. Option B is wrong because the Microsoft Entra ID data connector (formerly Azure AD) ingests sign-in logs and audit logs for identity-related security events, not threat intelligence feeds. Option C is wrong because the Amazon Web Services data connector ingests AWS CloudTrail and other AWS service logs, not external threat intelligence feeds.

Practice this question →
334
MCQeasy

Your Microsoft Sentinel workspace has a Microsoft 365 Defender connector configured. You notice that incidents are being created from Microsoft Defender for Office 365 alerts, but not from Microsoft Defender for Identity alerts. What should you check?

A.Enable the Microsoft Defender for Identity alert streaming in the connector configuration.
B.Verify that the Microsoft 365 Defender connector is connected.
C.Ensure you have licenses for Microsoft Defender for Identity.
D.Check the incident correlation rules in Microsoft Defender XDR.
AnswerA

The Microsoft 365 Defender connector in Microsoft Sentinel has a service-selection pane that allows you to choose which Defender signal sources to ingest, including Microsoft Defender for Identity alerts. If only Office 365 alerts are flowing, the most likely root cause is that the Defender for Identity alert stream was not toggled on in the connector's configuration. After enabling it, save the connector configuration and wait for new alerts to start appearing in the Sentinel workspace.

Why this answer

The Microsoft 365 Defender connector in Microsoft Sentinel requires explicit enablement of alert streaming for each Microsoft Defender service. By default, the connector may stream alerts from Defender for Office 365 but not from Defender for Identity unless the corresponding toggle is turned on in the connector configuration. Option A directly addresses this by instructing you to enable the Defender for Identity alert streaming, which resolves the missing incident creation.

Exam trap

The trap here is that candidates assume a working connector automatically streams all Defender alerts, but Microsoft deliberately tests whether you know that each workload's alert streaming must be individually enabled in the connector configuration.

How to eliminate wrong answers

Option B is wrong because the connector is already confirmed to be working (incidents are being created from Defender for Office 365), so the connection is not the issue. Option C is wrong because if you lacked licenses for Defender for Identity, you would not receive any alerts from that service at all, but the question implies the connector is configured and alerts are expected; the problem is specifically about streaming those alerts into Sentinel. Option D is wrong because incident correlation rules in Microsoft Defender XDR govern how alerts are grouped into incidents within the Defender portal, not how alerts are ingested into Sentinel; the issue is at the data ingestion layer, not correlation.

Practice this question →
335
MCQmedium

Your company uses Microsoft Defender for Cloud to monitor multi-cloud resources. You want to ensure that all critical security recommendations are automatically assigned to the appropriate team leads based on the resource's tags. Which feature should you configure?

A.Configure a regulatory compliance standard to send email notifications.
B.Create a workbook that lists recommendations and manually assign them.
C.Use the 'Assign ownership' feature in Microsoft Defender for Cloud to map tags to owners.
D.Create a governance rule that automatically applies a compliance standard.
AnswerC

The 'Assign ownership' feature in Microsoft Defender for Cloud lets you configure resource tag keys (for example, 'owner' or 'business-unit') and map the tag values to Azure AD users or groups, which then become recommendation owners. This creates a governance rule that automatically assigns every recommendation for resources with matching tags to the designated owner, optionally with a fix timeframe and escalation path. This is the native, purpose-built mechanism for distributing security recommendation ownership across teams, and it is the correct way to ensure each recommendation is acted upon.

Why this answer

The 'Assign ownership' feature in Microsoft Defender for Cloud allows you to map resource tags to specific owners (e.g., team leads) via an automated rule. When a critical security recommendation is generated for a resource with a matching tag, the recommendation is automatically assigned to the designated owner, ensuring accountability without manual intervention.

Exam trap

The trap here is confusing governance rules (which enforce compliance standards or auto-remediation) with the 'Assign ownership' feature, which specifically handles tag-based assignment of recommendations to users.

How to eliminate wrong answers

Option A is wrong because regulatory compliance standards are used to assess compliance against frameworks (e.g., CIS, NIST) and send email notifications for compliance drift, not to assign recommendations to owners based on tags. Option B is wrong because creating a workbook only provides a visual list of recommendations; it does not automate assignment to team leads based on tags. Option D is wrong because a governance rule that applies a compliance standard enforces compliance policies (e.g., auto-remediation), but it does not assign ownership of recommendations to specific users based on resource tags.

Practice this question →
336
Multi-Selectmedium

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

Select 2 answers
A.Create a new analytics rule based on an incident.
B.Assign an incident to a specific analyst.
C.Modify the data connector's polling interval.
D.Run a playbook automatically when an incident is created.
E.Automatically create an incident from a log event.
AnswersB, D

Assigning an incident to a specific analyst is a supported automation rule action, where you can set the owner to a particular Microsoft Entra ID user or group. This action is frequently used to implement dynamic triage and routing, such as sending all high-severity incidents to a senior threat hunter or specific incident responder as soon as the incident is created. It exists as a first-class action in the automation rule configuration pane.

Why this answer

Microsoft Sentinel automation rules can directly assign an incident to a specific analyst using the 'Assign owner' action. This allows security operations teams to automatically route incidents to the appropriate personnel based on criteria such as severity, tactic, or entity, improving response efficiency.

Exam trap

Microsoft often tests the distinction between automation rules (which act on incidents/alerts) and analytics rules (which generate incidents from log data), causing candidates to confuse the scope of automation rule actions.

Practice this question →
337
MCQmedium

Refer to the exhibit. You are reviewing a KQL query used in a Microsoft Sentinel scheduled analytics rule. What is the primary purpose of this query?

A.To investigate a new type of attack pattern
B.To identify which accounts are associated with the most incidents
C.To find accounts that have generated false positive alerts
D.To detect accounts that have triggered a high number of suspicious process alerts within 7 days
AnswerD

This query correctly identifies accounts that fire a high number of 'suspicious process' alerts within a 7-day lookback. It uses a filter for that alert name, summarize by AccountName to count occurrences, and then sets a threshold of more than 5 alerts—surfacing users whose process execution behavior is repeatedly flagged as suspicious. The time window and threshold are both configurable, thereby allowing defenders to tune the query to their environment's baseline noise.

Why this answer

The query uses `summarize` with `dcount(EventID)` to count distinct process creation events per account, then filters for accounts with a count greater than 10 using `where EventCount > 10`. The `where TimeGenerated > ago(7d)` restricts the time window to the last 7 days. This pattern is designed to detect accounts that have triggered a high number of suspicious process alerts (EventID 4688) within a week, making D correct.

Exam trap

The trap here is that candidates may confuse counting process alerts (EventID 4688) with counting incidents or false positives, leading them to select options B or C without recognizing the query's focus on raw event aggregation over a specific time window.

How to eliminate wrong answers

Option A is wrong because the query does not analyze new attack patterns; it simply aggregates known process creation events by account without comparing to baselines or identifying novel behaviors. Option B is wrong because the query does not correlate accounts with incidents; it counts process alerts, not incidents, and incidents are not referenced in the query. Option C is wrong because the query does not evaluate alert accuracy or false positives; it only counts raw process creation events without any mechanism to distinguish true positives from false positives.

Practice this question →
338
MCQhard

Your company has a hybrid environment with Microsoft Sentinel and Microsoft Defender for Cloud. You notice that the 'Priority' field in Sentinel incidents is not being populated correctly. You need to ensure that Sentinel incidents inherit the priority from Microsoft Defender for Cloud alerts. What should you configure?

A.Enable the 'Sync incidents and alerts' setting in Microsoft Defender XDR.
B.Configure the Microsoft Defender for Cloud data connector to map severity and use an automation rule to set priority based on severity.
C.Use a workbook to display priority and manually update incidents.
D.Create an analytics rule that queries Microsoft Defender for Cloud alerts and sets the priority in the incident creation.
AnswerB

The Microsoft Defender for Cloud data connector ingests security alerts into Microsoft Sentinel and its configuration maps each alert's severity to the incident severity field, preserving the original alert's impact level. You then create an automation rule that triggers when an incident is created and sets the incident's priority (for example, via a tag or custom property) based on that mapped severity. This is the only option that correctly combines ingestion-level severity mapping with automated, rule-based priority assignment without manual effort or duplicate-creation risk.

Why this answer

Microsoft Defender for Cloud alerts include a severity field, and the Microsoft Defender for Cloud data connector in Sentinel can ingest this severity. By mapping the severity in the connector configuration, you can then use an automation rule to set the Sentinel incident's 'Priority' field based on the mapped severity, ensuring inheritance from Defender for Cloud alerts.

Exam trap

The trap here is that candidates often confuse the 'severity' field (which is automatically mapped by the connector) with the custom 'Priority' field, assuming they are the same or that synchronization settings like 'Sync incidents and alerts' will automatically populate Priority, when in fact Priority requires explicit automation rule configuration.

How to eliminate wrong answers

Option A is wrong because the 'Sync incidents and alerts' setting in Microsoft Defender XDR synchronizes incidents between Defender XDR and Sentinel, but it does not map or populate the custom 'Priority' field in Sentinel incidents; it only syncs incident metadata. Option C is wrong because workbooks are visualization tools and cannot automatically update incident fields; manually updating incidents is not a scalable or automated solution for ensuring priority inheritance. Option D is wrong because analytics rules create new incidents from queries, but they do not modify the priority of existing incidents that are already ingested from Defender for Cloud; the priority must be set during or after ingestion via the data connector and automation rules.

Practice this question →
339
MCQeasy

Your organization has Microsoft Defender for Cloud Apps enabled. You need to generate an alert when a user downloads more than 100 files from SharePoint in one hour. What should you create?

A.A data loss prevention (DLP) policy in Microsoft Purview.
B.A custom alert in Microsoft Sentinel using the CloudAppEvents table.
C.An app governance policy in Microsoft Defender for Cloud Apps.
D.An anomaly detection policy in Microsoft Defender for Cloud Apps.
AnswerD

An anomaly detection policy in Microsoft Defender for Cloud Apps uses user and entity behavior analytics (UEBA) to build a per-user baseline of normal activity. When a user's activity volume significantly deviates from that baseline—for example, an unusually high number of file downloads or sign-in events—the policy generates an alert, making it the correct native mechanism for this scenario.

Why this answer

An anomaly detection policy in Microsoft Defender for Cloud Apps is designed to detect unusual user behavior, such as mass file downloads, by establishing a baseline and triggering alerts when activity deviates from the norm. This policy type specifically supports the scenario of detecting a user downloading more than 100 files from SharePoint in one hour, as it can be configured with custom thresholds for file download activity.

Exam trap

The trap here is that candidates often confuse anomaly detection policies with DLP policies, assuming that any data exfiltration scenario must be handled by DLP, but DLP policies in Purview are content-based, not volume-based, making anomaly detection the correct choice for this behavioral threshold scenario.

How to eliminate wrong answers

Option A is wrong because a data loss prevention (DLP) policy in Microsoft Purview focuses on preventing data exfiltration by inspecting content and applying actions like blocking or encrypting, not on detecting volume-based anomalies like a high number of downloads. Option B is wrong because a custom alert in Microsoft Sentinel using the CloudAppEvents table would require ingesting logs and writing a KQL query, which is a more complex, post-facto detection method rather than a native, real-time policy within Defender for Cloud Apps. Option C is wrong because an app governance policy in Microsoft Defender for Cloud Apps is specifically for managing and monitoring OAuth-enabled apps (e.g., permissions, consent), not for detecting user behavior anomalies like mass file downloads.

Practice this question →
340
MCQhard

You are a security analyst for a company that uses Azure Firewall. You are reviewing a custom rule deployed via Azure Firewall Manager. The exhibit shows the rule configuration. The rule is intended to block inbound traffic from known Tor exit nodes. However, a recent incident involved an attacker using a Tor exit node with IP 138.197.5.5 to access an internal web server on port 8080. The log shows the traffic was ALLOWED. What is the most likely reason the rule did not block the traffic?

A.The destination port 8080 is not listed in the rule.
B.The source address range does not include 138.197.5.5.
C.The rule type is 'Prevention' but should be 'Detection'.
D.The rule priority is too low and is overridden by a higher priority rule.
AnswerA

The application rule's destination port list is the crux: it only specifies 443 (HTTPS) and 80 (HTTP), so any outbound connection to port 8080 does not match the rule's conditions, even when the destination FQDN or IP is otherwise covered. A matching source and destination are not enough; for an Azure Firewall application rule to apply, the protocol:port must also be present in the rule. Because 8080 is absent, the traffic bypasses this deny action, which explains why the connection was allowed.

Why this answer

The rule is configured to block traffic on destination port 80, but the attacker used port 8080. Azure Firewall rules are explicit; if the destination port in the traffic does not match any port specified in the rule, the rule is not applied, and the traffic is evaluated by subsequent rules or default allow logic. Since the rule only lists port 80, traffic to port 8080 is not matched, and thus the rule does not block it.

Exam trap

The trap here is that candidates assume a rule blocking a source IP will block all traffic from that IP, but Azure Firewall rules require exact port matching, and the rule only specifies port 80, not port 8080.

How to eliminate wrong answers

Option B is wrong because the exhibit shows the source address range includes 138.197.5.5, so the source IP is correctly covered. Option C is wrong because Azure Firewall Manager does not use 'Prevention' or 'Detection' rule types; those are concepts from other security products like Microsoft Defender for Cloud or IDS/IPS systems, not Azure Firewall custom rules. Option D is wrong because rule priority determines the order of evaluation, but if the rule does not match the traffic (due to port mismatch), priority is irrelevant; the rule is simply skipped.

Practice this question →
341
MCQmedium

Your organization uses Microsoft Defender for Office 365. You want to automatically isolate a user's mailbox if a high-confidence phishing email is detected. Which Microsoft Sentinel automation should you use?

A.Configure a workbook to display the alert and manually isolate the mailbox.
B.Create a playbook that uses the Microsoft Graph API to apply a mailbox litigation hold or block access.
C.Enable the Office 365 connector and configure automatic response in the data connector.
D.Create a scheduled analytics rule that isolates the mailbox when triggered.
AnswerB

Playbooks in Microsoft Sentinel are Azure Logic Apps workflows that automate response actions when triggered by an incident or alert. By calling the Microsoft Graph API, a playbook can programmatically apply a litigation hold to preserve mailbox content or block user access through conditional access policies. This provides a reliable, repeatable SOAR solution that integrates with Office 365 without requiring manual intervention.

Why this answer

Microsoft Sentinel playbooks, built on Azure Logic Apps, can use the Microsoft Graph API to perform automated remediation actions like applying a mailbox litigation hold or blocking user access. This enables automatic isolation of a user's mailbox when a high-confidence phishing email is detected, which is a key incident response capability in Defender for Office 365.

Exam trap

The trap here is that candidates often confuse data connectors (which only ingest data) with automated response capabilities, or assume that analytics rules can directly execute remediation actions, when in fact only playbooks (or automation rules that invoke playbooks) can perform such actions.

How to eliminate wrong answers

Option A is wrong because workbooks are visualization tools for displaying data and alerts, not automation mechanisms; they cannot perform actions like mailbox isolation. Option C is wrong because the Office 365 data connector ingests logs and alerts into Sentinel but does not provide native automatic response configuration for mailbox isolation; automated responses require playbooks or custom logic. Option D is wrong because scheduled analytics rules only generate alerts based on query schedules; they cannot directly execute remediation actions like mailbox isolation — that requires a playbook or automation rule.

Practice this question →
342
Multi-Selecthard

Your organization uses Microsoft Sentinel and has enabled user and entity behavior analytics (UEBA). You need to identify which two data sources are required to enable UEBA in Microsoft Sentinel. (Choose two.)

Select 2 answers
A.Azure Activity logs
B.Azure Active Directory (Azure AD) audit logs
C.Microsoft Defender for Identity logs
D.Microsoft 365 audit logs
E.Azure Active Directory (Azure AD) sign-in logs
AnswersB, E

Azure AD audit logs are required for UEBA because they track administrative and user activities such as group changes, role assignments, and application consent. These logs help UEBA establish normal behavior and detect suspicious changes. Together with sign-in logs, they form the minimum data set for UEBA.

Why this answer

To enable UEBA in Microsoft Sentinel, you must ingest Azure AD sign-in logs and Azure AD audit logs. These provide the necessary user authentication and activity data for behavioral baselining. Other logs can be added later to enrich UEBA but are not mandatory for the initial enablement.

Exam trap

The trap here is assuming that all Microsoft 365 or Defender logs are required; in fact, only Azure AD sign-in and audit logs are prerequisites for UEBA.

Practice this question →
343
MCQmedium

You are a security operations analyst for a company that uses Microsoft Sentinel. The SOC manager wants to ensure that only incidents with a severity of High or Critical are automatically assigned to the on-call analyst, while all other incidents remain unassigned. You need to create an automation rule that meets this requirement. What should you do first?

A.Create a playbook that runs on incident creation, parses the incident severity, and if High or Critical, assigns the incident using the Microsoft Sentinel API.
B.Create a scheduled query rule that detects High and Critical incidents and then triggers a Logic App to assign them.
C.Create a new automation rule and set the trigger to "When incident is created". Add a condition that checks if the incident severity is High or Critical. Then add an action to assign the incident to the on-call analyst.
D.Modify the incident settings in Microsoft Sentinel to automatically assign all High and Critical incidents to the on-call analyst by default.
AnswerC

This approach uses the native automation rule capability in Microsoft Sentinel to evaluate incident severity at creation time and assign accordingly. Automation rules support conditions based on incident properties, including severity, and can perform assignment actions. This directly satisfies the requirement without custom logic or external components.

Why this answer

Automation rules in Microsoft Sentinel are designed to automate incident handling tasks such as assignment, tagging, and status changes. They can be triggered when an incident is created and include conditions based on incident properties. This makes them the ideal solution for conditionally assigning incidents based on severity without custom development.

Exam trap

The trap here is confusing automation rules with playbooks; automation rules are lightweight and built-in for incident management, while playbooks are more powerful but require Logic Apps and are better suited for complex orchestration.

Practice this question →
344
MCQeasy

You are configuring Microsoft Sentinel to send email notifications to the SOC manager when a high-severity incident is created. What should you use?

A.Configure an analytics rule to send an email when an incident is created.
B.Create a playbook that sends an email and assign it to an automation rule.
C.Use a workbook to track incidents and configure an alert for email.
D.Add the SOC manager's email to a watchlist and configure a scheduled query.
AnswerB

The correct approach is to create a playbook—a Logic Apps workflow—that uses a connector such as Office 365 Outlook to send an email. You then assign this playbook to an automation rule with the trigger set to 'When incident is created.' This enables automatic, reliable email notifications to your SOC team whenever a new incident is generated.

Why this answer

Automation rules in Microsoft Sentinel can trigger a playbook (an Azure Logic Apps workflow) when an incident is created. The playbook can include an action to send an email notification, enabling automated response to high-severity incidents without manual intervention.

Exam trap

The trap here is confusing analytics rules with automation rules; candidates often think analytics rules can directly send emails, but they only generate alerts or incidents, while automation rules handle post-creation actions like playbook execution.

How to eliminate wrong answers

Option A is wrong because analytics rules generate alerts, not incidents directly; while they can be configured to create incidents, they do not have native email notification capabilities for incident creation. Option C is wrong because workbooks are visualization tools for data analysis and cannot trigger email alerts; they are not designed for automated actions. Option D is wrong because watchlists are used for correlation and enrichment in queries, not for triggering email notifications; a scheduled query can generate alerts but does not directly send emails to a specific recipient without additional automation.

Practice this question →
345
MCQhard

You are reviewing a Microsoft Sentinel analytics rule configuration. The rule is not generating incidents as expected. What is the most likely cause?

A.The queryFrequency and queryPeriod are mismatched.
B.The suppressionDuration is set to 5 hours, suppressing alerts.
C.The action type 'MFA disabled' is not supported in IdentityLogonEvents.
D.The query references a table that is not available in the Sentinel workspace.
AnswerD

IdentityLogonEvents is a table that is only present when the Microsoft Defender for Identity data connector (or Microsoft 365 Defender connector) is enabled and streaming data into the Sentinel workspace. Without that connector, the table does not exist, so the analytics rule query fails with a 'table not found' error when it tries to run. This is the correct explanation for the rule failing.

Why this answer

If the query in an analytics rule references a table that does not exist in the Microsoft Sentinel workspace, the rule will fail to execute or return no results, preventing incident generation. This is a common misconfiguration when migrating or authoring rules that depend on specific data connectors or schema that have not been onboarded.

Exam trap

The trap here is that candidates often focus on query logic or timing parameters, but Microsoft tests the foundational requirement that referenced tables must exist in the workspace for the rule to function at all.

How to eliminate wrong answers

Option A is wrong because queryFrequency and queryPeriod can be mismatched without preventing incident generation; the rule will still run, though it may produce unexpected results or duplicate alerts. Option B is wrong because suppressionDuration suppresses alerts after they are generated, not preventing incident creation; incidents would still be created initially. Option C is wrong because 'MFA disabled' is a valid action type in IdentityLogonEvents (part of Microsoft Entra ID sign-in logs), and the rule would still generate incidents if the query is otherwise correct.

Practice this question →
346
MCQmedium

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

A.Configure a custom API connector in Sentinel to pull alerts from Defender for Cloud REST API every 5 minutes.
B.Enable continuous export in Defender for Cloud to send alerts to a Log Analytics workspace and then create a scheduled query in Sentinel.
C.Use the Microsoft Defender for Cloud data connector in Sentinel to stream alerts.
D.Create a Logic App that triggers on Defender for Cloud alerts and sends them to Sentinel via the Azure Monitor HTTP Data Collector API.
AnswerC

The Microsoft Defender for Cloud data connector is a built-in, native integration that streams security alerts and recommendations directly into Sentinel's SecurityAlert table in near real-time, without requiring custom code or polling intervals. It automatically synchronizes alert status, severity, and entities, allowing Sentinel to create incidents immediately and making it the lowest-latency, lowest-maintenance approach.

Why this answer

The Microsoft Defender for Cloud data connector in Microsoft Sentinel provides a native, direct integration that streams security alerts from Defender for Cloud into Sentinel with near-real-time latency. This connector uses the underlying Azure Resource Graph and alert APIs to push alerts automatically, eliminating the need for custom polling or additional orchestration, which ensures the least possible ingestion delay.

Exam trap

The trap here is that candidates often overcomplicate the solution by choosing custom integration methods (Logic Apps, API polling) or multi-step exports, failing to recognize that Microsoft's native data connector is specifically designed for this exact purpose with minimal latency and configuration.

How to eliminate wrong answers

Option A is wrong because a custom API connector polling the Defender for Cloud REST API every 5 minutes introduces a minimum 5-minute latency and adds unnecessary complexity, whereas the native connector streams alerts continuously with lower latency. Option B is wrong because continuous export sends alerts to a Log Analytics workspace, but then using a scheduled query in Sentinel to ingest them adds additional delay and requires manual configuration; the native connector directly streams alerts without intermediate steps. Option D is wrong because a Logic App triggered on Defender for Cloud alerts and using the Azure Monitor HTTP Data Collector API introduces additional latency from the trigger, execution, and data transfer, and is less efficient than the direct streaming provided by the native data connector.

Practice this question →
347
MCQhard

You have a Microsoft Sentinel automation rule that triggers a playbook. The playbook definition is shown in the exhibit. The playbook runs but no email is sent. What is the most likely cause?

A.The JSON syntax is invalid.
B.The email operation 'SendEmailV2' is deprecated.
C.The playbook uses a recurrence trigger instead of a Microsoft Sentinel trigger.
D.The connection name 'office365' is incorrect.
AnswerC

This is correct because automation rules require a playbook to start with a Microsoft Sentinel trigger (such as 'When Incident Created or Updated') to receive the incident payload. A recurrence trigger runs on a fixed schedule and does not accept any incident-specific parameters, so the automation rule cannot pass the incident ARM ID or properties to the playbook. As a result, the rule's action to run the playbook either fails validation or the playbook runs without the necessary incident context.

Why this answer

The playbook uses a recurrence trigger, which means it runs on a schedule (e.g., every hour) rather than being invoked by a Microsoft Sentinel incident or alert. A Microsoft Sentinel automation rule can only trigger a playbook that has a Microsoft Sentinel trigger (e.g., 'When a response to a Microsoft Sentinel incident is triggered'). Without the correct trigger, the playbook will execute on its schedule but will not receive the incident context or be invoked by the automation rule, so no email is sent.

Exam trap

The trap here is that candidates assume any playbook that runs will work with an automation rule, but the trigger type must match the automation rule's invocation method; a recurrence trigger runs independently and does not receive the incident context, causing the email to fail silently.

How to eliminate wrong answers

Option A is wrong because if the JSON syntax were invalid, the playbook would fail to save or would show a syntax error in the designer; it would not run at all. Option B is wrong because 'SendEmailV2' is a current, supported operation in Microsoft Sentinel and Logic Apps; it is not deprecated. Option D is wrong because an incorrect connection name would cause a connection error at runtime, not a silent failure where the playbook runs but no email is sent; the connection name is validated when the playbook is saved or run.

Practice this question →
348
MCQeasy

Your organization is migrating from Azure Active Directory to Microsoft Entra ID. You need to ensure that Microsoft Sentinel continues to receive identity logs. What should you do?

A.Install the new Microsoft 365 Defender connector for identity logs.
B.No action is required; the existing connector automatically updates.
C.Reconfigure the diagnostic settings to send logs to a new Log Analytics workspace.
D.Create a new data connector for Microsoft Entra ID.
AnswerB

No action is required because the Microsoft Entra ID connector (formerly Azure AD) uses the same underlying Microsoft Graph API endpoints; the rebranding does not change the data schema or the retrieval method. The connector automatically inherits the updated display name and continues sending audit and sign-in logs to the same Log Analytics workspace. Recreating or reinstalling it would introduce unnecessary disruption and potential data gaps.

Why this answer

The migration from Azure Active Directory (Azure AD) to Microsoft Entra ID is a rebranding and consolidation effort that does not change the underlying service endpoints, APIs, or log schemas. The existing Azure AD data connector in Microsoft Sentinel continues to collect identity logs (e.g., Sign-in logs, Audit logs, Provisioning logs) without any reconfiguration because the connector is tied to the same underlying directory service. Therefore, no action is required; the existing connector automatically updates to reflect the new name.

Exam trap

The trap here is that candidates assume a rebranding or migration requires reconfiguring connectors or creating new ones, when in fact the underlying service and API endpoints remain unchanged, so the existing connector continues to function automatically.

How to eliminate wrong answers

Option A is wrong because the Microsoft 365 Defender connector is designed for security alerts and incidents from Microsoft 365 Defender, not for identity logs like Sign-in or Audit logs; identity logs are collected via the Azure AD (now Entra ID) connector. Option C is wrong because diagnostic settings are used to stream resource logs (e.g., from Azure resources) to a Log Analytics workspace, but identity logs from Entra ID are ingested via the dedicated data connector, not through diagnostic settings; reconfiguring diagnostic settings would not affect the existing connector. Option D is wrong because creating a new data connector for Microsoft Entra ID is unnecessary and would duplicate data ingestion; the existing Azure AD connector is automatically updated to reflect the Entra ID branding and continues to function without manual intervention.

Practice this question →
349
MCQmedium

Your organization uses Microsoft Defender for Identity (MDI) and Microsoft Sentinel. You notice that MDI alerts are not appearing in Sentinel. You have already installed the MDI data connector and configured the workspace. What is the most likely cause?

A.The workspace is in a different region than MDI
B.The Microsoft 365 Defender connector is not installed
C.The data connector is not enabled, even though it is installed
D.Microsoft Defender for Identity is not licensed
AnswerC

Installing the Microsoft Defender for Identity data connector from the Content Hub only copies the connector into your Sentinel workspace; you must separately enable it by opening the connector page and clicking 'Connect' to establish the data flow. In the common scenario where the connector is installed but not enabled, the Health and Status column shows 'Disconnected' while the connector still appears as installed. Without this explicit enablement step, even an active MDI deployment will not send alerts to Sentinel, so the alerts remain missing from the workspace.

Why this answer

The most likely cause is that the MDI data connector, although installed, is not enabled. In Microsoft Sentinel, installing a data connector only makes it available; you must explicitly enable it to start ingesting data. Without enabling the connector, alerts from Microsoft Defender for Identity will not flow into Sentinel, even if the workspace is correctly configured.

Exam trap

The trap here is that candidates confuse 'installed' with 'enabled', assuming that installing a data connector automatically starts data ingestion, when in fact a separate enablement step is required.

How to eliminate wrong answers

Option A is wrong because the workspace region does not affect data ingestion from MDI; Sentinel and MDI can operate in different regions as long as the connector is properly enabled. Option B is wrong because the Microsoft 365 Defender connector is not required for MDI alerts; MDI has its own dedicated data connector in Sentinel. Option D is wrong because the question states that MDI alerts are being generated (you notice they are not appearing in Sentinel), which implies MDI is already licensed and functioning; the issue is specifically with the connector's enabled state.

Practice this question →
350
MCQmedium

Your SOC team uses Microsoft Sentinel to manage incidents. You want to categorize incidents based on the MITRE ATT&CK technique. You notice that some incidents are not being tagged with the correct technique. What should you check first?

A.The playbook assigned to the incident is overriding the technique tag.
B.The incident creation rule in the automation section is misconfigured.
C.The data connector for the source service is not ingesting the required fields.
D.The analytics rule that generated the incident has the correct MITRE ATT&CK technique selected.
AnswerD

MITRE ATT&CK technique tagging is defined on the analytics rule itself; if the rule lacks the correct technique mapping, generated incidents inherit nothing. Checking the rule's technique selection addresses the root cause of missing tags.

Why this answer

MITRE ATT&CK technique tags on a Microsoft Sentinel incident are inherited directly from the analytics (detection) rule that generated the incident. If the rule was created without the correct technique mapped — or the mapping was later edited — every incident it produces will carry the wrong or missing tag. The first place to verify is therefore the analytics rule's 'Incident settings' / 'MITRE ATT&CK' mapping, not downstream automation.

Exam trap

SC-200 often tests the assumption that automation (playbooks or automation rules) can rewrite incident metadata like MITRE technique tags, when in fact the analytics rule is the authoritative source.

How to eliminate wrong answers

Option A is wrong because playbooks (Logic Apps) run after incident creation and do not natively rewrite the MITRE technique taxonomy field — they can add comments, tags, or tasks, but the technique mapping is set by the analytics rule. Option B is wrong because automation rules control triage actions (assign, tag, close, run playbook) and do not author the ATT&CK technique metadata on the incident. Option C is wrong because a data connector that fails to ingest fields would prevent the rule from firing at all or produce malformed events, not silently mis-tag the technique on an incident that was successfully created.

Practice this question →
351
MCQeasy

Your organization uses Microsoft Sentinel for security operations. You need to ensure that a specific AWS CloudTrail log is ingested into Microsoft Sentinel. Which data connector should you use?

A.AWS CloudTrail Connector
B.Amazon Web Services S3 Connector
C.Azure Functions (AWS)
D.AWS Security Hub Connector
AnswerB

The AWS S3 connector is the correct data connector because it directly ingests CloudTrail log files from an S3 bucket into Microsoft Sentinel. It uses an Azure Functions app to poll the bucket or subscribe to an SQS queue, retrieving CloudTrail JSON objects and translating them into the AWSCloudTrail table. This makes it the sole standard first-party connector for shipping CloudTrail logs into the SIEM.

Why this answer

The Amazon Web Services S3 Connector is the correct choice because AWS CloudTrail logs are stored as JSON files in an S3 bucket. Microsoft Sentinel ingests these logs by connecting directly to the S3 bucket, reading the CloudTrail log files, and pulling them into the Log Analytics workspace. The AWS CloudTrail Connector, by contrast, is a legacy connector that requires a separate AWS Lambda function and is deprecated in favor of the S3 connector.

Exam trap

The trap here is that candidates confuse the legacy AWS CloudTrail Connector (Option A) with the modern Amazon Web Services S3 Connector, assuming the name 'CloudTrail' is the correct match, when in fact the S3 connector is the current recommended method for ingesting CloudTrail logs.

How to eliminate wrong answers

Option A is wrong because the AWS CloudTrail Connector is a legacy connector that requires an AWS Lambda function to forward logs, and it is deprecated in favor of the Amazon Web Services S3 Connector. Option C is wrong because Azure Functions (AWS) is a generic compute service used for custom integrations, not a dedicated data connector for CloudTrail logs. Option D is wrong because the AWS Security Hub Connector ingests security findings from AWS Security Hub, not raw CloudTrail log files.

Practice this question →
352
MCQmedium

Your organization uses Microsoft Defender for Cloud Apps. You need to block downloads from a specific app for users outside the corporate network. What should you configure?

A.A session policy
B.An anomaly detection alert
C.A file policy
D.An access policy
AnswerA

A session policy is correct because it operates in real time using Conditional Access App Control to reverse-proxy user actions, enabling granular controls such as blocking a download based on the user's geolocation. Session policies are the only option here that can intercept and enforce at the individual action level within an active application session, not just at sign-in or post-hoc.

Why this answer

A session policy in Microsoft Defender for Cloud Apps allows you to monitor and control user activities in real time by leveraging reverse proxy architecture. To block downloads from a specific app for users outside the corporate network, you configure a session policy with the action 'Block' and apply a condition based on the IP address tag (e.g., 'Not corporate IP range'). This enforces the restriction at the moment the user attempts to download, without affecting other app activities.

Exam trap

The trap here is confusing access policies (which control sign-in) with session policies (which control in-session actions), leading candidates to choose D when they need granular action-level control.

How to eliminate wrong answers

Option B is wrong because an anomaly detection alert only generates alerts for suspicious behavior (e.g., impossible travel) but does not actively block downloads; it is a detection-only control. Option C is wrong because a file policy is designed to scan and govern files at rest (e.g., DLP for stored content) and cannot enforce real-time download blocking based on network location. Option D is wrong because an access policy controls authentication and authorization (e.g., requiring MFA or blocking sign-in) but does not granularly block specific actions like downloads within a session.

Practice this question →
353
Multi-Selectmedium

Which THREE actions are recommended practices for managing Microsoft Sentinel costs?

Select 3 answers
A.Set daily caps on high-volume tables.
B.Use Basic Logs tier for verbose logs.
C.Implement ingestion-time data transformation to filter out noise.
D.Ingest all logs to ensure complete visibility.
E.Increase retention period to 1 year for all tables.
AnswersA, B, C

Setting a daily cap on high-volume tables is a cost-control safeguard that stops ingestion once the defined quota is reached, preventing runaway spend from unexpected data spikes. However, you must configure the cap carefully so that critical security telemetry is not dropped during an incident, since any data exceeding the cap is discarded. This practice is explicitly recommended in Microsoft Sentinel and Log Analytics cost optimization guidance.

Why this answer

Setting daily caps on high-volume tables is a recommended practice because it prevents unexpected cost overruns by limiting the amount of data ingested into expensive tables like SecurityEvent or CommonSecurityLog. Microsoft Sentinel bills per GB ingested, so capping tables that generate large volumes of noise (e.g., verbose Windows event logs) directly controls costs without necessarily impacting security visibility, as critical alerts can still be generated from other sources.

Exam trap

The trap here is that candidates often confuse 'complete visibility' (Option D) with best practice, but Microsoft Sentinel explicitly recommends filtering noise at ingestion to reduce costs and improve signal-to-noise ratio, not ingesting everything.

Practice this question →
354
Multi-Selectmedium

Which TWO roles are included in Microsoft Sentinel built-in roles? (Choose two.)

Select 2 answers
A.Microsoft Sentinel Responder
B.Microsoft Sentinel Administrator
C.Microsoft Sentinel Reader
D.Microsoft Sentinel Operator
E.Global Administrator
AnswersA, C

Microsoft Sentinel Responder is a built-in role intended for security operations analysts who need to triage and manage incidents. It grants permissions to view and act on incidents, including changing their status, assigning ownership, and adding comments, while deliberately excluding write access to Sentinel configuration such as analytics rules or data connectors. This role supports day-to-day incident response without enabling broad changes to the Sentinel environment.

Why this answer

Microsoft Sentinel Responder is a built-in role that grants permissions to respond to incidents, including the ability to update incidents, dismiss alerts, and take response actions. This role is designed for security operations center (SOC) analysts who need to triage and remediate threats without full administrative access.

Exam trap

The trap here is that candidates often confuse the 'Operator' role name with a valid built-in role, or assume 'Administrator' is a built-in role when the correct term is 'Contributor', leading them to select incorrect options that sound plausible but do not exist in Sentinel's RBAC model.

Practice this question →
355
MCQmedium

Your organization uses Microsoft Sentinel and Microsoft Defender XDR. A new security policy requires that all incidents involving 'Credential Access' tactics be automatically assigned to the Tier 1 SOC team and have a severity of 'High'. You need to configure this automation. What should you do?

A.Configure an automated investigation rule in Microsoft Defender XDR to assign incidents.
B.Create a playbook in Microsoft Sentinel that runs on incident creation and assigns the incident to Tier 1 SOC.
C.Create an automation rule in Microsoft Sentinel with conditions for tactic 'Credential Access' and actions to assign to Tier 1 SOC and set severity to High.
D.Modify the analytics rule that generates the incidents to include the assignment and severity settings.
AnswerC

Automation rules in Microsoft Sentinel natively evaluate incident properties such as tactics and can trigger actions including owner assignment and severity modification, satisfying the policy's requirement that Credential Access incidents be auto-assigned to Tier 1 SOC at High severity. Unlike playbooks, automation rules run directly on incident creation without requiring a Logic Apps workflow.

Why this answer

Automation rules in Microsoft Sentinel allow you to define conditions based on incident properties, such as tactic, and then trigger actions like assigning the incident to a specific owner (Tier 1 SOC) and setting the severity. This directly meets the policy requirement without requiring external playbooks or modifying analytics rules.

Exam trap

The trap here is that candidates may confuse automation rules (incident-level) with automated investigation rules (Defender XDR) or think that analytics rules can directly assign incidents, when in fact automation rules are the correct post-creation mechanism for assignment and severity changes.

How to eliminate wrong answers

Option A is wrong because automated investigation rules in Microsoft Defender XDR are designed for automated response actions (e.g., isolating devices) and cannot assign incidents to a SOC team or set severity based on MITRE tactics. Option B is wrong because while a playbook can assign incidents, it requires additional configuration and is not the simplest or most direct method; automation rules are the native, recommended approach for incident-level automation in Sentinel. Option D is wrong because analytics rules generate alerts/incidents but do not support actions like assignment or severity override; those are post-creation automation tasks.

Practice this question →
356
MCQeasy

Refer to the exhibit. You execute the Azure CLI command to create an analytics rule in Microsoft Sentinel. The rule is created but never triggers. What is the most likely cause?

A.The query references a column that does not exist in SigninLogs
B.The --enabled parameter should be set to false
C.The severity must be set to Low for the rule to trigger
D.The resource group name is incorrect
AnswerA

The KQL query in the rule references a column that is not present in the SigninLogs schema. The correct property is riskLevelDuringSignIn, written in camelCase, but the query uses a variant such as riskLevelDuringSignin or plain riskLevel, which Log Analytics will reject because that column does not exist. When the scheduled query runs, Kusto throws a 'column does not exist' error and returns no rows, so the rule never creates an alert.

Why this answer

If the KQL query in the analytics rule references a column that does not exist in the SigninLogs table, the query will run but return zero results (or an error depending on the query structure), causing the rule to never trigger an alert. In Microsoft Sentinel, analytics rules rely on the query to produce matching results; if the column name is misspelled or absent, no events will match the rule conditions, so no incidents are generated.

Exam trap

The trap here is that candidates may assume a rule creation success means the query is valid, but Microsoft Sentinel does not validate column existence in KQL queries at creation time—only at execution time, leading to silent failures.

How to eliminate wrong answers

Option B is wrong because setting --enabled to false would disable the rule entirely, but the question states the rule is created and never triggers—implying it is enabled but not firing; the issue is not about the enabled state. Option C is wrong because severity (Low, Medium, High) does not affect whether a rule triggers; severity only determines the classification of the incident once the rule fires. Option D is wrong because if the resource group name were incorrect, the Azure CLI command would fail during creation with a resource-not-found error, but the rule was successfully created, so the resource group name is valid.

Practice this question →
357
MCQhard

Refer to the exhibit. You are reviewing a Microsoft Sentinel automation rule created via ARM template. You notice that the rule is not triggering the playbook when a high-severity incident is created. What is the most likely cause?

A.The playbook resource ID is missing the 'locations' parameter.
B.The automation rule is disabled by default and needs to be enabled.
C.The playbook does not have a trigger for Microsoft Sentinel.
D.The condition syntax is invalid; automation rules in ARM templates require specific operator properties.
AnswerD

Automation rule conditions in ARM templates must follow a strict schema: each condition is an object containing 'property', 'operator', and 'value', and the operator must be a valid, case-sensitive value such as 'equals', 'notEquals', or 'contains'. If the template uses an unsupported operator like 'Equal' or otherwise misstructures the condition, Azure Resource Manager fails with a validation error. This is exactly the issue in the exhibit—the condition syntax is invalid because of the operator property, making this the correct answer.

Why this answer

Automation rules in ARM templates require explicit operator properties (e.g., 'Equals', 'Contains') in the condition syntax. If the condition is written without these operators or uses invalid JSON structure, the rule will fail to evaluate triggers correctly, preventing the playbook from being invoked when a high-severity incident is created.

Exam trap

Microsoft often tests the nuance that ARM templates require explicit operator properties in automation rule conditions, while the portal UI may hide this complexity, leading candidates to overlook syntax validation errors.

How to eliminate wrong answers

Option A is wrong because the 'locations' parameter is not a required property for a playbook resource ID in an automation rule; the resource ID only needs the subscription, resource group, and playbook name. Option B is wrong because automation rules created via ARM templates are not disabled by default; they are enabled unless explicitly set to 'disabled' in the template. Option C is wrong because the playbook does not need a separate trigger for Microsoft Sentinel; the automation rule itself invokes the playbook via its action, and the playbook's first step is typically a Microsoft Sentinel connector trigger.

Practice this question →
358
MCQmedium

You are a SOC analyst using Microsoft Defender XDR. You notice that a user's account has been compromised and is being used to send phishing emails. You need to prevent the user from sending any more emails while preserving the ability to receive emails for investigation. What should you do?

A.Remove the user's Microsoft 365 license.
B.Disable the user account in Microsoft Entra ID.
C.Restrict the user from sending email using Microsoft Defender for Office 365 mailbox restrictions.
D.Delete the user's mailbox in Exchange Online.
AnswerC

Use the mailbox restriction feature in Microsoft Defender for Office 365 (or the corresponding Exchange Online mail flow rule) to place a targeted 'Restrict sending' action on the user. This blocks only outbound email — both to internal and external recipients — while the user can still receive email, allowing you to continue monitoring for malicious replies or C2 activity. This is the recommended containment step for a compromised account that is sending spam or phishing, because it balances security with the ability to investigate.

Why this answer

Microsoft Defender for Office 365 mailbox restrictions allow you to block a user from sending email while still permitting them to receive messages. This is done via the 'Restrict user from sending email' policy in the Microsoft 365 Defender portal, which applies a transport rule that rejects outbound mail from the user but leaves inbound delivery intact, enabling forensic analysis of incoming phishing responses.

Exam trap

The trap here is that candidates often confuse disabling the user account (which blocks all access) with a targeted email restriction, or they assume removing the license is a quick fix, not realizing it also stops email reception critical for investigation.

How to eliminate wrong answers

Option A is wrong because removing the user's Microsoft 365 license disables all services, including email reception, which would prevent the investigation from receiving incoming phishing replies. Option B is wrong because disabling the user account in Microsoft Entra ID blocks all authentication, including access to receive email via Exchange Online, and also prevents the account from being used for any other investigative purposes. Option D is wrong because deleting the user's mailbox in Exchange Online permanently removes all email data and prevents both sending and receiving, destroying evidence needed for investigation.

Practice this question →
359
Multi-Selecthard

Which THREE components are part of Microsoft's unified security operations platform (Microsoft Defender XDR)?

Select 3 answers
A.Microsoft Defender for Endpoint.
B.Microsoft Intune.
C.Microsoft Defender for Office 365.
D.Microsoft Defender for Identity.
E.Microsoft Sentinel.
AnswersA, C, D

Microsoft Defender for Endpoint is a core workload in Microsoft Defender XDR, providing endpoint detection and response (EDR), vulnerability management, and attack surface reduction. It ingests signals from endpoints and correlates them with other Defender workloads to enable automated investigation and remediation. As one of the three correct choices, it is a native component of the unified security operations platform.

Why this answer

Microsoft Defender XDR is Microsoft's unified security operations platform that integrates signals from across the Microsoft 365 ecosystem. Microsoft Defender for Endpoint is a core component, providing endpoint detection and response (EDR) capabilities, including behavioral-based detection, automated investigation, and threat hunting on Windows, macOS, Linux, Android, and iOS devices. It contributes telemetry such as process creation, network connections, and file events to the unified incident and alert correlation in the Defender XDR portal.

Exam trap

The trap here is that candidates often confuse Microsoft Sentinel as a component of Microsoft Defender XDR, when in fact Sentinel is a separate SIEM that can ingest data from Defender XDR but is not part of the unified platform itself.

Practice this question →
360
MCQhard

Refer to the exhibit. You have an automation rule in Microsoft Sentinel configured as shown. An analyst reports that low-severity incidents are not being closed automatically. The rule is enabled and has the highest order. What is the most likely reason?

A.The rule is triggered by alerts, not incidents.
B.The automation rule does not have the required permissions to modify incidents.
C.The rule is set to close incidents with classification 'TruePositive' but low-severity incidents are not true positives.
D.The rule is disabled due to a conflict with another rule.
AnswerB

To close incidents, the automation rule's service identity must hold Microsoft Sentinel Contributor (or a custom role with equivalent write permissions) on the workspace. When the identity lacks those permissions, the automation rule stays enabled and the trigger fires, but the 'Close incident' action fails in the activity log due to Azure RBAC denial. Granting the rule's identity proper Sentinel permissions and retrying the incident will allow the closure to complete.

Why this answer

The automation rule requires an automation account with Microsoft Sentinel contributor permissions to run playbooks or modify incidents. Without these permissions, the rule cannot close incidents regardless of its order or enabled status. The rule being enabled and having the highest order does not override the missing permissions.

Exam trap

The SC-200 exam often tests the misconception that a rule's order or enabled state is the primary factor, when in fact missing permissions for the automation account cause silent failures in incident modification actions.

How to eliminate wrong answers

Option A is wrong because the exhibit shows the rule is triggered 'When incident is created,' not by alerts, so it is incident-triggered. Option C is wrong because the classification 'TruePositive' is a valid closing classification, and low-severity incidents can be true positives; the issue is not about classification validity. Option D is wrong because the rule is enabled and has the highest order, so there is no conflict or disabling effect from another rule.

Practice this question →
361
MCQeasy

Your organization uses Microsoft Sentinel and Microsoft Defender XDR. You want to ensure that incidents generated in Microsoft 365 Defender are automatically synchronized to Microsoft Sentinel. What should you configure?

A.Set up an automation rule to import incidents
B.Configure the Microsoft Sentinel connector in Microsoft Defender XDR
C.Create an analytics rule to query Defender XDR data
D.Enable the Microsoft Defender XDR data connector in Microsoft Sentinel
AnswerD

Enable the Microsoft Defender XDR data connector in Microsoft Sentinel to automatically synchronize incidents and alerts from Defender XDR into Sentinel. This official connector uses the Microsoft Graph API to ingest incidents from Defender for Endpoint, Defender for Identity, Defender for Office 365, and other Microsoft Defender products. Once connected, incident properties such as severity, status, and assigned analyst are kept in sync, enabling unified triage in Sentinel.

Why this answer

The Microsoft Defender XDR data connector in Microsoft Sentinel is specifically designed to synchronize incidents from Microsoft 365 Defender into Sentinel. When enabled, this connector uses the Microsoft Graph Security API to ingest incidents, alerts, and evidence, ensuring automatic and bidirectional synchronization without requiring additional automation rules or analytics queries.

Exam trap

The trap here is that candidates often confuse automation rules (which handle incident orchestration) with data connectors (which handle ingestion), leading them to select Option A instead of the correct data connector configuration.

How to eliminate wrong answers

Option A is wrong because automation rules in Sentinel are used to automate responses to incidents already in Sentinel, not to import incidents from external sources. Option B is wrong because the Microsoft Sentinel connector in Microsoft Defender XDR is not a standard configuration; the data flow is from Defender XDR to Sentinel, not the reverse, and the connector is configured in Sentinel, not in Defender XDR. Option C is wrong because analytics rules query data already ingested into Sentinel to generate new incidents, but they cannot import or synchronize existing incidents from Microsoft 365 Defender.

Practice this question →
362
Multi-Selectmedium

Which TWO of the following are valid methods to ingest custom logs into Microsoft Sentinel? (Choose two.)

Select 2 answers
A.Use Windows Event Forwarding to send custom logs to Sentinel.
B.Use the Azure Monitor Agent to collect custom logs via data collection rules.
C.Use the Application Insights connector to ingest custom logs.
D.Configure the Log Analytics agent to collect custom logs from a file.
E.Configure the syslog daemon to forward custom application logs.
AnswersB, D

The Azure Monitor Agent (AMA) is the current cross-platform data collection agent that supports custom logs by defining a data collection rule (DCR) specifying the source file path, log name, and table name. The DCR also allows a transform to parse or filter the log data before it lands in a Log Analytics workspace. This is the recommended modern approach for collecting custom file-based logs into Microsoft Sentinel.

Why this answer

The Azure Monitor Agent (AMA) can collect custom logs from text files on Windows and Linux machines by defining a data collection rule (DCR) that specifies the file path and parsing logic. This is the modern, recommended method for custom log ingestion into Log Analytics workspaces, which underpin Microsoft Sentinel.

Exam trap

The trap here is that candidates confuse Windows Event Forwarding (which forwards structured events) with custom log file collection, or assume syslog can handle arbitrary text logs when it is strictly for syslog-formatted messages.

Practice this question →
363
MCQhard

Refer to the exhibit. You are deploying an Azure Resource Manager (ARM) template to create a saved search in Microsoft Sentinel. However, the template does not create an analytics rule. What is missing to turn this saved search into a scheduled analytics rule?

A.A Schedule section with frequency and period
B.An IncidentConfiguration section
C.A Microsoft.OperationalInsights/workspaces/savedSearches/schedules resource
D.A Query property with a valid KQL
AnswerC

The Microsoft.OperationalInsights/workspaces/savedSearches/schedules resource is the missing deployable component in the classic Log Analytics alert model. A saved search alone only stores a query; it does nothing until a schedule child resource is attached to it to run the query repeatedly, define the frequency and time window, and send notifications when results match. This resource type is recognized by ARM as a child of the savedSearch resource and is required to create a classic scheduled alert. The correct answer is to add this schedule resource to the template, even though modern deployments commonly use Microsoft.Insights/scheduledQueryRules instead.

Why this answer

In Microsoft Sentinel, a saved search alone is just a stored KQL query; to turn it into a scheduled analytics rule that runs periodically and generates alerts, you must define a schedule resource under the saved search. The correct resource type is `Microsoft.OperationalInsights/workspaces/savedSearches/schedules`, which specifies the frequency and time period for the query execution. Without this schedule resource, the saved search remains static and never triggers alerts.

Exam trap

The trap here is that candidates assume a saved search with a KQL query automatically becomes a scheduled analytics rule, when in fact a separate schedule resource is required to define the run frequency and time window.

How to eliminate wrong answers

Option A is wrong because a Schedule section with frequency and period is not a top-level property of the saved search resource; it must be defined as a separate child resource of type `schedules` under the saved search. Option B is wrong because IncidentConfiguration is used to configure alert grouping and incident creation settings within an analytics rule, but it is not the missing component that turns a saved search into a scheduled rule—the schedule itself is required first. Option D is wrong because a Query property with a valid KQL is already present in the saved search definition; the issue is not the query but the lack of a schedule to run it periodically.

Practice this question →
364
Multi-Selecthard

Which THREE components are required to enable automated investigation and response (AIR) in Microsoft Defender XDR for alerts from Microsoft Defender for Identity?

Select 3 answers
A.Microsoft Sentinel workspace configured to ingest Defender for Identity alerts.
B.Automated investigation and response enabled in Microsoft Defender XDR.
C.A Microsoft 365 E5 license.
D.Microsoft Defender for Identity onboarded and connected to Microsoft Defender XDR.
E.A custom playbook in Microsoft Sentinel.
AnswersB, C, D

Automated investigation and response must be enabled in Microsoft Defender XDR as the central control that orchestrates the investigation workflow when a Defender for Identity alert is triggered. When enabled, Defender XDR automatically opens an incident, runs investigation steps across identity signals, and executes response actions such as disabling compromised accounts or enforcing password resets. This toggle distinguishes autonomous remediation from manual threat hunting; without it, alerts are merely displayed and no automated actions occur.

Why this answer

Automated investigation and response (AIR) must be explicitly enabled in Microsoft Defender XDR to allow the platform to automatically respond to alerts. Without this setting enabled, even if other components are in place, the system will not trigger automated actions for Defender for Identity alerts.

Exam trap

The trap here is that candidates often confuse the need for a SIEM (Sentinel) or custom automation (playbooks) with the built-in, native AIR capabilities of Microsoft Defender XDR, leading them to select unnecessary components like A or E.

Practice this question →
365
MCQmedium

Your organization uses Microsoft Sentinel and Microsoft Defender XDR. You need to ensure that an external user from a partner organization can access a specific Sentinel workbook without having access to the entire Log Analytics workspace. What should you do?

A.Create a new Log Analytics workspace dedicated to the external partner and deploy the workbook there.
B.Use Azure AD B2B collaboration to invite the external user and assign the Sentinel Reader role on the workbook.
C.Share the workbook as a shared dashboard in the Azure portal.
D.Add the external user to the resource group containing the workspace with Reader role.
AnswerB

Azure AD B2B collaboration is the correct solution because it lets you invite the external user as a guest in your tenant, preserving their own corporate credentials while giving them scoped access. Assigning the Sentinel Reader role specifically on the workbook grants read-only visibility to that workbook without exposing the underlying Log Analytics workspace data or allowing any modifications. This provides fine-grained, auditable access control exactly suited to secure external sharing.

Why this answer

Azure AD B2B collaboration allows you to invite an external user from a partner organization into your Azure AD tenant. By assigning the Sentinel Reader role specifically on the workbook resource (not the workspace), the user can view the workbook without gaining access to the underlying Log Analytics workspace data or other Sentinel resources. This meets the requirement of granular, scoped access.

Exam trap

The trap here is that candidates confuse sharing a workbook (which requires RBAC on the workbook resource) with sharing a dashboard (which is a visual-only artifact in the Azure portal and does not grant any data access permissions).

How to eliminate wrong answers

Option A is wrong because creating a dedicated Log Analytics workspace for the partner is unnecessary overhead and still requires managing separate data ingestion and retention, whereas the requirement is to share only a specific workbook. Option C is wrong because sharing a workbook as a shared dashboard in the Azure portal does not grant the external user access to the workbook’s underlying data queries or Sentinel context; dashboards are visual only and cannot enforce Sentinel RBAC. Option D is wrong because adding the external user to the resource group with Reader role grants them read access to all resources in that group, including the entire Log Analytics workspace and its data, which violates the requirement to restrict access to only the workbook.

Practice this question →
366
MCQhard

Your organization uses Microsoft Sentinel with UEBA enabled. You notice that the UEBA entity pages are not showing any insights for Azure resources. What is the most likely cause?

A.UEBA is not enabled for the workspace.
B.The user accounts are not synchronized with Microsoft Entra ID.
C.The Azure Activity data connector is not configured.
D.The resource context data is not being ingested from Azure Resource Manager.
AnswerD

The correct cause is that resource context data from Azure Resource Manager is not being ingested. UEBA in Microsoft Sentinel requires this data to enrich entity insights with detailed Azure resource attributes, such as resource type and resource group, which are essential for displaying Azure resource insights. Without this ingestion, the UEBA feature will operate for user behaviors but lack the resource-specific context that drives the 'Azure resource insights' views.

Why this answer

UEBA entity pages for Azure resources rely on resource context data, which includes metadata about Azure resources such as virtual machines, storage accounts, and their activities. This data is ingested from Azure Resource Manager (ARM) via the Azure Activity data connector. If the resource context data is not being ingested, UEBA cannot correlate activities to specific Azure resources, resulting in no insights on entity pages.

Option D correctly identifies this missing data source as the root cause.

Exam trap

The trap here is that candidates often confuse the Azure Activity data connector (which handles subscription-level logs) with the Azure Resource Manager data connector (which provides resource context data), leading them to incorrectly select Option C.

How to eliminate wrong answers

Option A is wrong because UEBA is explicitly stated as enabled in the question, so the issue is not about UEBA being disabled. Option B is wrong because user accounts not synchronized with Microsoft Entra ID would affect user entity insights, not Azure resource insights, which are based on resource metadata rather than user identities. Option C is wrong because the Azure Activity data connector is responsible for ingesting Azure subscription-level logs (e.g., resource creation, deletion), but the specific data needed for UEBA resource insights is the resource context data from ARM, which is a separate ingestion pipeline; the connector alone does not guarantee resource context data is being ingested.

Practice this question →
367
MCQeasy

Your organization uses Microsoft Defender for Endpoint. You need to ensure that when a malware alert is generated, an automated investigation is triggered. What should you configure?

A.Configure the Action center settings.
B.Create custom indicators of compromise (IOCs).
C.Use threat analytics to trigger investigations.
D.Enable automated investigation and remediation in the Microsoft 365 Defender portal.
AnswerD

In Microsoft 365 Defender (now Microsoft Defender XDR), the 'Automated investigation and remediation' feature is the switch that allows alerts to automatically run investigation and remediation actions. When this setting is enabled, Defender for Endpoint automatically starts an investigation for qualifying alerts, providing the required automation. This configuration, not other controls like IOCs or the Action center, is the correct way to enable automatic investigation triggers.

Why this answer

Enabling automated investigation and remediation in the Microsoft 365 Defender portal is the specific configuration that triggers an automated investigation when a malware alert is generated by Microsoft Defender for Endpoint. This feature allows the security operations team to define the automation level (e.g., full, semi, or no automation) for alerts, ensuring that when a malware alert fires, the system automatically initiates an investigation to contain and remediate the threat without manual intervention.

Exam trap

The trap here is that candidates often confuse the Action center (which handles post-investigation remediation actions) with the automated investigation configuration itself, leading them to select Option A, when in fact the trigger is controlled by the automation level settings in the Microsoft 365 Defender portal under 'Automated investigation and remediation'.

How to eliminate wrong answers

Option A is wrong because the Action center settings in Microsoft 365 Defender are used to review and approve or reject pending remediation actions (e.g., quarantine a file, isolate a device) after an automated investigation has already been triggered; they do not configure the trigger for automated investigations. Option B is wrong because creating custom indicators of compromise (IOCs) allows you to define your own threat intelligence (e.g., file hashes, IPs, domains) to generate alerts, but they do not enable or configure the automated investigation workflow for those alerts; automated investigation must be enabled separately. Option C is wrong because threat analytics is a reporting and analysis tool that provides insights into active threats and vulnerabilities, but it does not trigger automated investigations; it is used for understanding threat landscape and applying mitigations, not for configuring alert-driven automation.

Practice this question →
368
MCQmedium

Your organization uses Microsoft Defender XDR. You need to ensure that alerts from Microsoft Defender for Identity are automatically correlated with alerts from Microsoft Defender for Endpoint in the unified incidents queue. What should you verify?

A.Microsoft Defender for Office 365 is enabled
B.Microsoft Defender XDR incident correlation is enabled
C.Microsoft Sentinel is connected to Microsoft Defender XDR
D.Custom detection rules are created in Microsoft 365 Defender
AnswerB

The Microsoft Defender XDR incident correlation setting is the core aggregation mechanism that fuses alerts from Defender for Endpoint, Defender for Identity, Defender for Office 365, and Defender for Cloud Apps into a single incident. It leverages the entity graph and attack-story logic to link related alerts based on user, device, and process relationships. Enabling this switch is what allows alerts to be merged into a unified, cross-workload incident rather than appearing as disjointed alerts.

Why this answer

Microsoft Defender XDR incident correlation is the feature that automatically aggregates alerts from different Microsoft Defender workloads—including Defender for Identity and Defender for Endpoint—into a single unified incident. When this setting is enabled, the correlation engine analyzes alert telemetry and entities (such as user accounts, devices, and IP addresses) to merge related alerts, reducing alert fatigue and providing a consolidated view. Without this setting enabled, alerts from different workloads remain isolated and are not automatically correlated in the unified incidents queue.

Exam trap

The trap here is that candidates often confuse the need for a SIEM integration (like Microsoft Sentinel) or additional workload licensing (like Defender for Office 365) with the native, built-in correlation capability of Defender XDR, which is controlled by a single toggle in the settings.

How to eliminate wrong answers

Option A is wrong because Microsoft Defender for Office 365 is a separate workload for email and collaboration threats; enabling it does not control the correlation of alerts between Defender for Identity and Defender for Endpoint. Option C is wrong because Microsoft Sentinel is a SIEM that can ingest alerts from Defender XDR, but it is not required for the native correlation of alerts within the Defender XDR unified incidents queue—the correlation is a built-in feature of Defender XDR itself. Option D is wrong because custom detection rules in Microsoft 365 Defender are used to create custom alerts based on specific queries, but they are not the mechanism that enables automatic correlation of existing alerts from different workloads; that is handled by the incident correlation setting.

Practice this question →
369
MCQmedium

You are managing Microsoft Defender for Cloud Apps. You discover that a user is downloading large amounts of data from a sanctioned cloud app. You need to automatically suspend the user's access when the download exceeds 5 GB in 10 minutes. What should you create?

A.An anomaly detection policy with a mass download detection template.
B.A session policy to block downloads.
C.An app connector for the cloud app.
D.A data loss prevention (DLP) policy in Microsoft Purview.
AnswerA

An anomaly detection policy with a mass download detection template is the correct choice because Defender for Cloud Apps uses these built-in UEBA-based policies to establish a per-user baseline of normal activity and flag when a single user downloads a file volume that deviates significantly from that history. This template is specifically designed to detect mass download activity that is characteristic of data exfiltration, and once triggered, the policy can be configured with governance actions such as automatically suspending the user's account and sending an alert to your security team. It is the only option here that responds to aggregate download volume over time rather than to individual session or file characteristics.

Why this answer

An anomaly detection policy in Microsoft Defender for Cloud Apps can detect unusual user behavior, such as mass file downloads, using predefined templates like 'Mass download by a single user'. This policy can be configured to trigger automatic governance actions, including suspending the user, when the download exceeds a threshold like 5 GB in 10 minutes. It directly addresses the need to automatically suspend access based on volume and time.

Exam trap

The trap here is that candidates often confuse session policies (which block actions in real-time) with anomaly detection policies (which trigger automated responses like suspension based on behavioral patterns), leading them to choose Option B instead of A.

How to eliminate wrong answers

Option B is wrong because a session policy blocks downloads in real-time but does not automatically suspend the user's access; it only prevents the download action during the session. Option C is wrong because an app connector is used to connect Defender for Cloud Apps to a cloud app for visibility and control, but it does not create policies to suspend users based on download thresholds. Option D is wrong because a DLP policy in Microsoft Purview focuses on preventing data loss by inspecting content (e.g., sensitive information) rather than monitoring download volume or triggering user suspension based on size and time.

Practice this question →
370
MCQhard

Your organization has a Microsoft Sentinel workspace that ingests data from multiple sources. You notice that the cost of data ingestion is higher than expected. You need to reduce costs without affecting security visibility. Which action should you take?

A.Reduce the data retention period for all tables to 30 days.
B.Disable the collection of Windows event logs from domain controllers.
C.Configure specific tables to use the Basic Logs tier instead of Analytics Logs.
D.Export logs to Azure Storage and use Azure Data Explorer for analysis.
AnswerC

Configuring specific tables, such as high-volume diagnostic tables, to the Basic Logs tier reduces ingestion cost while still allowing basic KQL queries and a limited retention window. Basic Logs are designed for verbose, less frequently accessed data and cost about 25% of Analytics Logs, but they do not support full analytics, alerts, or advanced hunting features. This option directly addresses cost without removing data from Sentinel, unlike other choices.

Why this answer

Configuring specific tables to use the Basic Logs tier reduces ingestion costs for high-volume, low-security-value data (e.g., verbose diagnostics or debug logs) while retaining full analytical capabilities for security-critical tables in the Analytics Logs tier. Basic Logs are charged at a lower ingestion rate and support simple queries, but they lack the full KQL and indexing features of Analytics Logs, so you must carefully select which tables to downgrade to avoid impacting security visibility.

Exam trap

The trap here is that candidates often assume reducing retention or disabling log sources is the simplest cost-saving measure, but the SC-200 exam emphasizes that cost reduction must never compromise security visibility, making the Basic Logs tier the only option that selectively lowers cost without losing critical security data.

How to eliminate wrong answers

Option A is wrong because reducing the data retention period to 30 days for all tables would delete historical security data needed for incident investigation, compliance, and threat hunting, thus directly affecting security visibility. Option B is wrong because disabling Windows event log collection from domain controllers removes critical security events (e.g., 4624, 4625, 4776) that are essential for detecting authentication attacks, privilege escalation, and lateral movement, severely compromising security monitoring. Option D is wrong because exporting logs to Azure Storage and using Azure Data Explorer for analysis adds complexity and latency, and does not reduce Sentinel ingestion costs since data is still ingested into Sentinel before export; it also shifts analysis out of Sentinel, breaking native integration and alerting capabilities.

Practice this question →
371
MCQmedium

You have a Microsoft Sentinel automation rule as shown in the exhibit. The rule triggers a playbook that blocks a user in Microsoft Entra ID. The rule is enabled but never fires. What is the most likely reason?

A.The automation rule is disabled.
B.The playbook does not have a Microsoft Sentinel trigger.
C.No incidents with High severity are created.
D.The JSON syntax is invalid.
AnswerB

Automation rules in Microsoft Sentinel can only invoke a playbook if that playbook begins with a Microsoft Sentinel trigger, such as 'When a response to a Microsoft Sentinel alert is triggered' or 'When a Microsoft Sentinel incident is created'. Without this trigger, the playbook is not recognized as a valid Sentinel playbook and cannot be called by the automation rule. The rule may still run and match incidents, but the playbook action will fail or be unavailable because the expected trigger is missing.

Why this answer

The automation rule is configured to trigger a playbook, but for a playbook to be invoked by a Microsoft Sentinel automation rule, it must have a Microsoft Sentinel trigger (e.g., 'When a response to a Microsoft Sentinel incident is triggered'). Without this trigger, the playbook cannot receive the incident context from Sentinel, so the rule will never fire even if all other conditions are met.

Exam trap

The trap here is that candidates assume any playbook can be attached to an automation rule, but Microsoft Sentinel requires the playbook to have a specific Sentinel trigger to receive incident context; otherwise, the rule appears enabled but never executes.

How to eliminate wrong answers

Option A is wrong because the question explicitly states the rule is enabled, so it is not disabled. Option C is wrong because the rule's trigger condition is not limited to High severity incidents; the exhibit would show the specific severity filter, but the rule failing to fire is not due to a lack of High severity incidents unless that is the only condition, which is not indicated. Option D is wrong because invalid JSON syntax would cause a validation error when saving the rule, not a silent failure to fire; the rule is enabled and saved, so the syntax is valid.

Practice this question →
372
MCQhard

You are a security operations analyst for a company that uses Microsoft Sentinel. You need to enable User and Entity Behavior Analytics (UEBA) to identify anomalous behavior. You have already enabled the UEBA setting in Microsoft Sentinel. What else must you do to ensure UEBA data is available for investigation?

A.Create a custom analytics rule that runs on the BehaviorAnalytics table to generate incidents.
B.Assign the Microsoft Sentinel Contributor role to the UEBA service account.
C.Enable the Microsoft Defender XDR connector to import UEBA data from Defender services.
D.Configure data sources to send logs to the Microsoft Sentinel workspace and enable entity behavior data sources in UEBA settings.
AnswerD

UEBA requires data sources to be connected and entity behavior data sources enabled. After enabling UEBA, you must select which data sources provide entity behavior information, such as Azure AD sign-in logs, to populate the UEBA tables and enable anomaly detection.

Why this answer

After enabling UEBA in Microsoft Sentinel, you must configure the data sources that provide entity behavior information. This includes connecting sources like Azure Active Directory sign-in logs and enabling them in the UEBA settings. Without this, UEBA tables remain empty and anomaly detection cannot function.

The other options either confuse detection with data population or involve unrelated configurations.

Exam trap

The trap here is assuming that simply toggling UEBA on is enough, when in fact you must also select and enable the relevant data sources for entity behavior.

Practice this question →
373
Multi-Selectmedium

Your security team uses Microsoft Sentinel and Microsoft Purview. You need to classify incidents that involve sensitive data according to Microsoft Purview's sensitivity labels. Which THREE components should you use?

Select 3 answers
A.Microsoft Defender for Cloud to apply sensitivity labels.
B.Analytics rules that trigger on data sensitivity events from Microsoft Purview.
C.Automation rules in Microsoft Sentinel to check for sensitivity labels in the incident.
D.Playbooks in Microsoft Sentinel to query Microsoft Purview for label information.
E.Microsoft Intune compliance policies to label data.
AnswersB, C, D

Microsoft Sentinel analytics rules are scheduled or near-real-time queries that can be set to run against data ingested from Microsoft Purview through its audit log connector. When Purview logs sensitivity label activities—such as a label downgrade, a removal, or an unusual number of files receiving a 'Highly Confidential' label—the analytics rule can match those events and automatically create an incident in Sentinel. This usage directly supports your security team's need to detect and respond to data security threats, so it is a correct option.

Why this answer

Microsoft Purview's data sensitivity events, such as when a file is labeled with a specific sensitivity label, can be ingested into Microsoft Sentinel via the Purview Data Connector. Analytics rules can then be configured to trigger on these events, allowing the security team to automatically generate incidents when sensitive data is detected or mishandled, directly integrating Purview's classification into Sentinel's incident pipeline.

Exam trap

The trap here is that candidates may confuse Microsoft Defender for Cloud's compliance features with Microsoft Purview's sensitivity labeling, or assume Intune can apply data labels, when in fact only Purview and its associated connectors handle sensitivity label events in Sentinel.

Practice this question →
374
MCQhard

Your organization uses Microsoft Sentinel and has enabled UEBA. A security analyst observes that a user account with no prior administrative activity performed a high volume of Azure Resource Manager operations. The analyst wants to investigate further. Which Microsoft Sentinel feature should the analyst use to quickly identify if this behavior is anomalous based on the user's historical profile?

A.Hunting queries
B.Workbooks
C.User and Entity Behavior Analytics (UEBA)
D.Analytics rules
AnswerC

User and Entity Behavior Analytics (UEBA) is the correct capability because it uses machine learning models to build a personalized historical baseline for each user and entity—such as typical logon times, locations, and performed actions—then continuously scores new activities against that profile to identify anomalous behavior automatically in Sentinel. UEBA's anomaly detections are surfaced as suspicious activities or incidents and feed into the entity timeline, requiring no custom rule authoring to compare current events to the user's own established patterns.

Why this answer

UEBA is the correct feature because it builds a behavioral baseline for each user over time, including typical Azure Resource Manager activity patterns. When a user with no prior administrative history suddenly performs a high volume of ARM operations, UEBA can flag this as anomalous by comparing the current activity against the user's historical profile, surfacing the deviation in the UEBA investigation pane without requiring custom query creation.

Exam trap

The trap here is that candidates often confuse UEBA with Analytics rules, assuming that any detection must come from a rule, but UEBA is specifically designed for behavior-based anomaly detection against a user's own historical baseline, not signature-based or rule-based detection.

How to eliminate wrong answers

Option A is wrong because Hunting queries are proactive, iterative searches for potential threats using KQL, but they do not automatically compare current behavior against a user's historical baseline; they require the analyst to manually define and run queries. Option B is wrong because Workbooks are visualization dashboards that aggregate data from various sources, but they do not perform user-specific anomaly detection or compare against historical profiles. Option D is wrong because Analytics rules are used to create automated detections and alerts based on predefined logic, but they do not inherently leverage UEBA's historical user profiles to identify anomalies unless specifically configured with UEBA data, and the question asks for quickly identifying anomalous behavior based on the user's historical profile, which is UEBA's core function.

Practice this question →
375
MCQeasy

Refer to the exhibit. You are reviewing an automation rule in Microsoft Sentinel. What is the effect of this rule?

A.It assigns the incident to the SOC team.
B.It changes the status of newly created incidents from 'New' to 'Active'.
C.It suppresses the incident if it is a false positive.
D.It creates a task in the incident for investigation.
AnswerB

The rule is configured with an action of type 'ChangeStatus' and the status is set to 'Active'. Because the trigger is 'When incident is created,' this action executes immediately for every new incident that meets the rule's conditions, changing its status from the default 'New' to 'Active.' This is the direct and intended effect of the rule, as distinct from other possible actions like assignment or task creation.

Why this answer

The automation rule is configured to run when an incident is created, and the action taken is to change the incident status from 'New' to 'Active'. This is a common initial triage step to indicate that the incident is being worked on, rather than leaving it in the default 'New' state. The rule does not assign ownership, suppress incidents, or create tasks.

Exam trap

The trap here is that candidates may confuse the 'Change status' action with other common actions like assignment or task creation, or assume that changing status to 'Active' automatically implies assignment to a team.

How to eliminate wrong answers

Option A is wrong because the rule does not include an 'Assign incident' action; it only changes the status. Option C is wrong because suppression of false positives requires a different action (e.g., 'Close incident' or 'Run playbook') and is not configured here. Option D is wrong because creating a task requires the 'Create task' action, which is not present in the rule's configuration.

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