HashiCorp Vault is a tool that manages secrets—the digital keys, passwords, and certificates that computers use to prove their identity to each other. Before Vault, IT teams stored these secrets in hardcoded text files, spreadsheets, or configuration files that everyone could see, creating massive security risks. For the VA-003 exam, you need to understand why Vault exists and what problems it solves, because that foundational logic is tested directly in exam objective 1.1.
Jump to a section
A simple way to picture Introduction to Vault and Core Concepts
A locked apartment building has a single master key that opens the main entrance, the laundry room, and each individual flat. The building manager holds this master key on a special ring that also holds a separate key for the storage locker, the rooftop garden, and the maintenance closet. Tenants each have their own key that only opens their flat and the main door. A plumber who needs to fix a leak in unit 3A is given a temporary key that works only on that day, only for that unit's door, and stops working at 5 PM. The key system itself is a small metal box with numbered hooks inside the manager's office. When the manager needs to give out a key, they sign a logbook recording which hook they took the key from, who took it, and when. If a key is lost, the manager can rekey just that one lock without changing all the others. The box does not care who the tenant is or why they need the key—it just stores keys securely and releases them only to authorised people following the rules written in the logbook. This is precisely what HashiCorp Vault does for computer systems: it stores secrets (like keys, passwords, certificates) in a central sealed box, issues them temporarily with strict rules, and logs every single access.
When a computer needs a password to talk to another computer, Vault acts like that key box. The computer requests the password, Vault checks the rules (who is asking, what time is it, is this request allowed), and if everything matches, it hands over the password for a short time. When the password expires, the computer must ask again. No one person or system holds all the passwords permanently, just like no tenant holds the master key. This central control means that if a password leaks, it is useless within minutes because Vault already revoked it. The manager never walks around carrying all the keys at once—they stay locked in the box.
HashiCorp Vault is a software tool that securely stores, controls access to, and automatically rotates secrets. A secret is any piece of sensitive data that a computer needs to authenticate or authorise itself—passwords, API keys (programmatic access tokens for external services), database credentials (username/password pairs for databases), and TLS certificates (digital files that prove a server's identity and encrypt network traffic).
Before Vault, IT teams had a problem called 'secrets sprawl'. They would copy passwords into configuration files (text files that tell a computer how to run), paste API keys into scripts (small programs that automate tasks), and email database credentials to colleagues. These secrets would live forever, even after the person who used them left the company or the computer was decommissioned. If one leaked—for example, in an accidental code upload to a public repository like GitHub—attackers could use that credential for years because nobody remembered to change it.
Vault solves this by creating a single central control point for all secrets. Instead of storing a database password in a configuration file, the application (the computer program that needs the password) asks Vault for it at runtime (while the program is actually running). Vault checks the application's identity using a process called authentication—the application presents a token or another form of ID that proves who it is. If the authentication passes, Vault applies authorisation rules (policies that define what each identity is allowed to do). If the request matches a policy, Vault dynamically generates a secret on the spot. The secret comes with a Time-To-Live (TTL), which is a built-in expiration period—typically minutes or hours. When the TTL expires, the secret becomes invalid automatically. The application can request a new one, or a new secret is generated the next time it asks.
This dynamic secret generation is a key concept. For example, Vault can connect to a database engine (a plugin inside Vault that knows how to talk to databases like PostgreSQL or MySQL) and create a temporary database username and password just for that application. The password is strong, randomly generated, and only works for the duration of the TTL. When the TTL expires, Vault tells the database to delete that username. The application never stored a permanent database password—it only had a short-lived one.
Another core concept is encryption-as-a-service. Vault can encrypt and decrypt data without you ever seeing the encryption key. Suppose you need to store a customer's credit card number in your own database. You send the plain text number to Vault, Vault encrypts it using a master key stored inside Vault's own encrypted storage (a secure filesystem called the storage backend), and Vault returns an encrypted blob (a block of scrambled data). To read it later, you send the encrypted blob back to Vault, and Vault decrypts it using the same master key. You never handle the encryption key yourself, which reduces the risk of it leaking.
Vault also handles secret leasing and renewal. A lease is a contract between Vault and the client that says 'this secret is valid for this time period'. The client can renew the lease before it expires, asking for more time. If the client goes offline or forgets to renew, the lease expires and the secret is automatically revoked.
The architecture of Vault has several key components:
The storage backend: where Vault stores its encrypted data. This can be a filesystem, a cloud storage like Amazon S3, or a database like Consul.
The seal: an extra layer of encryption that protects the master key. Vault starts 'sealed' and must be 'unsealed' by providing a threshold of unseal keys (shared among trusted administrators) before it can serve any requests. This protects data even if the server is stolen.
The API (Application Programming Interface): the way other programs talk to Vault, usually over HTTP or HTTPS (secure web protocols).
Policies: written in HashiCorp Configuration Language (HCL), these are rules that define which paths (specific areas within Vault) a user can read, write, or delete.
Why does this matter for the VA-003 exam? Objective 1.1 specifically asks you to explain Vault's purpose and use cases. The exam wants you to recognise that Vault is not just a password manager for humans—it is an automated secrets management system for machines. You must understand that Vault reduces the attack surface (the number of places where secrets can be stolen) by eliminating hardcoded secrets, rotating credentials automatically, and providing detailed audit logs of who accessed what and when.
1. Initialise Vault
When Vault is installed for the first time, an administrator runs a command to initialise it. This generates a master encryption key that protects all stored secrets. The master key is immediately split into multiple key shards using Shamir's Secret Sharing. The administrator distributes these shards to trusted colleagues. Without this step, Vault cannot be used because no data can be written or read until the seal is broken.
2. Unseal Vault
After initialization, Vault is in a sealed state. The administrator must provide a threshold number of key shards (e.g., 3 out of 5) to unseal Vault. This ensures that no single person can unlock Vault unilaterally. Only unsealed Vault can accept authentication requests and serve secrets. This step protects against an attacker who gains physical access to the Vault server.
3. Configure Authentication Methods
The administrator enables one or more authentication backends (e.g., token, username/password, AWS IAM role, Microsoft Entra ID). Each backend defines how clients prove their identity to Vault. For a beginner setup, the token method is simplest: the admin generates a root token that has unrestricted access, then creates more limited tokens for applications.
4. Enable Secrets Engines and Write Policies
The administrator activates a secrets engine (e.g., the KV engine for static secrets or the database engine for dynamic credentials). Then they write HCL policies that restrict each authenticated entity to specific paths. For example, a policy might say: 'web-server can read secret from path database/creds/webapp but cannot delete anything'. The policy is then attached to the token or role that the web server uses.
5. Test Secret Retrieval and Leasing
The application or a test script authenticates to Vault using its token, then sends a read request to the appropriate path. Vault checks the attached policy, generates or retrieves the secret, wraps it in a lease with a TTL, and returns it to the client. The administrator verifies that the secret works (e.g., the database username/password connects successfully) and that the lease expires correctly. This step confirms the entire pipeline from authentication to authorisation to secret delivery.
Let us walk through a real-world scenario at a mid-sized e-commerce company called 'ShopFast'.
The company runs its website on a cluster of 50 servers (multiple computers working together). Each server needs to connect to a central MySQL database to read product information and customer orders. Previously, the database connection string (a text string containing the database address, port, username, and password) was hardcoded into the application code. Every developer, every ops engineer, and every build server had access to that file. The password had not been changed in three years.
An IT professional implementing Vault would take the following steps:
Install Vault on a dedicated secure server (a locked-down machine with minimal network access). Configure the storage backend as a high-availability Consul cluster (a distributed key-value store that Vault uses for redundancy).
Initialise Vault, which generates the master key shards (pieces of a cryptographic key that must be combined to unlock Vault). Share these shards with five senior administrators using Shamir's Secret Sharing (a cryptographic algorithm that splits a secret into parts that must be combined to recreate it).
Write policies in HCL that define exactly what each application can do. For example, the web server's policy might allow it to read secrets only from the path 'database/creds/webapp' and renew leases for up to 24 hours.
Enable the database secrets engine (the plugin that connects to MySQL). Configure the engine with a 'root' user that Vault can use to create and delete temporary users.
Update the application code to remove the hardcoded database password. Replace it with a call to Vault's API at startup: 'GET /v1/database/creds/webapp'. The response returns a new username and password with a TTL of 1 hour.
Configure the application to renew the lease every 30 minutes. If the application fails to renew, the MySQL user is automatically dropped after 1 hour.
Set up audit logging: Vault writes every request—who authenticated, what secret they read, what time it happened—to a secure log file. The IT professional reviews these logs weekly for anomalies.
Now consider a security incident: A developer accidentally commits the application source code to a public GitHub repository. In the old system, the hardcoded database password would be exposed to the world. With Vault, there is no password in the code. The worst case is that the developer's personal Vault token (a temporary authentication credential) is exposed, but that token has a short TTL and can be revoked immediately. The database itself remains secure because the attacker cannot generate new credentials without their own valid Vault token and policy permissions.
Another daily task for the IT professional is secret rotation. Without Vault, rotating the database password would require: notifying all 50 server teams, scheduling a maintenance window, updating configuration files on each server, and restarting services. With Vault, the IT professional simply updates the configuration in the database secrets engine. The next time any server asks for a new credential, Vault generates a password from the new configuration. Existing leases continue until they expire, at which point the application gets the new password automatically. No scheduled downtime is needed.
The IT professional also uses Vault for encryption-as-a-service. For PCI DSS compliance (a security standard for credit card data), the company must encrypt stored credit card numbers. The IT professional writes a small wrapper service that accepts customer card numbers, sends them to Vault's transit engine (the encryption plugin) for encryption, stores the ciphered output in the main database, and never stores the encryption key anywhere. When the billing system needs to decrypt a card number to process a recurring charge, it sends the encrypted blob to Vault, which decrypts it only if the billing system's policy permits that path.
The VA-003 exam tests objective 1.1 through a mix of multiple-choice, multiple-select, and hot-area questions. You will be asked to identify the primary purpose of Vault, match use cases to scenarios, and distinguish Vault from other security tools.
Exam traps you must avoid:
They love testing the difference between 'secret management' and 'identity management'. Vault manages secrets, not user accounts. A trap question might describe a scenario about managing employee login passwords (like Microsoft Entra ID). The correct answer is that this is not a Vault use case—Vault is for machine-to-machine secrets, not human identity and access management (IAM).
They test that Vault dynamically generates secrets, not just stores them. A distractor answer might say 'Vault securely stores database passwords in encrypted files'. That is technically true but incomplete—the key feature is dynamic generation with automatic rotation. The exam expects you to choose the answer that mentions 'dynamic credentials with short TTLs'.
They test the 'seal / unseal' concept. A question may describe a server restart and ask what happens next. The answer: Vault starts in sealed state and requires unsealing before it can serve any secrets. They will offer traps like 'Vault automatically unseals using the stored key' or 'Vault remains unavailable until an admin manually unseals it' (the latter is wrong because multiple admins must provide their key shards; it is not a single admin).
They test that Vault supports multiple secrets engines. A question might list five types—database, AWS, SSH, PKI (public key infrastructure for certificates), and KV (key-value store for static secrets). They want you to know that Vault can handle all of these, not just one.
They test that Vault encrypts data at rest and in transit. The storage backend encrypts data before writing to disk, and all API calls use TLS (Transport Layer Security—the same encryption that secures HTTPS web traffic). They will offer options that only mention one of these protections.
Key concepts you must memorise for this objective:
Secret: any sensitive data Vault manages.
Lease: the contract granting temporary access to a secret with a fixed TTL.
Secrets engine: a plugin that manages a specific type of secret (e.g., database, AWS, KV).
Policy: HCL rules defining access permissions.
Authentication: verifying the identity of the client (using tokens, usernames/passwords, or cloud IAM like AWS IAM roles).
Audit device: a component that logs every request for compliance and security review.
Common question patterns:
'A company wants to stop storing API keys in configuration files. Which Vault feature addresses this directly?' Correct answer: dynamic secrets with TTL and automatic rotation.
'What is the primary benefit of Vault's lease system?' Correct answer: secrets automatically expire after a set time, reducing the window of exposure if a secret is compromised.
'Which of the following is NOT a valid Vault use case?' They will include something like 'storing employee HR records' or 'managing user login sessions' (those are not secrets management). The correct answer is the non-Vault option.
'During a Vault initialization, what is generated?' The master key is generated, and it is split into multiple key shards using Shamir's Secret Sharing.
Do not overthink. If a question mentions a password for a human logging into a website, that is not Vault. Vault is for automated processes (applications, scripts, microservices) that need credentials to talk to each other.
Vault centrally manages secrets by issuing them dynamically with limited lifetimes instead of storing them permanently in application code.
A lease is the temporary contract between Vault and an application that dictates when a secret expires and must be renewed.
Vault starts sealed after initialization and must be unsealed using a threshold of Shamir's Secret Sharing key shards before it can serve requests.
Policies written in HCL define fine-grained access controls over which paths and operations each authenticated client can perform.
Secrets engines are plugins that allow Vault to generate and manage different types of secrets like database credentials, SSH keys, and cloud API tokens.
Audit devices log every request to Vault for compliance, security monitoring, and incident investigation.
These come up on the exam all the time. Here's how to tell them apart.
Vault's Dynamic Secrets
Generated on demand with each request
Temporary with a configurable TTL, then automatically revoked
An application never stores the secret permanently in code
Static Secrets (e.g., Config Files)
Hardcoded or stored in a file indefinitely
No built-in expiration; must be manually changed
If leaked, the secret remains valid until someone remembers to rotate it
Vault Authentication
Verifies machine identity using tokens, certificates, or cloud IAM roles
Output is a temporary token with limited permissions
Used for automated processes, not human users
Application-Level Login (e.g., username/password form)
Verifies human identity with username and password
Output is a session cookie or JWT for web browsing
Used for human users interacting with a web interface
Sealed Vault
Cannot serve any requests—no reads, no writes
Encrypted data is inaccessible; only the seal configuration is loadable
Requires administrator intervention (providing key shards) to become operational
Unsealed Vault
Fully operational and can serve authentication and secret requests
Master key is decrypted in memory and available for encryption/decryption
Automatically transitions to sealed state if the server restarts or the process crashes
Vault Secrets Engine (Database)
Dynamically generates short-lived database usernames and passwords
Connects to the database system to create and destroy users
Leases are tightly integrated; expiration triggers actual user deletion
Vault Secrets Engine (KV - Key Value)
Stores user-provided static secrets like API keys or JSON blobs
No interaction with external systems; just stores and retrieves raw data
Leases are optional; secrets can be stored without expiration if configured
Mistake
Vault is just a password manager like LastPass or 1Password for teams.
Correct
Vault is a machine-oriented secrets management platform that dynamically generates and rotates credentials for applications and services, not primarily a human-friendly password vault.
The term 'password manager' is familiar, so beginners assume Vault fits that category. In reality, Vault's dynamic secrets and API-first design are fundamentally different from consumer password managers.
Mistake
Once Vault is installed, it starts serving secrets immediately without any setup.
Correct
Vault starts in a sealed state after initialization and must be unsealed by providing a threshold of key shards before it can process any requests.
New users expect software to work out of the box. The seal/unseal mechanism is a unique security feature that has no equivalent in most common tools, so it is a surprise.
Mistake
Vault stores secrets permanently, just like a secure file server.
Correct
Vault stores secrets temporarily through leases; secrets expire and are automatically revoked. Even static secrets in the KV engine have a configurable TTL if used with leases.
The word 'store' implies permanence. Beginners do not grasp that the core value proposition is temporary, automated credential management.
Mistake
Vault eliminates all security risks if you use it correctly.
Correct
Vault reduces the attack surface but does not eliminate all risks—poorly written policies, leaked admin tokens, or compromised Vault server infrastructure can still lead to breaches.
Marketing around 'zero-trust' and 'secure by default' leads beginners to overestimate Vault's invulnerability. It is a tool, not a silver bullet.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
No. Vault has a command-line interface (CLI) and a web UI. You can configure most features without writing code. For advanced policies and automation, knowing HCL and basic scripting helps but is not required for the VA-003 exam.
No. Vault scales down equally well. A small startup with one database and three microservices benefits from dynamic credentials even more because manual rotation is impractical for small teams.
If Vault is down, applications that have active, unexpired leases can continue using those secrets until they expire. However, new secrets cannot be issued, and existing leases cannot be renewed. That is why production deployments use high-availability mode with multiple Vault nodes.
Yes. Vault is platform-agnostic. It can manage secrets for servers in your own data centre, for virtual machines in AWS or Azure, and for Kubernetes containers—all from a single control plane.
No. Vault is a software tool that runs on standard Linux, Windows, or macOS servers. You can even run it as a container in Docker. However, for production, a dedicated server or cluster is recommended for security and performance.
You update the database secrets engine configuration with new root credentials or a new rotation schedule. Vault generates new credentials for the next request. Existing leases remain valid until they expire, at which point the application gets the new password automatically. No application restart or manual change is needed.
You've finished Introduction to Vault and Core Concepts. Continue through the VA-003 study guide to build a complete picture of the exam.
Done with this chapter?