Describe the difference between a Deployment and a StatefulSet
Tests stateful pod identity versus stateless scaling. Outline: contrast Deployments' interchangeable replicas with StatefulSets' stable hostnames, per-pod PVCs, and ordered rollout; give a database example.
What's really being asked
This question probes whether you understand the infrastructure contract Kubernetes offers for stateful workloads versus stateless ones. A senior candidate should move beyond memorized definitions and explain why pod identity, storage stickiness, and startup ordering matter for distributed systems that manage their own replication or consensus.
The full answer
First, the core abstraction of a Deployment: it manages ReplicaSets to maintain a desired number of identical, fungible pods with random hashes in their names, no startup ordering, and no guarantee that a pod will reclaim the same persistent volume after rescheduling. Second, the StatefulSet contract: it assigns each replica a stable ordinal hostname like web-0, web-1, web-2; creates a dedicated PersistentVolumeClaim per pod that follows the pod across rescheduling; performs rolling updates and scaling sequentially rather than in parallel; and exposes each member via a stable network identity through a headless Service. Third, the concrete example: a distributed database such as Apache Cassandra or a replicated PostgreSQL cluster with streaming replication, where each node must know its own identity to join the ring or follow the correct primary, and where losing the mapping between node name and data directory would break the cluster.
The mistakes people make
Treating StatefulSets as simply Deployments with a volume template attached, which ignores the identity and ordering guarantees. Claiming that StatefulSets automatically make an application strongly consistent, when in reality they only provide stable infrastructure; the application still must handle its own consensus. Suggesting a StatefulSet for a simple stateless API server that happens to read from a remote database, which misses the point entirely. Stating that StatefulSets cannot be scaled, when they can, but scaling events are ordered and may require application awareness.
What usually comes next
How would you handle backup and restore for a StatefulSet member? What happens if pod-2 fails and is rescheduled to a different node; does it keep its data? How do you perform a rolling restart of a StatefulSet without breaking quorum? When would you use a DaemonSet instead of a StatefulSet for per-node stateful services?
A concrete example
A three-replica Apache Kafka cluster is a canonical StatefulSet workload. Each broker needs a unique broker ID that maps to a stable hostname, kafka-0, kafka-1, kafka-2, so that partition replicas and ISR lists remain valid after pod rescheduling. Each broker also requires its own log directories on dedicated persistent storage; if kafka-1 were replaced by an anonymous pod and attached to a random volume, it would lose its committed log segments and break consumer offsets. The headless Service gives each broker a DNS entry that clients and other brokers use to route traffic, while the StatefulSet ensures brokers start in order so that initial cluster formation can proceed safely.
Interview question
When deploying a three-replica Apache Kafka cluster in Kubernetes, why is a StatefulSet the appropriate abstraction rather than a Deployment?
- a.StatefulSets use a single shared PersistentVolumeClaim template so every replica accesses the same data directory
- b.StatefulSets provide each broker with a stable ordinal hostname and a dedicated persistent volume that remains bound to that specific pod identity across reschedulingCorrect
- c.StatefulSets create pods with random hashed names to ensure no single broker becomes a permanent bottleneck
- d.StatefulSets guarantee automatic strong consistency and consensus management for the broker cluster
Why? this is the answer
A StatefulSet gives each Kafka broker a stable ordinal hostname and a dedicated PVC that follows the pod across rescheduling, which is required to preserve broker IDs and log segments. The most tempting distractor claims strong consistency guarantees, but the card explicitly notes that StatefulSets only provide stable infrastructure; the application itself must still handle consensus.
Just read this? Test yourself on what you have been reading.
Read the original → kubernetes.io
- #kubernetes
- #statefulset
- #deployment
- #workloads
- #storage
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on kubernetes — each one lists the topics its interview covers.
See open roles