SC-200 Practice Question: A company uses Microsoft Defender for Cloud with…

Answer analysis

Option-by-option breakdown

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

• ✓

  Enable the Defender for Containers plan for the subscription in Defender for Cloud.

  Why this is correct

  Enabling the Defender for Containers plan at the subscription level is the required first action; it activates Microsoft's workload protection for AKS and all other supported Kubernetes platforms in that subscription. Once toggled on, Defender for Cloud automatically provisions the necessary components for existing and future AKS clusters, including Kubernetes audit log analysis, runtime threat detection, and image vulnerability assessment. No separate node-agent installation or workspace configuration is needed for the plan to take effect, making this the precise enablement step.

• ✗

  Install the Microsoft Defender for Cloud agent on the AKS nodes.

  Why it's wrong here

  The 'Microsoft Defender for Cloud agent' you would install on an AKS node is the legacy Log Analytics agent, which is not the correct security sensor for container protection. Defender for Containers uses a dedicated Defender profile/sensor, deployed as a DaemonSet, and that deployment is triggered automatically when the plan is enabled—manual node-level installation is redundant and provides only OS-level data, not Kubernetes control-plane audit events. Even with a node agent, threat detection stays disabled until the subscription-level plan is turned on.

• ✗

  Create a Log Analytics workspace and connect AKS to it.

  Why it's wrong here

  Connecting AKS to a Log Analytics workspace enables Container Insights, giving you performance metrics, inventory data, and container logs, but this is observability, not security enablement. The Defender for Containers plan can optionally use a Log Analytics workspace for storing collected security data, yet creating and linking a workspace does not by itself enable any Defender detections or threat protections. The plan must be enabled first; the workspace is only a downstream data sink for the security telemetry that the plan generates.

• ✗

  Enable Azure Policy for AKS.

  Why it's wrong here

  Enabling Azure Policy for AKS adds governance guardrails—for example, preventing privileged containers or enforcing ingress restrictions—and can automatically remediate non-compliant clusters, but it is not the lever that turns on Defender for Containers. The Defender for Containers plan internally installs Azure Policy components to support some of its security recommendations, but toggling policy alone does not provide runtime threat detection, vulnerability assessment, or Kubernetes audit log monitoring. Security protection requires the subscription-level Defender for Containers plan to be explicitly enabled; policy is an additional compliance layer, not a substitute for that activation.

Go deeper

Related to this question