A school district runs a three-member etcd cluster and two members fail. What is the expected impact on cluster API availability?
Select an answer to reveal the explanation.
Short Explanation
Three mayors need a majority of two to vote. Lose two and the last mayor cannot pass motions alone—etcd quorum works the same way, and the API goes dark for safe consensus.
Full Explanation
etcd requires quorum—a majority of members—to commit consensus. In a three-member school-district etcd cluster, majority is two. If two members fail, only one remains, quorum is lost, and etcd cannot safely serve consistent reads/writes; the Kubernetes API depending on that etcd becomes unavailable for reliable operations. One surviving member does not retain quorum in a three-member ensemble; majority of three is two, so a lone member cannot pass consensus alone. Losing two etcd members is not limited to Ingress controllers; it strikes the cluster datastore and therefore the API’s consistent operation, far beyond Ingress alone. Quorum loss is not confined to kubectl top; metrics may also fail, but object creates and many reads/writes are blocked or unsafe—do not minimize the blast radius to metrics. Exam caveat: Even numbers of members are awkward for majority math; production HA commonly uses three or five. Learners sometimes confuse “replica count” with “quorum.” Remember: majority, not “any survivor.” Operational check: Monitor etcd member health, restore failed members from known-good backups if data is suspect, bring members back until quorum returns, and verify API writes succeed again before declaring the district control plane healthy.