Google ACE Practice Question: A gaming company's GKE cluster uses a mix of node…

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 podAffinity to prefer nodes where Spot pods are running

  Why it's wrong here

  Using a podAffinity that *prefers* nodes where Spot pods are already running does not reliably or exclusively target Spot node pools. Pod affinity matches nodes based on pod labels, not node labels, and it only influences placement relative to existing pods; if no Spot pods exist yet, the preference is ignored. Even when it does match, the affinity is only a soft preference (`preferredDuringSchedulingIgnoredDuringExecution`), so the scheduler can still place the pod on a regular node. To pin scheduling to Spot nodes, you need a node-level constraint, not a pod-to-pod relationship.

• ✓

  Add a nodeSelector: cloud.google.com/gke-spot: 'true' to the simulation Deployment spec

  Why this is correct

  Adding `nodeSelector: cloud.google.com/gke-spot: 'true'` is the precise way to ensure the Simulation pod lands on a Spot node. When a node pool is created with Spot VM settings, Google Kubernetes Engine automatically labels every node with `cloud.google.com/gke-spot=true`. A nodeSelector constrains the pod's scheduling to nodes that carry that exact label, which is a hard constraint during the scheduling decision. This directly targets the Spot pool without relying on ambiguous affinity logic or naming conventions.

• ✗

  Set requests.cpu and requests.memory to very high values — GKE will route them to Spot nodes

  Why it's wrong here

  Inflating the Deployment's resource requests does not signal GKE to use Spot nodes. Resource requests and limits are used by the Kubernetes scheduler to determine which existing nodes have enough allocatable CPU and memory to fit the pod; they are never interpreted as a node-pool preference. In fact, very high requests could make the Simulation pod unschedulable if no node has that much capacity, or force the cluster to autoscale a non-Spot pool. To target Spot VMs, you must explicitly use scheduling constraints such as a nodeSelector or nodeAffinity for the Spot label.

• ✗

  Name the simulation Deployment with a 'spot-' prefix — GKE routes prefixed deployments to Spot pools

  Why it's wrong here

  Prefixing the Deployment name with `spot-` has no effect on the Kubernetes scheduler or GKE node pool selection. Deployment names are arbitrary metadata used for identification and labeling, and GKE does not inspect prefixes to infer workload placements. Node assignment is controlled exclusively through scheduling directives in the pod spec, such as `nodeSelector`, `nodeAffinity`, `taints`, and `tolerations`. Naming conventions may help humans organize resources, but they never influence infrastructure routing.

Go deeper

Related to this question