Bring Your Own Key to Azure SQL Database TDE
Bradley Schacht is a Principal Program Manager on the Microsoft Fabric product team based in Saint Augustine, FL. Bradley is a former consultant, trainer, and has coauthored 6 SQL Server and Power BI books, most recently Learn Microsoft Fabric. As a member of the Microsoft Fabric product team, Bradley works directly with customers to solve some of their most complex data problems and helps shape the future of Microsoft Fabric. Bradley gives back to the community through speaking at events such as the SQLBits, Fabric Community Conference, PASS Community Data Summit, SQL Saturdays, Code Camps, and user groups across the country including locally at the Jacksonville SQL Server User Group (JSSUG). He is a contributor on SQLServerCentral.com and blogs on his personal site, BradleySchacht.com.
Great news, now you can bring your own key to Azure SQL Database TDE! The process to bring your own key (BYOK) is a little tricky at the moment since there is no portal option for doing this. So break out the PowerShell and follow along below. For my sample, I am going to be taking an existing server and database that are currently deployed with TDE enabled, UtilityMeters. You can see the encryption_state = 3 meaning the database is encrypted and the encryptor_thumbprint is 0x55ED837D5D49B0AF6C21F37C39E05FAD6D8A417D. The process is only slightly different on the first step if you are creating a new server, but you can always create the server and then follow these steps.
As previously mentioned you will need to use PowerShell to complete the setup. You'll need to use Azure PowerShell version 4.2.0 or newer. First, we need to create an Azure Active Directory identity for our SQL Server. If you recall from the previous TDE/Key Vault post, Azure Key Vault uses Azure AD for authenticating into the service and managing permissions on key access. Our first command will accomplish this. We will need the Principal ID later, so we'll want to hold on to the output in a variable. The optional parameter "AssignIdentity" will generate and assign an Azure Active Directory Identity for this server for use with Azure Key Vault.
Next, we need to grant this new identity, our server, the appropriate rights on our Key Vault service. It will need to be able to get, wrap and unwrap keys.
Now it is time to associate your key with your SQL Server. First, a key will need to exist in the Key Vault. If one does not exist, create it now. Navigate to your Key Vault in the 
Run the following PowerShell command to add key to the SQL Server.
Run the following PowerShell command to set the key as the TDE key for the server resources.
To verify the TDE key on the server has switched from being managed by the service over to the Key Vault key you can run Get-AzureRmSqlServerTransparentDataEncryptionProtector. I know exactly what you are thinking. That is a nice, short, sweet, to the point command.
Notice the Key ID matches the key that was generated in Key Vault. The next screenshot is what the output will be when the TDE key is managed by the service rather than the key you provided in Azure Key Vault. 
If you had TDE enabled at the database level then you are done! That is all, the key change will be reflected at the database level through the same system DMV in the beginning of this post. If you still need to enable TDE on the database that can be done through the portal or by running
Back in SSMS you can see the key has been changed as the thumbprint has changed. 
And now the thumbprint is back to what it was before I moved to Azure Key Vault keys. 
It was time to do some digging. By running Get-AzureRmKeyVault -VaultName "bradschacht" I was able to see the property called Soft Delete Enabled? was blank. Interesting, and not exactly what I was looking for. 
If you run that command and don't even see a property listed for Soft Delete Enabled then you may have an outdated version of the PowerShell cmdlets. In that case run the following to see the property value: