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. Explain what must happen outside the controller before a replacement member is safe to use.
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 requests the same claim, subject to storage availability, topology and attachment constraints. 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 where the abstraction stops helping. PVCs created by volumeClaimTemplates outlive the StatefulSet by default, but persistentVolumeClaimRetentionPolicy can request deletion on scale-down or StatefulSet deletion, so inspect the configured retention policy before assuming deletion and recreation preserve data, 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.
Recovery exercise: stable identity, unavailable storage
In a fictional three-member database, db-1 loses its node. The replacement retains its ordinal and claim, but the volume is tied to a zone with no eligible capacity. The controller's identity guarantee does not create storage access in another zone. Inspect pod scheduling events, PV node affinity and CSI attachment state before restarting database processes.
A network partition adds another risk: the old process may still be writing while the control plane cannot reach it. Force-deleting its Pod object does not prove that process stopped. Use the storage and database fencing procedure before permitting a replacement writer; stable naming alone cannot prevent split-brain.
After storage becomes available, verify that the member rejoins the intended cluster and catches up rather than independently initializing a new database. Test restore and quorum behaviour under the operator's supported procedures. The StatefulSet provides lifecycle structure, while data correctness depends on the application and storage system.
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.