HashiCorp Vault Associate (003) Question 148
Single answer5e Describe the use of response wrappingA platform team needs to deliver a short-lived AppRole SecretID from a CI pipeline to a deployment job running in another system. They want to reduce the chance that the SecretID is exposed in logs, chat messages, or intermediary services, and they also want evidence if someone accesses it before the deployment job does. Which Vault approach best meets this requirement?
- A
Use response wrapping so the CI pipeline sends only a single-use wrapping token to the deployment job, which then unwraps it to retrieve the SecretID
- B
Store the SecretID in KV v2 and give the deployment job read access to the path so it can fetch the value when needed
- C
Create a periodic token for the deployment job and embed the SecretID directly in the token metadata for later retrieval
- D
Encrypt the SecretID with Transit and send the ciphertext to the deployment job, which can decrypt it locally without contacting Vault
Show answer and explanation
Correct answer: A
Explanation
Response wrapping is a Vault feature used to securely pass sensitive response data between trusted parties while minimizing exposure of the underlying secret. Instead of transmitting the actual secret, the sender receives a wrapping token with a TTL and passes that token to the recipient. The recipient calls the unwrap endpoint to retrieve the original response. This is especially useful for AppRole SecretID delivery, bootstrap workflows, and other machine-to-machine handoffs. A key benefit is that the wrapping token is intended for one-time use, so if it is intercepted and unwrapped early, the intended recipient will detect that the token is no longer valid. This aligns with Vault best practices for reducing secret exposure in transit and across intermediary systems. See HashiCorp Vault documentation on response wrapping, cubbyhole/wrapping tokens, and AppRole patterns for secure SecretID distribution.
- A. Correct.
Correct. Response wrapping is designed for securely delivering sensitive values such as SecretIDs without exposing the raw secret to intermediaries. Vault returns a wrapping token that contains the original response. The deployment job can present that wrapping token to Vault's unwrap endpoint and receive the SecretID. Wrapping tokens are short-lived, intended for one-time use, and if someone unwraps the token before the intended recipient, that action is detectable because the token can no longer be used by the deployment job.
- B. Incorrect.
Incorrect. Storing the SecretID in KV v2 and allowing the deployment job to read it exposes the secret more broadly than necessary and changes the use case from secure delivery to persistent storage. It also does not provide the same one-time handoff semantics as response wrapping. Someone with path access could read the SecretID without the intended consumer knowing through the wrapping workflow.
- C. Incorrect.
Incorrect. Token metadata is not a secure place to transport another secret for later retrieval in this way. Embedding a SecretID in token metadata does not provide the one-time, short-lived delivery mechanism that response wrapping provides. This reflects a common misconception that any Vault object can be used as a secret transport envelope.
- D. Incorrect.
Incorrect. Transit can encrypt data, but the deployment job would still need a secure way to decrypt or obtain the plaintext, typically by contacting Vault with appropriate permissions. Transit is not a substitute for response wrapping in a secret handoff workflow. This option also incorrectly suggests local decryption without Vault, which is not how Vault Transit works.