Google ACE Practice Question: A platform team needs a Kubernetes workload that…

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Deployment with replicas set equal to the node count

  Why it's wrong here

  A Deployment with replicas set to the node count creates a ReplicaSet that the scheduler distributes using its default bin-packing and scoring algorithms; this does not force one Pod per node. Multiple replicas can land on the same node, leaving other nodes without a Pod. If the cluster autoscaler adds a new node, the Deployment won't create a new Pod until the replica count is manually increased, and even then the scheduler may not place it on the new node. DaemonSet, by contrast, automatically adds Pods to every new and existing node matching the selector.

• ✗

  StatefulSet with one replica per node

  Why it's wrong here

  A StatefulSet is designed for applications that need stable network identities and persistent storage; it does not include any scheduling semantics that enforce one Pod per node. Even with replicas equal to node count, StatefulSet Pods are scheduled by the default scheduler and can be co-located on the same node. It also maintains a fixed replica count, so nodes added by the autoscaler won't receive a StatefulSet Pod unless the replica count is manually increased—making it unsuitable for node-level metric collection.

• ✓

  DaemonSet

  Why this is correct

  A DaemonSet is the correct controller because it declaratively ensures that one Pod runs on every node that matches its node selector, including nodes added later by the cluster autoscaler. The DaemonSet controller watches the cluster's node list and places a Pod on each qualifying node, removing Pods from nodes that no longer match. This makes it purpose-built for node-level workloads like metric collectors, kube-proxy, or network agents.

• ✗

  CronJob running every minute to check and restore missing Pods

  Why it's wrong here

  A CronJob would run a scheduled Job every minute, executing a script to detect and replace missing Pods. This is a reactive, polling-based approach that leaves a window of unavailability between runs and adds unnecessary complexity. It also cannot guarantee per-node placement because the replacement Pods are scheduled according to general resource availability, not node-level constraints. DaemonSet's controller continuously reconciles desired state, eliminating the need for a cron-driven repair loop.

Go deeper

Related to this question