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.
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
| Concept | Meaning | Key difference | Common 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
| Concept | Meaning | Key difference | Common 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
| Concept | Meaning | Key difference | Common 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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
- Identify the type of secret or operation: a stored value, a generated credential, a certificate, an SSH key or an encryption request.
- If credentials should be unique and expire, choose the dynamic engine for that system; otherwise KV usually fits stored values.
- If the data must stay outside Vault while being encrypted, choose transit; if a secret must cross an untrusted hop, use response wrapping.
- Check the mount path and engine version, adding data/ for KV version 2 API calls and -path for additional mounts.
- Consider lifecycle effects, such as lease revocation on disable, soft delete versus destroy, and single-use wrapping tokens.
Practice question
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.
- CompTIA Cybersecurity Analyst+ Study guide
- Microsoft Security Operations Analyst Associate Study guide
- Certified Ethical Hacker Study guide
- Penetration Tester Study guide
- Systems Security Certified Practitioner Study guide
- Certified in Risk and Information Systems Control Study guide
- CompTIA PenTest+ Study guide
- CompTIA SecurityX (CASP+) Study guide
- Azure Security Engineer Associate Study guide
- CISM (Certified Information Security Manager) Study guide
- CISSP Study guide
- CompTIA Security+ Study guide
- Certified Information Systems Auditor Study guide
- Certified Cloud Security Professional Study guide
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
- Training Training Built on your Weak areas
- Practice test Questions by domain, with explanations
- Mock exam Full length, timed like the real exam
- Readiness test Find your weakest domain in minutes
- Cheat sheet Key terms and formulas on one page
- Ask the Vault Associate AI tutor Get any concept explained your way