Describe the difference between a Deployment and a StatefulSet

WHAT THIS TESTS: 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.

A GOOD ANSWER COVERS: 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.

COMMON WRONG ANSWERS: 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.

LIKELY FOLLOW-UPS: 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?

ONE 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.

Source: kubernetes.io