Your organization uses Microsoft Defender for Cloud and Microsoft Sentinel. You need to ensure that security alerts from Defender for Cloud are automatically synchronized to Sentinel and assigned to the cloud security team. Which three actions should you take?

Manually export alerts from Defender for Cloud to Sentinel daily.

Create a playbook that periodically pulls alerts from Defender for Cloud.

SC-200 Manage a security operations environment Practice Question

Correct answer & explanation

✓

Create an automation rule that sets the incident owner to the cloud security team.

Automation rules in Microsoft Sentinel allow you to automatically assign incident owners based on conditions such as alert severity or source connector. By creating an automation rule that sets the incident owner to the cloud security team, you ensure that every Defender for Cloud alert synchronized to Sentinel is immediately assigned to the appropriate team without manual intervention.

Answer analysis

Option-by-option breakdown

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

✓
Create an automation rule that sets the incident owner to the cloud security team.
Why this is correct
Assigning the incident owner via an automation rule is the correct approach because automation rules can perform built-in incident actions immediately after the incident is created. This rule can use conditions such as the alert being generated from Defender for Cloud to set the owner field to the cloud security team, ensuring proper routing without requiring a playbook. Automation rules run after the connector or analytics rule creates the incident, making them the precise mechanism for ownership assignment in the incident lifecycle.
✗
Manually export alerts from Defender for Cloud to Sentinel daily.
Why it's wrong here
Manually exporting alerts from Defender for Cloud to Sentinel daily is not a valid solution because it provides a point-in-time snapshot rather than continuous streaming, so alerts generated between exports would not be available for investigation or automated responses. This introduces unacceptable latency for a SOC, and the manual effort is error-prone and not scalable for production environments. The proper connector uses a continuous API stream to deliver alerts in near real time, making manual export both redundant and impractical.
✗
Create a playbook that periodically pulls alerts from Defender for Cloud.
Why it's wrong here
A custom playbook that periodically pulls alerts from Defender for Cloud is unnecessary because the data connector already subscribes to the Defender for Cloud API and pushes alerts into Sentinel as they are generated. Periodic polling would add latency between the poll intervals, risk missing alerts if the pull fails, and create duplicate analysis if the connector is also enabled. This approach also increases the attack surface and operational complexity when Microsoft provides a managed, automated ingestion path.
✓
Enable the Microsoft Defender for Cloud data connector in Sentinel.
Why this is correct
Enable the Microsoft Defender for Cloud data connector in Sentinel is the correct first step because it establishes the automated ingestion pipeline that streams security alerts from all Defender for Cloud subscriptions into the Sentinel workspace's SecurityAlert table. The connector uses the Defender for Cloud API to continuously synchronize alerts, including any changes to alert status, which is essential for maintaining an accurate incident timeline. Without this connector, no alerts from Defender for Cloud can be processed by Sentinel's analytics rules or automation rules.
✓
Configure the connector to create incidents automatically from alerts.
Why this is correct
Configuring the connector to automatically create incidents is necessary to convert the incoming security alerts into actionable Sentinel incidents that can be assigned, investigated, and tracked in the incident queue. This is done by checking the 'Create incidents automatically' option on the connector page, which leverages the SecurityAlert data to generate a new incident each time an alert matching the configured severity arrives. Enabling this ensures that the alerts do not just sit as raw entries in the SecurityAlert table but instead become incidents that automation rules can then process for ownership and triage.

SC-200 Manage a security operations environment Practice Question

Why each option matters

Option-by-option breakdown

Related to this question