1V0-71.21 · Question #23
Which Kubernetes resource provides the specification of the number of running Pod instances?
The correct answer is A. ReplicaSet. A ReplicaSet is the Kubernetes resource specifically designed to maintain a stable set of replica Pods running at any given time - its spec.replicas field directly specifies how many Pod instances should be running, and it continuously reconciles actual vs. desired state…
Question
Which Kubernetes resource provides the specification of the number of running Pod instances?
Options
- AReplicaSet
- BService
- CCronjob
- DDaemonset
How the community answered
(28 responses)- A93% (26)
- B4% (1)
- C4% (1)
Explanation
A ReplicaSet is the Kubernetes resource specifically designed to maintain a stable set of replica Pods running at any given time - its spec.replicas field directly specifies how many Pod instances should be running, and it continuously reconciles actual vs. desired state.
- Service (B) provides stable network access and load balancing to a set of Pods, but has nothing to do with controlling how many Pods exist.
- CronJob (C) schedules Jobs to run at specific times (like a cron expression), it doesn't maintain a persistent count of running Pods.
- DaemonSet (D) ensures one Pod runs on each (or a subset of) nodes - the count is node-driven, not a user-specified replica number.
Memory tip: Think "ReplicaSet = Set the replica count." If you see replicas: 3 in a YAML spec, you're almost certainly looking at a ReplicaSet (or a Deployment that manages one under the hood).
Topics
Community Discussion
4
Carlos M.Oct 30, 2025A is correct. A ReplicaSet is the resource whose whole job is maintaining a desired number of running Pod replicas, that spec field is literally what defines how many instances stay up at any given time.
Grace U.Nov 9, 2025ReplicaSet is right, it exists purely to maintain a desired pod count.
Ivana K.Nov 16, 2025ReplicaSet is the right call here, and it is worth understanding why the other options do not fit before you sit for the exam. A Service handles network access and load balancing to a group of Pods, it has nothing to say about how many Pods exist. A CronJob schedules workloads on a time basis, and a DaemonSet ensures exactly one Pod per node rather than a user-defined count. The ReplicaSet holds the replica count field and the Pod template, and the controller loop continuously reconciles actual running Pods against that desired number. One thing I want to make sure candidates understand here, because it comes up in day-2 automation scenarios too: if you deploy a ReplicaSet directly versus wrapping it inside a Deployment, how does that affect your ability to roll back or update the replica count through a catalog action? Thinking through that distinction will deepen your grasp of why Deployments own ReplicaSets in practice rather than you managing ReplicaSets by hand.
Ola B.Nov 23, 2025ReplicaSet is your answer here, and if you spin up a quick cluster and run "kubectl get replicaset" after deploying an app you will see exactly how it tracks desired vs. current pod counts. Have you played around with what actually manages a ReplicaSet in most real deployments, and why you might rarely create one directly?