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

Question 1

The exhibit shows a KQL query used in a Microsoft Sentinel analytics rule. The rule is intended to detect brute-force attacks by identifying IP addresses that have more than 10 failed sign-ins (result code 50057) followed by a successful sign-in (result code 0) within an hour. However, the rule is not triggering alerts even though you are confident such patterns exist. What is the most likely issue?

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

Accepted Answer

The query does not ensure the successful sign-in occurred after the failed attempts.. The query likely uses a join that pairs failed sign-ins with successful sign-ins based on the same IP address but does not enforce that the successful sign-in occurred after the failed attempts. This means it could pair a successful sign-in that happened before the failed ones, which would not constitute a brute-force attack. The rule is designed to detect a pattern of many failures followed by a success within an hour; without a temporal condition ensuring the success comes after the failures, the rule may not trigger correctly. Option C correctly identifies this issue. Option A (threshold too high) is incorrect because the threshold of 10 is set and presumably appropriate. Option B (time window too short) is incorrect because the time window is one hour, which is reasonable. Option D (not considering same IP across different users) is less likely because the join likely uses IP address, which is already considering the same IP across users.

Answer

The threshold is too high.

Answer

The time window is too short to capture the pattern.

Answer

The query does not consider the same IP address across different users.

Question 2

Your Microsoft Sentinel workspace is ingesting data from multiple sources. You notice that the cost is higher than expected. You need to reduce costs without losing critical security data. Which two actions should you take? (Choose two.)

Accepted Answer

Set a daily cap on tables that generate high volumes but low security value.. Setting daily caps on specific tables (option A) prevents high-volume, low-security-value data from incurring excessive costs, while moving verbose logs to Auxiliary logs (Basic Logs) tier (option B) reduces cost because this tier is cheaper than Analytics logs. Option C is wrong because increasing retention raises storage costs. Option D is wrong because changing to Pay-as-you-go Gen2 is not a built-in cost-reduction feature; it's a newer pricing model that may be more expensive. Option E is wrong because turning off data connectors stops all ingestion, which could eliminate critical security data.

Answer

Increase the retention period for all tables to 90 days.

Answer

Change the workspace pricing tier to 'Pay-as-you-go Gen2'.

Answer

Turn off data connectors for non-critical sources.

Question 3

Refer to the exhibit. You create an automation rule in Microsoft Sentinel using the ARM template snippet shown. However, the rule does not trigger when a high-severity incident is created. What is the most likely cause?

Accepted Answer

The automation rule does not specify the incident provider condition.. The ARM template snippet does not include the 'incidentProvider' condition, which is required for automation rules to trigger on incidents created by Microsoft Sentinel (e.g., from analytics rules). Without specifying the provider (e.g., 'Microsoft Sentinel'), the rule will not evaluate or trigger when a high-severity incident is created, as the condition defaults to no provider filter, effectively disabling the rule for Sentinel incidents.

Answer

The playbook resource ID is invalid.

Answer

The 'triggersWhen' property should be 'Updated' instead of 'Created'.

Answer

The order property is set to 1, conflicting with another rule.

Question 4

You are a security operations analyst. You need to ensure that when a suspicious sign-in is detected by Microsoft Entra ID Protection, an incident is automatically created in Microsoft Sentinel and assigned to the Tier 1 SOC team. What should you configure in Microsoft Sentinel?

Accepted Answer

Create an automation rule that triggers when an incident is created and sets the owner to the Tier 1 SOC group.. Automation rules in Microsoft Sentinel can be configured to run when an incident is created, and one of the available actions is to set the incident owner to a specific group (e.g., Tier 1 SOC). This directly fulfills the requirement to automatically assign the incident to the Tier 1 SOC team upon creation from a Microsoft Entra ID Protection detection.

Answer

Create a playbook that is triggered by the Microsoft Entra ID Protection data connector.

Answer

Enable UEBA and configure role-based access control (RBAC).

Answer

Configure an analytics rule with a corresponding automation rule to assign the incident.

Question 5

