CCNA Fault Tolerant Vault Environments Questions

This is correct. In a three-node Raft cluster, quorum is two nodes. As long as two nodes are running and can communicate, the cluster can elect a leader and commit writes. The third node can be down without affecting write availability. This is the fundamental principle of Raft consensus: a majority is required for progress.

The load balancer fronts the cluster, directing client traffic to the active node and health-checking standby nodes. It satisfies the HA requirement by removing the single address dependency, so failover is transparent to clients without reconfiguration.

When a node is removed from the Raft configuration due to prolonged absence, it must be manually rejoined. Running `vault operator raft join` on vault-3 with the leader's API address will add it back as a follower. This is the correct and documented procedure for re-adding a node that was previously part of the cluster but was removed.

Deploying one node per availability zone ensures that if one zone fails, the remaining two nodes are in different zones and can still form a quorum (2 out of 3). This provides fault tolerance for a single zone failure. This distribution is a common best practice for high availability in cloud environments, as it minimizes the impact of a zone outage.

Promotion leaves the secondary's nodes serving reads only until clients are redirected; the DR secondary's advertise addresses and any load balancer targets still reference the lost primary. Repointing the load balancer restores write traffic to the promoted cluster, satisfying the stem's requirement to regain full functionality immediately after promotion.

Integrated Raft storage achieves high availability by having multiple Vault nodes join one Raft cluster, electing an active node and maintaining replicated state through consensus, so standby nodes can take over if the active fails.

This command instructs the Vault node to join the Raft cluster by contacting the specified leader or any existing peer. It is the correct method to rejoin a node after it has been offline or removed. The command does not disrupt the existing cluster and will add the node as a follower, allowing it to catch up on the Raft log.

api_addr advertises the address that clients and other cluster peers should use to reach this node. Changing it alters that advertised endpoint, so redirects, request forwarding and peer communication target the new address rather than the storage backend itself.

A Performance Replication secondary cluster is designed to be read-only for replicated data and will reject write requests to replicated paths unless it is promoted. It can still serve reads and handle local writes to non-replicated mounts if configured. Therefore, no action is needed to prevent writes to replicated data during the primary's downtime.

Vault Enterprise does not automatically prevent a performance secondary from serving reads based on lag. The recommended practice is to monitor replication status via the API endpoint `sys/replication/performance/status`, which shows the lag in WAL entries. If the lag is too high and stale reads are unacceptable, you should redirect clients to the primary until the secondary is sufficiently caught up. This ensures data consistency.

Running `vault operator raft remove-peer` directly on a surviving node removes the dead server from the Raft configuration without requiring the failed node to be online. This satisfies the stem's constraint: the peer is unreachable, so removal must be performed from a healthy cluster member rather than the dead node itself.

A performance standby shares the primary's replicated data and handles read-only requests locally, including token checks, thereby scaling read throughput without forwarding every call. Writes are still forwarded to the primary, preserving a single write authority.

Replication lag directly indicates whether the secondary is keeping pace with the primary. Sustained lag risks stale data and failed promotions, so continuously monitoring these metrics lets operators detect degradation early and remediate before a DR event exposes the gap.

A Raft cluster requires a quorum of (N/2)+1 nodes to elect a leader and commit writes. With 3 nodes, quorum is 2, so the cluster can tolerate the failure of 1 node. This meets the requirement of tolerating a single node failure while maintaining availability. Two nodes would not provide fault tolerance because losing one node would leave only one node, which cannot form a quorum (quorum of 2 is 2). Therefore, 3 is the minimum.

The storage backend provides the coordination primitive: Consul sessions and key-value locks let nodes compete for a lock, so only the holder becomes active leader. This satisfies the single-leader constraint, since Vault itself has no quorum mechanism of its own.

HA replication forwards performance standby nodes to share request load within a primary cluster, while DR replication asynchronously replicates data to a separate secondary cluster for failover. This satisfies the stem's distinction: HA addresses throughput and availability locally, whereas DR addresses data durability and recovery across regions.

Setting `api_addr` correctly advertises the cluster's client-facing API endpoint, which the performance secondary and other clusters use to forward requests. Without a reachable value, cross-cluster request forwarding fails, so verifying it satisfies the stem's requirement for reliable inter-cluster communication across the Vault deployment.

A DR secondary holds its own root key and unseal keys, separate from the primary, so its seal status is independent. Divergent seal status therefore simply reflects that the secondary has not been unsealed locally, which is required before replication can proceed.

In Performance Replication, secondary clusters can service read requests locally but cannot accept writes. When a write request is received by the secondary, it is forwarded to the primary cluster over the replication connection. The primary processes the write, and the change is then replicated back to the secondary. This ensures data consistency and a single source of truth for writes.

The isolated nodes cannot communicate with the leader or the rest of the cluster. Without a quorum, they cannot elect a new leader and will not accept writes or reads. They will continue to attempt to reconnect and will rejoin the cluster once the network partition is resolved, synchronizing any missed logs.

This is correct. When a Raft node's storage is wiped or replaced, it loses its Raft state and cannot automatically rejoin. The 'vault operator raft join' command is used to join a node to an existing Raft cluster by providing the leader's API address. The node will then receive the current Raft configuration and catch up on the log. This is the documented procedure for adding or rejoining a node with empty storage.

Performance Standby nodes handle read-only operations locally while forwarding write requests to the active primary, satisfying the stem's requirement for true statements about their behaviour. This forwarding mechanism preserves a single writer for data consistency, letting standby clusters serve reads without duplicating write authority across the replication set.

Raft replication traffic between clusters flows over the cluster port 8201, while 8200 carries the API and request forwarding. Both must be open bidirectionally so the secondary can receive replication streams and serve client requests.

After a partition, nodes that were isolated may not automatically rejoin if they fell behind or lost their configuration. Running `vault operator raft join` on each isolated node with the leader's API address forces them to rejoin the cluster and catch up. This is the documented procedure for adding or re-adding nodes to a Raft cluster and minimizes downtime because the active cluster continues serving requests.

After promoting the DR secondary, the new primary can generate a new activation token for a new DR secondary. You then deploy a new Vault cluster in Region A, configure it with the same storage backend and seal, and use the token to enable DR replication. This establishes a new DR relationship and ensures data is replicated to the new secondary.

The `vault operator raft join` command is used to join a node to an existing Raft cluster. You must specify the API address of a node that is already a member of the cluster, typically the leader. Running this on vault-2 and vault-3 will add them as followers. This is the standard procedure for adding nodes to a Vault Raft cluster after initialization.

Raft requires a strict majority of voting nodes to commit entries and elect a leader. Losing more than half the voters halts writes and leader election, directly satisfying the stem's quorum-loss condition. Non-voting or standby nodes do not count towards this majority, so their survival cannot prevent quorum loss.

Before promotion, the secondary must be unsealed and operational. A valid license with Performance Replication is required for the secondary to function as a replication target and to be promoted. Without these, the promotion will fail or the cluster may not operate correctly.

Raft requires a quorum of (n/2)+1 nodes to elect a leader and commit writes. Three nodes tolerate one failure while retaining quorum, satisfying the stem's fault-tolerance constraint; two would lose quorum on any single failure.