TL;DR: A StatefulSet gives you three things a Deployment does not: a stable network identity per pod, a persistent volume that follows that identity across reschedules, and ordered startup/scale-down under the default OrderedReady policy. That is all it gives you. It does not make your application clustered, replicated or safe.
How to approach it
Answer with the three guarantees, then immediately say what it does not do, because that is where the follow-up goes. Interviewers use this question to find out whether you have actually run a database on Kubernetes or only read about it.
A strong answer
A Deployment treats its pods as interchangeable. It creates them through a ReplicaSet with random name suffixes, replaces them in any order, and has no built-in per-ordinal volumeClaimTemplates. Deployments can still mount PVCs; shared or single-replica storage must obey its access mode.
A StatefulSet gives each pod an ordinal identity that survives rescheduling. Pod postgres-0 keeps that name, gets a stable DNS record through the headless Service, and keeps its own PersistentVolumeClaim. If the node dies and the pod is recreated elsewhere, it is still postgres-0 and it reattaches the same volume. That identity is the whole point: a replicated database needs to know which member it is, and a Deployment cannot tell it.
The default OrderedReady policy is the third piece. Pods start in order, zero before one before two, and each must be Running and Ready before the next begins. Scale-down reverses it, removing the highest ordinal first. podManagementPolicy: Parallel changes scale-up/down behavior so the controller does not wait for each predecessor. This matters for systems where a member must join an existing quorum rather than form a new one.
Now the limits, which is what senior candidates get right. PVCs created by volumeClaimTemplates outlive the StatefulSet by default, but persistentVolumeClaimRetentionPolicy can request deletion on scale-down or StatefulSet deletion, so deleting and recreating leaves the old data attached, which is a feature during upgrades and a surprise during cleanup. Ordering slows rollouts significantly, and a pod stuck Ready-never means the rollout stops entirely rather than proceeding. And crucially, none of this replicates your data. The application does that. A StatefulSet running three Postgres pods with no replication configured is three unrelated databases with a shared name.
The practical failure this produces: a StatefulSet pod is deleted and does not come back, because the PVC is stuck Terminating on a finalizer, or because the volume requires a zone with no available eligible node and the scheduler cannot place a pod that must mount it. A Deployment using a PVC can encounter the same finalizer and zonal placement constraints. StatefulSet policies.
What interviewers probe next
"Why the headless Service?" Because you need per-pod DNS rather than a single virtual IP. A normal Service load balances and hides identity, which is the opposite of what a cluster member needs.
"Should you run databases on Kubernetes at all?" A defensible position either way, but you have to pick one. Mine: yes with a mature operator that handles failover and backups, no if the plan is a StatefulSet and hope, because the hard part was never the scheduling.
"What happens on scale-down from five to three?" With OrderedReady and the default Retain policy, pods four and three terminate in that order and their PVCs remain. Scaling back up reattaches them, which is usually what you wanted and occasionally a data hazard.
Common mistakes
Saying "StatefulSets are for stateful apps" and stopping. That is the name, not the mechanism.
Believing the StatefulSet replicates data or provides failover. It provides identity and ordering; the application or its operator provides everything else.
Forgetting that PVCs survive deletion, then being surprised by stale data or an unexpected storage bill.