control plane

Managed Kubernetes offers several responsibility models. Application availability remains yours even when the provider also manages nodes and networking, and the interview tests whether you know where that line sits.

The pitch is continuous reconciliation instead of a plan someone runs. The cost is that your cloud estate now depends on a cluster, and that drift correction without a plan step is a very different risk posture.

The single most common Kubernetes interview question, and the one where a vague answer is most obvious. Every stage you name is a place the interviewer can ask you to debug.

Every control plane component depends on the API server, so who starts the API server? The bootstrap paradox sits at the heart of every cluster, and the kubelet plus a directory of files is the accepted way out.

Upgrades look like rolling restarts right up to the morning the CNI stops talking to the new kubelet. The scored answer is ordering, skew policy, and addon sequencing, not courage under pressure.

Three API servers behind one health-checked endpoint, etcd on its own quorum, leader election everywhere else. The scored part is naming what degrades quietly before anything alerts.

One disk metric explaining a whole cluster's weirdness is the point of this question. Candidates who restart etcd first turn a slow cluster into a down one.

Every client fails at once, which rules out pods and points at shared PKI. Know which certificates share one expiry clock, and the ten-minute fix that avoids a rebuild.