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. A candidate who says "a Deployment manages ReplicaSets" and stops has not said what the management is for. 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. Somebody adds a pod with matching labels, it deletes one. 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. Kubernetes considers a new pod available when it passes readiness, and only then removes an old one. 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.
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?" No reduction in capacity during a rollout, at the cost of needing spare room for the surge. 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.