Your organization has deployed Microsoft Defender XDR and Microsoft Sentinel in a hybrid environment. You need to ensure that incidents from Microsoft Defender for Endpoint are synchronized to Microsoft Sentinel with full alert details. You have already connected the Microsoft Defender XDR connector. What additional step must you take?

Accepted Answer

In the Microsoft Defender XDR connector, enable 'Microsoft 365 Defender incident creation'.. After connecting the Microsoft Defender XDR connector, you need to enable 'Microsoft 365 Defender incident creation' within the connector settings to ensure that incidents from Microsoft Defender for Endpoint are synchronized to Microsoft Sentinel with full alert details. Option B is incorrect because the Microsoft Defender for Endpoint API connector is not required; the XDR connector handles incident streaming. Option C is incorrect because bi-directional sync is not supported and not needed. Option D is incorrect because the connector does not automatically sync full alert details without enabling incident creation.

Answer

Enable the Microsoft Defender for Endpoint API connector in Microsoft Sentinel.

Answer

Configure a bi-directional sync between Microsoft Sentinel and Microsoft Defender XDR.

Answer

No additional steps are required; the connector automatically syncs all incident details.

Question 6

You run the above KQL query in Microsoft Sentinel. The query returns no results. What is the most likely reason?

Accepted Answer

The query does not specify a time range, so it may be querying data older than the default 24-hour lookback.. By default, KQL queries in Microsoft Sentinel without an explicit time range filter only look back 24 hours. If the relevant SecurityAlert records were generated more than 24 hours ago, the query will return no results. This is a common oversight when investigating historical incidents.

Answer

The column 'AlertSeverity' does not exist in the SecurityAlert table.

Answer

The 'summarize' operator is misspelled.

Answer

The 'has' operator is case-sensitive and the alert names are capitalized differently.

Question 7

Your organization uses Microsoft Defender XDR. You need to ensure that when a user reports a phishing email using the built-in Outlook add-in, the incident is automatically created in Microsoft Sentinel with high severity and a custom tag 'Phishing-Reported'. What is the most efficient way to achieve this?

Accepted Answer

Configure the 'User-reported phishing' policy in Microsoft Defender XDR to create an incident in Microsoft Sentinel with high severity and the tag.. The 'User-reported phishing' policy in Microsoft Defender XDR can be configured to automatically create an incident in Microsoft Sentinel with a specified severity and custom tags. This policy directly processes user-reported phishing emails from the built-in Outlook add-in and integrates natively with Sentinel via the Microsoft Defender XDR connector, making it the most efficient method without requiring additional automation or custom code.

Answer

Set up an automation rule in Microsoft Sentinel to tag incidents from 'Microsoft Defender' connector with the tag when severity is high.

Answer

Create a Power Automate flow that reads from the unified audit log and creates a Sentinel incident via API.

Answer

Use a playbook triggered by a Microsoft Sentinel analytics rule that monitors for 'PhishDeliver' events.

Question 8

You have a Microsoft Sentinel workspace that ingests logs from multiple sources. The log analytics workspace is in the East US region. You have a requirement to keep logs for 90 days for active investigation, then archive them to an Azure storage account for compliance for 5 years. What should you configure?

Accepted Answer

Set the retention period to 90 days and configure a data export rule to send logs older than 90 days to Azure Blob Storage. In Microsoft Sentinel, you can set the workspace retention to 90 days for active investigation. To archive logs for 5 years, configure a data export rule that continuously exports all ingested logs to Azure Blob Storage. The data export rule sends data as it arrives, not after retention expiry, so the exported copy is available in storage from day one, while the workspace copy is automatically deleted after 90 days. This meets the requirement without incurring high costs of extended workspace retention.

Answer

Set the retention period to 5 years and use purging for data older than 90 days

Answer

Set the retention period to 90 days and enable 'Archive' in the workspace retention settings

Answer

Configure diagnostic settings to send logs to storage with a retention of 90 days

Question 9

You are a security analyst. An incident in Microsoft Sentinel is assigned to you. The incident contains multiple alerts. You want to group related alerts into a single incident to reduce noise. What feature should you use?

