Vault Associate · Domain 5 of 9

Vault Associate Domain 5: Secrets engines

The largest Vault Associate objective group. It covers what secrets engines are, how to choose one, dynamic versus static secrets, transit, response wrapping, and enabling engines and reading secrets through the CLI, API and UI.

Exam weight estimate
Not published
Official objectives
8
Estimated questions estimate
~11
Suggested study time estimate
8–10 hrs

About 14 min read Reviewed October 2026

Overview

Secrets engines are the components that store, generate or encrypt data in Vault. Each is enabled at a path, and requests to that path are routed to it. HashiCorp lists eight objectives here, the most of any group: choosing an engine for a use case, comparing dynamic and static secrets, the uses of transit, the purpose of secrets engines, response wrapping, the value of short-lived dynamic secrets, enabling engines, and accessing secrets through the CLI, API and UI.

Expect to know KV versions 1 and 2, database, AWS and other cloud engines, PKI, SSH, transit, TOTP, cubbyhole and identity well enough to match each to a scenario. KV version 2 adds versioning, soft delete, undelete and destroy. Response wrapping places a response in a single-use wrapping token's cubbyhole, so the secret can be delivered safely through an intermediary.

How it's tested

Secrets engine questions combine scenario selection with command recognition. Expect to choose the engine that matches a need, to identify the benefit of dynamic secrets, to reason about response wrapping, and to read CLI, API or UI steps for enabling engines and retrieving data.

  • Match the engine

    A requirement such as unique database users, short-lived TLS certificates or signed SSH keys is described, and you choose the engine.

  • Static or dynamic

    You decide whether the scenario needs a stored value or credentials generated on demand that Vault revokes automatically.

  • Command and endpoint syntax

    A vault secrets enable, vault kv get or curl request is shown, and you identify the path, version or missing part.

Reasoning it through

A team stores one shared database password in KV and rotates it by hand every quarter. Rotating faster in KV still leaves one credential shared by every application. The database secrets engine generates a unique user per request with a lease, so each application gets its own short-lived credential that Vault revokes automatically. That limits blast radius and audit ambiguity, which is the exam's preferred answer.

Objectives 8

Official objectives from the HashiCorp outline, in outline order.

