Deployment versus StatefulSet

WHAT THIS TESTS This checks whether you understand identity and storage semantics well enough to pick the correct controller.

A GOOD ANSWER COVERS A Deployment manages stateless, interchangeable Pods. They get random hash-suffixed names, can be created, replaced, or scaled in any order, and share no per-Pod identity or storage. This suits stateless web servers and APIs where any replica handles any request. A StatefulSet is for workloads that need stable identity. Each Pod gets a stable ordinal name like db-0, db-1, a stable DNS hostname via a headless Service, ordered startup and shutdown, and its own PersistentVolumeClaim that follows the Pod across rescheduling. This matters for databases and clustered systems where a primary and replicas must be distinguishable, where storage must persist per instance, and where scaling order matters. Choosing wrong causes data corruption or broken clustering, for example if a database loses its volume or two Pods share one.

COMMON WRONG ANSWERS Running a clustered or replicated database on a Deployment. Using a StatefulSet for a plain stateless API. Thinking Deployments preserve Pod identity. Ignoring the per-Pod volume difference.

LIKELY FOLLOW-UPS What is a headless Service and why does a StatefulSet need it? How does PVC behavior differ? What is the scaling order for a StatefulSet? Can you run a database on a Deployment with a shared volume?

ONE CONCRETE EXAMPLE A stateless image-resize API runs as a Deployment with five identical replicas behind a Service; any Pod handles any request and scaling up or down is trivial. A three-node Cassandra cluster runs as a StatefulSet: each Pod is cassandra-0, cassandra-1, cassandra-2, each keeps its own PersistentVolume across restarts, and they start in order so the cluster forms correctly, which a Deployment could not guarantee.