HashiCorp Vault Associate (003) Question 156
Single answer5g Enable secrets engines using the CLI, API*, and UIYour team is onboarding an application that needs static database credentials stored in Vault. A Vault administrator asks you to enable a KV version 2 secrets engine at the path app-data so the application team can start writing secrets there. You need to choose the command or API call that correctly enables the secrets engine at the required path. Which option is correct?
- A
vault secrets enable -path=app-data -version=2 kv
- B
vault kv enable -path=app-data --version=2
- C
POST /v1/app-data/config with body {"type":"kv","options":{"version":"2"}}
- D
POST /v1/sys/mounts/app-data with body {"type":"kv-v2"}
Show answer and explanation
Correct answer: A
Explanation
To enable a secrets engine in Vault, you use the mounts system endpoint or the equivalent CLI command. For KV v2, the correct CLI pattern is vault secrets enable -path=<mount> -version=2 kv. In the API, the equivalent action is a POST request to /v1/sys/mounts/<mount> with a body like { "type": "kv", "options": { "version": "2" } }. In the UI, the same task is done by selecting Enable new engine, choosing KV, specifying the path, and selecting version 2 if prompted. A key exam objective is understanding the difference between interacting with a secrets engine and enabling it. Commands in the vault kv family work with KV data after the engine is mounted; they do not create the mount itself. This aligns with Vault documentation for managing secrets engines and the sys/mounts API.
- A. Correct.
Correct. The Vault CLI command to enable a secrets engine is
vault secrets enable. To mount KV at a custom path and specify KV v2, you use-path=app-dataand-version=2 kv. This creates a mount atapp-data/using the KV secrets engine with version 2 semantics. - B. Incorrect.
Incorrect. There is no standard
vault kv enablecommand for enabling a secrets engine. Thevault kvcommand group is used for interacting with KV data, such as put/get/list metadata-aware secrets, not for mounting the engine itself. A candidate might choose this because KV operations are commonly done withvault kv, but enabling mounts is done withvault secrets enable. - C. Incorrect.
Incorrect. Enabling a secrets engine through the API is done under the system mounts endpoint, not by posting directly to a path like
/v1/app-data/config. The/configpath is used for configuration within certain already-enabled engines, not for creating a new mount. This reflects a common misconception between configuring an engine and enabling one. - D. Incorrect.
Incorrect. The API endpoint should be under
/v1/sys/mounts/<path>, so the path structure is close, but the type is wrong. Vault uses"type":"kv"with an options field such as"options":{"version":"2"}to specify KV v2.kv-v2is not the mount type name used by the enable API.