5a Choose a secrets engine based on use caseMatching common engines to requirements.
What it means
This objective asks you to pick the engine that fits a scenario, such as KV for arbitrary static values, database for dynamic database users, AWS, Azure or GCP for cloud credentials, PKI for X.509 certificates, SSH for signed SSH certificates, transit for encryption and TOTP for one-time codes.
What to understand
Look for the type of secret and whether it should be generated per request. Static API keys or configuration values fit KV. Short-lived database or cloud credentials fit the matching dynamic engine. Certificates issued by an internal CA fit PKI. Data that applications must encrypt without Vault storing it fits transit. Cubbyhole is per-token private storage and is enabled by default, as is identity.
How it shows up
Scenarios describe a credential or data type, and you select the engine that produces or protects it.
Common confusion
Choosing KV to hold credentials when the requirement says they must expire automatically.
5b Compare and contrast dynamic secrets vs. static secrets, and know their use casesGenerated-on-demand credentials compared with stored values.
What it means
Static secrets are values a person or process writes into Vault and reads back unchanged, such as KV entries. Dynamic secrets are created by Vault on request with a lease and revoked when the lease ends.
What to understand
Static secrets suit values Vault cannot generate, such as third-party API keys, and must be rotated by whoever owns them. Dynamic secrets give each client unique credentials, limit exposure time, and allow targeted revocation. Some engines, such as database, also manage static roles where Vault rotates a fixed account's password on a schedule. Dynamic secrets require the engine to have privileged access to the target system to create and delete users.
How it shows up
Expect to classify a secret type or explain why a dynamic approach reduces risk in a given scenario.
Common confusion
Thinking dynamic secrets are just static secrets with automatic rotation; each request receives distinct credentials.
5c Describe the uses of transit secrets engineEncryption as a service without storing the data.
What it means
The transit engine performs cryptographic operations on data sent to it, such as encrypt, decrypt, sign, verify, HMAC and generating data keys, using named keys that never leave Vault.
What to understand
Transit does not store the ciphertext; the application keeps it in its own database. This centralises key management and lets developers encrypt data without handling key material. Typical uses include encrypting sensitive columns, signing payloads and producing data keys for envelope encryption of large files. The detailed workflow for encrypting, decrypting and rotating keys is covered in the encryption as a service group.
How it shows up
A scenario wants data encrypted without Vault storing it, and transit is the engine to choose.
Common confusion
Expecting transit to store encrypted data for later retrieval.
5d Describe the purpose of secrets enginesWhat engines are and how path routing works.
What it means
Secrets engines are pluggable components that store, generate or encrypt data. Each is enabled at a path, and Vault routes requests under that path to the engine, which behaves like a virtual filesystem with its own API.
What to understand
Engines are isolated from one another, and the same engine type can be enabled several times at different paths, for example kv-v2 at team-a/ and team-b/. Mounts can be tuned for default and max lease TTL. Disabling an engine revokes its leases and deletes its stored data. Moving an engine to a new path with vault secrets move also revokes its existing leases.
How it shows up
Expect questions on path-based routing, multiple mounts of one type, and consequences of disabling.
Common confusion
Assuming disabling a mount keeps its data available for later re-enabling.
5e Describe the use of response wrappingDelivering secrets through single-use wrapping tokens.
What it means
Response wrapping places a Vault response inside the cubbyhole of a new single-use token, the wrapping token, which is returned instead of the secret. Only the holder of that token can unwrap it, once, within its TTL.
What to understand
Request wrapping with -wrap-ttl on the CLI or the X-Vault-Wrap-TTL header. The recipient calls vault unwrap. Because the token can be used only once, a failed unwrap signals that someone may have intercepted it. vault token lookup on the wrapping token or sys/wrapping/lookup reveals its creation path, so the recipient can check it came from the expected endpoint. A common use is passing an AppRole SecretID to an application through a trusted orchestrator.
How it shows up
A scenario requires passing a secret through an intermediary that must not see it, pointing to response wrapping.
Common confusion
Thinking the wrapping token can be reused or that wrapping encrypts the secret with a user key.
5f Explain the value of short-lived, dynamically generated secretsWhy expiring, unique credentials reduce risk.
What it means
Short-lived dynamic secrets limit how long a leaked credential remains useful and tie each credential to one client, which narrows exposure and improves accountability.
What to understand
Because each consumer receives unique credentials, Vault can revoke one application's access without affecting others, and audit logs show which client used which credential. Automatic expiry removes forgotten long-lived passwords. Applications should be designed to renew or refetch secrets, which Vault Agent can automate. The trade-off is added load on target systems and the need for applications to handle credential changes.
How it shows up
Expect to state the security benefit of dynamic secrets in a breach or audit scenario.
Common confusion
Assuming the main benefit is convenience rather than reduced exposure and precise revocation.
5g Enable secrets engines using the CLI, API, and UIMounting engines at paths through each interface.
What it means
Enabling an engine mounts it at a path so it can be configured and used. The CLI uses vault secrets enable, the API uses a POST to /v1/sys/mounts/<path>, and the UI offers the same under Secrets Engines.
What to understand
vault secrets enable -path=team-a kv-v2 mounts KV version 2 at team-a/. Without -path, the engine type becomes the path. vault secrets list -detailed shows mounts and versions; vault secrets tune adjusts TTLs; vault secrets disable removes a mount. The API body includes the type and options such as version for KV. HashiCorp added the API to this objective on 4 March 2025.
How it shows up
A mount command or API request is shown, and you identify the path, type or option it sets.
Common confusion
Forgetting that a mount without -path uses the engine type name as its path.
5h Access Vault secrets using the CLI, API, and UIReading and writing secrets through each interface.
What it means
Accessing secrets means reading, writing and listing values through vault kv commands or vault read and write, through HTTP calls under /v1/ with a token, and through the UI's secret browser.
What to understand
vault kv put, get, patch, delete, undelete, destroy, rollback and metadata manage KV version 2, with -version for a specific version. The API for KV version 2 uses /v1/<mount>/data/<path>, while the CLI hides the data/ segment. Requests send the token in the X-Vault-Token header or as an Authorization Bearer token. vault read database/creds/<role> retrieves dynamic credentials. -format=json and -field help in scripts.
How it shows up
Expect to identify the correct API URL or CLI command to read a specific secret or version.
Common confusion
Leaving out data/ in a KV version 2 API URL.

High-yield concepts

