Skip to content
Cheat sheets

003 · Domain 5: Secrets engines · 20% of the exam

Task 5.7: Enable secrets engines using the CLI, API, and UI

vault secrets enable with -path and -version, POST to sys/mounts, tuning lease TTLs, the UI flow, and the errors a busy or reserved path returns.

Study it

  • Enabling secrets engines from the CLI, the API and the UI

    Lesson coming

Sample questions

Try each one before opening the answer. Every option is explained, with the HashiCorp documentation page that proves it.

Question 1 · choose 1

A team ran these commands, wanting KV version 2 at team-a/: $ vault secrets enable -path=team-a kv $ vault kv put team-a/app key=value $ vault secrets enable -path=team-a -version=2 kv Error enabling: ... path is already in use at team-a/ The data already written must stay at team-a/. What should the team run?

  1. Avault secrets enable -path=team-a kv-v2
  2. Bvault kv enable-versioning team-a/
  3. Cvault secrets disable team-a/, then enable it again with -version=2
  4. Dvault secrets move team-a/ team-a-old/, then enable version 2 at team-a/
Show the answer and why

  • Avault secrets enable -path=team-a kv-v2

    Incorrect

    Enabling any engine at a path that is already mounted returns the same error.

  • Bvault kv enable-versioning team-a/

    Correct

    This upgrades the existing KV v1 mount to version 2 in place, keeping its data at the same path.

  • Cvault secrets disable team-a/, then enable it again with -version=2

    Incorrect

    Disabling a mount deletes all of its data from storage.

  • Dvault secrets move team-a/ team-a-old/, then enable version 2 at team-a/

    Incorrect

    The existing data would then live at team-a-old/, not at team-a/.

Upgrade a v1 mount in place with kv enable-versioning.

HashiCorp documentation

Task 5.7Report a problem with this question

Question 2 · choose 1

A team built its own secrets engine plugin and copied the binary into the server's plugin directory. vault secrets enable -path=inventory inventory-plugin fails because Vault does not know the plugin. What step is missing?

  1. AEnable it with -plugin-version set to the binary's version
  2. BRegister the binary in the plugin catalog with vault plugin register
  3. CRestart Vault so that it loads every binary in its plugin directory
  4. DEnable it through the UI, which accepts unregistered plugins
Show the answer and why

  • AEnable it with -plugin-version set to the binary's version

    Incorrect

    A version selects among registered plugins; it does not make an unknown binary known.

  • BRegister the binary in the plugin catalog with vault plugin register

    Correct

    An external plugin must be registered in the plugin catalog, for example with its SHA-256 checksum, before secrets enable can mount it.

  • CRestart Vault so that it loads every binary in its plugin directory

    Incorrect

    Being in the directory is not enough; each external plugin must be registered first.

  • DEnable it through the UI, which accepts unregistered plugins

    Incorrect

    Only built-in plugins are preregistered; an external plugin must be registered before any mount can use it, whichever interface enables it.

Built-in plugins are preregistered; external ones must be registered in the plugin catalog before any mount can use them.

HashiCorp documentation

Task 5.7Report a problem with this question

Question 3 · choose 1

A script enables KV version 2 at shared/ with POST /v1/sys/mounts/shared. Which request body is correct?

  1. A{"type": "kv", "options": {"version": "2"}}
  2. B{"type": "kv", "version": "2"}
  3. C{"type": "kv", "config": {"version": "2"}}
  4. D{"type": "kv", "options": {"versioned": true}}
Show the answer and why

  • A{"type": "kv", "options": {"version": "2"}}

    Correct

    The version is passed in the options object of the mount request.

  • B{"type": "kv", "version": "2"}

    Incorrect

    version is not a top-level mount parameter; it belongs in options.

  • C{"type": "kv", "config": {"version": "2"}}

    Incorrect

    config holds settings such as lease TTLs; the KV version goes in options.

  • D{"type": "kv", "options": {"versioned": true}}

    Incorrect

    The option is named version.

/sys/mounts/<path> returns no data on success; check with a GET of sys/mounts.

HashiCorp documentation

Task 5.7Report a problem with this question

Question 4 · choose 1

How is a new KV engine enabled from the Vault UI?

  1. AAccess, then Enable new method, and choose KV from the list
  2. BPolicies, then Create policy, with a kv stanza
  3. CTools, then Wrap, with the engine type as data
  4. DSecrets Engines, Enable new engine, KV, then a path
Show the answer and why

  • AAccess, then Enable new method, and choose KV from the list

    Incorrect

    Access is where auth methods are enabled.

  • BPolicies, then Create policy, with a kv stanza

    Incorrect

    Policies do not enable engines.

  • CTools, then Wrap, with the engine type as data

    Incorrect

    Wrapping tools do not enable engines.

  • DSecrets Engines, Enable new engine, KV, then a path

    Correct

    The UI enables engines from the Secrets Engines page with a chosen type and path.

The CLI, the API and the UI all end in the same sys/mounts request.

HashiCorp documentation

Task 5.7Report a problem with this question

Question 5 · choose 1

A database engine must be enabled at db/ with leases defaulting to 1 hour and never exceeding 24 hours. Which command sets that up front?

  1. Avault secrets enable -path=db -ttl=1h -max=24h database
  2. Bvault secrets enable -path=db database ttl=1h max_ttl=24h
  3. Cvault secrets enable -path=db -default-lease-ttl=1h -max-lease-ttl=24h database
  4. Dvault write sys/mounts/db/tune type=database ttl=1h
Show the answer and why

  • Avault secrets enable -path=db -ttl=1h -max=24h database

    Incorrect

    The flags are -default-lease-ttl and -max-lease-ttl.

  • Bvault secrets enable -path=db database ttl=1h max_ttl=24h

    Incorrect

    Key=value pairs after the type are not mount TTL settings.

  • Cvault secrets enable -path=db -default-lease-ttl=1h -max-lease-ttl=24h database

    Correct

    secrets enable accepts default and max lease TTLs for the new mount.

  • Dvault write sys/mounts/db/tune type=database ttl=1h

    Incorrect

    tune changes an existing mount; it does not enable one.

Mount TTLs can also be changed later with vault secrets tune.

HashiCorp documentation

Task 5.7Report a problem with this question

Practice domain 5 →Practice all domains →