HashiCorp Vault Associate (003) Question 159
Single answer5g Enable secrets engines using the CLI, API*, and UIA Vault administrator needs to enable the KV v2 secrets engine at the path "apps/" in a development Vault server. They want to be able to perform the task from the CLI, from the HTTP API, or from the Vault UI. Which option correctly describes a valid way to enable this secrets engine?
- A
Run
vault secrets enable -path=apps kv-v2; alternatively, send a POST request to/v1/sys/mounts/appswith{ "type": "kv", "options": { "version": "2" } }; in the UI, go to Secrets Engines and enable a KV engine at pathapps/with version 2 selected. - B
Run
vault enable secret kv apps; alternatively, send a PUT request to/v1/secret/enable/appswith{ "engine": "kv-v2" }; in the UI, go to Policies and create a KV v2 policy for pathapps/. - C
Run
vault secrets enable kv -path=apps -version=2; alternatively, send a POST request to/v1/sys/enable/appswith{ "type": "kv-v2" }; in the UI, go to Access and add a new auth method namedapps. - D
Run
vault mount kv apps/ version=2; alternatively, send a POST request to/v1/sys/mountswith{ "path": "apps", "type": "kv" }; in the UI, go to Secrets Sync and add a KV destination namedapps.
Show answer and explanation
Correct answer: A
Explanation
To enable a secrets engine in Vault, administrators can use the CLI, UI, or HTTP API. For KV v2 specifically, Vault uses the kv secrets engine type with the mount option version=2 when calling the API. In the CLI, kv-v2 is a supported shorthand for enabling a KV v2 mount, for example: vault secrets enable -path=apps kv-v2. In the API, the documented pattern is a POST request to /v1/sys/mounts/<path> with a payload similar to { "type": "kv", "options": { "version": "2" } }. In the UI, this is done from the Secrets Engines area by selecting KV and choosing version 2. This topic commonly tests whether candidates can distinguish secrets engines from auth methods, understand mount paths, and recognize the correct system endpoint for enablement: /sys/mounts.
- A. Correct.
Correct. In the CLI,
vault secrets enable -path=apps kv-v2is a valid way to enable the KV v2 secrets engine at a custom mount path. Through the HTTP API, enabling a secrets engine is done under/v1/sys/mounts/:path, and KV v2 is configured by using typekvwithoptions.versionset to2. In the UI, administrators can enable a secrets engine by navigating to Secrets Engines, choosing KV, specifying the mount path, and selecting version 2. This matches how Vault represents KV v2 internally and externally. - B. Incorrect.
Incorrect.
vault enable secret kv appsis not valid Vault CLI syntax for enabling secrets engines. The API endpoint/v1/secret/enable/appsis also not a real endpoint for mounting a secrets engine. In the UI, creating a policy does not enable a secrets engine; policies only control access after a mount exists. This option reflects a common misconception that access configuration and engine enablement are the same task. - C. Incorrect.
Incorrect. The CLI syntax shown is not correct for Vault. While the idea of specifying version 2 is relevant, Vault does not use
-version=2in this command form to enable KV v2. The API endpoint/v1/sys/enable/appsis not the correct endpoint; mounts are managed under/v1/sys/mounts/:path. The UI action described enables an auth method, not a secrets engine. Auth methods and secrets engines are separate concepts in Vault. - D. Incorrect.
Incorrect.
vault mount kv apps/ version=2is not a valid current Vault CLI command for enabling a secrets engine. The API request to/v1/sys/mountswithout the path in the URL is not how mount enablement works; the mount path is part of the endpoint, such as/v1/sys/mounts/apps. Also, omittingoptions.version=2would not explicitly enable KV v2. The UI section mentioned, Secrets Sync, is unrelated to enabling a secrets engine mount.