SC-200 Manage a security operations environment Practice Test 7 — 15 Questions

Question 1

You are a Microsoft Security Operations Analyst for a large enterprise with 50,000 users. Your organization uses Microsoft Defender XDR, Microsoft Sentinel, and Microsoft Defender for Cloud Apps. The security team has observed an increase in alerts related to SaaS applications (e.g., Box, Salesforce) accessed from unusual locations. You need to design a solution to automatically investigate and respond to these alerts. The solution should: (1) correlate user activity across multiple SaaS apps, (2) automatically isolate a user's account if the risk score exceeds 90, and (3) create an incident in Sentinel. Which approach should you use?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

Configure Microsoft Defender for Cloud Apps to use session policies that require reauthentication or block access when risk is high, and stream alerts to Sentinel.. Microsoft Defender for Cloud Apps (MDA) is the CASB that discovers and governs SaaS app activity (Box, Salesforce, etc.), correlates user behavior across apps via its Cloud Discovery and anomaly detection, and supports session policies that can block or require reauthentication when risk is high. Streaming alerts to Sentinel via the MDA connector satisfies the incident-creation requirement, and MDA's built-in anomaly detection covers the cross-app correlation.

Answer

Use Microsoft Sentinel UEBA to detect anomalies and manually trigger a playbook to block the user.

Answer

Deploy Microsoft Defender for Endpoint on all devices and use device risk as a factor for conditional access.

Answer

Create analytics rules in Sentinel for each SaaS app and a playbook to isolate accounts using Microsoft Entra ID conditional access.

Question 2

Your company has a hybrid identity environment with Microsoft Entra ID and on-premises Active Directory. You recently deployed Microsoft Defender for Identity (MDI) to monitor on-premises domain controllers. The SOC team needs to receive alerts from MDI in Microsoft Sentinel. You have already installed the MDI sensor on all domain controllers and confirmed that the MDI portal shows alerts. However, no MDI alerts appear in Sentinel. The Microsoft Defender for Identity data connector in Sentinel shows 'Connected'. What should you do next?

Accepted Answer

Enable the Microsoft 365 Defender connector in Sentinel, as MDI alerts are ingested through that connector.. Microsoft Defender for Identity alerts are surfaced in Microsoft Sentinel through the Microsoft 365 Defender connector (or the Microsoft Defender XDR connector), not solely through the standalone MDI data connector. Even when the MDI connector shows 'Connected', alert ingestion into Sentinel requires the Microsoft 365 Defender connector to be enabled so that MDI alerts flow through the unified XDR pipeline.

Answer

Update the MDI sensor to the latest version.

Answer

Reconfigure the MDI data connector to select all alert severities.

Answer

Check the MDI sensor health status on each domain controller.

Question 3

Your organization uses Microsoft Sentinel and has a requirement to retain log data for two years for compliance purposes. You have configured the Log Analytics workspace with a retention policy of 90 days. You need to extend the retention to two years while minimizing costs. The data must remain queryable. What should you do?

Accepted Answer

Configure archive retention on the Log Analytics workspace: keep interactive retention at 90 days and set total retention to 730 days, so older logs are archived in the low-cost archive tier within the same workspace.. Configure the Log Analytics workspace's per-table (or workspace-level) retention setting so interactive retention stays short (e.g., 90 days) and total retention extends to 730 days. Data beyond the interactive retention window is automatically transitioned to the low-cost archive tier within the SAME Log Analytics table — it is not exported or moved to an Azure Storage account. Archived data isn't queryable with ordinary interactive KQL; to search it you run an asynchronous Search Job (or a Restore for a specific time range), which copies matching records into a new table for querying. This meets the two-year compliance requirement while minimizing cost, since archive-tier storage is billed at a small fraction of interactive-tier pricing.

Answer

Increase the workspace retention to 730 days.

Answer

Export logs to Azure Blob Storage with cool access tier.

Answer

Enable unlimited retention for the workspace.

Question 4

Your organization uses Microsoft Sentinel and Microsoft Defender XDR. You need to ensure that all incidents are reviewed within 24 hours. Which TWO actions should you take?

Accepted Answer

