VA-003 Explain Vault architecture Practice Test 1 — 15 Questions

Question 1

During a performance test, Vault becomes unresponsive for several seconds when the storage backend experiences high latency. Which architectural change would best improve Vault's resilience to storage latency?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

Configure Performance Standby nodes. Performance Standby nodes are designed to handle read requests and can serve as hot standbys that take over active duty if the primary node becomes unresponsive due to storage backend latency. They maintain a local copy of the data via replication, allowing them to continue serving requests without waiting for the slow storage backend, thus improving resilience to high-latency storage conditions.

Answer

Add more storage backend nodes

Answer

Disable storage replication

Answer

Increase the number of Vault nodes without replication

Question 2

A company is using Vault's Integrated Storage (Raft) for high availability. During a network partition, two Vault nodes become isolated from the third. What happens to the isolated nodes?

Accepted Answer

The two isolated nodes continue to serve requests, the third stops. In Vault Integrated Storage (Raft), a quorum of nodes (majority) is required to maintain cluster leadership and serve requests. During a network partition where two nodes are isolated from the third, the two nodes form a majority (2 out of 3) and can continue to serve requests, while the isolated third node loses quorum and stops serving requests to prevent split-brain. This behavior is enforced by the Raft consensus algorithm, which requires a majority for any write or read operations to ensure consistency.

Answer

All three nodes automatically rejoin after partition

Answer

All three nodes continue to serve requests

Answer

The two isolated nodes stop serving requests

Question 3

An administrator notices that after a Vault unseal operation, the root token is no longer usable. The audit logs show no revocations. What is the most likely cause?

Accepted Answer

The root token's TTL expired during unseal. Root tokens can be generated with a configurable TTL. If the TTL is set to a short duration, it may expire during the unseal process, making the token unusable. The audit logs show no revocations because expiration is not a revocation event.

Answer

The root token was revoked during unseal

Answer

The root token's policy was removed

Answer

The root token was stored in memory only and lost on seal

Question 4

A team wants to use Vault's AWS auth method to authenticate EC2 instances. Which architectural requirement must be met?

Accepted Answer

Vault must be able to reach the AWS metadata endpoint. The AWS auth method in Vault authenticates EC2 instances by verifying the instance's identity via the AWS metadata endpoint (http://169.254.169.254/latest/meta-data/). Vault must be able to reach this endpoint to retrieve the instance's PKCS7 signature, instance ID, and account ID, which are used to validate the instance's IAM role and ensure it matches the configured auth role. Without network access to the metadata endpoint, Vault cannot perform the cryptographic verification required for authentication.

Answer

Each EC2 instance must have an IAM role attached

Answer

Vault must have AWS API credentials configured

Answer

Vault must be deployed on an EC2 instance in the same region

Question 5

Which TWO components are required for Vault to process client requests after startup?

Accepted Answer

Unseal key shares. C is correct because Vault starts in a sealed state and requires a threshold of unseal key shares to reconstruct the master key and decrypt the storage backend. Without unsealing, Vault cannot access any data or process client requests. E is correct because an enabled auth method is necessary to authenticate clients; Vault rejects all unauthenticated requests by default.

Answer

Audit Device

Answer

A policy

Answer

A secrets engine

Question 6

Which THREE architectural considerations are important when designing a multi-datacenter Vault deployment?

Accepted Answer

Use separate storage backends per datacenter. Each datacenter must maintain its own independent storage backend to avoid a single point of failure and ensure data isolation. Option D is correct because Performance Replication enables local reads by replicating data from the primary cluster to secondary clusters, reducing read latency. Option E is correct because Disaster Recovery Replication provides failover capability, replicating data asynchronously to a standby cluster for disaster recovery. Together, these three considerations ensure high availability, low latency, and resilience in a multi-datacenter Vault deployment.

Answer

Use a single storage backend across datacenters

Answer

Deploy a single Vault cluster spanning datacenters

Question 7

An organization uses Vault with a Consul storage backend. They have three Vault servers and three Consul servers. During a routine maintenance, they restart all Consul servers simultaneously. After the restart, Vault becomes sealed and cannot be unsealed. The Vault logs show 'storage: error listing' and 'failed to check status'. The Consul cluster is healthy with a leader. What is the most likely cause and solution?

