HashiCorp Vault Associate (003) Question 164
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, but when trying to read the secret secret/data/payments/api with the CLI and API, they receive permission errors. In the Vault UI, they can authenticate but do not see the expected secret path. You review the policy attached to their token and find this stanza:
path "secret/payments/*" { capabilities = ["read", "list"] }
Which change is most likely required to allow the developer to access the secret consistently by CLI, API, and UI?
- A
Update the policy to use KV v2 API paths, such as granting access to
secret/data/payments/*for reads andsecret/metadata/payments/*for list operations - B
Keep the policy unchanged, but tell the developer to use
vault read secret/payments/apiinstead ofvault kv get secret/payments/api - C
Add
sudocapability tosecret/payments/*so the UI can display the path and the API can bypass the permission error - D
Change the mount from KV v2 to KV v1 so the existing policy path matches the developer's CLI and API requests
Show answer and explanation
Correct answer: A
Explanation
For KV v2, Vault separates secret data and metadata into different API paths. Reading a secret requires access to /data/ paths, and listing/browsing typically requires /metadata/ paths. This is why a policy that worked conceptually for KV v1-style paths often fails for KV v2. In practice, a developer might use vault kv get secret/payments/api, while the underlying API request is made to secret/data/payments/api. Likewise, the UI often needs list capability on secret/metadata/payments/ to display folders and secrets. HashiCorp documentation for KV secrets engines and policy pathing emphasizes that policies must align with the actual API path structure of the mounted engine. This scenario tests the candidate's ability to connect CLI behavior, API paths, and UI browsing requirements when troubleshooting Vault access.
- A. Correct.
Correct. KV v2 uses different underlying API paths than KV v1. Reads go through
secret/data/..., while listing in the UI typically requires access tosecret/metadata/.... A policy written assecret/payments/*matches neither the v2 read path nor the metadata path used for listing/browsing, so the token can authenticate but still cannot read or browse the secret as expected. - B. Incorrect.
Incorrect. Although CLI commands differ,
vault kv getis the correct CLI workflow for KV v2 because it understands the versioned engine and translates to the proper API path. Usingvault read secret/payments/apidoes not fix the policy mismatch and is a common misconception when moving from generic reads to KV-specific commands. - C. Incorrect.
Incorrect.
sudois not a general-purpose override for secret access and is only meaningful for a limited set of privileged system paths. It will not solve a normal KV policy path mismatch for reads or UI browsing. - D. Incorrect.
Incorrect. Changing the mount type is unnecessary and disruptive. The problem is the policy path, not the secret engine itself. Best practice is to write policies that match the mounted engine's actual API structure rather than altering the engine to fit an incorrect policy.