VA-003 Explain Vault architecture Practice Question
A Vault cluster configured with auto-unseal using AWS KMS is deployed across two availability zones. After a network partition, the standby node remains sealed while the active node is unsealed and serving requests. What is the most likely reason the standby cannot unseal?
⚠ Common exam trap
Many candidates confuse the cluster replication traffic (which uses the cluster address) with the auto-unseal traffic (which uses outbound HTTPS to AWS KMS), leading them to incorrectly select Option C.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
The standby node cannot communicate with AWS KMS due to the network partition.
In a Vault cluster with auto-unseal via AWS KMS, each node must independently communicate with AWS KMS to unseal itself. A network partition that isolates the standby node from AWS KMS prevents it from reaching the KMS endpoint, so it cannot decrypt its unseal key and remains sealed. The active node is unaffected because it is already unsealed and serving requests from the other side of the partition.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The standby node is using the wrong AWS region configuration.
Why it's wrong here
A wrong region would prevent unsealing from the outset, yet the node operated before the partition, so its KMS configuration was already valid. It is tempting because region mismatch is a common auto-unseal misconfiguration, and would be correct if the node had never successfully unsealed since deployment.
- ✗
The active node consumed all available KMS API quota for the region.
Why it's wrong here
KMS throttling would affect the active node too, since both nodes call the same regional endpoint, so it cannot explain why only the standby stays sealed. It is tempting because quota exhaustion is a real auto-unseal failure mode, and would be correct if unsealing were failing intermittently across the whole cluster.
- ✗
The cluster address on the standby is misconfigured.
Why it's wrong here
The cluster address governs Raft peer communication and request forwarding, not the KMS unseal call, so a misconfiguration there leaves the seal mechanism unaffected. It is tempting because cluster address errors are a frequent Vault misconfiguration, and would be correct if the standby failed to join the Raft cluster rather than to unseal.
- ✓
The standby node cannot communicate with AWS KMS due to the network partition.
Why this is correct
Auto-unseal delegates the unseal key to AWS KMS, so each node must reach KMS at startup or after resealing. The partition blocks the standby's KMS calls, leaving it sealed, while the active node already holds its unsealed state and continues serving.
Go deeper
Related to this question
About these practice questions
This VA-003 question is part of Courseiva's 366-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This VA-003 practice question is part of Courseiva's free HashiCorp certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the VA-003 exam.