Secrets Engines Overview — the part of Vault that actually creates, stores, and manages secrets. For the VA-003 exam, you need to know what a secret is, what an engine does, and why Vault doesn't just dump everything into one big bucket. This chapter gives you the mental model that maps directly to exam questions about engine types, use cases, and the difference between static and dynamic secrets.
Jump to a section
A simple way to picture Secrets Engines Overview
Every day, 17 different delivery drivers arrive at a 50-unit apartment building. Each driver has packages, letters, and sensitive documents — paycheques, tax forms, medical records. They all head straight for the mailroom. But there's no single locked mailbox per resident. Instead, there is one enormous, open bin labelled 'Building Mail'. Every driver tosses their delivery into the same bin. Residents then dig through the pile to find their own mail. This is a nightmare: letters get lost, privacy is destroyed, and the postmaster can never track who sent what or when.
Now imagine the same building installs a proper, tiered mailroom system. Each resident has their own locked, numbered compartment. When a delivery driver arrives, they walk to a digital keypad, enter the destination unit number, and the system assigns a temporary, single-use code for that compartment. The driver places the item, locks the door, and the system logs the time, the sender, and the exact compartment used. The resident receives a notification and uses their permanent key to retrieve their item. The building manager can revoke any driver's access instantly. This is how Vault's secrets engines work: each 'engine' is a separate, locked compartment designed for one type of sensitive data — database passwords, cloud keys, API tokens. Each engine has its own rules for generating, storing, and revoking that specific type of secret. Nobody shares a single bin anymore.
That single open bin is legacy secrets management — passwords in text files, config files with hard-coded keys. The mailroom system is HashiCorp Vault, and each locked compartment is a secrets engine. The analogy maps precisely: compartments are isolated (each engine handles one secret type), access is logged (audit trail), keys are revoked per driver (dynamic secret rotation), and residents never see each other's mail (tenant isolation).
Start with a definition. A secret is any piece of information you want to keep private — a database password, an API token, a cloud access key, an SSH private key. In the real world, secrets are everywhere. A website needs a password to talk to its database. A mobile app needs an API key to call a payment service. A cloud server needs an access key to write logs to Amazon S3. Traditionally, these secrets were stored in plain text files, config files, environment variables, or even hard-coded in source code. This is dangerous: any person or script that reads that file now has permanent access, and changing it means updating every copy by hand.
That is the problem Vault solves. Vault is a centralised system that stores and controls access to secrets. But Vault does not use one single drawer for all secrets. Instead, Vault uses secrets engines. A secrets engine is a plugin-like component that handles one specific type of secret in one specific way. Think of Vault as an empty cabinet. You do not throw everything into the cabinet. First, you install a drawer designed for keys, another drawer designed for passwords, another for cloud credentials. That drawer is a secrets engine. Each engine is enabled at a path — a URL-like address like "database/" or "aws/". When you read or write to that path, the engine handles the logic.
Secrets engines fall into two main categories: static and dynamic. A static secret is one you create and give to Vault to store — for example, your existing database password. Vault encrypts it and serves it back when authorised. It does not change unless you manually update it. A dynamic secret is one Vault generates on demand, leases for a limited time, and then automatically destroys when the lease expires. For example, Vault can connect to your cloud provider (like AWS or Microsoft Azure), create a temporary access key valid for 2 hours, hand it to your application, and then delete that key after 2 hours. Dynamic secrets are far more secure because even if a hacker steals the key, it stops working after a short time.
Here are the major types of secrets engines you will be tested on:
KV (Key-Value) Engine: Stores arbitrary key-value pairs. You write a key like "myapp/secret" with a value "supersecretpassword". This is the simplest engine, used for static secrets. It can be versioned (v1 is simple, v2 keeps versions so you can roll back).
Database Engine: Connects to supported databases (PostgreSQL, MySQL, MongoDB, etc.) and generates temporary database credentials — a username and password that only work for a specific number of hours. No more sharing one root password across all apps.
AWS Engine: Generates temporary AWS access keys with fine-grained IAM policies. You tell Vault "I need a key that can only read from S3 bucket X for 1 hour" and Vault creates it.
Azure Engine: Does the same for Microsoft Azure — generates temporary service principal secrets or managed identity tokens. Uses Microsoft Entra ID (formerly Azure Active Directory) for authentication and access control.
PKI/TLS Engine: Generates short-lived X.509 certificates for TLS/SSL. Your app asks for a certificate, Vault issues one that expires in 48 hours, and your app uses it to secure traffic. Perfect for service mesh and zero-trust architectures.
Transit Engine: Does not store secrets; instead, it provides encryption-as-a-service. You send plaintext data to Vault, Vault encrypts it with a key you manage, and returns ciphertext. You never have to store the encryption key yourself.
Active Directory Engine: Manages passwords for Active Directory. Can rotate passwords for AD service accounts automatically.
An important concept is that each secrets engine can be enabled or disabled on a mount path. When you enable a database engine at "database/", you get a fully functional API at paths like "database/creds/my-role". You can also tune the engine — set default lease times (how long a dynamic secret lives), maximum lease times, and whether the engine is allowed to be used at all if its mount is sealed.
Secrets engines are isolated from each other. If you enable the AWS engine at "aws/" and the KV engine at "mysecrets/", reading from "mysecrets/" will never expose AWS credentials. This isolation is enforced by Vault's access control (policies) and by the path itself — each engine only knows how to handle requests under its own mount path.
Why does this matter? Because Vault is not a one-trick pony. Each organisation has hundreds of different types of secrets — cloud keys, database passwords, API tokens, certificates, SSH keys. A single storage drawer cannot handle all these types equally. A database password has different rotation requirements than a TLS certificate. A cloud access key has a different lifecycle than a static API token. Secrets engines give Vault the flexibility to treat each secret type according to its own best practices.
For the VA-003 exam, you must memorise the purpose of each major engine type, the difference between static and dynamic secrets, and the concept of mount paths. You will see scenario questions that say "Your team needs temporary database credentials for a CI/CD pipeline. Which secrets engine should you use?" The answer is the database engine. Or "You need to secure traffic between two microservices without managing certificate files. Which engine?" PKI/TLS engine.
Enable a Secrets Engine on a Mount Path
You tell Vault 'Enable the database engine at the path database/'. This creates an empty engine ready to be configured. The mount path is how clients will reference the engine in API calls and policies. Without this step, Vault does not know which engine to use for which requests.
Configure the Engine with Connection Details
For the database engine, you provide the database connection string, the admin username and password (or other credentials) so Vault can connect to the database. For the AWS engine, you provide the AWS access key and secret key for a user that has permission to create IAM users or STS tokens. This is the 'setup' step that links Vault to the external system.
Define Roles that Control What Secrets to Generate
A role is a named configuration inside the engine. For the database engine, a role like 'read-only' specifies the SQL grants to apply to the generated credential. For the AWS engine, a role specifies which IAM policy document to attach. Roles let you create different levels of access — read-only vs. read-write for different services.
Request a Secret from the Engine
An application makes an API call to Vault at the path corresponding to the engine and role, e.g., 'database/creds/read-only'. Vault authenticates the request (via a token or other auth method), checks the policy to ensure the caller is authorised, then generates a new secret — a unique username and password for the database, or an STS token for AWS. Vault returns the secret along with a lease duration.
Vault Manages the Secret's Lifecycle
Vault starts a timer for the lease duration. When the lease expires, Vault automatically revokes the secret — deleting the database user, or invalidating the STS token. If the application no longer needs the secret, it can explicitly revoke it early. Vault also logs every revocation for audit. This lifecycle management is the core value of dynamic secrets.
Imagine you work for a mid-size company called ShopNow, an e-commerce platform with 30 microservices, 10 databases, and infrastructure hosted in AWS and GCP. Every day, thousands of customers browse, add items to cart, and pay. The security team just discovered that the root password to the PostgreSQL database was stored in a plain text file on an engineer's laptop — and that file was accidentally uploaded to a public GitHub repo. That is a real-world disaster. Enter secrets engines.
The head of security says: 'We are moving all secrets into Vault. No more static passwords in files.' Here is exactly what happens, step by step:
The operations team enables the KV Secrets Engine at a path called "kv/legacy" and migrates all existing static passwords — the PostgreSQL root password, the API key for Stripe, the JWT signing secret — into that engine as static secrets. These are now encrypted at rest by Vault's barrier and only accessible via policies.
For each production database, the team enables the Database Engine. They configure Vault to connect to their PostgreSQL cluster using a powerful admin user. Then they create roles in the engine — for example, a role called "read-only" that generates a credential with SELECT-only permissions on the public schema. Another role called "read-write" that allows INSERT, UPDATE, DELETE on the orders table. Now, whenever the order-processing service needs database access, it calls Vault's API at path "database/creds/read-write" and receives a unique username and password. That credential expires in 1 hour. If the service is compromised, the attacker has at most 1 hour of access — not permanent root.
The platform engineering team configures CI/CD pipelines (tools like Jenkins, GitLab CI, GitHub Actions) to use the AWS Secrets Engine. Before each deployment, the pipeline requests temporary AWS keys from Vault via the path "aws/creds/deployer". These keys have a policy that allows them to push container images to ECR and update ECS services, but nothing else. After the deployment finishes, Vault revokes the keys. Even if a malicious actor sniffs the pipeline logs, they get nothing usable.
The security team also enables the Transit Engine. They store a master encryption key in Vault (never leaving Vault). When the payment service needs to encrypt a customer's credit card number before storing it in the database, it sends the plaintext to Vault's "transit/encrypt/payments-key" path. Vault returns the ciphertext. To decrypt, the service sends the ciphertext to "transit/decrypt/payments-key". The encryption key itself never leaves Vault. This meets PCI DSS requirements without the team having to manage encryption keys.
For inter-service TLS, they enable the PKI engine. Every microservice starts up and requests a certificate from Vault at path "pki/issue/my-service". Vault issues a certificate valid for 48 hours. The service uses it to communicate with other services over HTTPS. When the certificate expires, the service requests a new one. No more manual certificate rotation, no more expired certificates causing outages.
In this scenario, the IT professional's job is not just to 'turn on Vault'. It is to choose the right secrets engine for each workload, configure the engine with the correct connection details, define roles with least privilege, set appropriate lease durations, and write policies that control who can call each engine's paths. They also monitor audit logs to see which engine is being used by which application. The database engine dramatically reduces the blast radius of a compromised application because every credential is short-lived. The transit engine reduces the risk of key leakage because no application ever holds the raw encryption key. The PKI engine eliminates the overhead of running an internal CA and managing certificate files.
This whole stack — multiple engines working together — is what makes Vault an enterprise-grade secrets management tool. For the VA-003, you do not need to configure a real engine, but you must be able to read a scenario and identify which engine solves which problem.
The VA-003 exam tests secrets engines in two main ways: definition recall and scenario-based identification. You must be able to answer questions like 'Which secrets engine would you use to generate temporary database credentials?' without hesitation. The exam loves to test your ability to distinguish between engine types, especially the ones that sound similar.
Here are the specific concepts the exam tests about Secrets Engines Overview:
The difference between static and dynamic secrets. Static secrets are stored and served on demand; dynamic secrets are generated, leased, and revoked. Traps: the exam might describe a scenario where a long-lived API key is stored in Vault (static) and ask if that is a valid use case — it is, but it is less secure than using a dynamic engine like AWS.
The KV engine's two versions: KV v1 (no versioning, non-configurable delete behaviour) and KV v2 (versioned, configurable, supports check-and-set). The exam may give you a list of features and ask which version supports metadata or version control.
The Database Engine's ability to rotate root credentials (the admin user used to connect to the database) in addition to generating temporary credentials. A common trap: the question asks 'What does the database engine do with the root credential?' The correct answer is that Vault rotates it automatically after a configurable rotation period.
The AWS Engine's credential types: IAM user (static-like) and STS (Security Token Service) for truly temporary credentials. The exam tests that STS credentials are the recommended type for short-lived access.
The Azure Engine uses Microsoft Entra ID (formerly Azure Active Directory) for authentication. If a question mentions 'Azure service principal' or 'Active Directory', the answer is the Azure secrets engine, not the Active Directory engine (which is for on-prem AD).
The Transit Engine does not store secrets — it provides encryption operations. A common trap question: 'Which engine stores encryption keys and allows you to encrypt data in Vault?' The Transit engine stores keys but not the data itself; it performs on-the-fly encryption. The KV engine stores data but does not perform encryption operations.
The PKI Engine's roles allow you to set allowed domains, TTLs, and key types. The exam tests that the PKI engine can act as an internal Certificate Authority (CA) for issuing short-lived certificates.
Exam traps to watch for:
The 'one secret type' trap: The exam might describe a scenario where you need to store a database password AND an AWS key, and ask whether you need two engines. Trick: you can store both in the KV engine, but that is not best practice. The 'correct' answer on the exam is usually the best practice answer — use the database engine for database passwords and the AWS engine for cloud keys. The KV engine is the fallback for arbitrary secrets, not the recommended one.
The 'secrets engine vs. auth method' trap: Beginners confuse secrets engines with authentication methods. An auth method (like LDAP, token, Okta) is how a user or machine proves who they are. A secrets engine is what they access after authenticating. The exam may list both in a question and ask you to pick which one is used to generate database passwords. The answer is the database secrets engine, not an auth method.
The 'mount path' trap: The exam may ask 'What happens if you enable the AWS engine at path "database/"?' The answer: it works, but it is confusing. There is no rule preventing it, but it breaks convention and makes policy writing harder. The exam tests that mount paths are arbitrary but should follow a consistent naming convention.
The 'static vs. dynamic lease' trap: A dynamic secret always has a lease (TTL). A static secret can optionally have a lease (if you set it), but by default it does not expire. The exam may ask 'Which type of secret can be revoked after a TTL?' Dynamic secrets.
Key definitions to memorise:
Secrets Engine: A plugin that creates, stores, or rotates secrets of a specific type. Isolated by mount path.
Static Secret: A secret created and managed outside Vault, then stored in Vault. Does not expire unless you set a lease manually.
Dynamic Secret: A secret generated on demand, with a lease. Vault creates it, returns it, and automatically destroys it when the lease expires.
Mount Path: The URL-like address under which a secrets engine is accessible (e.g., "database/", "aws/").
Lease: The duration a dynamic secret is valid. After expiry, Vault revokes the secret.
Role: A named configuration within an engine that defines what kind of secret to generate (e.g., which database privileges, which cloud policy).
A secrets engine is a plugin that handles one type of secret — database passwords, cloud keys, certificates — in one specific way, isolated by mount path.
Static secrets you create and store in Vault; dynamic secrets Vault generates on demand, hands out with a lease, and destroys when the lease expires.
The KV engine is the simplest engine for storing arbitrary static secrets, with KV v2 providing versioning, rollback, and metadata support.
Dynamic secrets are the most secure type because they limit the blast radius of a credential leak to the lease duration.
Each cloud provider (AWS, Azure, GCP) has its own separate secrets engine — do not mix them up on the exam.
The Transit engine does not store secrets; it only provides encryption and decryption operations using keys you manage in Vault.
The PKI engine allows Vault to act as an internal Certificate Authority that issues short-lived TLS certificates automatically.
Mount paths are arbitrary but should follow a consistent naming convention for clarity — the engine does not enforce any particular path.
These come up on the exam all the time. Here's how to tell them apart.
Static Secret (KV Engine)
Secret is created and stored in Vault; Vault does not manage its lifecycle beyond encryption at rest.
No automatic expiration — secret lives until manually deleted or updated.
Best for long-lived credentials like a root API key that rarely changes.
Dynamic Secret (Database Engine)
Secret is generated on demand by Vault when requested; Vault creates and manages the lifecycle.
Automatic expiration via a lease; Vault revokes the secret when the lease ends.
Best for short-lived credentials like a database user for a CI/CD pipeline.
Transit Engine
Does not store data; only performs encryption/decryption operations on data you send.
The encryption key is managed in Vault but never leaves Vault — client never sees the key.
Use case: encrypt a credit card number on the fly without storing the encrypted value in Vault.
KV Engine
Stores arbitrary key-value pairs (both plain and encrypted by Vault's barrier).
The client stores the encrypted ciphertext (if using Vault's barrier) inside Vault itself.
Use case: store a static API key or configuration value that is retrieved by an application.
AWS Secrets Engine
Generates temporary AWS access keys (access key ID and secret access key) via IAM or STS.
Policies are defined as IAM policy documents in the engine role.
Works exclusively with Amazon Web Services — cannot generate Azure tokens.
Azure Secrets Engine
Generates temporary Azure service principal secrets or Managed Identity tokens.
Policies are defined as Azure RBAC roles or custom assignments.
Works exclusively with Microsoft Azure — cannot generate AWS keys.
KV v1 Engine
No versioning — each write overwrites the previous value with no way to roll back.
Delete is immediate and permanent; no undelete capability.
Simpler, less overhead, but less resilience against accidental data loss.
KV v2 Engine
Versioning enabled — each write creates a new version; you can read, roll back, or destroy specific versions.
Supports soft delete — deleted versions are hidden but can be undeleted until destroyed.
Includes metadata (creation time, deletion time, version numbers) and supports check-and-set operations.
PKI Engine
Issues X.509 TLS certificates — signed by Vault's internal or external CA.
Lease duration is the certificate's TTL; Vault automatically revokes the certificate from the CA when it expires.
Used for securing network communications (TLS/SSL) between services, devices, or users.
Database Engine
Issues temporary database usernames and passwords for supported database systems.
Lease duration is the credential's TTL; Vault drops the database user when the lease expires.
Used for authenticating applications to databases with minimal blast radius.
Mistake
Secrets engines are the same thing as authentication methods — they both control access to secrets.
Correct
Authentication methods are how you prove your identity to Vault (who you are). Secrets engines are what you access after you are authenticated (what you can get). They are completely separate subsystems that work together.
In Vault's CLI and UI, authentication methods and secrets engines both appear as 'backends' and are both enabled at paths. Beginners see the similarity and assume they are interchangeable. The exam explicitly tests this distinction.
Mistake
The KV secrets engine can only store text strings — you cannot store binary data like SSH keys or images.
Correct
The KV engine is binary-safe. It stores arbitrary bytes. You can store SSH private keys, .tar.gz files, or any binary blob. Vault encodes the data using base64 when needed, but the engine itself does not restrict content type.
Many beginners come from web development where key-value stores are 'strings only'. Vault's KV engine is a generic blob store, not a JSON-only datastore. This misconception leads to wrong answers about what the KV engine can handle.
Mistake
You must use the AWS secrets engine for all cloud secrets — GCP, Azure, and AWS are handled by the same engine.
Correct
Each cloud provider has its own dedicated secrets engine: the AWS Engine for Amazon Web Services, the Azure Engine for Microsoft Azure, and the GCP Engine for Google Cloud Platform. They are completely separate plugins. You cannot use the AWS engine to generate Azure tokens.
Vault’s modular design means each engine is a separate plugin. Beginners often think 'cloud secrets = one engine' because in daily life we use 'the cloud' as a single concept. The exam uses this to test whether you know which engine maps to which provider.
Mistake
Enabling the Transit engine allows you to store encrypted secrets in Vault for later retrieval, like the KV engine.
Correct
The Transit engine does not store any data. It is an encryption-as-a-service engine: you send plaintext to Vault and receive ciphertext. If you want to later retrieve that ciphertext, you must store it yourself — in a database, a file, or even the KV engine. Transit only handles the encryption and decryption operations.
The word 'encryption' makes beginners think 'secure storage', but Transit is purely a cryptographic operation provider, not a storage backend. The exam sets traps where a question asks 'which engine stores your encrypted secrets?' and the answer is KV, not Transit.
Mistake
The Database Engine only works with relational databases like PostgreSQL and MySQL.
Correct
The Database Engine also supports NoSQL databases such as MongoDB (via MongoDB Atlas and self-hosted) and Cassandra, as well as Elasticsearch, Redis, and even Google Bigtable. It uses database-specific plugins to provision credentials.
Most tutorials and exam prep focus on the big three relational databases. Beginners assume the engine is only for SQL databases. The exam uses an example with MongoDB to catch this assumption.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
No. The KV engine only stores static secrets — it never connects to a database to change passwords. To get automatic rotation, you need the database engine, which can rotate both the root credential and temporary generated credentials.
Vault itself does not enforce a per-engine limit beyond the available storage backend capacity. However, practice imposes limits via lease expiration (for dynamic secrets) and policy controls. The exam does not test a specific number limit.
You cannot. Vault enforces that each mount path has exactly one secrets engine. If you try to enable a second engine on a path that already has one, Vault returns an error. You must choose a different path.
It is definitely a secrets engine. It is enabled on a mount path, uses roles and policies, and provides a service (encryption-as-a-service). It is not used for authentication.
Yes, absolutely. An application might authenticate once, then request a database credential from the database engine, an AWS key from the AWS engine, and a TLS certificate from the PKI engine — all in the same session. Each request is authorised independently by Vault's policies.
A dynamic secret always has a lease — it is temporary and Vault will revoke it when the lease expires. A static secret stored in the KV engine has no lease by default (it lives until you delete it), but you can optionally attach a lease to a static secret to force its renewal.
You've finished Secrets Engines Overview. Continue through the VA-003 study guide to build a complete picture of the exam.
Done with this chapter?