Create an automation rule that runs 24 hours after incident creation and escalates if status is not 'In progress'.. Option A is correct because Microsoft Sentinel automation rules can be triggered based on incident creation time and conditions such as status, allowing you to escalate incidents that remain unaddressed after 24 hours; automation rules support time-based triggers and can change status, assign owners, or run playbooks. Option D is correct because a Microsoft Sentinel workbook can query incident data using KQL to surface incidents older than 24 hours, and workbook-based alerts can notify the SOC manager, providing visibility and accountability for timely review. Option B is not correct because playbooks are triggered by incidents or alerts, not by a recurring hourly schedule, and they cannot independently poll incident age without an external trigger. Option C is not correct because Microsoft Defender XDR does not provide a native automatic reassignment feature after 24 hours. Option E is not correct because analytics rules generate incidents and do not automatically close them after a fixed time; closing incidents requires automation rules or manual action.

Answer

Create a playbook that runs every hour and checks incident age.

Answer

Configure Microsoft Defender XDR to automatically reassign incidents after 24 hours.

Answer

Modify the analytics rule to automatically close incidents after 24 hours.

Question 5

Your organization uses Microsoft Sentinel and Microsoft Defender for Cloud. You need to implement a solution that automatically suppresses low-severity incidents from specific IP addresses that are known internal scanners. Which THREE configurations should you make?

Accepted Answer

Add the IP addresses to a watchlist and reference it in analytics rules.. Option A is correct because a Microsoft Sentinel watchlist can store the known internal scanner IP addresses as a reusable lookup, and analytics rules can reference that watchlist in their query logic to identify or exclude activity from those addresses. Option B is correct because Sentinel analytics rules support suppression (configured via incident settings/alert grouping or suppression) so that matching low-severity incidents from the specified IP addresses are not generated or are suppressed for a defined period. Option C is correct because an automation rule in Microsoft Sentinel can trigger on incident creation, evaluate conditions such as the IP address entity, and automatically close or resolve matching low-severity incidents, which directly achieves automatic suppression. Option D is not correct because suppression rules are not a Microsoft Defender for Cloud configuration for suppressing Sentinel incidents; Defender for Cloud handles security posture and alerts, not Sentinel incident suppression. Option E is not correct because playbooks cannot delete incidents, and deleting incidents is not the supported or appropriate suppression mechanism in Microsoft Sentinel.

Answer

Create a suppression rule in Microsoft Defender for Cloud.

Answer

Create a playbook that deletes incidents from those IP addresses.

Question 6

Your organization uses Microsoft Sentinel and Microsoft Defender for Cloud. You need to ensure that all security alerts from Microsoft Defender for Cloud are ingested into Sentinel and that incidents are automatically created for alerts with severity 'High' or higher. You have already connected Microsoft Defender for Cloud to Sentinel using the data connector. However, no incidents are being created. What should you do?

Accepted Answer

Create an analytics rule that uses the SecurityAlert table and generates incidents for high severity.. The Microsoft Defender for Cloud data connector ingests alerts into the SecurityAlert table in Microsoft Sentinel, but it does not automatically create incidents. To generate incidents from these alerts, you must create an analytics rule that queries the SecurityAlert table and uses the 'Group by' and 'Alert grouping' settings to create incidents for alerts with severity 'High' or higher. Option B is incorrect because streaming policies are used to forward logs to other destinations, not to create incidents in Sentinel. Option C is incorrect because the Defender for Cloud data connector does not have a toggle to create incidents; it only enables the ingestion of alerts. Option D is incorrect because automation rules act on alerts that have already been ingested and can perform actions like changing severity or assigning ownership, but they do not create incidents; incident creation is solely the function of analytics rules.

Answer

Configure a streaming policy to forward Defender for Cloud incidents.

Answer

Create an automation rule that runs on alert ingestion and creates incidents.

Question 7

Your organization uses Microsoft Sentinel. You have a custom analytics rule that generates incidents based on a KQL query. The rule is configured to run every 5 minutes. You notice that the rule is generating duplicate incidents for the same event. What should you do to prevent duplicates?

Accepted Answer

Enable entity mapping in the analytics rule and set appropriate entities.. Duplicate incidents in Microsoft Sentinel typically occur when the analytics rule cannot correlate alerts to the same underlying entity, so each run treats the event as new. Enabling entity mapping (Account, Host, IP, etc.) lets Sentinel recognize that alerts share the same entities and group them into a single incident rather than creating separate ones. This is the built-in mechanism for deduplication and incident correlation.

Answer

Create an automation rule that deletes duplicate incidents.

Answer

Set the rule to group alerts into a single incident if they occur within 5 minutes.

Answer

Create a playbook that checks for duplicates before incident creation.

Question 8

