HashiCorp Vault Associate (003) Question 162
Single answer5h Access Vault secrets using the CLI, API, and UIA team stores application credentials in a KV v2 secrets engine mounted at secret/. A developer has already authenticated to Vault and now needs to verify the same secret value using the CLI, the HTTP API, and the UI. The secret path is app/config and one of the fields is db_password. Which option correctly describes how to access that secret across these interfaces?
- A
Use
vault kv get secret/app/configin the CLI, send a GET request to/v1/secret/data/app/configin the API, and in the UI open the secret under the secret mount and view the data for app/config. - B
Use
vault read secret/app/configin the CLI, send a GET request to/v1/secret/app/configin the API, and in the UI open the Transit secrets engine and browse to app/config. - C
Use
vault kv get secret/data/app/configin the CLI, send a GET request to/v1/secret/metadata/app/configin the API, and in the UI open the secret under the secret mount to view db_password. - D
Use
vault secrets get secret/app/configin the CLI, send a POST request to/v1/secret/data/app/configin the API, and in the UI use the Access tab for the token to reveal db_password.
Show answer and explanation
Correct answer: A
Explanation
This question tests practical access patterns for a KV v2 secrets engine across Vault interfaces. In Vault, KV v2 introduces versioning and changes the HTTP API path structure: reading secret data uses /v1/<mount>/data/<path>, while metadata operations use /v1/<mount>/metadata/<path>. The Vault CLI simplifies this by providing vault kv get <mount>/<path>, which abstracts away the internal /data/ path. In the UI, users typically navigate to the KV mount and open the secret path directly. A common misconception is to use KV v1-style API paths or to insert /data/ into the CLI path. HashiCorp Vault documentation for the KV secrets engine v2 and Vault CLI commands reflects these patterns and is the best reference for the expected behavior.
- A. Correct.
Correct. For a KV v2 engine mounted at
secret/, the Vault CLI commandvault kv get secret/app/configis the normal way to read secret data. The CLI understands the KV v2 mount and internally uses the proper API structure. With the HTTP API, KV v2 reads use the/data/path, so the correct endpoint isGET /v1/secret/data/app/config. In the UI, you navigate to thesecret/mount and then open theapp/configsecret to view its fields such asdb_password. - B. Incorrect.
Incorrect.
vault read secret/app/configis a common mistake because it can work for generic raw API-style paths, but it does not handle KV v2 in the recommended exam-focused way. More importantly, the API path/v1/secret/app/configis wrong for KV v2 because KV v2 data reads require the/data/segment. The Transit secrets engine is unrelated because Transit encrypts/decrypts data and does not store arbitrary key-value secrets for browsing like KV. - C. Incorrect.
Incorrect. In the CLI,
vault kv get secret/data/app/configincorrectly includes the internal KV v2 API segment/data/. Thevault kvCLI command expects the logical secret pathsecret/app/config, not the raw API path. In the API,/metadata/is used for metadata operations such as listing versions or reading metadata, not for retrieving the actual secret value. Although the UI portion sounds plausible, the CLI and API details make this option incorrect. - D. Incorrect.
Incorrect.
vault secrets getis not a valid command for reading KV secrets. For the API, reading a secret usesGET, notPOST, at the KV v2 data endpoint. In the UI, the Access tab for a token is used to inspect token details and capabilities, not to reveal a secret's stored value. This option mixes unrelated concepts from authentication and secret access.