SC-200 Manage a security operations environment Practice Question
You are a SOC analyst at Contoso. The environment includes Microsoft Sentinel in a single workspace, Microsoft Defender XDR (including Defender for Endpoint, Defender for Office 365, Defender for Identity, and Defender for Cloud Apps), Microsoft Entra ID, and Microsoft Intune. You need to design a solution to automatically triage and respond to phishing incidents detected by Defender for Office 365. The requirements are: 1) When a phishing alert is generated with high confidence, an incident should be automatically created in Sentinel. 2) The incident should be assigned to the 'Phishing' team and have a severity of High. 3) A playbook should run that will send a Teams message to the Phishing team and also block the sender in Exchange Online. 4) The incident should be automatically closed if the playbook successfully executes. What should you do?
⚠ Common exam trap
Watch out — candidates often confuse the Office 365 connector (which ingests raw alerts) with the Microsoft 365 Defender connector (which synchronizes incidents), leading them to choose Option A, which requires an extra analytics rule and does not natively support high-confidence phishing incident synchronization.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Enable the Microsoft 365 Defender connector to synchronize incidents, create an automation rule triggered on incident creation with conditions for 'Phishing' and high confidence, assigning to 'Phishing' team, running a playbook, and enabling auto-closure.
It leverages the Microsoft 365 Defender connector to synchronize incidents from Defender for Office 365 into Microsoft Sentinel, which is the recommended approach for ingesting high-confidence phishing alerts. An automation rule triggered on incident creation with conditions for 'Phishing' and high confidence can assign the incident to the 'Phishing' team, run a playbook to send a Teams message and block the sender in Exchange Online, and enable auto-closure upon successful playbook execution.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Use the Office 365 connector to ingest alerts, then create an analytics rule to generate incidents, and use automation rules to assign and run playbooks.
Why it's wrong here
The Office 365 connector ingests Exchange and Office 365 audit logs, not Defender for Office 365 alerts, so there are no alert records to feed an analytics rule. Creating an analytics rule to generate incidents from these logs would require custom detection logic and would not capture the native phishing alerts from Defender. Additionally, automation rules act on incidents, but without ingested alert data, the pipeline fails at the ingestion stage.
- ✓
Enable the Microsoft 365 Defender connector to synchronize incidents, create an automation rule triggered on incident creation with conditions for 'Phishing' and high confidence, assigning to 'Phishing' team, running a playbook, and enabling auto-closure.
Why this is correct
This is the recommended approach because the Microsoft 365 Defender connector synchronizes existing Defender for Office 365 incidents into Microsoft Sentinel as incidents. An automation rule can be configured to trigger on incident creation, with conditions for 'Phishing' and 'High' confidence, which assigns the incident to the Phishing team and runs a playbook for automated investigation. Enabling auto-closure ensures that incidents resolved in Defender are automatically closed in Sentinel, maintaining end-to-end fidelity.
- ✗
Use a Logic App to continuously poll Defender for Office 365 APIs for alerts, create incidents via the Sentinel API, and assign them.
Why it's wrong here
Developing a Logic App to poll Defender for Office 365 APIs and create Sentinel incidents is possible but architecturally off-pattern; it requires custom code for authentication, pagination, and error handling, and it bypasses the built-in connector's native synchronization. This approach adds unnecessary complexity, latency, and maintenance burden, and it would not automatically inherit Defender's incident correlation or alert grouping. The Microsoft 365 Defender connector is the native, supported integration that requires no custom polling logic.
- ✗
Create a custom analytics rule with KQL to detect phishing in Defender for Office 365 logs, generate incidents, and use automation rules.
Why it's wrong here
A custom KQL analytics rule cannot detect Defender for Office 365 phishing alerts directly because those alerts are not stored in the Log Analytics workspace unless the Microsoft 365 Defender connector or a separate data collection pipeline is enabled. Without that connector, the KQL query would need to run against raw email or message trace logs, which lack the alerting context and confidence scores that Defender incident synchronization provides. This method also requires you to build detection logic from scratch rather than consuming the ready-made, correlated incident data from Defender.
Go deeper
Related to this question
About these practice questions
One of 1,303 original SC-200 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SC-200 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SC-200 exam.