While this process would appear arduous at first, it provides a safer alternative to hard-coding credentials or parameters needed for the application to authenticate itself to the Key Vault. In addition, this provides the application author the ability to revoke access to the application without necessarily changing keys or certificates.
With many projects, compliance requirements dictate special handling for keys and secrets. In some cases, only a security or DevOps administrator has access to the key. Engineering teams may not be permitted to manage these keys, especially in production workloads. In these scenarios, the administrators have the responsibility of managing the life cycle of this sensitive material including creating, importing, revoking, and deleting the keys and secrets. Monitoring key usage is also a mandatory requirement in these environments. Engineering teams only have access to sensitive material via their identifiers (URIs) provided by the administrator. This way, the applications don't own responsibility to the keys/secrets. Additionally, the key management remains external to the application.
Another feature of Key Vault is having different versions of a particular key/secret. When authorized personnel wants the value of a secret/key to be updated, the older version of the secret/key is archived, in the likely event that a workload will need to decrypt data encrypted with an older version of the secret/key.
Finally, Key Vault offers logging features. Here, logging provides the ability to monitor when and who accessed a key, secret, or certificate from the Key Vault. Key Vault saves access logs into an Azure storage account. Manage this storage account by using standard access control methods.