Your organization uses Microsoft Sentinel and Microsoft Defender XDR. You need to configure a solution that automatically escalates incidents that have been in 'New' status for more than 4 hours. The escalation should change the status to 'Active' and assign the incident to a senior analyst. What should you do?

Accepted Answer

Create a playbook that runs every hour and updates incidents.. To automatically escalate incidents based on time, you need an automation rule that triggers on incident creation but with a condition that checks 'Time since created > 4 hours'. However, automation rules in Microsoft Sentinel trigger immediately upon incident creation, not after a delay. Therefore, the correct approach is to create a playbook that runs on a schedule (e.g., every hour) and queries for incidents in 'New' status older than 4 hours, then updates their status and owner. The playbook uses the Sentinel API or Logic Apps connectors to perform these actions.

Answer

Create an automation rule that triggers when an incident is created, with a condition 'Time since created > 4 hours' and actions to set status and owner.

Answer

Modify the analytics rule to update the incident after 4 hours.

Answer

Configure Microsoft Defender XDR to escalate incidents older than 4 hours.

Question 9

Your organization uses Microsoft Sentinel. You need to ensure that all incidents are classified with a specific classification when closed. The classification must be chosen from a predefined list. What should you configure?

Accepted Answer

Configure incident settings in Sentinel to define custom classifications.. Microsoft Sentinel's incident settings allow administrators to define custom classifications and reasons that appear in the closure dialog, and to require a classification before an incident can be closed. This is the built-in configuration point for enforcing a predefined classification list at closure time.

Answer

Modify the analytics rule to require classification.

Answer

Create a playbook that validates classification before closure.

Answer

Create an automation rule that enforces classification on closure.

Question 10

Your organization uses Microsoft Sentinel and Microsoft Defender for Cloud. You have a requirement to automatically tag incidents that involve resources from a specific subscription with the label 'Critical Subscription'. The subscription ID is stored in a watchlist. Incidents are created from multiple data sources. What is the most efficient way to apply the tag?

Accepted Answer

Create an automation rule that runs when an incident is created, queries the watchlist, and if the subscription matches, applies the label.. An automation rule in Microsoft Sentinel is the most efficient way to apply a label to incidents based on a watchlist lookup, because automation rules run centrally on incident creation and can query watchlists without needing a full playbook. Automation rules are designed for lightweight incident triage and tagging, and they support conditions and actions like 'Add label'. This avoids modifying every analytics rule or creating a heavy playbook that runs on all incidents.

Answer

Create a playbook that runs on all incidents and checks the watchlist to apply the label.

Answer

Modify each analytics rule to include the subscription ID in the incident title.

Answer

Create a separate analytics rule for the subscription that generates incidents with the label.

Question 11

Your organization uses Microsoft Defender XDR and Microsoft Sentinel in a hybrid deployment. You need to ensure that all incidents from Defender XDR are synchronized to Sentinel and that any changes to incident status in Sentinel are reflected back in Defender XDR. Which THREE components or configurations are required?

Accepted Answer

Automation rules that trigger on incident status change and call a playbook to update the other platform.. The correct answers are A, B, and C. Option A: Automation rules are required to trigger a playbook when an incident status changes in Sentinel, allowing the change to be reflected back to Defender XDR for bidirectional sync. Option B: The Microsoft Defender XDR data connector ingests incidents from Defender XDR into Sentinel. Option C: The bi-directional incident synchronization setting must be enabled in the data connector configuration to sync status changes both ways. Option D is incorrect because the Microsoft Defender for Cloud Apps connector ingests alerts from Cloud Apps, not incidents. Option E is incorrect because mail flow rules are for email routing, not incident synchronization.

Answer

Microsoft Defender for Cloud Apps connector.

Answer

Configure a mail flow rule in Exchange Online.

Question 12

Your organization has a Microsoft Sentinel workspace in the East US region. You have deployed the Microsoft Defender XDR connector and are ingesting incidents from Microsoft Defender for Endpoint, Defender for Office 365, and Defender for Identity. The SOC team reports that some incidents from Defender for Office 365 are missing in Sentinel, but all incidents from the other sources appear correctly. You have verified that the connector is enabled and that there are no ingestion errors. The missing incidents are related to phishing emails that were detected by Defender for Office 365 and automatically remediated (soft deleted) by the system. The incidents are visible in the Microsoft 365 Defender portal. What should you do to ensure these incidents appear in Sentinel?

Accepted Answer

