Task 8.1: Explain cluster strategy for self-managed and HashiCorp-managed Vault clusters

• AThree voting servers, one in each zone

  Incorrect

  Three servers tolerate only one failure.

• BFour voting servers, two in each of two zones

  Incorrect

  Four servers need three for quorum, so they tolerate one failure, and losing a zone with two leaves no quorum.

• CSix voting servers, two in each zone

  Incorrect

  Six tolerate two failures, but five already do, and HashiCorp recommends an odd number of servers.

• DFive voting servers, two in each of two zones and one in the third

  Correct

  Five servers need three for quorum and tolerate two failures, and losing any zone removes at most two.

Quorum is a majority of voters, so failure tolerance grows only with odd sizes: 3 tolerate 1, 5 tolerate 2. Spread the voters so that no zone holds more servers than the cluster can lose.

• AThe standby applies the write itself and syncs the active node later

  Incorrect

  Only the active node handles requests that change data.

• BThe standby rejects it with an error and drops the connection

  Incorrect

  Standbys pass requests on rather than refusing them.

• CThe write is split across all three nodes

  Incorrect

  There is one active node at a time; requests are not split.

• DIt forwards the request to the active node, or redirects there

  Correct

  Standby nodes either forward requests or redirect clients to the active node.

High availability in Vault means one active node and hot standbys ready to take over.

• ABoth clusters scale themselves automatically as the traffic grows

  Incorrect

  Neither scales by itself; HCP offers a scaling action.

• BHCP: portal or Terraform; self-managed: the team's own work

  Correct

  HCP Vault Dedicated scales cluster size dynamically; self-managed Vault has no built-in feature for it.

• COnly self-managed clusters can change size after creation

  Incorrect

  HCP clusters can be scaled up or down.

• DHCP clusters scale only by adding performance standbys that the team runs

  Incorrect

  In HCP the team does not run nodes.

Managed clusters move capacity work to HashiCorp; self-managed clusters keep it with the operators.

• AIt uses its own seal type, since Raft replicates the root key in plaintext

  Incorrect

  Joining uses an encrypted challenge that needs the shared seal.

• BIt is initialized with vault operator init first

  Incorrect

  Only the first node is initialized; others join it.

• CIts seal configuration matches the cluster's, and it joins via retry_join

  Correct

  All nodes in a Raft cluster must share the same seal configuration, and nodes join via retry_join or vault operator raft join.

• DIt points its storage stanza at the leader's data directory

  Incorrect

  A joining node does not use another node's data directory.

With auto unseal the join challenge is answered automatically; with Shamir the joining node needs the unseal keys.

• APerformance standby nodes for non-mutating requests

  Correct

  Performance standbys handle reads and other non-mutating requests such as transit encryption.

• BPlain standby nodes, which answer reads in every edition

  Incorrect

  Without the Enterprise feature, standbys do not answer requests themselves.

• CA second active node elected for reads

  Incorrect

  A cluster has one active node.

• DDR replication, whose secondaries serve local reads

  Incorrect

  DR replication copies data to another cluster; it does not spread load within this one.

Performance standbys scale reads within one cluster; performance replication scales across clusters.