VA-003 Sealed State Practice Question
A Vault cluster uses performance replication. A performance standby node is not responding to read requests. What is the most likely cause?
⚠ Common exam trap
Candidates often overlook that performance standby nodes must be unsealed to serve any requests, assuming they can serve reads even when sealed because they hold replicated data. In reality, Vault requires a node to be unsealed to perform any operation.
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 performance standby node is sealed.
The performance standby node is sealed. In Vault, a sealed node cannot serve any requests, including read requests. Since the cluster uses performance replication, the standby node should be able to serve reads if it is unsealed. The fact that it is not responding indicates it is likely sealed. Other options are less likely: A is false because the cluster uses performance replication; B, a firewall blocking inbound traffic would cause no response but is less common; D, inability to connect for writes would affect write forwarding but reads should still work from local data.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Performance replication is not configured on this cluster.
Why it's wrong here
The stem states the cluster uses performance replication, so this contradicts the given scenario rather than explaining the standby's silence. It is tempting because an unconfigured secondary would indeed refuse reads, but that applies when replication was never enabled, not when a configured standby stops responding.
- ✗
The firewall is blocking inbound traffic to the standby node.
Why it's wrong here
A firewall blocking inbound traffic would prevent client connections to the standby's API listener, producing exactly the reported unresponsiveness. It is tempting because network filtering is a common cause of unreachable nodes, and it would be the answer if the standby were reachable from other nodes but not from clients.
- ✓
The performance standby node is sealed.
Why this is correct
A sealed performance standby node cannot serve read requests because its barrier is active and its storage and API access are locked. Unsealing it restores read serving, which is the specific condition preventing responses here.
- ✗
the performance standby node cannot connect to the primary for writes.
Why it's wrong here
Performance standby nodes serve reads locally and forward writes to the primary; inability to reach the primary for writes would not stop read requests being answered. It is tempting because write forwarding is part of the replication design, but that mechanism concerns write operations, not the read path the stem describes.
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.