The terms, rules and formulas this domain turns into questions most often.

  • Secrets engine mount

    An engine enabled at a path.

    Remember
    Requests are routed by path.
    Tested as
    Purpose questions.
    Trap
    Expecting engines to share data.
  • KV version 2

    Versioned key/value storage.

    Remember
    Supports versions, soft delete, undelete and destroy.
    Tested as
    Static secret questions.
    Trap
    Confusing delete with destroy.
  • Database engine

    Generates database credentials on demand.

    Remember
    Unique users per lease.
    Tested as
    Dynamic secret questions.
    Trap
    Choosing KV for expiring credentials.
  • PKI engine

    Issues X.509 certificates.

    Remember
    Short-lived certificates replace revocation lists.
    Tested as
    Certificate scenarios.
    Trap
    Choosing transit for certificates.
  • Transit engine

    Encryption as a service.

    Remember
    Does not store application data.
    Tested as
    Encryption scenarios.
    Trap
    Expecting it to store ciphertext.
  • Cubbyhole

    Private storage scoped to one token.

    Remember
    Enabled by default; vanishes with the token.
    Tested as
    Wrapping questions.
    Trap
    Thinking other tokens can read it.
  • Dynamic secret

    Credential generated per request with a lease.

    Remember
    Revoked automatically at expiry.
    Tested as
    Comparison questions.
    Trap
    Treating it as rotated static data.
  • Response wrapping

    Secret delivered inside a single-use token.

    Remember
    Unwrap once; check the creation path.
    Tested as
    Secure delivery questions.
    Trap
    Reusing the wrapping token.
  • vault secrets enable

    Mounts an engine.

    Remember
    Without -path the type is the path.
    Tested as
    CLI questions.
    Trap
    Forgetting -path for second mounts.
  • X-Vault-Token header

    Carries the token on API calls.

    Remember
    Required on authenticated requests.
    Tested as
    API syntax questions.
    Trap
    Putting the token in the URL.
  • Disabling a mount

    Removes an engine from a path.

    Remember
    Revokes leases and deletes data.
    Tested as
    Consequence questions.
    Trap
    Expecting data to remain.

Side by side

Concepts candidates mix up, compared on the point that decides the answer.

Static vs. dynamic secrets

ConceptMeaningKey differenceCommon trap
Static (KV) Stored values written by users Same value for every reader Using it for expiring credentials
Dynamic Generated on request with a lease Unique per client, auto-revoked Thinking it is static plus rotation
Static role (database) Vault rotates one fixed account Shared account, scheduled rotation Confusing it with dynamic users

Common engines by use case

ConceptMeaningKey differenceCommon trap
KV Arbitrary key/value data Static values Choosing it for certificates
Database / cloud Short-lived credentials Dynamic with leases Overlooking them for apps
PKI X.509 certificates Internal CA Confusing with transit
Transit Encrypt, sign, HMAC Stores keys, not data Expecting stored ciphertext

KV version 2 removal commands

ConceptMeaningKey differenceCommon trap
delete Soft-deletes the latest version Can be undeleted Thinking data is gone
destroy Permanently removes versions Cannot be recovered Using it when undelete is needed
metadata delete Removes all versions and metadata Deletes the whole key Confusing it with delete

Exam traps

Each trap is an answer that looks right. Learn the clue that should change your mind.

  1. KV for expiring creds

    What candidates pick
    Store database passwords in KV with a reminder to rotate.
    Why it looks right
    KV is familiar and simple.
    Why it's wrong
    Only a dynamic engine generates unique credentials that Vault revokes automatically at lease end.

    Clue to watch for The requirement says credentials must expire or be unique.

  2. Transit as storage

    What candidates pick
    Send data to transit and read it back later.
    Why it looks right
    Encryption feels like secure storage.
    Why it's wrong
    Transit returns ciphertext for the application to store; Vault never keeps the data.

    Clue to watch for The scenario mentions where encrypted data lives.

  3. Reusable wrap

    What candidates pick
    Share one wrapping token with several services.
    Why it looks right
    It looks like a normal token.
    Why it's wrong
    Wrapping tokens are single-use, so a second unwrap fails and may signal tampering.

    Clue to watch for More than one recipient needs the secret.

  4. KV API without data/

    What candidates pick
    Call /v1/secret/myapp for a KV v2 secret.
    Why it looks right
    It matches the CLI path.
    Why it's wrong
    The KV version 2 API requires /v1/secret/data/myapp; the CLI adds data/ automatically.

    Clue to watch for A curl command reads a KV v2 secret.

  5. Disable keeps data

    What candidates pick
    Disable a mount temporarily and re-enable it later.
    Why it looks right
    Other tools pause rather than delete.
    Why it's wrong
    Disabling revokes all leases and deletes the mount's stored data.

    Clue to watch for An option suggests disabling as a pause.

  6. Delete equals destroy

    What candidates pick
    Assume vault kv delete removes data permanently.
    Why it looks right
    Delete usually means gone.
    Why it's wrong
    KV v2 delete is a soft delete that undelete reverses; destroy is permanent.

    Clue to watch for The scenario needs to recover a deleted version.

  7. Cubbyhole is shared

    What candidates pick
    Store a secret in cubbyhole for a team.
    Why it looks right
    It is a storage engine.
    Why it's wrong
    Cubbyhole is private to one token and disappears when that token expires or is revoked.

    Clue to watch for Multiple users need access.

