Google ACE Practice Question: A GKE Deployment runs a web application with 6…

Answer analysis

Option-by-option breakdown

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

• ✓

  Set podAntiAffinity with requiredDuringSchedulingIgnoredDuringExecution and topologyKey: kubernetes.io/hostname

  Why this is correct

  This creates a hard (required) anti-affinity rule that tells the scheduler: do not place a Pod on a node where a Pod matching the same selector already runs. Using topologyKey: kubernetes.io/hostname scopes that check to individual nodes, so the scheduler will only place one replica per node, even as nodes are added or removed. Because the rule is in the Pod spec, it is dynamic and self-managing, unlike manual node pinning. This is the standard declarative approach for achieving strict per-node exclusivity.

• ✗

  Set podAffinity with requiredDuringSchedulingIgnoredDuringExecution and topologyKey: kubernetes.io/hostname

  Why it's wrong here

  podAffinity attracts Pods to nodes where matching Pods already run, which is the opposite of the desired spread. With requiredDuringSchedulingIgnoredDuringExecution, the scheduler is forced to place a new replica on the same node as an existing replica of the same workload, causing co-location rather than separation. Even with a topologyKey of hostname, it encourages stacking replicas onto fewer nodes, defeating the goal of one replica per node. You would need podAntiAffinity to invert the relationship.

• ✗

  Set topologySpreadConstraints with maxSkew: 1 and topologyKey: kubernetes.io/hostname

  Why it's wrong here

  While topologySpreadConstraints can distribute Pods evenly across nodes, it does not guarantee absolute exclusivity; it only balances counts with a tolerance (skew). In a small cluster where replicas outnumber nodes, the scheduler can still place multiple Pods on the same node, and even with maxSkew: 1 it allows a difference of one replica per topology domain. For hard node-exclusivity (one replica per node, no co-location ever), podAntiAffinity with requiredDuringSchedulingIgnoredDuringExecution is the explicit and deterministic constraint.

• ✗

  Set nodeSelector to a specific node for each replica

  Why it's wrong here

  Using nodeSelector pins each replica to a pre-assigned node, which requires manual node management and leaves no dynamic scheduling flexibility. If a node fails, its replica cannot be rescheduled elsewhere because the selector restricts it to that dead node, and you must edit the Deployment to move it. It also doesn't prevent co-location by itself—you'd have to know the cluster topology in advance and ensure no two replicas share a node. This is brittle and does not express the desired 'one per node' rule declaratively.

Go deeper

Related to this question