Secure Azure using Microsoft Defender for Cloud and Microsoft Sentinel →hardMultiple Choice

AZ-500 Practice Question: Secure Azure using Microsoft Defender for Cloud and Microsoft Sentinel

Exhibit

{
  "properties": {
    "policyDefinitionId": "/providers/Microsoft.Authorization/policyDefinitions/12345678-1234-1234-1234-123456789012",
    "parameters": {
      "effect": {
        "value": "DeployIfNotExists"
      },
      "workspaceId": {
        "value": "/subscriptions/12345678-1234-1234-1234-123456789012/resourcegroups/myResourceGroup/providers/Microsoft.OperationalInsights/workspaces/myWorkspace"
      }
    }
  }
}

Refer to the exhibit. You are reviewing a policy assignment in Microsoft Defender for Cloud that deploys the Log Analytics agent to Azure VMs. The policy uses 'DeployIfNotExists' effect and specifies a workspace. However, newly created VMs are not showing the agent installed. What is the most likely cause?

⚠ Common exam trap

A common mix-up: candidates assume a policy with 'DeployIfNotExists' automatically has permissions to deploy resources, but Azure Policy requires an explicit managed identity assignment for remediation actions, which is a common oversight in exam scenarios.

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 policy assignment does not have a managed identity assigned.

The 'DeployIfNotExists' effect in Azure Policy requires a managed identity to perform remediation tasks, such as installing the Log Analytics agent. Without a managed identity assigned to the policy assignment, the policy can evaluate compliance but cannot execute the deployment action. This is the most likely cause because the policy is correctly configured but lacks the necessary identity to write resources (agent installation) to the VM.

Answer analysis

Option-by-option breakdown

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

✗
The workspace ID is incorrect.
Why it's wrong here
The exhibit displays a syntactically valid workspace ID; if it were genuinely incorrect, the policy assignment would fail validation or the agent would error during installation. An invalid workspace ID would produce an explicit error in the activity log, not simply a lack of installation. Since the policy assignment is active and the effect is not the issue, the workspace ID is not the most likely cause.
✓
The policy assignment does not have a managed identity assigned.
Why this is correct
DeployIfNotExists policies require a managed identity to execute the deployment template that installs the Log Analytics agent. Without a system-assigned or user-assigned managed identity on the policy assignment, Azure Policy cannot perform any remediation actions, so the agent is never deployed. The exhibit likely omits this identity, making it the most probable reason no installation occurs.
✗
The policy effect is set to 'Disabled'.
Why it's wrong here
The effect shown in the exhibit is explicitly DeployIfNotExists, not Disabled. If the effect were Disabled, the policy would be inert and would not evaluate or attempt any deployment. Because the effect is active and the policy is assigned, the absence of installation cannot be attributed to a disabled effect.
✗
The Log Analytics workspace is in a different region than the VMs.
Why it's wrong here
The Log Analytics agent can connect to a workspace in any region; region mismatch does not prevent agent installation or reporting. The workspace ID and key are sufficient for the agent to authenticate and send data regardless of geographic location. While data residency may be affected, region mismatch is not a technical blocker to deployment.

Go deeper

AZ-500 Practice Question: Secure Azure using Microsoft Defender for Cloud and Microsoft Sentinel

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question