Answer framework

Use these steps for any Domain 5 engine selection or syntax item.

  1. Identify the type of secret or operation: a stored value, a generated credential, a certificate, an SSH key or an encryption request.
  2. If credentials should be unique and expire, choose the dynamic engine for that system; otherwise KV usually fits stored values.
  3. If the data must stay outside Vault while being encrypted, choose transit; if a secret must cross an untrusted hop, use response wrapping.
  4. Check the mount path and engine version, adding data/ for KV version 2 API calls and -path for additional mounts.
  5. Consider lifecycle effects, such as lease revocation on disable, soft delete versus destroy, and single-use wrapping tokens.

Practice question

A deployment tool must hand an AppRole SecretID to a new application instance. The tool should never be able to read the SecretID, and the application must detect if anyone else retrieved it first. Which Vault feature meets these needs?

Choose one answer

Want more like this? The Vault Associate practice test has questions for every domain.

Checklist

0 of 13

Tick each one you can do without notes. Your ticks stay in this browser.

Study strategy

Give this group the largest share of your preparation, since it has eight objectives and links to leases and encryption. Start on a dev server with KV version 2: put, get, patch, delete, undelete, destroy and rollback a secret, then read the same secret with curl so the data/ path segment becomes second nature. Enable a second KV mount at a custom path and confirm how vault secrets list shows both.

Next, run at least one dynamic engine end to end. The database engine with a local PostgreSQL container is ideal: configure the connection, create a role, read credentials twice and compare usernames, then revoke a lease. Enable transit, create a key and encrypt a short base64 string. Practise response wrapping by wrapping a KV read with -wrap-ttl, unwrapping it, and trying to unwrap again.

Finish with an engine selection table that lists each engine, the secret it handles, static or dynamic, and a sample scenario. Drill practice questions on engine choice and API syntax until you answer them reliably.

FAQ

Is Secrets engines the biggest part of the Vault Associate exam?

HashiCorp publishes no weights, but Secrets engines has eight objectives, more than any other group. We estimate about eleven questions and suggest giving it the most study time.

What is the difference between static and dynamic secrets?

Static secrets are stored values that stay the same until someone changes them. Dynamic secrets are generated per request with a lease and revoked automatically when it ends.

Does the transit engine store my data?

No. Transit encrypts or decrypts data you send and returns the result. Your application stores the ciphertext; Vault only holds the keys.

Why can a wrapping token be used only once?

Single use means only one party can retrieve the secret. If the intended recipient's unwrap fails, the secret may have been intercepted and should be treated as compromised.

Why does the KV version 2 API path include data/?

KV version 2 separates secret values under data/ from version information under metadata/. The CLI inserts data/ for you, but direct API calls must include it.

What happens when I disable a secrets engine?

Vault revokes all leases issued by that mount and deletes the data stored there, so disabling is not a temporary pause.

Do I need to know the API for enabling engines?

Yes. HashiCorp added the API to objective 5g in March 2025, so recognise POST /v1/sys/mounts/<path> alongside the CLI and UI.

Other Cybersecurity certifications

Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.

Test your Domain 5 knowledge

You have covered engine selection, static and dynamic secrets, transit, response wrapping and CLI, API and UI access. Test whether you choose correctly under exam conditions.

Keep going