VA-003 Explain encryption as a service Practice Question
A security architect is designing a system where one microservice writes encrypted records and a separate reporting microservice reads them. The architect wants the writer to be unable to decrypt anything, while the reader can decrypt but cannot create new ciphertext. Which Vault policy design achieves this with the transit engine?
⚠ Common exam trap
The trap here is granting read instead of update on transit encrypt and decrypt paths, because these data operations are POST requests that require the update capability.
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
✓
Grant the writer update on transit/encrypt/orders and the reader update on transit/decrypt/orders.
Transit authorizes each operation by path, so splitting update on the encrypt path for the writer and update on the decrypt path for the reader enforces the desired asymmetry. The writer can only produce ciphertext and the reader can only recover plaintext, neither gaining the other's ability. Managing keys or sharing a combined token would grant broader capability than the design intends.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Grant both services a shared token with a policy allowing update on transit/encrypt/orders and transit/decrypt/orders.
Why it's wrong here
A shared token with both capabilities collapses the separation the architect requires. Either service could then decrypt or encrypt at will, so a compromise of the writer yields decryption ability. Least privilege calls for distinct identities with distinct policies, not one credential carrying the union of permissions for both roles.
- ✓
Grant the writer update on transit/encrypt/orders and the reader update on transit/decrypt/orders.
Why this is correct
Transit operations are authorized per endpoint path, so a policy granting update on transit/encrypt/orders lets the writer encrypt but not decrypt, and update on transit/decrypt/orders lets the reader decrypt but not encrypt. This creates the least-privilege split the architect wants, since neither identity can perform the other's operation on that key.
- ✗
Grant both services update on transit/keys/orders and let the application decide which operation to call.
Why it's wrong here
The transit/keys path manages key lifecycle, such as rotation and configuration, not encryption or decryption of data. Granting it would let either service rotate or reconfigure the key, which is a privilege escalation rather than the intended split. Application-side decisions are not an access control boundary, so a compromised writer could still call decrypt.
- ✗
Grant the writer read on transit/encrypt/orders and the reader read on transit/decrypt/orders.
Why it's wrong here
Transit encrypt and decrypt endpoints are invoked with HTTP POST and therefore require the update capability, not read. A read grant on those paths does not authorize the operation, so both services would receive permission denied errors. The correct verb for these data operations is update, which is a common source of confusion for policy authors.
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.