Let's look at key rotation with regard to transparent data encryption. First, I'll generate a key and configure a rotation policy. I'll give the key an appropriate name and click the not configured rotation policy link. The expiry time field applies to the new rotated key, not the key we're creating now. Next, we enable the rotation policy and select a rotation option. Only the automatically renew at a given time after creation option is enabled, as there is no expiration date set on the key. If I cancel out and set an expiration date, we can set the key to be renewed at a time relative to the expiration date. The rotation time must be less than the expiry time. Set a notification period that will give you enough time to sort out all the resources using the key that cannot handle the key rotation automatically. 

With the key and rotation policy in place, let's see how it can be applied to an SQL Server instance using transparent data encryption. Here we are on the security page of create an SQL database, where we can configure TDE. I'll select customer-managed key, so I can select the key I created earlier. The change key hyperlink lets us pick the key from a vault. I don't want to set the key here, so I'll cancel selecting a key. The message tells us that we'll need to set the appropriate permissions for the SQL identity so it can perform the required get, wrap, and unwrap actions. This is not necessarily the case if we set up the key vault relationship after creating the SQL Server resource. I'll fast-forward through the rest of the database creation.

Now the SQL Server resource is up and running, let's set up transparent data encryption. I'll go through the same process of selecting the key as I did when creating the SQL Server, but his time, I'll complete it. Notice I have to select a specific version of the key as opposed to the generic current version. The message here is slightly different, with the addition of "If needed, we will try granting these permissions on your behalf." I'm going to make an educated guess and say that as the resource's managed identity now exists, Azure can use it to grant the permissions automatically. I'll also check auto-rotate key. Typically when you select a key and have to choose a specific version of the key, as I did here, you will need to manually update the key in the resource. However, this is not the case with TDE keys. As it is such a common task, Azure has automated the process. When automatic key rotation is enabled the SQL Server will regularly check the vault for an updated key. If a new key is found, the database server will start using it within 60 minutes. If you need to restore a database which has been encrypted with a key that has been rotated since the last backup was taken, then you'll need to re-instate the pre-rotated key.