Auditors want the canal authority to hold the TDE protector for lock-lab Azure SQL. What change meets that requirement without turning this into Key Vault administration?
Select an answer to reveal the explanation.
Short Explanation
Service-managed TDE is Microsoft holding the protector. Point SQL at your Key Vault or Managed HSM key and let the SQL identity unwrap it—that’s customer-managed TDE, not a vault redesign project.
Full Explanation
Customer-managed TDE means switching the logical server or managed instance from the service-managed TDE protector to a key in Azure Key Vault or Managed HSM and granting the SQL identity permission to wrap and unwrap that key. The canal authority then controls protector rotation and custody while TDE continues to encrypt data files, logs, and backups. Keeping the service-managed protector and storing a portal screenshot proves nothing about customer key custody. Disabling TDE and encrypting exports on a help-desk laptop abandons platform encryption and creates unmanaged copies. Dynamic data masking does not implement a TDE protector. Exam caveat: if the CMK becomes unavailable, databases depending on it can go inaccessible—soft-delete and purge protection on the vault, plus tested key rotation and access policies, are mandatory companions to customer-managed TDE. Operational check: configure the CMK on a non-production server first, confirm databases show customer-managed protector, rotate the key following Microsoft’s documented process, validate backups and restores, then promote the pattern to production with break-glass vault access documented. Record the Key Vault URI and SQL identity role assignments in the change ticket so future rotations are repeatable.