HashiCorp Vault Associate (003) Question 173
Single answer6a Encrypt and decrypt secretsA security team wants an internal application to protect API tokens before storing them in a database. The application must be able to recover the original token later, so hashing is not acceptable. The team enables Vault's transit secrets engine at the path transit/ and creates a key named api-token. A developer tries to encrypt a token by sending the raw plaintext directly to transit/encrypt/api-token, but Vault returns an error. What should the developer do to successfully encrypt and later decrypt the token using Vault transit?
- A
Base64-encode the plaintext before sending it to transit/encrypt/api-token, then send the returned ciphertext to transit/decrypt/api-token when recovery is needed
- B
Store the token in the KV secrets engine instead, because transit only supports hashing and signing, not reversible encryption
- C
Use the cubbyhole secrets engine because it automatically encrypts the token and allows any authenticated application to decrypt it later
- D
Provide the plaintext as a SHA-256 hash to transit/encrypt/api-token, then decrypt the hash through transit/decrypt/api-token when needed
Show answer and explanation
Correct answer: A
Explanation
The correct solution is to use the transit secrets engine for cryptographic operations and base64-encode the plaintext before calling the encrypt endpoint. In Vault, transit is commonly used when applications need encryption as a service without exposing key material to the application. The encrypt endpoint expects the plaintext field to be base64-encoded, and the decrypt endpoint accepts the ciphertext returned by Vault. This aligns with HashiCorp Vault transit documentation and best practices for protecting sensitive application data while preserving the ability to decrypt it later. KV and cubbyhole are storage backends, not substitutes for transit encryption, and hashing is not reversible, so it does not meet the requirement.
- A. Correct.
Correct. Vault's transit secrets engine performs encryption and decryption without storing the plaintext. For the encrypt endpoint, the plaintext field must be base64-encoded before it is sent to Vault. Vault returns ciphertext in the form of a Vault-formatted value (for example, starting with vault:v1:), and that ciphertext can later be passed to the decrypt endpoint to recover the original value. This is the standard pattern for application-layer encryption with transit.
- B. Incorrect.
Incorrect. This reflects a common misconception. The KV secrets engine stores secret values, while the transit secrets engine is specifically designed for cryptographic operations such as encryption, decryption, signing, and HMAC generation. Transit absolutely supports reversible encryption when using the encrypt and decrypt endpoints.
- C. Incorrect.
Incorrect. Cubbyhole is a per-token private storage backend, not a cryptographic service for application data protection. It does not provide the same encrypt/decrypt workflow as transit, and data in one token's cubbyhole is not broadly accessible to other authenticated applications. Choosing cubbyhole here confuses secret storage with cryptographic transformation.
- D. Incorrect.
Incorrect. A hash is one-way and cannot be decrypted back to the original token. Transit encryption requires the original plaintext, base64-encoded, not a SHA-256 digest. Someone might choose this if they confuse hashing with encryption, but the scenario explicitly requires recovery of the original token.