etcd as the cluster source of truth

WHAT THIS TESTS This checks your grasp of where cluster state lives, the consistency model, and the operational consequences of losing it.

A GOOD ANSWER COVERS etcd is a distributed key-value store that holds all Kubernetes objects, every Deployment, Pod, Secret, ConfigMap, and their status, making it the single source of truth. Only the kube-apiserver reads and writes it, so all components see one authoritative state. etcd uses the Raft consensus algorithm and requires a majority quorum, so an odd-numbered cluster of three or five members tolerates one or two failures respectively. If etcd loses quorum it becomes read-only or unavailable for writes, so the control plane cannot schedule, scale, or change anything; however, the data plane keeps running because the kubelet and kube-proxy continue with their last known state. Permanent loss without a backup means losing the entire cluster definition, which is why regular snapshots and secure, low-latency storage matter.

COMMON WRONG ANSWERS Claiming all Pods crash the instant etcd dies. Forgetting that etcd needs a quorum and using an even number of members. Saying components talk to etcd directly. Ignoring backups and encryption at rest.

LIKELY FOLLOW-UPS How many members for fault tolerance? What happens to running workloads during an etcd outage? How do you back up and restore etcd? Why encrypt Secrets at rest?

ONE CONCRETE EXAMPLE A cluster runs a three-member etcd. One member fails; quorum holds with two of three, so the cluster operates normally. A second member then fails, breaking quorum: kubectl apply now hangs and no scheduling occurs, but the web app Pods already running keep serving traffic. The team restores a member from a recent etcd snapshot, quorum returns, and control plane operations resume.