Describe core data concepts →hardMultiple ChoiceObjective-mapped

DP-900 Describe core data concepts Practice Question

Exhibit

{
  "properties": {
    "displayName": "Enforce encryption on Data Lake Storage",
    "policyType": "BuiltIn",
    "mode": "Indexed",
    "description": "This policy ensures encryption is enabled on Azure Data Lake Storage accounts.",
    "parameters": {
      "effect": {
        "type": "String",
        "defaultValue": "AuditIfNotExists",
        "allowedValues": ["AuditIfNotExists", "Deny", "Disabled"]
      }
    },
    "policyRule": {
      "if": {
        "field": "type",
        "equals": "Microsoft.Storage/storageAccounts"
      },
      "then": {
        "effect": "[parameters('effect')]"
      }
    }
  }
}

Refer to the exhibit. The JSON shows an Azure Policy definition. Which effect should be used to proactively prevent creation of storage accounts without encryption?

⚠ Common exam trap

A common mix-up: candidates confuse 'AuditIfNotExists' with a proactive block, not realizing it only logs non-compliance after the resource is created, whereas 'Deny' is the only effect that prevents creation entirely.

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

✓

Deny

The 'Deny' effect is correct because it proactively blocks the creation or update of a storage account that does not meet the encryption requirement, preventing non-compliant resources from being provisioned. This aligns with Azure Policy's ability to enforce compliance at resource creation time, rather than auditing or remediating after the fact.

Answer analysis

Option-by-option breakdown

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

✗
AuditIfNotExists
Why it's wrong here
The AuditIfNotExists effect logs a compliance event when a required dependent resource or field is absent, but it does not prevent the resource from being created or updated. In this scenario, using AuditIfNotExists would flag the non-compliant resource in the compliance report, but the deployment would still succeed. Because the policy's goal is to block non-compliant resource creation, this effect is not sufficient; it only provides visibility after the fact.
✓
Deny
Why this is correct
The Deny effect actively intercepts resource creation or update requests and compares the request against the policy rule. If the condition matches, Azure returns a 403 Forbidden error, preventing the resource from being provisioned. This is the correct effect when the requirement is to block non-compliant resources, because it enforces the policy at request time and does not allow the deployment to continue.
✗
Disabled
Why it's wrong here
The Disabled effect deactivates the policy definition, making Azure Policy ignore it completely during resource provisioning. No evaluation or enforcement occurs, so non-compliant resources are created without any objection. While disabling a policy is useful for temporarily turning it off without deleting the definition, it cannot be used to block resource creation because it takes no action at all.
✗
Append
Why it's wrong here
The Append effect is designed to add or modify fields, such as tags, on a resource during creation or update. It evaluates the resource and adds the required fields if they are missing, but it never rejects or blocks the request. In this context, Append would simply add the required metadata and allow the deployment to proceed, which does not achieve the goal of preventing non-compliant resource creation.

Go deeper

DP-900 Describe core data concepts Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question