HashiCorp Vault Associate (003) Question 170
Single answer6a Encrypt and decrypt secretsA security team stores customer API keys in an external application database, but developers must never see the plaintext values after initial onboarding. They decide to use Vault's Transit secrets engine so the application can encrypt API keys before storing them and decrypt them only when needed at runtime. An engineer enables Transit at the default path and creates a key named "customer-keys". The application successfully encrypts a value, stores the returned ciphertext, and later sends that ciphertext back to Vault for decryption. Which action is required for Vault to return the original plaintext value to the application?
- A
Send the ciphertext to the transit/decrypt/customer-keys endpoint and base64-decode the plaintext field returned by Vault
- B
Send the ciphertext and the original plaintext together to the transit/rewrap/customer-keys endpoint so Vault can verify and decrypt it
- C
Read the key material for customer-keys from Vault and use it locally to decrypt the ciphertext
- D
Call the transit/encrypt/customer-keys endpoint again with the ciphertext to reverse the earlier encryption
Show answer and explanation
Correct answer: A
Explanation
Vault's Transit secrets engine is commonly used for encryption-as-a-service when applications need to protect sensitive data such as API keys, tokens, or identifiers without storing encryption keys in the application. The correct workflow is to send base64-encoded plaintext to the encrypt endpoint and later send the resulting ciphertext to the decrypt endpoint for the same key. Vault returns plaintext as a base64-encoded string, which the client decodes locally. This design keeps key material inside Vault and supports operational features such as key rotation, convergent encryption options, and rewrap. According to Vault Transit documentation and best practices, rewrap is for re-encrypting ciphertext under the latest key version without revealing plaintext, while decrypt is the only operation that returns the original value.
- A. Correct.
Correct. With the Transit secrets engine, decryption is performed by sending the ciphertext to the decrypt endpoint for the named key, such as transit/decrypt/customer-keys. Vault returns the recovered plaintext base64-encoded in the response, so the client must base64-decode that value to obtain the original secret. This reflects the normal Transit workflow: plaintext is provided to encrypt, ciphertext is provided to decrypt, and key material remains inside Vault.
- B. Incorrect.
Incorrect. The rewrap endpoint is not used to decrypt data for the client. Rewrap takes existing ciphertext and returns new ciphertext encrypted under the latest version of the same key, without exposing plaintext. It is useful for key rotation workflows, not for recovering the original value. Including the original plaintext is also unnecessary and not part of the API contract for rewrap.
- C. Incorrect.
Incorrect. A core purpose of the Transit engine is that Vault performs cryptographic operations without exposing the underlying key material to clients. Clients do not read Transit key material and decrypt locally. Someone might choose this option if they confuse Transit with a key-value secrets engine or a traditional key export workflow, but Vault Transit is specifically designed to avoid that pattern.
- D. Incorrect.
Incorrect. The encrypt endpoint does not reverse a previous encryption operation. Passing ciphertext to the encrypt endpoint would be treating ciphertext as if it were plaintext input, producing another ciphertext value rather than the original secret. This distractor reflects a common misunderstanding that encryption is symmetric at the API level; in Transit, encrypt and decrypt are separate operations with different endpoints.