HashiCorp Vault Associate (003) Question 161
Single answer5h Access Vault secrets using the CLI, API, and UIYour team stores application credentials in a KV v2 secrets engine mounted at secret/. A developer can log in to Vault successfully and has read access to the path secret/data/payments/api, but their script fails when trying to retrieve the secret through the HTTP API. They currently use: curl -H "X-Vault-Token: $VAULT_TOKEN" $VAULT_ADDR/v1/secret/payments/api. In the Vault UI, they can browse to the secret and see the current version. Which action should the developer take to retrieve the secret correctly through the API while matching what they see in the UI and with the CLI command vault kv get secret/payments/api?
- A
Call the KV v2 data endpoint instead: curl -H "X-Vault-Token: $VAULT_TOKEN" $VAULT_ADDR/v1/secret/data/payments/api
- B
Keep the same API path, but add ?version=current to the URL so Vault knows to return the latest KV v2 secret
- C
Use the metadata endpoint instead: curl -H "X-Vault-Token: $VAULT_TOKEN" $VAULT_ADDR/v1/secret/metadata/payments/api
- D
Change the CLI command to vault read secret/payments/api because vault kv get is only for KV v1
Show answer and explanation
Correct answer: A
Explanation
This question tests a common real-world issue: understanding the difference between how Vault CLI/UI simplify KV v2 access and how the raw HTTP API exposes the underlying paths. In KV v2, secret values are read from the /data/ endpoint and metadata is accessed through /metadata/. For a KV v2 mount at secret/, vault kv get secret/payments/api works because the CLI knows the engine version and internally targets the proper API route. The UI similarly abstracts these details. By contrast, a direct API call must use the full KV v2 path, such as /v1/secret/data/payments/api. This behavior is documented in HashiCorp Vault's KV secrets engine v2 API and CLI documentation, which distinguishes KV v1 from KV v2 pathing and notes that the CLI handles version-specific behavior automatically.
- A. Correct.
Correct. KV v2 adds an API structure under the mount, including /data/ for reading secret values and /metadata/ for version metadata. For a mount at secret/ and a secret path payments/api, the correct read path is /v1/secret/data/payments/api. This matches how the UI and vault kv get abstract KV v2 details for the user. The developer's original API call omitted /data/, which is a common reason API reads fail against KV v2.
- B. Incorrect.
Incorrect. KV v2 supports versioned reads, but the core problem here is the wrong endpoint path, not a missing query parameter. The latest version is returned by default when reading from the correct /data/ endpoint. There is no standard requirement to use ?version=current for this use case.
- C. Incorrect.
Incorrect. The /metadata/ endpoint is used for metadata operations such as listing version information and managing metadata, not for retrieving the secret data payload itself. Someone might choose this because the UI shows version information, but the actual secret values are read from /data/.
- D. Incorrect.
Incorrect. vault kv get is the correct CLI command for reading from KV secrets engines, including KV v2. In fact, one advantage of vault kv get is that it automatically handles KV v2 path translation. vault read can be used for generic API-style reads, but saying vault kv get is only for KV v1 is false.