HashiCorp Vault Associate (003) Question 158
Single answer5g Enable secrets engines using the CLI, API*, and UIA Vault administrator needs to enable the KV v2 secrets engine at a custom path named "apps/" so application teams can store versioned secrets there. The admin wants to verify which action correctly enables the engine using a supported Vault interface without changing any other mounts. Which option is correct?
- A
Run
vault secrets enable -path=apps kv-v2from the CLI - B
Send a POST request to
/v1/sys/mounts/appswith JSON body{ "type": "kv", "options": { "version": "2" } } - C
In the UI, go to Access and click Create Token, then set the token path to
apps/ - D
Send a PUT request to
/v1/secret/appswith JSON body{ "engine": "kv", "version": 2 }
Show answer and explanation
Correct answer: B
Explanation
To enable a secrets engine in Vault, administrators use the mount system interfaces: the CLI (vault secrets enable), the API (/v1/sys/mounts/<path>), or the UI's Secrets Engines workflow. For KV v2 specifically, the engine type is still kv; version 2 is selected through mount options, such as options.version=2 in the API or -version=2 in the CLI. This is a frequent exam trap because candidates may assume kv-v2 is a separate engine type. In the UI, the admin would choose to enable a secrets engine, select KV, and choose version 2 at the desired path. According to Vault documentation on enabling secrets engines and the system mounts API, mount creation is handled through sys/mounts, while data operations occur under the mounted path after the engine is enabled.
- A. Incorrect.
Incorrect. This is a common CLI misconception. The CLI uses the secrets engine type
kv, notkv-v2, and KV v2 is enabled by setting the version option. A correct CLI command would bevault secrets enable -path=apps -version=2 kvor equivalent options syntax supported by the CLI. Usingkv-v2as the type is not the documented engine type. - B. Correct.
Correct. The system mounts API is the supported API for enabling a secrets engine. To enable KV v2 at a custom mount path, Vault expects a request to
/v1/sys/mounts/<path>withtypeset tokvandoptions.versionset to2. This enables a new mount atapps/without modifying existing mounts. - C. Incorrect.
Incorrect. Creating a token in the UI is unrelated to enabling a secrets engine. The relevant UI workflow would be under the Secrets Engines area, where an administrator can enable a new engine and choose KV with version 2 at the
apps/path. This option reflects confusion between authentication/token management and secrets engine configuration. - D. Incorrect.
Incorrect.
/v1/secret/appsis not the API used to enable a mount. Paths under a mounted secrets engine are used to read or write secrets after the engine already exists. Enabling a secrets engine is an administrative operation performed through/v1/sys/mounts/<path>.