HashiCorp Vault Associate (003) Question 147
Single answer5e Describe the use of response wrappingA platform team needs to deliver a short-lived database credential from Vault to a bootstrap script running on a newly provisioned VM. The team does not want the credential to appear in CI/CD logs, shell history, or intermediate systems. They also want the VM to be able to prove whether the secret was intercepted before it was used. Which Vault approach best meets these requirements?
- A
Use response wrapping so the CI/CD system receives only a single-use wrapping token, and the VM unwraps it to retrieve the actual credential
- B
Store the database credential in Vault KV and give the VM a long-lived token so it can read the secret directly whenever it starts
- C
Encrypt the database credential with Transit and send the ciphertext to the VM, which can use it directly to connect to the database
- D
Create a child token for the VM with a very short TTL and pass that token through the CI/CD pipeline instead of using response wrapping
Show answer and explanation
Correct answer: A
Explanation
Response wrapping is a Vault feature used to securely pass sensitive data, such as Secret IDs, tokens, or generated credentials, through untrusted or semi-trusted systems. Instead of returning the secret directly, Vault returns a wrapping token with a limited TTL. The recipient calls the unwrap endpoint (or equivalent CLI command) to retrieve the original response. Because wrapping tokens are single-use, they help detect interception: if another party unwraps the token first, the intended recipient cannot unwrap it later. This is a common best practice in workflows such as AppRole Secret ID delivery and bootstrap automation. See HashiCorp Vault documentation for response wrapping and cubbyhole/unwrap behavior.
- A. Correct.
Correct. Response wrapping is designed for secure secret delivery through potentially untrusted intermediaries. Vault returns a wrapping token instead of the secret value itself. The wrapping token is single-use and has a TTL, and the target system unwraps it to obtain the original secret. This reduces exposure in logs and transit paths. It also supports detection of interception because if someone unwraps the token before the VM does, the VM's unwrap attempt will fail.
- B. Incorrect.
Incorrect. While storing a secret in KV is valid for some use cases, giving the VM a long-lived token increases risk and does not address the requirement to avoid exposing the secret during delivery through CI/CD or intermediate systems. It also does not provide the same interception-detection behavior as response wrapping.
- C. Incorrect.
Incorrect. Transit encrypts and decrypts data but does not make ciphertext usable as a database password. The VM would still need a way to decrypt it or otherwise obtain the plaintext credential. This option confuses encryption as a transport mechanism with response wrapping, which is specifically meant for secure handoff of Vault responses.
- D. Incorrect.
Incorrect. A short-lived child token is better than a long-lived token, but it is still a bearer credential granting Vault access rather than a single-use wrapped response containing the specific secret. Passing a token through the pipeline increases exposure and does not provide the same one-time unwrap semantics used to detect whether the handoff was intercepted.