Courseiva

SC-200 Respond to security incidents Practice Question

Exhibit

Refer to the exhibit.

```json
{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "workspaceName": {
      "value": "sentinel-workspace"
    },
    "location": {
      "value": "eastus"
    },
    "enableUEBA": {
      "value": true
    },
    "dataConnectors": {
      "value": [
        "AzureIdentity",
        "AzureActivity",
        "MicrosoftThreatProtection"
      ]
    }
  }
}
```

You are deploying Microsoft Sentinel using the above ARM template parameters. After deployment, you notice that Microsoft Defender for Cloud alerts are not being ingested. What is the MOST likely reason?

⚠ Common exam trap

Many exam-takers assume the 'MicrosoftThreatProtection' connector ingests all Microsoft security alerts, including Defender for Cloud, because of the broad 'Threat Protection' naming, but in reality it only covers Microsoft Defender XDR signals.

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

✓

The 'MicrosoftThreatProtection' connector only ingests Microsoft Defender XDR signals, not Defender for Cloud alerts.

The 'MicrosoftThreatProtection' connector is specifically designed to ingest signals from Microsoft Defender XDR (formerly Microsoft 365 Defender), which includes Defender for Endpoint, Defender for Office 365, Defender for Identity, and Defender for Cloud Apps. It does not ingest Microsoft Defender for Cloud alerts. To ingest Defender for Cloud alerts, you must use the dedicated 'Defender for Cloud' data connector in Microsoft Sentinel. Therefore, deploying only the 'MicrosoftThreatProtection' connector will result in Defender for Cloud alerts not being ingested.

Answer analysis

Option-by-option breakdown

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

  • ✗

    UEBA is enabled, which conflicts with Defender for Cloud data ingestion.

    Why it's wrong here

    UEBA in Microsoft Sentinel is an analytics feature that uses entity behavior and baseline profiling to detect anomalies, and it does not modify or block the ingestion pipelines of any data connectors. The Defender for Cloud connector (Azure Security Center) delivers alerts through the Log Analytics workspace independently, and enabling UEBA simply adds data on top of existing ingested logs. Therefore, UEBA and Defender for Cloud data ingestion can coexist without conflict, making this option incorrect.

  • ✗

    The workspace location (eastus) does not support Defender for Cloud connector.

    Why it's wrong here

    Microsoft Sentinel is supported in the eastus region, and the Defender for Cloud (Azure Security Center) connector is available in all Azure public regions where Sentinel is offered. Workspace location does not affect the capability to connect Defender for Cloud; the connector relies on the Azure Security Center service itself, which is a regional PaaS service with broad regional coverage. Thus, the eastus location fully supports this connector, so this option is not the reason for the missing Defender for Cloud alerts.

  • ✓

    The 'MicrosoftThreatProtection' connector only ingests Microsoft Defender XDR signals, not Defender for Cloud alerts.

    Why this is correct

    The 'MicrosoftThreatProtection' connector (also known as the Microsoft 365 Defender connector) exclusively ingests incident and alert data from Microsoft Defender XDR components such as Defender for Endpoint, Defender for Office 365, Defender for Identity, and Defender for Cloud Apps. Defender for Cloud alerts are delivered via the 'AzureSecurityCenter' (now 'Microsoft Defender for Cloud') connector, which is a separate data source with its own connector type. Because the ARM template only includes the MicrosoftThreatProtection connector, Defender for Cloud alerts would never appear in Sentinel, making this the correct explanation for the issue.

  • ✗

    The workspace name 'sentinel-workspace' is reserved for internal use.

    Why it's wrong here

    Log Analytics workspace names in Azure are arbitrary user-defined strings, and there is no reserved name like 'sentinel-workspace' that would restrict its use. The name only needs to be globally unique within the resource group and follow Azure naming conventions; it has no bearing on connector configuration or data ingestion behavior. Since 'sentinel-workspace' is a valid and unrestricted name, this option is not a plausible cause for the missing Defender for Cloud alerts.

About these practice questions

Courseiva writes every SC-200 question from scratch — 1,303 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

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.