Secure compute, storage, and databases →mediumMultiple Choice

AZ-500 Secure compute, storage, and databases Practice Question

Exhibit

{
  "properties": {
    "encryption": {
      "keySource": "Microsoft.Keyvault",
      "keyvaultproperties": {
        "keyvaulturi": "https://mykeyvault.vault.azure.net/",
        "keyname": "mykey",
        "keyversion": ""
      }
    },
    "identity": {
      "type": "SystemAssigned"
    }
  }
}

Refer to the exhibit. You are deploying an Azure Disk Encryption Set using this ARM template. The deployment succeeds, but when you try to create a disk using this encryption set, the disk creation fails with an error about key vault permissions. What is the most likely cause?

⚠ Common exam trap

Many candidates assume the ARM template automatically grants the necessary key vault permissions to the disk encryption set's managed identity, when in fact this must be explicitly configured via an access policy.

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 disk encryption set's system-assigned identity lacks Get, WrapKey, and UnwrapKey permissions on the key vault

The disk encryption set uses a system-assigned managed identity to authenticate to Azure Key Vault. When the ARM template deploys the encryption set, this identity is created but must be explicitly granted Get, WrapKey, and UnwrapKey permissions on the key vault's access policy. Without these permissions, the encryption set cannot retrieve the key or perform wrapping operations, causing disk creation to fail.

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 identity type should be UserAssigned
Why it's wrong here
The selection of a system-assigned identity for a disk encryption set is fully supported; Azure documentation explicitly allows it. User-assigned identities can also be used, but they are not mandatory, and simply swapping the identity type would not resolve the underlying failure. The encryption will only succeed after the DES's identity — whether system- or user-assigned — is granted the required Key Vault permissions. Therefore, the identity type is not the cause of the error.
✗
The key vault URI is malformed
Why it's wrong here
The URI shown follows the canonical Key Vault key identifier format: a valid vault DNS name, the "keys" segment, and the key name (e.g., https://myvault.vault.azure.net/keys/mykey). An empty key version is intentionally allowed and directs Azure to always use the latest version of the key, so that does not signal malformation. A truly malformed URI would typically produce an InvalidResourceId or KeyVaultKeyNotFound error, which is not what the exhibit indicates. Thus, the URI being malformed is not the correct explanation.
✓
The disk encryption set's system-assigned identity lacks Get, WrapKey, and UnwrapKey permissions on the key vault
Why this is correct
The disk encryption set (DES) carries a system-assigned managed identity that Azure uses to authenticate to Key Vault when it must unwrap or wrap the disk encryption key. That identity needs explicit permissions on the key vault: Get on the key to read its attributes and WrapKey/UnwrapKey to perform the envelope encryption operations. Without these permissions, the DES cannot access the key material, and disk encryption or decryption operations will fail with an authorization error. Even though the URI is valid and the key exists, missing crypto permissions are the precise root cause.
✗
The key source should be Microsoft.Storage
Why it's wrong here
Disk encryption sets are purpose-built to reference a key in an Azure Key Vault; the key source is always Key Vault for encryption-at-rest with customer-managed keys. "Microsoft.Storage" is a valid encryption type for Azure Storage account encryption, not for managed disks, and cannot be substituted in the disk encryption set configuration. Reconfiguring the key source to Microsoft.Storage would break the disk encryption set's reference to the wrapping key and would not fix the permission problem. Therefore, this option misidentifies the architecture.

Go deeper

AZ-500 Secure compute, storage, and databases Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question