Accepted Answer

Incident grouping settings in the analytics rule. Not C. Incident grouping settings in the analytics rule allow you to group multiple alerts into a single incident based on criteria like entities or time window. Option A (Automation rules) is for automating incident management actions, not for grouping alerts. Option B (Threat intelligence indicators) is used to enrich alerts with threat intelligence, not to group them. Option C (Incident details tab) is for viewing details of an existing incident, not for configuring grouping.

Answer

Automation rules

Answer

Threat intelligence indicators

Answer

Incident details tab

Question 10

Your organization uses Microsoft Sentinel and you are designing a data retention strategy. You have a Log Analytics workspace with the following tables: SecurityEvent, SigninLogs, and CommonSecurityLog. The compliance team requires that SigninLogs be retained for 7 years, while other tables can be retained for 1 year. Which THREE steps must you take to meet this requirement?

Accepted Answer

Set the workspace retention to 7 years.. Option B is correct because the Log Analytics workspace-level retention must be set to the maximum required period (7 years) so that the longest-retained table, SigninLogs, can actually keep data that long; table-level retention cannot exceed the workspace retention. Option D is correct because Microsoft Sentinel/Log Analytics supports per-table retention settings, so you set SigninLogs (and any other 7-year tables) to 7 years while leaving SecurityEvent and CommonSecurityLog at the workspace default of 1 year. Option E is correct because long retention beyond the standard limits (interactive retention up to 730 days, with total retention up to 12 years via archive) is only available in regions that support the long-term retention/archive capability, so the workspace must reside in a supported region. Option A is not required because archiving is an optional cost-optimization tier, not a prerequisite for meeting a 7-year retention requirement, and the question asks for mandatory steps. Option C is not required because Azure Data Explorer is a separate analytics service and is not needed to satisfy Log Analytics table retention requirements.

Answer

Set an archiving policy to move SigninLogs to cold storage after 1 year.

Answer

Enable Azure Data Explorer (ADX) for long-term storage.

Question 11

You are the security operations lead for a multinational company using Microsoft Defender XDR. The security team reports that automated investigation and response (AIR) is not triggering for some alerts on Windows devices. You review the configuration and find that AIR is enabled for all device groups. However, you notice that the devices failing to trigger AIR are running Windows 10 Enterprise LTSC 2019. What is the most likely reason AIR is not working on these devices?

Accepted Answer

Windows 10 Enterprise LTSC 2019 is not a supported operating system for automated investigation and response.. Automated investigation and response (AIR) in Microsoft Defender for Endpoint requires a supported Windows version. Windows 10 Enterprise LTSC 2019 (Long-Term Servicing Channel) is not a supported operating system for AIR because it lacks the necessary components and update cadence to support the automation engine. Even if AIR is enabled globally and devices are properly onboarded, the feature will not trigger on unsupported OS versions.

Answer

The devices are not properly onboarded to Microsoft Defender for Endpoint.

Answer

The devices are not connected to the internet.

Answer

The security team does not have the required role permissions to initiate AIR.

Question 12

Refer to the exhibit. You are reviewing a playbook configuration in Microsoft Sentinel. The playbook is supposed to create a task to generate a ServiceNow ticket and notify the SOC manager when a high-severity alert is triggered. However, when a high-severity alert occurs, only the notification task is created, and the ticket creation task is missing. What is the most likely cause?

Accepted Answer

The alertRuleId is a placeholder and does not correspond to a real analytics rule in the environment.. The playbook uses the 'alertRuleId' field as a placeholder, which means it does not reference a real analytics rule in the environment. When the playbook runs, the condition that checks for the specific alert rule ID fails, so the action to create a ServiceNow ticket is skipped, while the notification task (which does not depend on that condition) still executes. In Microsoft Sentinel playbooks, the alertRuleId must match an existing analytics rule's identifier for conditional branching to work correctly.

Answer

The playbook uses an unsupported trigger type.

Answer

The playbook JSON has an invalid structure for the trigger.

Answer

