SC-200 Practice Question: A cloud security administrator needs to ensure…

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 auto-provisioning in the Defender for Cloud environment settings.

  Why this is correct

  Auto-provisioning in Microsoft Defender for Cloud is the native, first-party mechanism that automatically installs the Log Analytics agent (or Azure Monitor Agent when selected) on both existing and newly created VMs by leveraging a built-in 'deployIfNotExists' policy assigned at the subscription or management group scope. Once enabled, Defender for Cloud continuously evaluates VMs for the agent extension, remediates any gaps without manual intervention, and configures each VM to connect to the designated Log Analytics workspace. This guarantees consistent security telemetry collection and is the recommended approach for ensuring all supported VMs are covered.

• ✗

  Deploy a custom Azure Policy to install the agent on all VMs.

  Why it's wrong here

  Deploying a custom Azure Policy is not the most direct method here, as Microsoft Defender for Cloud provides a built-in auto-provisioning capability specifically designed to automatically install the Log Analytics agent on new virtual machines as they are provisioned. This option is tempting because Azure Policy is a robust tool for enforcing compliance and deploying extensions across Azure resources. It would be the correct approach for deploying agents or extensions *not* natively supported by Defender for Cloud's auto-provisioning, or for highly customised deployment scenarios.

• ✗

  Use an Azure Automation runbook to install the agent on newly created VMs.

  Why it's wrong here

  An Azure Automation runbook is a custom, scripted alternative that would require you to author, schedule, and maintain the automation job, along with an authentication mechanism such as an Azure Run As account or managed identity to call Set-AzVMExtension or Invoke-AzVMRunCommand against each VM. This approach is reactive and unreliable at scale: it does not automatically trigger on VM creation unless you build an external event-based orchestration (like an Event Grid subscription), nor does it continuously remediate VMs whose agent is later uninstalled or compromised. Since auto-provisioning already delivers proactive, integrated deployment, a runbook adds operational overhead and failure points without providing the same level of coverage, making it a redundant and inferior solution.

• ✗

  Enable Azure Update Management on the VMs.

  Why it's wrong here

  Azure Update Management (and its successor, Azure Update Manager) is specifically designed to orchestrate and assess OS patches, not to deploy or install the Log Analytics agent. In fact, Update Management is a downstream consumer of the agent's telemetry—it requires the Log Analytics agent to already be installed and connected to a Log Analytics workspace before it can report update data or initiate patching. Enabling Update Management on a VM that lacks the agent will simply show an unresolvable status or fail to collect compliance data, since the feature cannot install the prerequisite agent on its own. Thus, this option addresses patching workflows and cannot serve as a substitute for Defender for Cloud's agent deployment capability.

Go deeper

Related to this question