HashiCorp Vault Associate (003) Question 124
Single answer5 Secrets enginesA team stores application configuration in Vault's KV v2 secrets engine at path secret/. Developers need to update only the password field in secret/data/apps/payments without accidentally overwriting the other keys in that secret. They also want to keep version history so they can roll back if a bad value is written. Which action should they take?
- A
Use the KV v2 patch operation on secret/apps/payments to update only the password field
- B
Use the KV v1 put operation on secret/apps/payments so Vault merges the new password into the existing secret
- C
Use the Transit secrets engine instead of KV so individual fields can be updated without changing the rest of the secret
- D
Disable versioning on the KV engine before writing the new password to avoid overwriting other fields
Show answer and explanation
Correct answer: A
Explanation
This scenario is about selecting the appropriate behavior of a Vault secrets engine for a real operational need. KV v2 is the correct engine when teams need versioned secret storage, soft deletes, metadata, and recovery of prior values. When only one field in a multi-key secret must change, the patch capability is preferred over a full write because a normal write replaces the stored data at that version. This helps prevent accidental loss of sibling keys such as username, host, or API settings. HashiCorp Vault documentation for the KV secrets engine version 2 describes versioned key/value storage and partial update behavior. By contrast, KV v1 lacks versioning, and Transit is a different secrets engine intended for encryption-as-a-service rather than secret storage.
- A. Correct.
Correct. KV v2 supports versioned secrets and provides a patch operation for partial updates. Using patch lets the team modify only the password field while leaving other fields unchanged, and KV v2 keeps previous versions for recovery or rollback. In practice, this is the safest choice when multiple keys are stored in one secret and only one value needs to change.
- B. Incorrect.
Incorrect. KV v1 does not provide built-in versioning, and a standard put/write replaces the secret data rather than merging fields. This is a common misconception because users expect JSON-like merge behavior, but Vault writes the submitted data as the new secret value unless using KV v2 patch semantics.
- C. Incorrect.
Incorrect. Transit is designed for cryptographic operations such as encryption, decryption, signing, and key management. It is not used to store arbitrary application configuration fields for partial updates. Choosing Transit here confuses secret storage with cryptographic services.
- D. Incorrect.
Incorrect. Versioning is a key benefit of KV v2, not something to disable for this use case. Disabling versioning would work against the rollback requirement and would not solve the problem of partial field updates. The issue is selecting the correct write method, not removing version history.