ADeploymentis a higher-level controller that managesReplicaSetsand provides rollout/rollback behavior, soDis correct. A ReplicaSet’s primary job is to ensure that a specified number of Pod replicas are running at any time, based on a label selector and Pod template. It’s a fundamental “keep N Pods alive” controller.

Deployments build on that by managing the lifecycle of ReplicaSets over time. When you update a Deployment (for example, changing the container image tag or environment variables), Kubernetes creates anew ReplicaSetfor the new Pod template and gradually shifts replicas from the old ReplicaSet to the new one according to the rollout strategy (RollingUpdate by default). Deployments also retain revision history, making it possible to roll back to a previous ReplicaSet if a rollout fails.

Why the other options are incorrect:

A is false: Deployments absolutely control the number of replicas via spec.replicas and can also be controlled by HPA.

B is false: ReplicaSetsdoguarantee that a stable number of replicas is running (that is their core purpose).

C is false: a Deployment is not “a ReplicaSet with annotations.” It is a distinct API resource with additional controller logic for declarative updates, rollouts, and revision tracking.

Operationally, most teams create Deployments rather than ReplicaSets directly because Deployments are safer and more feature-complete for application delivery. ReplicaSets still appear in real clusters because Deployments create them automatically; you’ll commonly see multiple ReplicaSets during rollout transitions. Understanding the hierarchy is crucial for troubleshooting: if Pods aren’t behaving as expected, you often trace from Deployment → ReplicaSet → Pod, checking selectors, events, and rollout status.

So the key difference is:ReplicaSet maintains replica count; Deployment manages ReplicaSets and orchestrates updates.Therefore,Dis the verified answer.

=========