SC-200 security operations environment
Manage a security operations environment is worth 40–45% of SC-200, the largest domain. It covers configuration rather than investigation: automating Defender XDR and Sentinel, setting up the Sentinel platform, getting data into it, and building the detections that raise incidents. The questions ask which setting, rule type or connector fits a stated requirement, so you need to know what each feature does and what it cannot do.
Configure automation for Defender XDR and Sentinel
Defender XDR and Defender for Endpoint
The objectives cover email and alert notifications (including tuning, suppression and correlation), advanced features and rule settings in Defender for Endpoint, custom data collection, security policies including attack surface reduction (ASR) rules, automated investigation and response, automatic attack disruption, and device groups with permissions and automation levels.
Device groups are the key idea. A group decides which devices a role can see and which automation level applies. The automation level (for example, requiring approval for remediation versus remediating automatically) is set per group, so a question about letting servers be remediated only after approval usually points at a separate device group with a stricter level.
Automatic attack disruption acts on its own when Defender XDR has high confidence that an attack such as ransomware is in progress, for example by containing devices or disabling accounts. It is different from automated investigation, which examines alerts and proposes or takes remediation.
Sentinel automation
| Automation rule | Playbook | |
|---|---|---|
| Built on | Sentinel itself | Azure Logic Apps |
| Typical use | Assign owner, set severity or status, add tags, close noisy incidents | Call other systems, post to chat, block a user, enrich an entity |
| Code needed | None | Workflow designer, optional code |
| Triggers | Incident or alert created or updated | Incident, alert or entity trigger |
Automation rules orchestrate and can run playbooks. A playbook needs permission to act, which is why Sentinel has an Automation Contributor role used by the service itself.
Configure the Sentinel platform
- Roles: Reader (view), Responder (manage incidents), Contributor (create and edit content) and Automation Contributor. Choose the lowest that satisfies the scenario.
- Retention: data is kept in tiers, which the outline names as analytics, data lake and XDR. Data used by detections and frequent hunting belongs in the analytics tier; large, rarely queried data is cheaper in the data lake.
- Workbooks: dashboards over your data.
- SOC optimization: recommendations that point out unused data, missing coverage for threats relevant to you, and where cost and detection value are out of balance.
Ingest data
| Source | Connector approach |
|---|---|
| Windows security events | Windows Security Events via AMA, configured with a data collection rule |
| Collected through a forwarder | Windows Event Forwarding, planned and configured |
| Linux and network devices | Syslog via AMA, Common Event Format (CEF) via AMA |
| Azure activity | Azure Policy and resource diagnostic settings |
| Threat indicators | Threat intelligence ingestion |
| Anything else | Custom log tables in the workspace |
A data collection rule lets you filter or transform data before it is stored, which is how you control cost. A scenario that asks to collect only certain event IDs, or to drop noisy fields, is a data collection rule question.
Configure detections
- Custom detection rules in Defender XDR are built from advanced hunting queries and run on a schedule or continuously, then raise alerts and optionally take actions.
- Sentinel analytics rules come in scheduled, near-real-time (NRT), threat intelligence and machine learning types. NRT runs about every minute for fast detections on simple queries; scheduled rules suit joins and longer lookbacks.
- Anomaly rules use machine learning to surface unusual behaviour.
- MITRE ATT&CK coverage shows which techniques your rules address and where the gaps are.
Example questions
Question 1. Domain controllers must send only logon-related Windows security events to Microsoft Sentinel to control ingestion cost. Which approach meets this?
- A. Collect all events and delete unwanted rows after ingestion
- B. Use the Windows Security Events via AMA connector with a data collection rule that selects the required events
- C. Create a workbook that hides other events
- D. Increase the workspace retention period
Show answer
Answer: B
The Windows Security Events via AMA connector uses a data collection rule, which can select specific event IDs or filter with XPath before data is ingested. Collecting all events and deleting them later still incurs ingestion cost. A workbook only displays data. Raising retention does not reduce what is ingested.
Want more questions like this? Full SC-200 practice tests →
Question 2. A scheduled analytics rule fires too slowly for a high-risk event that you can detect with a simple single-table query. Which rule type reduces the delay?
- A. A longer scheduled rule lookback period
- B. A machine learning anomaly rule
- C. A workbook with a refresh timer
- D. A near-real-time (NRT) analytics rule
Show answer
Answer: D
Near-real-time (NRT) rules run about every minute and suit simple single-table queries, so they cut the detection delay. A scheduled rule runs at a set interval and has a higher minimum delay. An anomaly rule uses machine learning and is not a precise detection for a known event. A workbook cannot raise incidents.
Want more questions like this? Full SC-200 practice tests →
Question 3. Servers in Defender for Endpoint must only be remediated automatically after an analyst approves the actions, while workstations should be remediated without approval. What should you configure?
- A. Separate device groups for servers and workstations with different automation levels
- B. One device group with an ASR rule requiring approval
- C. An alert suppression rule for servers
- D. One device group with the lowest automation level
Show answer
Answer: A
The automation level is configured per device group, so placing servers in their own group with an approval-required level and leaving workstations in a group with full automation meets both requirements. A single group cannot have two levels. Attack surface reduction rules prevent behaviours but do not set approval for remediation. Suppression rules hide alerts rather than control remediation.
Want more questions like this? Full SC-200 practice tests →
How to revise this domain
Work in the portals. Create one NRT rule, one automation rule and one playbook, then break something deliberately, such as removing the playbook’s permissions, and read the error. Next, build a data collection rule with a filter and check which events arrive. Then read the KQL guide, because custom detections and analytics rules are KQL queries.
Continue with responding to security incidents, or test yourself with the practice test.