HashiCorp Vault Associate (003) Question 155
Single answer5g Enable secrets engines using the CLI, API*, and UIA platform engineer needs to enable the KV version 2 secrets engine at the custom path "apps/" in an existing Vault cluster. The engineer wants a method that is valid whether they use the Vault CLI, the HTTP API, or the Vault UI. Which action correctly enables the secrets engine with the required version and mount path?
- A
Run
vault secrets enable -path=apps -version=2 kv, or send a POST request to/v1/sys/mounts/appswith{ "type": "kv", "options": { "version": "2" } }, or in the UI enable a KV secrets engine at pathapps/and select version 2. - B
Run
vault kv enable -path=apps -version=2, or send a POST request to/v1/secret/appswith{ "engine": "kv-v2" }, or in the UI create a secret underapps/and Vault automatically enables the mount. - C
Run
vault secrets tune -path=apps -version=2 kv, or send a PUT request to/v1/sys/remount/appswith{ "type": "kv" }, or in the UI edit the defaultsecret/mount path to rename it toapps/. - D
Run
vault auth enable -path=apps kv, or send a POST request to/v1/sys/auth/appswith{ "type": "kv" }, or in the UI enable an auth method namedapps/and choose KV v2.
Show answer and explanation
Correct answer: A
Explanation
To enable a secrets engine in Vault, you must use the secrets-engine mount workflow, not KV data commands and not auth-method commands. Across interfaces, the concepts are equivalent: CLI uses vault secrets enable, the API uses the /sys/mounts endpoint, and the UI uses the Enable Secrets Engine flow. For KV v2 specifically, Vault still uses type kv; version 2 is selected through mount options, commonly options.version=2. This is a frequent exam distinction: vault kv put/get operate on an existing KV engine, while vault secrets enable creates the mount itself. HashiCorp Vault documentation for secrets engines and the sys/mounts API describes this behavior and the KV v1 vs v2 configuration pattern.
- A. Correct.
Correct. Enabling a secrets engine is done with
vault secrets enable, notvault kv enable. For KV v2 at a custom mount, the CLI syntaxvault secrets enable -path=apps -version=2 kvis valid. Via the HTTP API, enabling a secrets engine uses the system mounts endpoint, typically POST to/v1/sys/mounts/<path>, with the engine type set tokvand the version specified inoptions.versionas2. In the UI, the equivalent workflow is to enable a new secrets engine, choose KV, set the mount path toapps/, and select version 2. - B. Incorrect.
Incorrect.
vault kvis used for interacting with data in an existing KV engine, such as put/get/list operations, not for enabling a new mount. The API path/v1/secret/appsis not the correct endpoint for enabling secrets engines; enabling uses/v1/sys/mounts/<path>. Also, creating a secret in the UI does not automatically create or enable a secrets engine at a new path. - C. Incorrect.
Incorrect.
vault secrets tunemodifies configuration on an already enabled mount; it does not create a new secrets engine. The remount endpoint is for changing a mount's path after it already exists, not for creating a new one or selecting the engine version during creation. Renaming the defaultsecret/mount in the UI would affect an existing mount and is not the same as enabling a new KV v2 engine atapps/. - D. Incorrect.
Incorrect.
vault auth enableand/v1/sys/auth/<path>are for authentication methods such as AppRole, userpass, or GitHub, not for secrets engines. KV is a secrets engine, not an auth method. Enabling an auth method in the UI would not create a KV mount.