VA-003 Explain encryption as a service Practice Question
A DevOps engineer is configuring Vault to encrypt data in transit for a microservice. They create a key in the transit engine and want to encrypt a base64-encoded plaintext. Which API path and operation should they use?
⚠ Common exam trap
HashiCorp often tests the distinction between the input field names (`plaintext` vs `ciphertext`) and the correct HTTP method (POST vs GET) for state-changing operations, leading candidates to confuse the encrypt endpoint with the decrypt endpoint or to incorrectly assume a GET request can be used.
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
✓
POST /v1/transit/encrypt/{key_name} with plaintext in payload
The Vault Transit Secrets Engine exposes a POST endpoint at `/v1/transit/encrypt/{key_name}` that accepts a JSON payload containing the `plaintext` field, which must be base64-encoded. This operation encrypts the provided plaintext using the named encryption key and returns the ciphertext. The POST method is required because the operation modifies state (encrypts data) and the plaintext is sent in the request body, not as a query parameter.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
POST /v1/transit/encrypt/{key_name} with ciphertext in payload
Why it's wrong here
The encrypt endpoint accepts base64-encoded plaintext, not ciphertext, so supplying ciphertext returns an error or garbage. It is tempting because the path and verb are correct for transit encryption, and this endpoint is the right choice when the payload is plaintext awaiting encryption.
- ✗
GET /v1/transit/encrypt/{key_name} with query param
Why it's wrong here
The encrypt endpoint accepts plaintext only via a POST body; a GET with a query parameter is not a supported operation and would not carry the data. It is tempting because GET reads are common for lookups; it would be correct for reading key metadata such as GET /v1/transit/keys/{name}.
- ✓
POST /v1/transit/encrypt/{key_name} with plaintext in payload
Why this is correct
The transit engine's encrypt endpoint accepts a base64-encoded plaintext value in the JSON payload and returns the resulting ciphertext. POST to /v1/transit/encrypt/{key_name} is the documented path, satisfying the requirement to encrypt data using the named key.
- ✗
POST /v1/transit/sign/{key_name}
Why it's wrong here
The sign endpoint produces a cryptographic signature for verifying authenticity, not ciphertext, so it cannot encrypt the base64 plaintext. It is tempting because signing also uses a transit key and returns a base64 blob; it would be correct when the microservice needs to prove a message's integrity and origin.
- ✗
POST /v1/transit/hmac/{key_name}
Why it's wrong here
The hmac endpoint generates a keyed message authentication code for integrity checking, returning a digest rather than reversible ciphertext. It is tempting because HMAC also uses a transit key and base64 output; it would be correct when the microservice must verify that a payload was not altered.
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.