Edit the Microsoft Defender XDR connector settings to include alerts with a resolved status.. The Microsoft Defender XDR connector in Microsoft Sentinel by default only ingests incidents that are in an active or unresolved state. Incidents that Defender for Office 365 automatically remediates (e.g., soft-deleted phishing emails) are marked as resolved, so they are filtered out. Editing the connector settings to include alerts with a resolved status ensures these incidents are also ingested into Sentinel.

Answer

Create an automation rule that triggers on missing incidents and creates them manually.

Answer

Create a new Microsoft Defender XDR connector in a different region to capture all incidents.

Answer

Re-enable the Microsoft Defender XDR connector and restart the data ingestion.

Question 13

Your company uses Microsoft Sentinel as its SIEM and has enabled User and Entity Behavior Analytics (UEBA) to detect insider threats. The UEBA timeline for a user shows several high-risk events, including unusual data exfiltration to an external site and multiple failed logons from a new geographic location. You are asked to create a custom analytics rule that generates an incident when a user exhibits both high-risk behaviors within a 24-hour period. You have the necessary KQL skills. However, when you test the rule, it does not generate any incidents even though the behavior exists. You have confirmed that the UEBA tables (BehaviorAnalytics, IdentityInfo) are populated and that the rule is enabled with a frequency of 1 hour. What is the most likely reason the rule is not firing?

Accepted Answer

The UEBA data has not yet been fully processed and may take up to 24 hours to appear in the tables.. The most likely reason is that UEBA data ingestion and enrichment in Microsoft Sentinel is not instantaneous — BehaviorAnalytics and IdentityInfo tables can take up to 24 hours (and sometimes longer) to populate after UEBA is enabled or after new user activity occurs. Even though the tables appear populated with some data, the specific high-risk events the rule depends on may not yet have been processed into the BehaviorAnalytics table. Until the UEBA pipeline completes its enrichment cycle, the KQL query will return no results and the analytics rule will not fire.

Answer

The analytics rule is not enabled for the correct workspace.

Answer

The KQL query is referencing the wrong tables.

Answer

The rule's frequency is too long; it should be set to 5 minutes.

Question 14

Your SOC team uses Microsoft Sentinel workbooks to monitor the security posture. One workbook shows a chart of incidents by severity over the last 7 days. The workbook uses a KQL query that queries the SecurityIncident table. Recently, the workbook stopped displaying data. You check the workspace and confirm that incidents are being created and are visible in the Sentinel portal. You also verify that the workbook has not been modified. What is the most likely cause?

Accepted Answer

The Log Analytics workspace linked to the workbook has been moved or renamed.. Microsoft Sentinel workbooks are saved as Azure resources that reference a specific Log Analytics workspace by its resource ID. If the workspace is moved to another resource group or subscription, or renamed, the workbook's data source link breaks, causing queries to return no data. Since incidents are still visible in Sentinel, the workspace itself is functional, but the workbook's reference is stale.

Answer

The workbook was accidentally deleted and needs to be re-created.

Answer

The workspace has been switched to a different pricing tier that does not support workbooks.

Answer

The KQL query in the workbook has a syntax error.

Question 15

Your organization has deployed Microsoft Sentinel and Microsoft Defender XDR. You have enabled bi-directional incident synchronization. The SOC team uses Microsoft Teams to collaborate on incidents. They have configured a playbook that posts incident details to a Teams channel whenever an incident is created. Recently, the playbook stopped posting messages. You check the playbook's run history in Azure Logic Apps and see that the run was successful with a 200 status code from the Teams connector. However, no message appears in the channel. You verify that the Teams webhook URL is correct and that the channel is active. What is the most likely cause?

Accepted Answer

The service principal or managed identity used by the Logic App has lost permissions to post messages in the Teams channel.. The most likely cause is that the service principal or managed identity used by the Logic App has lost permissions to post messages in the Teams channel. Even though the Logic App run returned a 200 status code from the Teams connector, that only indicates that the request was sent successfully; it does not guarantee that the Teams channel received the message if the identity lacks permissions. Option A is incorrect because the connector is installed and working (HTTP 200). Option B is incorrect because the playbook is not disabled; the run history shows it executed successfully. Option D is incorrect because if the channel were deleted and re-created, the webhook URL would be different, but the question states the webhook URL is correct.

Answer

The Microsoft Teams connector is not installed in the Logic Apps environment.

Answer

The playbook is disabled and needs to be re-enabled.

Answer

The Teams channel has been deleted and re-created with a different ID.