You could rotate the key (make available the new secret) before expiring the old. During that time (which can be even a few hours) you typically reload your application to use the new credential.
If you are able to change your application's code, you could integrate with vault's API directly which is the most clean solution. If you are unable, you can use [consul-template](https://github.com/hashicorp/consul-template) or [envconsul](https://github.com/hashicorp/envconsul) to securely introduce your secret which would entail reloading/restarting your application.
The idea is that Vault creates/deletes/rotates the credentials that are used so the timeframe for exposure is limited. If your application can't re-connect to a database and drain the prior connection pool (or remove itself from a load balancer while restarting–whatever works for you) the credentials have to be long lived.
In that situation I would check out periodic tokens[0] since they live as long as they're renewed within the TTL.
if you mean the generic backend(a place to store secrets), they do not last a fixed amount of time, they are there forever.. there is a TTL, but vault does not erase anything that outlives it's TTL. Locally we just touch the TTL whenever we access it, in case someday the TTL's are followed and secrets get erased.
TOKENS however do get killed at the end of their TTL. But you can renew tokens forever if you allow for that.
How do people handle refreshing secrets on servers which maintain a connection to a database once their creds expire?