HashiCorp Vault Associate (003) Question 174
Single answer6a Encrypt and decrypt secretsA security team stores API keys in an application database and wants to reduce exposure by encrypting the values before they are written. The application must be able to send plaintext to Vault, store only the returned ciphertext, and later submit that ciphertext to Vault to recover the original value. The team does not want to generate short-lived data encryption keys in the application or manage key material outside Vault. Which Vault approach best meets these requirements?
- A
Enable the Transit secrets engine, use the encrypt endpoint to protect the API keys before storage, and use the decrypt endpoint when the application needs the original value.
- B
Enable the KV v2 secrets engine, write the plaintext API keys to KV, and rely on Vault's storage backend encryption as the application's encryption and decryption workflow.
- C
Use the PKI secrets engine to issue a certificate for the application and use that certificate to encrypt and decrypt API keys stored in the database.
- D
Use response wrapping to wrap each API key before storing it in the database, then unwrap it later when the application needs the original value.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use the Transit secrets engine. Transit allows Vault to perform cryptographic functions without exposing key material to the client application, which is exactly what this scenario requires. The application can encrypt plaintext before writing it to the database and later decrypt the stored ciphertext by calling Vault again. This is a common pattern for protecting sensitive data while keeping application-side key management minimal. By contrast, KV stores secrets in Vault rather than acting as an encrypt/decrypt service; PKI manages certificates, not arbitrary secret encryption workflows; and response wrapping is for secure secret delivery, not durable encrypted storage. HashiCorp Vault documentation describes Transit as providing encryption, decryption, rewrapping, and related cryptographic operations for applications, which aligns directly with this use case.
- A. Correct.
Correct. The Transit secrets engine is designed for 'encryption as a service.' The application sends plaintext to Vault's encrypt endpoint and receives ciphertext that it can safely store. Later, it sends the ciphertext to the decrypt endpoint to recover the original plaintext. This matches the requirement to avoid managing cryptographic keys in the application while still supporting reversible encryption/decryption.
- B. Incorrect.
Incorrect. KV v2 is for storing secrets in Vault, not for providing an application-facing encrypt/decrypt API for external database values. Although Vault encrypts its own storage at rest, that does not mean the application can store Vault-generated ciphertext in its database and later ask KV to decrypt it. This confuses Vault's internal storage encryption with the Transit engine's cryptographic operations.
- C. Incorrect.
Incorrect. The PKI secrets engine is for issuing and managing X.509 certificates and related PKI material. It is not the correct service for general-purpose encryption/decryption of arbitrary application secrets like API keys in a database. Someone might choose this if they associate certificates with encryption broadly, but PKI does not provide the simple symmetric encrypt/decrypt workflow described here.
- D. Incorrect.
Incorrect. Response wrapping is a secure delivery mechanism for Vault responses, typically used to hand off secrets securely between systems or operators. It is not intended as a general persistent encryption method for application data in a database. Wrapped responses are single-use and time-limited, so they do not fit a long-term store-and-later-decrypt pattern.