SC-200 Manage a security operations environment Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Remove data connectors for non-critical sources.

  Why it's wrong here

  Removing data connectors for non-critical sources can reduce ingestion volume, but it also strips away the raw telemetry that analytics rules, UEBA behavioral profiling, and threat-hunting queries rely on. Attackers commonly move laterally through lesser-monitored sources, so a 'non-critical' connector may be the only place an early-warning indicator appears. The connector itself does not incur direct cost; the cost is tied to the data flowing in, and stopping that flow trades a modest cost reduction for a significant increase in detection blind spots and potential compliance gaps.

• ✓

  Reduce the retention period of tables that do not require long-term storage.

  Why this is correct

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

• ✓

  Ingest verbose logs (e.g., DNS events) into Basic Logs tier.

  Why this is correct

  Basic Logs is a separate Log Analytics table tier offered at a significantly lower per-GB ingestion price than Analytics Logs, but it is designed for high-volume, low-analytics data such as verbose DNS queries or debug logs. These logs can still be accessed via direct KQL queries for ad-hoc triage and forensic review, but they are not intended for real-time threat detection rules or full-text search patterns. Ingesting verbose logs into Basic Logs lowers the daily ingestion bill while retaining the data for investigation, making it an effective cost-saving measure when the logs are not used for continuous alerting.

• ✗

  Disable analytics rules that generate low-severity incidents.

  Why it's wrong here

  Analytics rule execution costs are driven by the query and the volume of data scanned, not by the number of incidents generated, so disabling rules that produce low-severity incidents barely changes the Sentinel bill. More importantly, low-severity incidents often represent initial access, lateral movement attempts, or policy violations that, if undetected, can be chained into a serious breach. If a rule is noisy, the correct action is to refine its query, reduce its severity, or use incident grouping and alert suppression rather than switch it off entirely, because disabling the rule eliminates coverage for negligible savings.

• ✗

  Switch the workspace pricing tier from Capacity Reservations to Pay-as-you-Go.

  Why it's wrong here

  Capacity Reservations commit a workspace to a specific daily ingestion volume and provide progressively lower per-GB rates as the commitment tier increases. Pay-as-you-go charges the full list price per GB with no volume discount, so moving a high-volume Sentinel workspace from Capacity Reservations to consumption pricing will typically raise ingestion costs. This change only reduces costs if actual daily ingestion is consistently far below the committed tier, leaving the reservation under-utilized; otherwise, this is not a cost-saving action and is generally the opposite of what a cost-conscious SOC should do.

Go deeper

Related to this question