TL;DR: A ReplicaSet keeps N identical pods running and knows nothing about change. A Deployment owns a series of ReplicaSets and orchestrates moving between them, which is what gives you rolling updates, rollback and pause. You should essentially never create a ReplicaSet yourself.
How to approach it
Answer through what happens during an update, because that is where the difference lives. Saying "a Deployment manages ReplicaSets" and stopping leaves out what the management is for, which is the only part that matters during a rollout. Describing the two ReplicaSets existing at once during a rollout shows you have watched one happen.
A strong answer
A ReplicaSet has one job: a selector, a pod template and a replica count, and it makes the number of matching pods equal the count. A pod dies, it creates another. It can adopt matching orphan pods and reconcile excess replicas; owner references prevent indiscriminate adoption of pods already controlled elsewhere. It has no concept of a new version.
A Deployment sits above that. When you change the pod template, say a new image tag, the Deployment does not modify the existing ReplicaSet, because a ReplicaSet's template change would not move existing pods anyway. It creates a new ReplicaSet with the new template and then shifts capacity from the old one to the new one, a few pods at a time, governed by maxSurge and maxUnavailable. Mid-rollout you can see both:
kubectl get rs -n prod
# NAME DESIRED CURRENT READY AGE
# checkout-7d9f4b2 2 2 2 9d
# checkout-5c8a1e7 2 2 1 40s
The old ReplicaSet is scaled to zero when the new one is fully ready, and then kept, empty, as history. That retained history is what rollback is: kubectl rollout undo scales the previous ReplicaSet back up and the current one down. revisionHistoryLimit controls how many are kept, ten by default.
The rollout properties that come with this are the practical reason it matters. kubectl rollout status blocks until the new pods are ready, so a pipeline can actually wait and fail. kubectl rollout pause stops the shift partway, which is a crude canary: some traffic on the new version while you watch. And progressDeadlineSeconds marks the rollout failed if it stops making progress, which is what stops a broken image hanging a pipeline forever.
The rolling update depends entirely on readiness probes. Availability requires readiness for minReadySeconds when configured. Removal of old replicas follows maxUnavailable and maxSurge, so it is not always a one-for-one ready-then-remove sequence. Without a readiness probe, "started" counts as "ready" and the rollout replaces working pods with ones that are not yet serving, which is the usual explanation for dropped requests during an otherwise correct deploy.
When would you use a ReplicaSet directly? Effectively never. The honest answer is that it exists as the layer a Deployment builds on, and you interact with it when debugging (which ReplicaSet is which revision) rather than authoring it. The related objects for different needs are StatefulSet for stable identity and storage, DaemonSet for one pod per node, and Job or CronJob for work that finishes.
Work through a stalled four-replica rollout
Take a Deployment with four desired replicas, maxSurge: 1, maxUnavailable: 0 and minReadySeconds: 20. Its first new pod must fit alongside the four old pods. After passing readiness, it must remain ready for the availability interval before the controller can count it as available for rollout progress.
If the new pod cannot schedule, inspect its requests and placement constraints. The old four replicas can remain available while the rollout waits. If it schedules but fails readiness, inspect the new revision's configuration and probe rather than scaling the old ReplicaSet manually; the Deployment controller still owns those counts.
When the progress deadline is exceeded, the Deployment reports failed progress. It does not automatically undo the release. The pipeline should inspect that condition, preserve the failed revision's evidence and choose a compatible rollback or forward fix. Verify customer requests after the chosen recovery, because readiness is only as useful as the check it implements.
What interviewers probe next
"How do you roll back?" kubectl rollout undo deployment/checkout, which scales the previous ReplicaSet back up. Worth adding the caveat: this reverses the pods, not a database migration the release ran, so rollback is only safe if the schema still fits the old code.
"What does maxUnavailable: 0 give you?" The controller aims to keep the desired available replica count during its rollout, requiring surge capacity. It cannot prevent independent failures or guarantee equal throughput per replica. It is the right setting for a service that is already at its capacity limit.
"Why is my rollout stuck?" Almost always new pods failing readiness, or unschedulable because the surge needs capacity that does not exist. kubectl describe on the new ReplicaSet's pods says which.
Common mistakes
Creating a ReplicaSet by hand, then discovering there is no way to update it without deleting the pods.
Rolling out with no readiness probe and losing requests on every deploy.
Believing rollback restores everything the release changed, when it only restores the pods.
Editing a live Deployment with kubectl edit during an incident, which works and leaves the change invisible to whatever manages the manifests.