Moving a database password from a configuration file into a central store improves control over access. The harder part is changing the password while the application is serving traffic. Secrets management covers storage, retrieval, rotation, auditing, and, for supported systems, issuing credentials with limited lifetimes.
Follow the credential from creation to retirement
Start with how the workload authenticates. A service that can prove its identity through its runtime may be able to retrieve a secret without carrying another long-lived credential for the secret store. Give each workload access to the secrets it needs and track which applications share a credential before planning a rotation.
Then trace both sides of the change. The source system must accept the new credential, and the application must load it and establish a fresh connection. A cached password can keep the old value in use even after the secret store reports a successful update.
Where three approaches fit
HashiCorp Vault supports static secrets and can generate leased credentials through compatible secrets engines. The pilot should include renewal, revocation, and how applications behave if they temporarily lose access to Vault.
AWS Secrets Manager fits workloads that already rely on AWS IAM. Test the rotation mechanism for the specific backend, including permissions and network access for any rotation function.
Google Secret Manager integrates with Google Cloud access controls and supports scheduled Pub/Sub rotation notifications. The workflow that receives the notification still needs to change the credential and update the secret version.
Before migrating more workloads, rotate one production-like credential under load. Simulate an application that misses the update and a backend that rejects the new value. Record who can recover service, how access is audited, and how long stale credentials can remain usable.