Implement a secure environment →easyMultiple Choice

DP-300 Implement a secure environment Practice Question

Exhibit

{
  "identity": {
    "type": "UserAssigned",
    "userAssignedIdentities": {
      "/subscriptions/123/resourceGroups/rg1/providers/Microsoft.ManagedIdentity/userAssignedIdentities/mi-sql-access": {}
    }
  },
  "properties": {
    "serverKeyType": "AzureKeyVault",
    "uri": "https://kv-sql-keys.vault.azure.net/keys/sql-key/abc123",
    "serverKeyName": "sql-key"
  }
}

Refer to the exhibit. You are configuring Azure SQL Database Transparent Data Encryption (TDE) with customer-managed keys (CMK) stored in Azure Key Vault. The deployment uses a user-assigned managed identity. However, after deployment, the TDE status shows 'Inaccessible'. What is the most likely cause?

⚠ Common exam trap

Watch out — candidates often assume the issue is with the Key Vault firewall or the identity assignment, but the most common post-deployment cause of 'Inaccessible' TDE is missing cryptographic permissions on the managed identity, not network or identity existence issues.

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 managed identity lacks 'Get', 'Wrap Key', and 'Unwrap Key' permissions on the Key Vault key

When using customer-managed keys (CMK) for TDE in Azure SQL Database, the managed identity assigned to the logical server must have 'Get', 'Wrap Key', and 'Unwrap Key' permissions on the key in Azure Key Vault. Without these specific permissions, the SQL Database service cannot retrieve or use the key to encrypt or decrypt the database encryption key, resulting in an 'Inaccessible' TDE status.

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 key specified in the URI does not exist
Why it's wrong here
A missing key produces a distinct 'key not found' error during TDE configuration, not the 'Inaccessible' state, which specifically indicates the key exists but cannot be unwrapped. It tempts because key deletion or rotation is a frequent CMK failure mode, and verifying the URI is a sensible first diagnostic step.
✗
The user-assigned managed identity is not assigned to the SQL Database server
Why it's wrong here
The identity is specified in the template, so it is assigned.
✗
The Key Vault firewall is enabled and does not allow Azure services
Why it's wrong here
Key Vault firewall rules govern the vault's data plane, but TDE's key unwrap call from Azure SQL Database originates from the SQL logical server's user-assigned managed identity, which the firewall's 'Allow trusted Microsoft services' bypass does not cover for user-assigned identities. It tempts because firewall misconfiguration commonly blocks access.
✓
The managed identity lacks 'Get', 'Wrap Key', and 'Unwrap Key' permissions on the Key Vault key
Why this is correct
TDE with customer-managed keys requires the user-assigned managed identity to hold Get, Wrap Key and Unwrap Key permissions on the Key Vault key. Without them, Azure SQL Database cannot unwrap the protector, so TDE reports Inaccessible.

Go deeper

DP-300 Implement a secure environment Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question