Your company has a strict policy that Azure SQL Database backups must be encrypted with customer-managed keys stored in Azure Key Vault. You configure TDE with AKV integration. After a key rotation, you find that long-running queries start failing with encryption errors. What is the most likely cause?
TDE requires all previous key versions to be enabled to decrypt existing data.
Why this answer
When TDE is configured with Azure Key Vault (AKV) integration, the database uses the current key version from AKV to encrypt and decrypt data. If the previous key version is disabled or deleted during a key rotation, any long-running queries that still rely on that specific key version for decryption will fail with encryption errors. The database cannot automatically fall back to the new key version for in-flight operations that started before the rotation.
Exam trap
The trap here is that candidates often assume key rotation is seamless and never causes failures, overlooking that disabling or deleting the previous key version can break in-flight operations that still depend on it.
How to eliminate wrong answers
Option A is wrong because the service principal used for AKV access is a separate authentication entity; its expiration would cause a persistent access failure, not selective failures on long-running queries after a key rotation. Option C is wrong because Azure Key Vault and Azure SQL Database can be in different regions; cross-region access is supported and does not cause encryption errors. Option D is wrong because the scenario explicitly states that TDE with AKV integration is configured, meaning customer-managed keys are already in use; the database is not using service-managed TDE.