Dynamic secrets solve the problem of leaking long-lived, permanent passwords that are shared across many applications. For the VA-003 exam, you must understand that a dynamic secret is generated on demand, has a time-to-live (TTL), and is automatically revoked when it expires, replacing the risky practice of hard-coding passwords in application code.
Jump to a section
A simple way to picture Dynamic Secrets and Database Secrets Engine
A restaurant's guest list is a temporary, one-time permission slip to enter a specific table at a specific time. This list is created by the host, handed to the guest just before their meal, and becomes completely invalid the moment the guest leaves the restaurant. The host never gives the guest the master key to the building, only a temporary pass to a single table.
In an IT environment, a database is similar to a restaurant. The database secrets engine in HashiCorp Vault acts as the host. Instead of creating a permanent username and password (a permanent key to every table), Vault generates a dynamic, temporary credential for a specific database, for a specific application, and only for a specific duration. When the application's work is done (the guest leaves), Vault automatically destroys that credential (the guest list is thrown away). This prevents an attacker from finding a leftover, forgotten password that works on every database, just as it would be dangerous if a restaurant guest kept a permanent key to all tables.
To understand dynamic secrets and the database secrets engine, you first need to understand the problem they solve. Traditionally, when an application wants to talk to a database, it needs a username and password. IT teams would create one set of credentials (a single username and password) and hard-code it into the application’s configuration file or source code. This is like writing your house key on a sticky note and taping it to the front door. If an attacker ever reads that configuration file, they now have permanent, unrestricted access to the database. They can read, modify, or delete all the data. Even if you discover the breach, you have to change the password manually, update every application that uses it, and restart those applications – a slow and painful process.
A dynamic secret, in contrast, is a credential that is generated on demand by Vault. It is not permanent. Every time an application needs to access a database, it asks Vault for a new, unique username and password. Vault communicates with the database (using the database secrets engine) and creates a temporary user account that is valid only for a specific amount of time, for example, one hour. The application uses this credential to connect to the database, performs its work, and when the hour is up, Vault automatically tells the database to delete that user account. The credential is gone forever.
The term “database secrets engine” refers to a plugin within Vault that knows how to talk to a specific type of database, such as PostgreSQL, MySQL, MongoDB, or Microsoft SQL Server. You configure this engine by giving Vault a special “root” or “admin” credential that has permission to create and delete other users on the database. Vault then uses that admin power to dynamically create and destroy temporary usernames and passwords on your behalf.
Here are the key components of how this works:
A role definition in Vault: You create a “role” inside Vault that describes exactly what the temporary user can do. For example, a role might say “only allow read access to the ‘orders’ table” or “only allow the user to execute a specific stored procedure.” The role also defines the default time-to-live (TTL) for the credentials, such as 30 minutes.
The lease: When Vault creates a dynamic secret, it issues a “lease.” This lease is a contract that the credential is valid for a certain period. The lease is tracked by Vault, and Vault is responsible for revoking it when it expires.
Revocation: When the lease expires or is explicitly revoked, Vault connects back to the database and issues a command to delete the temporary user account. This ensures no stale credentials linger.
Renewal: An application can ask Vault to renew the lease before it expires. This extends the life of the credential. However, if the credential passes its maximum TTL, it cannot be renewed and must be revoked.
A real example: Imagine you have a Python application that needs to read customer data from a PostgreSQL database. Without Vault, you would store the password in a configuration file. With Vault, the application first authenticates to Vault using an identity token (like a machine “role” or a Kubernetes service account). It then requests a credential for the “customer-reader” role. Vault generates a unique PostgreSQL user like “db_user_a1b2c3” with a password like “pffab12…” and returns it to the application. The application connects to PostgreSQL, reads the data, and closes the connection. Fifty-nine minutes later, Vault revokes that user. Even if an attacker intercepted the credential during that minute, they only had a short window to use it. If they stole the configuration file later, they would find nothing useful because the user no longer exists.
The database secrets engine replaces the old model of static, shared, long-lived passwords. It reduces the blast radius of a security breach, simplifies credential rotation (because Vault does it automatically), and provides audit logs of exactly who requested a credential and when. For the VA-003 exam, you need to know the lifecycle of a dynamic secret: creation, lease, renewal, and revocation. You also need to understand that Vault uses a root/admin credential to manage temporary users, and that the role definition controls what permissions the temporary user gets.
Enable the database secrets engine
The administrator enables the database secrets engine at a specific path in Vault (e.g., database/). This tells Vault to prepare the ability to manage database credentials.
Configure the database connection
The administrator provides Vault with a static admin credential that has permission to create and delete users on the target database. This is the only permanent credential that Vault holds.
Define a role
The administrator creates a role that specifies the SQL statements Vault should run to create a temporary user. The role also sets the default TTL and maximum TTL for the credentials.
Application authenticates to Vault
The application sends a request to Vault to authenticate itself (e.g., using an AppRole or a token). Vault validates the identity and returns a short-lived token to the application.
Application requests a database credential
Using the Vault token, the application requests a credential from the role. Vault executes the creation statements on the database, generates a unique username and password, and returns them to the application.
Application uses and discards the credential
The application connects to the database using the temporary credential, performs its work, and then closes the connection. The application does not store the credential for future use.
Vault revokes the credential
After the TTL expires or when the application explicitly revokes the lease, Vault runs the revocation statements on the database to delete the temporary user account, ensuring the credential cannot be reused.
An IT professional responsible for securing a company’s backend services would use the database secrets engine to eliminate hard-coded passwords in their application code. Here is a concrete, step-by-step scenario from a real business context.
Imagine a mid-sized e-commerce company called ShopFast. They run a web application that uses a MySQL database to store product information, customer orders, and inventory data. In the past, the development team stored the MySQL root password directly in the application’s source code, which was stored in a version control system like GitHub. This was a massive security risk because any employee or attacker with access to the code could see the database password. The IT operations team spent hours every month manually rotating that password, updating every server, and restarting the application.
The IT security architect decides to implement HashiCorp Vault with the database secrets engine. Here is what they do, step by step:
First, they set up a Vault server and enable the database secrets engine for MySQL.
They provide Vault with a static admin credential (a MySQL user with CREATE USER and DROP USER permissions). Vault is the only system that holds this powerful credential.
They create a Vault role called “shopfast-app-reader” that specifies the SQL statements Vault should run when creating a temporary user. For example, the role includes a creation statement: CREATE USER '{{name}}'@'%' IDENTIFIED BY '{{password}}'; GRANT SELECT ON shopfast.* TO '{{name}}'@'%'; This means the temporary user can only run SELECT queries (read-only) on the ShopFast database.
The role also configures a default TTL of 15 minutes and a maximum TTL of 1 hour.
Next, the team updates the shopfast web application to authenticate with Vault using an AppRole (a machine identity). The application is configured with a role ID and a secret ID, both of which are distributed securely, not hard-coded. Every time the application needs to query the product catalogue (which happens hundreds of times per minute), it follows this process:
The application sends a request to Vault, authenticating with its AppRole credentials.
Vault validates the identity and returns a short-lived Vault token.
Using this token, the application requests a dynamic database credential from the “shopfast-app-reader” role.
Vault connects to MySQL, creates a temporary user (e.g., “v-token-shopfast-a1b2c3”), sets a randomised password, and returns the username and password to the application.
The application uses these credentials to connect directly to MySQL, run its SELECT queries, and generates the product catalogue page for the user.
The application closes the database connection.
Fifteen minutes later, Vault automatically revokes the temporary MySQL user, even if the application forgot to close it.
This scenario has several real-world benefits that an IT professional would care about:
The blast radius of a breach is tiny. If an attacker compromises the web application server, they only get access to a credential that works for 15 minutes and only allows read-only access.
Password rotation is fully automated. The IT team never has to manually change a password again.
Audit trails are clear. Vault logs every credential request, showing which application requested it, when, and from which IP address.
Compliance requirements become easier. Auditors love to see that database credentials are temporary and automatically rotated.
The IT professional also needs to plan for failure. If Vault is down, no new database connections can be made. To handle this, the team might configure a static fallback credential for emergency access (stored in a secure offline location), or they might set up Vault in a highly available cluster. For the VA-003 exam, however, you do not need to dive into high-availability architecture; you just need to know the core flow: request, generate, use, revoke.
The VA-003 exam tests your understanding of how dynamic secrets work within the database secrets engine, and there are specific traps and patterns you must recognise. The exam objective 2.3 “Generate dynamic secrets using the database secrets engine” focuses on the lifecycle, configuration, and behaviour of these credentials. Here is exactly what you need to know.
First, the exam will ask you to identify what a dynamic secret is versus a static secret. A dynamic secret is generated on demand, has a lease with a TTL, and is automatically revoked. A static secret is a long-lived credential stored in Vault (like an API key or a database password that never changes). A common trick question is to show a list of “secrets” and ask which one is a dynamic secret. The answer is always the one that involves Vault creating a temporary user in a database.
Second, the exam tests the concept of a lease. You must understand that a lease has a duration (TTL) and can be renewed or revoked. The exam may present a scenario where an application needs to keep using the database for longer than the default TTL. The correct answer is that the application can renew the lease (if it is within the maximum TTL), or the lease expires and the credential is revoked. They may also ask what happens after the maximum TTL – the credential is revoked and cannot be renewed.
Third, the exam tests the idea of a role. You must remember that a role describes the permissions of the temporary database user. The role includes creation statements (SQL commands to create the user) and revocation statements (SQL commands to drop the user). The exam may ask which component defines what tables a temporary user can access. The answer is the role definition.
Exam traps to watch for:
They might suggest that the application must store the database credential permanently. The correct answer is that the application requests a new credential each time and does not store it.
They might imply that Vault passes through the admin credential to the application. This is false. Vault uses the admin credential internally but only hands out temporary credentials.
They might say dynamic secrets are only for databases. This is false. Dynamic secrets also exist for other engines (like AWS or SSH), but the database secrets engine is specifically for databases.
They might confuse “lease” with “token.” A lease is associated with the database credential; a token is the credential used to authenticate to Vault itself.
Key definitions to memorise:
Dynamic secret: A credential generated on demand with a configurable TTL and automatic revocation.
Database secrets engine: The Vault plugin that manages creating and destroying temporary database users.
Role: A named configuration that defines the SQL statements for user creation and the TTL settings.
Lease: The contract that tracks the validity period of a dynamic secret.
Revocation: The process of deleting the temporary database user when the lease expires.
The exam may also test the concept of rotation. Dynamic secrets are automatically rotated because each request generates a new credential. Static secrets in Vault require manual rotation. Expect a question that asks: “Which approach eliminates the need for manual credential rotation?” The answer is dynamic secrets.
Finally, the exam may present a troubleshooting scenario. For example, “An application cannot connect to the database after 30 minutes. What is the most likely cause?” The answer is that the dynamic credential’s lease expired and the user was revoked. They want you to know that TTL is the key parameter.
A dynamic secret is a temporary credential generated on demand with a time-to-live (TTL) that is automatically revoked when the lease expires.
The database secrets engine in Vault uses an admin credential to dynamically create and destroy temporary database users.
A role in the database secrets engine defines the exact permissions (via SQL creation statements) that the temporary user will have on the database.
Leases track the lifecycle of a dynamic secret and can be renewed up to a maximum TTL, after which revocation is mandatory.
Dynamic secrets eliminate the need for manual password rotation and reduce the security risk of leaked static credentials.
The application never stores the dynamic secret permanently; it requests a new credential each time it needs database access.
These come up on the exam all the time. Here's how to tell them apart.
Dynamic Secret
Generated on demand with each request
Has a TTL and is automatically revoked
Reduces blast radius of a credential leak
Static Secret
Created once and stored permanently in Vault
No automatic expiration unless manually rotated
If leaked, remains valid until manually changed
Role Definition
A configuration object that defines permissions and TTL
Persists in Vault until deleted or updated
Contains SQL creation and revocation statements
Lease
A temporary contract for a specific credential instance
Exists only while the credential is active
Tracks creation time, current TTL, and expiry
Database Secrets Engine
Generates dynamic, temporary credentials
Interacts with external database systems
Requires an admin credential to operate
KV Secrets Engine
Stores static key-value pairs (e.g., passwords, API keys)
Does not interact with external systems
No automatic credential generation or rotation
Renewal
Extends the TTL of a dynamic credential
Can only be performed before the maximum TTL is reached
Prevents the credential from expiring mid-operation
Revocation
Immediately ends the credential’s validity
Can be triggered manually or automatically by TTL expiry
Deletes the temporary database user
Mistake
Dynamic secrets are permanent passwords that are just stored more securely in Vault.
Correct
Dynamic secrets are temporary passwords that expire and are automatically revoked after a set TTL.
Beginners often assume Vault just acts as a secure password manager (like a safe for passwords). They miss the central idea that the password does not persist.
Mistake
The database secrets engine requires a separate, dedicated Vault server for each database type.
Correct
One Vault server can host multiple database secrets engines (one per database type) simultaneously.
The word 'engine' sounds like a separate machine or service, but in Vault it is just a logical plugin.
Mistake
Vault stores the temporary password in its storage backend permanently for auditing.
Correct
Vault returns the password to the application and does not store it in its durable storage. It only tracks the metadata of the lease.
People assume Vault keeps a copy 'just in case,' but that would defeat the purpose of a secret that should not persist.
Mistake
If you set a very long TTL (like 30 days), the dynamic secret behaves the same as a static secret.
Correct
Even with a long TTL, the credential is still a dynamic secret and will be revoked after the TTL expires. A static secret never expires unless manually deleted.
Beginners think TTL is optional or just a recommendation. The exam stresses that TTL is enforced.
Mistake
The database secrets engine can only create database users with the same permissions as the admin credential.
Correct
The role definition can restrict permissions. For example, the temporary user can be limited to read-only access, even if the admin credential has full access.
It is tempting to think that the temporary user inherits the admin’s full power, but the role’s creation statements define a narrower scope.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
The database user is revoked by Vault, and the application’s database connection will be terminated. The application must handle this by either renewing the lease before it expires or requesting a new credential.
Yes, Vault supports many databases including MongoDB, Microsoft SQL Server, Oracle, and more through specific database secrets engine plugins.
No, Vault does not store the password. It only stores lease metadata (like the username and TTL). The password is returned to the application once and is not persisted.
A role is a configuration that defines the permissions and TTL settings for temporary users. A lease is the actual contract for a specific dynamic credential, tracking its creation time and expiry.
Yes, you can manually revoke the lease from Vault’s command line or API, which immediately deletes the temporary database user.
Dynamic secrets reduce the risk of a leaked credential because they are short-lived and automatically rotated. Static secrets, though stored securely, remain valid until manually rotated.
You've finished Dynamic Secrets and Database Secrets Engine. Continue through the VA-003 study guide to build a complete picture of the exam.
Done with this chapter?