HashiCorp Vault Associate (003) Question 157
Single answer5g Enable secrets engines using the CLI, API*, and UIA platform engineer needs to enable the KV v2 secrets engine at the path "apps/" in an existing Vault cluster. The engineer has admin access and wants to perform the task using the Vault HTTP API instead of the CLI or UI so it can be automated in a deployment pipeline. Which API request correctly enables the secrets engine?
- A
Send a POST request to /v1/sys/mounts/apps with JSON body {"type":"kv","options":{"version":"2"}}
- B
Send a PUT request to /v1/apps/config with JSON body {"engine":"kv-v2"}
- C
Send a POST request to /v1/sys/enable/apps with JSON body {"type":"kv-v2"}
- D
Send a PUT request to /v1/sys/mounts with JSON body {"path":"apps/","type":"kv","version":2}
Show answer and explanation
Correct answer: A
Explanation
To enable a secrets engine in Vault through the API, you use the system mounts API: write to /v1/sys/mounts/:path. For a KV v2 mount, the type remains "kv" and the version must be provided in the options block as a string value of "2". This matches how the CLI works when using commands such as "vault secrets enable -path=apps -version=2 kv", and in the UI where you select the KV engine and choose version 2 during mount configuration. This is a practical distinction candidates must know: KV v2 is not enabled by specifying a separate engine type like "kv-v2"; it is the kv engine with a version option. Refer to the Vault documentation for the sys/mounts API and the KV secrets engine versioning behavior.
- A. Correct.
Correct. Vault enables secrets engines by writing to the sys/mounts endpoint at the desired mount path. For KV v2, the engine type is still "kv" and version 2 is specified through the options map with "version":"2". Using POST to /v1/sys/mounts/apps is a valid API pattern for enabling a secrets engine at the apps/ path.
- B. Incorrect.
Incorrect. /v1/apps/config is not the API used to enable a secrets engine mount. It resembles a configuration endpoint for an already mounted engine, but enabling mounts is done under /v1/sys/mounts/
. - C. Incorrect.
Incorrect. There is no standard Vault API endpoint /v1/sys/enable/apps for enabling secrets engines. A common misconception is assuming there is a generic "enable" endpoint, but mounts are managed through the sys/mounts API.
- D. Incorrect.
Incorrect. The sys/mounts collection endpoint is not enabled this way. Vault expects the mount path in the URL, not as a JSON field, and KV version is set inside the options object rather than as a top-level numeric version field.