Accepted Answer

Restore Vault's storage backend from a recent backup. When all Consul servers are restarted simultaneously, the Vault storage backend (Consul) may lose critical metadata or consistency state that Vault relies on to maintain its seal/unseal status. Even though the Consul cluster appears healthy with a leader, the underlying data corruption or loss of key-value entries (such as the barrier key or storage index) prevents Vault from reading its storage, causing it to seal and fail to unseal. Restoring Vault's storage backend from a recent backup is the correct solution because it recovers the consistent state of the data, including the encrypted master key and configuration, without requiring re-initialization.

Answer

Re-initialize Vault and generate new unseal keys

Answer

Generate a new root token using unseal keys

Answer

Use the unseal keys to unseal Vault again

Question 8

Which of the following are valid ways to authenticate to Vault? (Select all that apply.)

Accepted Answer

SAML 2.0. Vault supports SAML 2.0 as an auth method (A), allowing browser-based single sign-on through an identity provider via the /auth/saml endpoint. GitHub personal access tokens are valid credentials for the GitHub auth method (B), which maps GitHub org/team membership to Vault policies. Kubernetes auth (C) is a first-class Vault auth method that validates a pod's service account JWT against the Kubernetes TokenReview API. LDAP authentication (D) is also a native Vault auth method that binds to an LDAP server to verify usernames and passwords. AWS EC2 instance metadata (E) is not itself an auth method; it is only an input used by the AWS auth method's ec2 login, so it is not a valid standalone way to authenticate to Vault.

Answer

AWS EC2 instance metadata

Question 9

A company runs Vault in a single cluster with three nodes using the Raft storage backend. The nodes are behind a load balancer that distributes traffic to all nodes. The operations team notices that occasionally, write operations (e.g., writing a secret or creating a policy) fail with a '502 Bad Gateway' error, while read operations succeed. The Vault audit logs show no errors. The load balancer health checks are configured to check the /v1/sys/health endpoint with a 200 response expected. The Vault nodes are all unsealed and the cluster is healthy. Which of the following is the most likely cause of the intermittent write failures?

Accepted Answer

The load balancer is sending write requests to standby nodes, which cannot handle writes.. In a Vault cluster with Raft storage, only the elected leader node can handle write operations (e.g., writing secrets, creating policies). Standby nodes serve read requests and forward writes to the leader. If the load balancer distributes traffic to all nodes without considering leadership, write requests sent to a standby node will fail with a 502 Bad Gateway error because the standby cannot process the write locally and the load balancer may not properly handle the forwarded response or timeout.

Answer

The Raft storage backend does not support write operations.

Answer

The load balancer is not configured to use the /v1/sys/leader endpoint for routing.

Answer

One of the Vault nodes is sealed, causing write requests to fail.

Question 10

A company wants to use Vault's Key Management Secrets Engine (KMSE) to encrypt data stored in AWS S3. The security team requires that the encryption key used by Vault is never exposed to the application. Which Vault architecture component ensures that the encryption key remains within the Vault boundary and is not accessible to the application?

Accepted Answer

Vault's Transit Secrets Engine. Transit Secrets Engine performs encryption/decryption using keys stored entirely within Vault. The application sends data to Vault, which processes it with the key and returns the result, ensuring the key is never exposed. KMSE (B) delegates key storage to an external KMS, placing the key outside Vault's boundary, which contradicts the requirement that the key remains within Vault.

Answer

Vault's Cubbyhole Response Wrapping

Answer

Vault's Key Management Secrets Engine (KMSE)

Answer

Vault's PKI Secrets Engine

Question 11

Which TWO statements correctly describe Vault's storage backend and seal/unseal mechanism?

Accepted Answer

