VA-003 Compare and configure secrets engines Practice Question
A database secrets engine is configured at database/ with a connection to PostgreSQL and a role named app-readonly. The role uses creation_statements to create a user with a random password and a TTL of one hour. An application retrieves credentials and uses them successfully, but after the lease expires the database user still exists and can log in. Which configuration change should the administrator make to ensure the user is removed when the lease ends?
⚠ Common exam trap
The trap here is assuming that lease expiration alone deletes the database user, when Vault depends on revocation_statements and the connection user's privileges to perform the cleanup.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Add revocation_statements to the role that drop the user, and ensure the connection user has permission to execute them.
Dynamic database credentials are cleaned up by executing the role's revocation_statements when the lease is revoked or expires. If those statements are absent or the connection user lacks the privilege to run them, the created user remains. Supplying correct DROP USER statements and ensuring the connection user can execute them restores proper lifecycle management.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Enable the database secrets engine with a root rotation schedule to force user cleanup.
Why it's wrong here
Root credential rotation updates the connection's privileged credentials and does not clean up dynamically created users from leases. It has no direct effect on revocation statements or on removing the app-readonly user, so it does not address the persistent database user described.
- ✗
Set the role's credential_type to static_role and rely on automatic revocation.
Why it's wrong here
Static roles map to pre-existing database users and do not create or delete users per lease, so they do not provide the dynamic creation and cleanup behavior described. Changing to static_role would actually stop the creation of new users and is the opposite of what the scenario requires.
- ✗
Increase the default_ttl on the role to match the maximum_ttl so the lease never expires.
Why it's wrong here
Extending the TTL delays expiration but does not remove the user; it simply postpones the problem and leaves credentials valid longer. The scenario requires cleanup at lease end, not avoidance of expiration, so changing TTLs does not satisfy the requirement and weakens the short-lived credential model.
- ✓
Add revocation_statements to the role that drop the user, and ensure the connection user has permission to execute them.
Why this is correct
Revocation is driven by revocation_statements on the role, which Vault executes when the lease expires or is revoked. If they are missing or the connection user lacks privileges, the database user persists. Adding appropriate DROP USER statements and granting the connection user permission resolves the lingering-user problem.
Go deeper
Related to this question
About these practice questions
One of 366 original VA-003 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official HashiCorp exam blueprint
This VA-003 practice question is part of Courseiva's free HashiCorp certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the VA-003 exam.