Refer to the exhibit. A data engineer wants to ensure that all Azure Storage accounts used for analytics use customer-managed keys. They apply this Azure Policy. What is the outcome?
The policy denies StorageV2 account creation when the encryption key source is not Microsoft.Keyvault. For StorageV2 accounts using Microsoft-managed keys, the keySource field is set to Microsoft.Storage, which is not equal to Microsoft.Keyvault, so the condition is satisfied and the deny effect blocks the deployment. The result is that a StorageV2 account must use customer-managed keys with Azure Key Vault to be created.
Why this answer
The Azure Policy in the exhibit uses the 'Deny' effect on storage accounts that do not use customer-managed keys (i.e., that use Microsoft-managed keys). This means any attempt to create or update a storage account without customer-managed encryption will be blocked. Option D correctly identifies that the policy denies creation of StorageV2 accounts (or any storage account type covered by the policy scope) that use Microsoft-managed keys.
Exam trap
The trap here is that candidates confuse the 'Deny' effect with 'Audit' or 'Append', and mistakenly think the policy only monitors or tags accounts instead of actively blocking non-compliant ones.
How to eliminate wrong answers
Option A is wrong because the policy uses the 'Deny' effect, not 'Audit'; an audit effect would only log compliance without blocking creation. Option B is wrong because the policy explicitly denies storage accounts that do not use customer-managed keys, so it does not allow all accounts regardless of key type. Option C is wrong because the policy does not filter by hierarchical namespace; it applies to all storage accounts in the scope, regardless of whether hierarchical namespace is enabled.