HashiCorp Vault Associate (003) Question 172
Single answer6a Encrypt and decrypt secretsA security team wants an internal billing application to protect customers' account numbers without storing the encryption key in the application. The application must be able to send plaintext to Vault, receive ciphertext, and later send that ciphertext back to Vault to recover the original value. The team enables the Transit secrets engine at path transit/ and creates a key named billing-key. Which approach should the application use?
- A
Call transit/encrypt/billing-key with the plaintext (base64-encoded), store the returned ciphertext, and later call transit/decrypt/billing-key with that ciphertext
- B
Store the account numbers in KV v2 and rely on Vault to automatically encrypt and decrypt them when reading and writing the secret
- C
Call transit/sign/billing-key to protect the account numbers, then call transit/verify/billing-key to recover the original plaintext when needed
- D
Read the raw encryption key material from transit/keys/billing-key and perform encryption and decryption inside the application
Show answer and explanation
Correct answer: A
Explanation
The correct solution is to use the Transit secrets engine's encrypt and decrypt endpoints with the named key. In Vault, Transit provides cryptographic functions as a service so applications can protect sensitive values without direct access to encryption keys. For encryption, the plaintext sent to the API must be base64-encoded, and Vault returns ciphertext in a Vault-formatted value such as vault:v1:... . That ciphertext can later be passed to the matching decrypt endpoint to recover the original plaintext. By contrast, KV v2 is for storing secrets, not for performing application-side encryption workflows. Transit sign/verify supports integrity and authenticity, not confidentiality. HashiCorp documentation and best practices emphasize using Transit when applications need encryption and decryption operations while keeping key material inside Vault.
- A. Correct.
Correct. The Transit secrets engine is designed for encryption as a service. The application sends base64-encoded plaintext to the encrypt endpoint, stores the returned ciphertext, and later submits that ciphertext to the decrypt endpoint to recover the original plaintext. This keeps key material inside Vault and matches the scenario requirement that the app must not store the key.
- B. Incorrect.
Incorrect. KV v2 is a key-value storage engine for secrets storage, not an encryption-as-a-service workflow for application data. While Vault encrypts data at rest internally, the application is not using Vault Transit to encrypt and decrypt arbitrary values through API calls in this option. This is a common misconception between storing secrets in Vault and using Transit cryptographic operations.
- C. Incorrect.
Incorrect. Signing and verification provide integrity and authenticity, not confidentiality. A signature does not encrypt the account number, and verify does not return plaintext. Someone might choose this if they confuse cryptographic signing with encryption, but Transit sign/verify is for digital signatures or HMAC-related verification use cases, not recovering original data.
- D. Incorrect.
Incorrect. Transit is specifically intended to keep key material inaccessible to clients. Applications use Vault to perform cryptographic operations without retrieving the raw key. Attempting to read key material contradicts the design of Transit and the stated security goal. This distractor targets the misconception that Vault acts like a simple key escrow service.