HashiCorp Vault Associate (003) Question 182
Single answer7 Vault architecture fundamentalsA company is deploying Vault for a production application that runs in a single region. The security team wants Vault to remain available during the loss of one server, and they want to avoid introducing external dependencies for storage. They plan to run three Vault nodes and need a design that supports high availability with automatic leader election. Which storage backend should they choose?
- A
Integrated Storage using Raft
- B
File storage on each Vault node
- C
In-memory storage
- D
Local file storage shared with rsync between nodes
Show answer and explanation
Correct answer: A
Explanation
Vault requires a storage backend that supports its operational goals for durability and, in HA deployments, coordinated access and leader election. For a production deployment that wants to avoid external storage dependencies, Integrated Storage using Raft is the appropriate choice. Raft is built into Vault and provides replicated, durable storage and HA behavior. A three-node Raft cluster is a common architecture because it allows the cluster to continue functioning after one node failure while preserving quorum. By contrast, file and in-memory storage do not meet production HA requirements, and manually syncing files between nodes is not a supported or safe HA design. This aligns with HashiCorp guidance that Integrated Storage is a first-class production storage backend and supports HA natively.
- A. Correct.
Correct. Integrated Storage with Raft is the recommended built-in storage option for many production Vault deployments. It provides durable storage, supports high availability, and uses Raft consensus for leader election and replication across Vault nodes without requiring a separate external data store. With three nodes, the cluster can tolerate the loss of one node and continue operating as long as quorum is maintained.
- B. Incorrect.
Incorrect. File storage is suitable for development or single-node scenarios, but each node's local file storage is independent and does not provide coordinated HA, replication, or leader election across nodes. Using file storage on multiple nodes would not create a true Vault HA cluster.
- C. Incorrect.
Incorrect. In-memory storage is non-persistent and intended only for testing or development. Data is lost on restart, and it is not appropriate for production durability or HA requirements.
- D. Incorrect.
Incorrect. Synchronizing local files with rsync does not provide the consistency, locking, transaction handling, or quorum-based coordination required for Vault HA. This is a common misconception: copying backend files between servers does not make a storage backend HA-safe for Vault.