HashiCorp Vault Associate (003) Question 160
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 successfully view the secret in the Vault UI at secret/data/payments/api, but their CLI command vault kv get secret/payments/api returns a permission denied error. They authenticate with the same token in both cases. Which action is most likely needed to make CLI and API access work consistently with the existing UI access?
- A
Update the policy to grant access to the KV v2 API path
secret/data/payments/apirather than only the logical path shown in the UI - B
Change the CLI command to
vault read secret/payments/apibecausevault kv getonly works with KV v1 - C
Recreate the secret under a KV v1 engine because the UI can read KV v2 secrets but the CLI and API cannot
- D
Add
sudocapability to the policy forsecret/payments/apiso the CLI can bypass the denied read
Show answer and explanation
Correct answer: A
Explanation
This scenario tests a practical Vault skill: understanding that CLI, API, and UI may present secret paths differently, especially with KV v2. For KV v2, the underlying API path for reading data is secret/data/<path>, while the CLI commonly uses the shorter logical form vault kv get secret/<path>. Policies must be written against the actual API paths and capabilities. This is a frequent source of confusion when users can navigate secrets in the UI but encounter permission errors with CLI or direct API calls. HashiCorp documentation for the KV secrets engine v2 and Vault policies explains that KV v2 introduces path prefixes such as /data/ and /metadata/, and policies must match those paths appropriately. Best practice is to verify the mount version and write policies specifically for KV v2 path structure when using CLI and API access.
- A. Correct.
Correct. KV v2 uses API paths that include
/data/for reading secret data. A common real-world issue is that a policy was written against the human-friendly logical path, such assecret/payments/api, instead of the actual KV v2 API pathsecret/data/payments/api. The Vault UI often abstracts this detail, so a user may be able to browse or appear to target a path in the UI while CLI/API operations enforce the underlying API path and capabilities. For consistent access, the policy must allow the correct KV v2 path. - B. Incorrect.
Incorrect.
vault kv getis the correct CLI command for reading from a KV secrets engine and supports KV v2. In fact,vault kv get secret/payments/apiis the normal CLI form when the engine is mounted atsecret/. The CLI translates that logical path to the KV v2 API path. Usingvault readdirectly is not the recommended fix and would still not solve a policy that lacks permission on the underlyingsecret/data/...path. - C. Incorrect.
Incorrect. Both the Vault CLI and API fully support KV v2. There is no requirement to downgrade to KV v1 for command-line or API access. This option reflects a misconception that the UI has different secret-engine support than the other interfaces. The issue is policy/path alignment, not engine version compatibility.
- D. Incorrect.
Incorrect.
sudois a special capability used only for certain privileged system paths and operations; it is not a general-purpose way to bypass denied access to secrets. Reading a KV secret requires the appropriatereadcapability on the correct path. Addingsudoonsecret/payments/apiwould not be the correct or standard solution.