During unseal, the unseal key is used to decrypt the master key which then decrypts the storage backend.. Option A is correct because during the unseal process, each unseal key share is used to reconstruct the master key (via Shamir's secret sharing), and the master key is then used to decrypt Vault's encryption key, which in turn decrypts data in the storage backend. Option C is correct because the storage backend is where Vault persists its encrypted data, and it is responsible for durability and high availability of that data, not for encryption or sealing. Option B is incorrect because Shamir's secret sharing splits the unseal key (root key), not the master key, into key shares. Option D is incorrect because sealing and unsealing are handled by Vault's core, not the storage backend. Option E is incorrect because a newly elected leader in a Vault cluster does not automatically unseal itself; unsealing requires the configured threshold of unseal key shares to be provided.

Answer

Shamir's secret sharing splits the master key into key shares.

Answer

The storage backend is responsible for sealing and unsealing Vault.

Answer

In a Vault cluster, when a new leader is elected, it automatically unseals itself.

Question 12

A company requires that Vault's master key be split into multiple key shares and distributed to different administrators using Shamir's Secret Sharing. They also need to ensure that Vault can automatically unseal if a majority of shares are provided but cannot rely on manual intervention. Which unseal approach should they configure?

Accepted Answer

Configure Shamir seal with a threshold and use unseal keys via a key provider. Shamir seal (also known as the 'seal' wrapping mechanism) allows Vault to use Shamir's Secret Sharing to split the master key into shares, and then automatically unseal by providing those shares via a key provider (e.g., a cloud KMS or HSM) without manual intervention. This satisfies the requirement of splitting the key among administrators while enabling auto-unseal when a majority of shares are available.

Answer

Store the master key in the transit secrets engine and unseal automatically

Answer

Use AWS KMS as a seal for auto-unseal

Answer

Use a single unseal key stored in a password manager and manually unseal

Question 13

A security team needs to audit all interactions with Vault, including requests that are denied due to policy violations. They want to ensure that even if the audit device is full, Vault does not halt operations. Which audit device configuration should they recommend?

Accepted Answer

File audit device with blocking=false and fallback path configured. The file audit device with `blocking=false` ensures that Vault does not block requests when the audit log cannot be written, preventing denial of service. The fallback path provides a secondary location to continue logging if the primary path fails, maintaining audit coverage without halting operations.

Answer

Socket audit device with a remote log aggregator

Answer

File audit device with blocking=true and a separate backup file

Answer

Syslog audit device with local syslog server

Question 14

An operator notices that after a network partition, a Vault cluster with integrated storage (Raft) has a node that is unreachable and does not automatically rejoin. The cluster has 5 nodes with a minimum quorum of 3. What is a likely cause for the node not rejoining?

Accepted Answer

The cluster may have lost quorum due to other nodes also being down. In a Raft-based Vault cluster with 5 nodes and a quorum of 3, if a node becomes unreachable due to a network partition and does not automatically rejoin, the most likely cause is that additional nodes are also down or unreachable, causing the cluster to lose quorum. Without a majority of nodes (3 out of 5) able to communicate, the Raft consensus protocol cannot elect a leader or process log entries, so the isolated node cannot rejoin because the cluster itself is in a degraded state. The node not rejoining is a symptom of the broader quorum loss, not an isolated issue with that node.

Answer

The node's raft index is ahead of the leader's

Answer

The node's clock skew is causing Raft timeouts

Answer

The node must be manually removed from the raft configuration and re-added

Question 15

A Vault administrator creates a policy that grants 'read' and 'list' on 'secret/data/engineering/*' for a group. However, users in that group cannot read 'secret/data/engineering/project/db_password'. What is the most likely issue?

Accepted Answer

The policy path is incorrect; KV v2 requires 'secret/data/engineering/*' for read access. The policy grants 'read' and 'list' on 'secret/data/engineering/*', which is correct for accessing secret data in KV v2. However, to read a KV v2 secret, the Vault API also requires access to the corresponding metadata path ('secret/metadata/engineering/*') to resolve version information. Without the metadata path capability, the read operation fails. None of the provided options correctly identify this issue. Option A incorrectly states that the path 'secret/data/engineering/*' is incorrect for read access, which is not true. Option B suggests a different mount path without evidence. Option C incorrectly requires 'update' capability. Option D introduces an unrelated namespace issue.

Answer

The secret is stored in a different mount path

Answer

The policy is missing 'update' capability for the path

Answer

The users are in a different namespace that doesn't inherit the policy