VA-003 Compare and configure secrets engines Practice Question
An administrator configures a database secrets engine with a role that uses 'creation_statements' and 'revocation_statements'. However, when a lease expires, the database user is not revoked. What is the most likely cause?
⚠ Common exam trap
HashiCorp often tests the misconception that lease duration or connection health is the root cause of revocation failures, when in reality the revocation SQL statement itself is the most common point of failure.
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
✓
The revocation statement is incorrect
The most likely cause is that the revocation statement is incorrect. When a lease expires, Vault executes the SQL statement defined in `revocation_statements` to delete or disable the database user. If this statement has a syntax error, references a non-existent table, or fails to match the user created by `creation_statements`, the revocation will silently fail, leaving the user active in the database.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
The revocation statement is incorrect
Why this is correct
Vault executes the role's revocation statement when a lease expires; if that statement is malformed or targets the wrong user, revocation silently fails. This satisfies the stem's scenario where the database user persists after lease expiry despite creation working correctly.
- ✗
The connection string is invalid
Why it's wrong here
An invalid connection string prevents Vault reaching the database at configuration time, so no credentials would ever be issued, not merely left unrevoked at lease expiry. It is tempting because connectivity faults commonly break secrets engines, and it would be correct if creation_statements themselves were failing.
- ✗
The database user has been manually deleted
Why it's wrong here
Manual deletion removes the account outside Vault, so revocation_statements fail against a nonexistent user, but that is a symptom of prior misconfiguration rather than the cause of leases not triggering revocation. It is tempting because missing users are visible, and it would be correct if revocation errors cited unknown users.
- ✗
The lease duration is set too high
Why it's wrong here
A long lease merely delays revocation until expiry; it does not stop Vault from running revocation_statements when the lease finally ends. It is tempting because shortening leases is a common tuning step, and it would be correct if users persisted well beyond the intended TTL.
Go deeper
Related to this question
About these practice questions
This VA-003 question is part of Courseiva's 366-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
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.