VA-003 Explain encryption as a service Practice Question
An application stores ciphertext produced by a Vault transit key named `orders` in a database. The security team rotates the key with `vault write -f transit/keys/orders/rotate`. After rotation, the application reports that decryption of previously stored records fails. The key was never deleted or reconfigured. What is the most likely cause?
⚠ Common exam trap
The trap here is blaming rotation for breaking decryption, when the real issue is treating the version prefix as disposable metadata.
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 application stripped or altered the `vault:vN:` version prefix from the stored ciphertext.
Transit ciphertext embeds the key version in a prefix like `vault:v1:`, and Vault relies on that prefix to choose which key version decrypts the data. Rotation adds a new version without invalidating old ones, so decryption normally continues to work. When it fails after rotation while the key still exists, the prefix has usually been stripped or corrupted in storage, removing Vault's ability to identify the correct version.
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 application must re-encrypt all existing records with the new key version before decryption is possible.
Why it's wrong here
Re-encryption is not a prerequisite for decrypting old ciphertext; Vault handles decryption of any retained key version transparently. Re-encrypting is a separate operation used to bring data under the newest version, often performed with the `rewrap` endpoint. Requiring it before decryption would contradict the purpose of versioned keys.
- ✓
The application stripped or altered the `vault:vN:` version prefix from the stored ciphertext.
Why this is correct
Transit ciphertext carries a version prefix such as `vault:v1:`. Vault uses that prefix to select the correct historical key version during decryption. If the application trimmed, truncated, or otherwise modified the stored ciphertext, Vault cannot identify the version and decryption fails even though all key versions are still present.
- ✗
The application is decrypting with the wrong key name because rotation renamed the key.
Why it's wrong here
Rotation does not rename or recreate the transit key; it adds a new key version under the same name. Existing ciphertext prefixes still reference the original name and version, so a rename is not the cause. Decryption continues to work with the same key name as long as the ciphertext is intact.
- ✗
Rotation automatically deletes the previous key version, so old ciphertext can never be decrypted.
Why it's wrong here
Rotation preserves earlier key versions by default so that previously encrypted data remains decryptable. Vault only removes old versions if `min_decryption_version` is advanced or the key is explicitly deleted or trimmed. Since the key was never deleted or reconfigured, historical versions are still available and the failure lies elsewhere.
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 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.