HashiCorp Vault Associate (003) Question 184
Single answer7 Vault architecture fundamentalsA company runs Vault in production with three server nodes using integrated storage (Raft). One node is the active leader and the other two are standby nodes behind a load balancer. During a maintenance window, the active node is stopped unexpectedly. Application teams report that secret reads continue to work after a brief interruption, and the security team wants to understand what happened in Vault's architecture. Which statement best explains this behavior?
- A
A standby node was automatically elected as the new active node through Raft leader election, allowing Vault service to resume once the failover completed.
- B
The load balancer promoted itself to the new Vault leader and redirected all requests to the remaining nodes.
- C
Because all Vault nodes are active in integrated storage mode, either standby node could continue serving all requests without any leadership change.
- D
Vault clients automatically switched to using the Raft storage backend directly, so service continued even though no Vault node was active.
Show answer and explanation
Correct answer: A
Explanation
This question tests a key Vault architecture concept: the difference between Vault's active/standby server model and its storage backend. With integrated storage, Vault uses Raft for both storage and consensus. In a multi-node cluster, one node is active and the others are standby from the Vault service perspective, even though all participate in Raft replication. If the active node fails, the cluster elects a new leader and that node becomes active. During this transition, clients may observe a short disruption until failover completes. This aligns with HashiCorp documentation on high availability and integrated storage: Vault remains an active/standby system, while Raft provides replicated storage and leader election for the cluster.
- A. Correct.
Correct. In a Vault cluster using integrated storage (Raft), the cluster maintains consensus among nodes and one node acts as the active Vault server. If the active node fails, the remaining nodes participate in leader election. Once a new leader is elected, that node becomes active and resumes handling client requests. A brief interruption is expected while failover occurs.
- B. Incorrect.
Incorrect. A load balancer does not participate in Vault's cluster coordination or Raft consensus. It can route traffic to healthy Vault nodes, but it cannot become a Vault leader or promote nodes. This option reflects a common misunderstanding between traffic distribution and application-level leader election.
- C. Incorrect.
Incorrect. In Vault, standby nodes do not behave as fully active nodes for normal request processing. Even in integrated storage deployments, Vault still has an active/standby operational model. Leadership matters because one node must be active to handle most client operations. The misconception here is confusing the distributed storage layer with all nodes actively serving Vault API traffic in the same way.
- D. Incorrect.
Incorrect. Vault clients do not communicate directly with the Raft storage backend. Clients talk to the Vault API exposed by Vault server nodes. Raft is an internal storage and consensus mechanism used by the cluster. If no active Vault node exists, clients cannot bypass Vault and access secrets by talking to Raft directly.