The severity filter is incorrectly specified; it should be an array of strings.

Question 13

You are a security operations analyst for a large enterprise with a hybrid environment. Your organization uses Microsoft Sentinel as the central SIEM, Microsoft Defender for Cloud for Azure workloads, Microsoft Defender for Endpoint for endpoints, and Microsoft Defender for Identity for on-premises Active Directory. Recently, the security team has been overwhelmed by a high volume of low-severity incidents from Defender for Cloud that are not actionable. These incidents are generated from the built-in 'ASC Default' policy initiative. You need to reduce the noise without disabling the entire policy. The security team still wants to be alerted on high-severity incidents. You have been asked to implement a solution that automatically suppresses low-severity incidents from Defender for Cloud but still allows high-severity ones to be created in Sentinel. You must not modify the policy initiative itself. What should you do?

Accepted Answer

Create an automation rule that triggers when an incident is created from Defender for Cloud with severity Low or Medium, and set the status to Closed.. Creating an automation rule that triggers on incidents from Defender for Cloud with Low or Medium severity and automatically closes them suppresses the noise without altering the underlying policy or analytics rule. High-severity incidents remain open and actionable, meeting the requirement to still be alerted on high-severity incidents.

Answer

Create a new analytics rule that creates incidents only for high-severity alerts from Defender for Cloud.

Answer

Modify the 'ASC Default' analytics rule in Sentinel to only trigger on high-severity alerts.

Answer

Turn off the Defender for Cloud data connector in Sentinel.

Question 14

You are the lead security operations analyst for a company that uses Microsoft Defender XDR. The company has recently deployed Microsoft Copilot for Security to help analysts investigate incidents. During a recent incident involving a potential ransomware attack on multiple devices, the analysts used Copilot to generate an investigation summary and recommended actions. However, the analysts report that Copilot's responses are not specific to the incident; they are generic and do not include device-specific details. You need to ensure that Copilot provides context-aware responses that include specific device information from the incident. What should you do?

Accepted Answer

Instruct analysts to use the 'Investigate' capability in Copilot and provide the incident ID.. Copilot for Security's 'Investigate' capability is designed to pull incident-specific context (device names, alerts, entities) from Defender XDR when given an incident ID, producing tailored summaries and recommended actions. Simply asking generic questions yields generic answers because no incident context is bound to the prompt.

Answer

Assign the Microsoft 365 Defender role to the analysts in Microsoft Entra ID.

Answer

Enable the Microsoft Defender XDR data connector in Microsoft Sentinel.

Answer

Configure a custom plugin in Copilot to fetch device data from Defender XDR.

Question 15

Your organization uses Microsoft Sentinel and Microsoft Defender XDR. You are configuring a new automation rule in Sentinel to automatically assign incidents to the appropriate SOC tier based on severity: Low and Medium to Tier 1, High to Tier 2, and Critical to Tier 3. You have created three separate automation rules, one for each tier. However, only the rule for Critical incidents is working. The other rules do not assign incidents. You verify that the other rules are enabled and have the correct conditions. What is the most likely cause?

Accepted Answer

The automation rule for Critical incidents has a higher order number and is processed first, preventing other rules from running.. Automation rules in Microsoft Sentinel are processed in ascending order of their 'order' number (lower number = runs first). If the Critical-tier rule has a lower order number than the Tier 1 and Tier 2 rules and includes a 'stop running further automation rules' action, it would only block rules for incidents that also match its own (Critical-only) condition. For genuinely separate, non-overlapping severity conditions, ordering alone should not block unrelated rules from running - so the actual most likely cause is that the higher-priority (lower order number) rule has a 'stop processing additional rules' action checked and its condition is unintentionally broader than intended, causing it to match and halt processing for incidents meant for the other tiers.

Answer

The automation rules for Tier 1 and Tier 2 are set to trigger on incident update instead of creation.

Answer

The SOC Tier 1 and Tier 2 users do not have the appropriate permissions to own incidents.

Answer

Automation rules cannot be created separately for each severity; you must use a single rule with multiple conditions.