How does Vault keep working even when one of its servers crashes? That is the exact problem storage backends and high availability solve. Without understanding this, you cannot guarantee that your applications will get their passwords and API keys when they need them, and the VA-003 exam will test you on this relentlessly.
Jump to a section
A simple way to picture Storage Backends and High Availability
Because a restaurant needs a safe, organised place to store its ingredients and recipes, it must choose between a simple pantry and a high-availability cold room.
A single, basic pantry works fine for a small café: the chef keeps all ingredients on one shelf, and if the pantry door jams, the café closes for the day. This is like a Vault storage backend using a single file on one server. When that server goes down, Vault is locked — no one can access secrets until the server is fixed.
Now picture a busy chain restaurant with dozens of kitchens. They cannot afford a single cold room failing and spoiling all their stock. Instead, they install three identical cold rooms, each independently powered and cooled. The chef can walk into any one of them and grab ingredients. If one cold room loses power, the other two still work. This is high availability (HA) for Vault: multiple servers share the same storage backend (like the central warehouse supplying all three cold rooms), so if one server fails, another instantly takes over.
The crucial detail is that the cold rooms don't store unique ingredients — they all access the same shared warehouse. Similarly, HA Vault nodes connect to a shared, highly available storage backend (like Consul, Raft, or Integrated Storage) so that a failing node never loses the keys.
Let us start with the most basic question: what is a storage backend, and why does Vault need one?
A storage backend is simply the place where Vault saves all its data. When you store a secret (like a database password) in Vault, that secret gets encrypted and written to a storage backend. When an application requests that secret, Vault reads it back from the same storage backend, decrypts it, and hands it over. You can think of the storage backend as Vault's filing cabinet — it holds everything Vault knows.
Vault itself is a stateless application, which is a fancy way of saying that Vault does not remember anything on its own. Every time Vault starts up, it has zero memory of its past life. It needs the storage backend to load all the secrets, policies, and configuration. This separation is deliberate and powerful: you can shut down a Vault server, replace it with a brand new one, and as long as it connects to the same storage backend, it picks up exactly where the old one left off.
Now, why does the VA-003 exam care about different types of storage backends? Because each type has different strengths and weaknesses, especially concerning high availability (HA).
High availability means the system stays up and working even when individual components fail. For Vault, HA is achieved by running multiple Vault server instances (called nodes) that all connect to the same storage backend. Only one node is the active leader at any moment — it handles all read and write requests. The other nodes are standby nodes: they are ready to take over if the active node fails, but they do not process requests. This setup is called an active-passive cluster.
The exam tests three main storage backends that support HA:
Consul: This is HashiCorp's own service discovery and key-value store. It is purpose-built for HA storage. Consul runs its own separate cluster (multiple Consul servers) that stores Vault's data with strong consistency and automatic failover. If a Consul server crashes, data is not lost because it is replicated across the cluster. Vault sees Consul as a highly reliable filing cabinet.
Raft (Integrated Storage): This is built directly into Vault. Instead of relying on an external system like Consul, Vault nodes themselves form a cluster and replicate data among themselves using the Raft consensus algorithm. This means you do not need to run a separate Consul cluster — Vault handles everything internally. Raft is simpler to set up for many users, but it requires you to manage the cluster size carefully (usually 3 or 5 nodes).
File + HA mode: The basic file storage backend stores everything in a single file on disk. By itself, it does not support HA at all — you cannot run multiple Vault nodes pointing at the same file because they would corrupt each other's data. However, you can pair a file backend with an external solution like a shared NFS volume and use Vault's HA mode with a separate lock mechanism. This is fragile and not recommended for production.
Why does HA matter so much in Vault? Think about what happens when Vault is down. Every application that depends on Vault to fetch its database credentials, API keys, or encryption keys will fail. If Vault is your central password manager, a crash locks the entire company out of its digital tools. HA ensures that a single server failure does not cause an outage.
The exam also tests the concept of seal and unseal in the context of HA. When a Vault node restarts, it starts in a sealed state, meaning it is locked and cannot read its storage backend. You must unseal it by providing a minimum number of unseal keys (this is the Shamir Seal mechanism). In an HA cluster, if the active node fails and a standby node takes over, that standby node must already be unsealed for the takeover to work. Otherwise, the cluster goes down. Therefore, properly configuring auto-unseal (such as using a cloud KMS or another Vault instance) is critical for true HA.
To sum up the technical picture: Vault stores encrypted data in a storage backend. Different backends (Consul, Raft, file) offer different levels of HA support. HA is achieved by running multiple Vault nodes against a shared backend, with one active leader and the rest on standby. For the exam, know the trade-offs: Consul needs a separate cluster to manage, Raft is simpler but requires careful capacity planning, and the file backend is for development only.
Choose a storage backend
Decide between file, Consul, or Raft based on your environment and HA requirements. For production with HA, choose Consul (if you already run Consul) or Raft (simpler, built-in). For learning or single-node, choose file.
Configure the storage backend in Vault's config file
Write a config.hcl file that specifies the storage stanza. For example, 'storage "raft" { path = "/vault/data" node_id = "node1" }'. This tells Vault where and how to store data.
Initialise the first Vault node
Run 'vault operator init' to generate the master key and unseal keys. This step creates the initial state in the storage backend. Only do this once; subsequent nodes will join the existing cluster.
Unseal the first node
Use 'vault operator unseal' with the required number of unseal keys (the threshold). The node is now ready to accept requests. For HA, note that this node is the initial active leader.
Join additional nodes to the cluster
On each new Vault node, start Vault with the same storage backend config but a unique node ID. Use 'vault operator raft join <leader_address>' to add it to the cluster. The leader replicates the existing data to the new node.
Unseal every standby node
Each standby node must be unsealed individually using the unseal keys (or auto-unseal). Without unsealing, they cannot take over if the leader fails. This is a common exam trap.
Imagine you work as a junior IT administrator at a mid-sized e-commerce company called ShopFast. The company uses Vault to manage credentials for all its cloud services: database passwords, AWS access keys, third-party payment gateway tokens, and SSL certificate private keys. Everything relies on Vault being available 24/7 — if Vault goes down during a Black Friday sale, the entire website could stop processing orders.
Your team has inherited a Vault setup that uses the simple file storage backend on a single Linux server. The senior engineer has just left, and you are told to make the setup highly available before the next big sale. Here is what you actually do:
Assess the current storage backend: You log into the Vault server and check the configuration file (config.hcl). You see it has 'storage "file"' with a path to a local directory. You know this cannot support multiple servers because two Vault instances writing to the same file would corrupt it. You decide to migrate to Raft Integrated Storage because your team has limited experience running Consul separately.
Set up a three-node Raft cluster: You provision two additional virtual machines (VMs) in your data centre. On each VM, you install Vault and configure the storage backend as Raft. You set the 'raft' stanza with the node ID, cluster address, and the API address. You initialise the first node and join the other two nodes to the cluster using the 'vault operator raft join' command.
Configure HA settings: In Vault's config, you enable 'ui = true' for the web UI, and you set 'api_addr' and 'cluster_addr' to the proper IP addresses so nodes can talk to each other. You also set 'disable_clustering = false' (or omit it) to allow Raft to replicate data.
Unseal each node: After each node restarts, Vault is sealed. You use the unseal keys (split across five holders) to unseal each node. You notice that if you only unseal the active node, the standby nodes remain sealed and cannot take over. You decide to implement auto-unseal using AWS KMS so that nodes automatically unseal on restart.
Test failover: You kill the active Vault process. Within seconds, one of the standby nodes is elected as the new leader. You check Vault's status using 'vault status' and confirm it is now active on the new node. Your applications never lost access because they were configured to retry connections.
Monitor cluster health: You set up monitoring alerts for cluster size and leadership changes. You notice that if two nodes go down simultaneously, the cluster becomes unavailable because Raft requires a majority (more than half) of nodes to be alive. You schedule maintenance during low-traffic periods.
The key lesson from this scenario: choosing the right storage backend and properly configuring HA is not a theoretical exercise. It requires understanding the trade-offs between simplicity (Raft) and operational overhead (Consul), and it demands practical steps like auto-unseal, majority calculations, and failover testing. The VA-003 exam expects you to know both the concepts and the commands involved.
The VA-003 exam tests storage backends and high availability in several distinct ways. First, memorise the three backends that support HA: Consul, Raft (Integrated Storage), and the file backend only when combined with an external HA mechanism (not for production). The exam loves to present a scenario and ask which backend is appropriate.
Common question types:
Scenario-based questions: 'A company wants to run Vault on a single server with no clustering. Which storage backend should they use?' The correct answer is 'file' or 'inmem' (in-memory, for dev only). They will offer Consul or Raft as distractors. Remember: file is for single-node dev/learning; Consul and Raft are for multi-node HA.
Command recall: You may be asked which command adds a Raft node to an existing cluster. The answer is 'vault operator raft join'. Do not confuse this with 'vault operator init' (initialises the first node) or 'vault operator unseal'.
Traps to watch out for: The exam might describe an HA cluster but mention that the standby nodes are not unsealed. This is a trap. For HA to work, all standby nodes must already be unsealed. Similarly, they might say 'file backend with NFS' is used for HA — this is technically possible but not recommended, and the exam correctly marks it as a poor choice.
Seal and unseal interaction: Questions often link HA with unsealing. For example: 'An HA cluster has 3 nodes. The active node crashes. Why does the cluster go down?' Possible answers: standby nodes were sealed; network partition; majority lost. The correct answer in many cases is that standby nodes were sealed.
Storage backend capabilities: Know which backends support high availability, which support replication, and which are for development only. The exam does not test every backend in existence (like Zookeeper, etcd), but it focuses on Consul, Raft, file, and inmem.
Key definitions to memorise:
Active node: The Vault instance handling all requests.
Standby nodes: Nodes that take over if the active node fails.
Quorum / Majority: For Raft, you need more than half of the nodes alive to maintain service. For a 3-node cluster, that means at least 2 nodes must be up.
Integrated Storage: Another name for Vault's built-in Raft storage backend.
Exam pattern: They often present a table of features (HA support, performance, complexity) and ask you to match the backend. Practise comparing Consul vs Raft vs file across these axes.\
Finally, be ready for questions about leadership election and failover timing. The exam does not test deep internal algorithms, but it does test that you know failover is automatic and that the active node is the only one performing writes.
Vault uses a storage backend as a persistent filing cabinet; Vault itself is stateless and forgets everything on restart.
High availability in Vault means running multiple nodes in an active-passive cluster where only the active node processes requests.
Consul and Raft (Integrated Storage) are the two production-ready storage backends that natively support high availability.
In a Raft cluster, a majority of nodes (more than half) must be alive for the cluster to function; for 3 nodes, that means at least 2 must be up.
Standby nodes in an HA cluster must be unsealed before they can take over if the active node fails.
The file storage backend is for development and single-node scenarios only; it does not support high availability without fragile external workarounds.
Auto-unseal (e.g., with a cloud KMS) is critical for true HA because it ensures nodes unseal automatically on restart.
The 'vault operator raft join' command is used to add a new node to an existing Raft cluster.
These come up on the exam all the time. Here's how to tell them apart.
Consul Storage Backend
Requires a separate Consul cluster to be managed independently of Vault
Supports external monitoring and service discovery beyond Vault
Mature and battle-tested in large-scale deployments
Raft Integrated Storage
Built directly into Vault; no separate system to maintain
Simpler to set up for teams without existing Consul experience
Uses local disk with Raft replication; in-built cluster management
Active Node
Handles all write and read requests from clients
Is the only node that can modify the storage backend
Send heartbeats to standby nodes to confirm it is alive
Standby Node
Does not process client requests directly; forwards them to the active node
Receives data replication from the active node to stay up to date
Promoted to active if the current active node fails and the standby is unsealed
File Storage Backend
Persists data to disk; survives Vault restarts
Single-node only; does not support HA natively
Suitable for development and learning
In-Memory Storage Backend
Stores data only in RAM; data lost on Vault restart
Does not support HA or any form of persistence
Intended for dev mode testing only; never for production
Mistake
Vault stores secrets directly on disk in plain text, so the storage backend must be encrypted separately.
Correct
Vault always encrypts secrets before writing them to the storage backend. The storage backend never sees plaintext secrets; it only stores encrypted ciphertext.
Beginners assume that because Vault is a security tool, it must rely on the underlying filesystem encryption. In reality, Vault performs its own encryption using its master key, making storage-level encryption optional.
Mistake
All storage backends support high availability equally well.
Correct
Only Consul, Raft (Integrated Storage), and (with caveats) file backend with external locking support HA. In-memory and simple file backends do not support HA at all.
Newcomers see 'storage backend' as a generic term and think any backend can be clustered. The exam tests the specific HA capabilities of each backend.
Mistake
In an HA cluster, every node can process read and write requests simultaneously.
Correct
In Vault's active-passive HA model, only the active node processes requests. Standby nodes accept connections but forward them to the active node. This is not a true active-active setup.
People familiar with web servers (which often run active-active) assume Vault works the same way. Vault uses active-passive to avoid conflicts over secret versioning and lease tracking.
Mistake
If the active node fails, any standby node automatically takes over even if it is sealed.
Correct
A standby node must be unsealed to become active. If all standby nodes are sealed, the cluster becomes unavailable after the active node fails.
The unsealing process is often misunderstood as a one-time setup. Beginners think once a node is part of the cluster, it is automatically ready. In reality, unsealing must happen after each restart.
Mistake
Raft Integrated Storage requires an external database like PostgreSQL or MySQL.
Correct
Raft Integrated Storage is built into Vault and uses local disk storage with replication between nodes. It does not require any external database.
The term 'storage backend' makes people think of traditional databases. Raft is a consensus algorithm, not a database. It writes to local files and replicates them across the cluster.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A storage backend is where Vault saves encrypted secrets. A seal mechanism protects the master key that decrypts those secrets. They are separate: you can use Consul for storage and AWS KMS for auto-unseal.
Technically yes, but only if you combine it with an external shared filesystem (like NFS) and an external HA tool. This is fragile and not recommended for production. The exam treats file backend as single-node only.
Minimum 3 nodes, but 5 is safer. You need an odd number to ensure a majority can be reached. With 3 nodes, you can lose 1. With 5 nodes, you can lose 2.
Secrets are safe because they are encrypted in the storage backend. Once you restart the cluster and unseal, the data is accessible. However, Vault will be unavailable until quorum is restored.
No. While Consul was historically the primary backend for HA, Vault now includes Integrated Storage (Raft) which does not require any external system.
No, not by default. Standby nodes forward all requests to the active node. However, the performance standby feature (introduced later) allows some nodes to serve reads for high-throughput scenarios, but this is not part of the basic HA model tested on VA-003.
You've finished Storage Backends and High Availability. Continue through the VA-003 study guide to build a complete picture of the exam.
Done with this chapter?