HashiCorp Vault Associate (003) Question 183
Single answer7 Vault architecture fundamentalsA company runs a three-node Vault cluster in production with integrated storage (Raft). During a maintenance window, the current active node is shut down for patching. The application team reports that reads and writes to secrets resume after a brief interruption, but one administrator notices that requests sent directly to the patched node fail until it fully rejoins the cluster. Which statement best explains this behavior?
- A
Vault automatically elects a new active node from the remaining nodes, and standby nodes can redirect client requests to the active node while the patched node is offline or rejoining.
- B
All Vault nodes in a Raft cluster can process writes at any time, so the interruption indicates a storage backend failure rather than normal failover behavior.
- C
When the active node goes down, Vault becomes unavailable until an operator manually promotes a standby node to active using the vault operator step-down command.
- D
Integrated storage removes the need for active/standby behavior, so clients should be able to use any node directly for all operations even while a node is restarting.
Show answer and explanation
Correct answer: A
Explanation
This question tests a core Vault architecture concept: HA request handling is separate from storage replication. In Vault Enterprise and OSS HA deployments using integrated storage, Raft provides replicated storage and leader election for the storage layer, but Vault still exposes one active node for servicing requests while other nodes remain standby. If the active node is lost and quorum remains, Vault automatically fails over to a new active node. Standby nodes generally redirect clients to the active node rather than acting as equal read/write endpoints. Best practice is to place Vault behind a load balancer or use client logic that follows redirects. This behavior is documented in HashiCorp Vault HA and integrated storage guidance, which distinguishes active/standby service behavior from the underlying Raft cluster mechanics.
- A. Correct.
Correct. In a Vault HA cluster, only one node is active at a time, while the others are standby nodes. With integrated storage (Raft), if the active node becomes unavailable, the remaining cluster members can elect a new leader and Vault can promote a new active node automatically, assuming quorum is maintained. Standby nodes do not independently service all requests like fully active peers; instead, they typically redirect clients to the active node. A node that is offline or still rejoining the cluster cannot serve requests until it is back and functioning normally.
- B. Incorrect.
Incorrect. This reflects a common misconception between Raft replication and request handling. Even though Raft replicates storage across nodes, Vault still uses an active/standby architecture for request processing in standard HA operation. Not every node accepts writes at all times. A brief interruption during leadership transition is expected behavior during failover and does not by itself indicate a storage backend failure.
- C. Incorrect.
Incorrect. Vault does not require a manual promotion step during normal HA failover. The vault operator step-down command is used to force the current active node to step down, not to manually promote a specific standby. In a healthy integrated storage cluster with quorum, a new active node is elected automatically.
- D. Incorrect.
Incorrect. Integrated storage changes the storage backend by using Raft, but it does not eliminate Vault's active/standby architecture. Clients cannot assume that every node will directly process all operations. In practice, requests should go through a load balancer or be sent to a node that can redirect to the current active node.