Cloud Digital Leader Google Cloud Products and Services Practice Question

Answer analysis

Option-by-option breakdown

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

• ✓

  Taint the regular node pool and use tolerations for stateful pods

  Why this is correct

  Taints on regular nodes with tolerations for stateful pods create an explicit scheduling contract: any pod without the matching toleration is blocked from the regular node pool, while stateful pods that declare the toleration are placed there exclusively. This ensures preemptible or stateless workloads cannot consume resources on those nodes, giving stateful services stable, non-preemptible infrastructure and predictable lifecycles.

• ✗

  Use a single node pool with a mix of regular and preemptible VMs

  Why it's wrong here

  A GKE node pool is uniform by design: you cannot mix preemptible and regular VM types in the same pool because they must share the same machine configuration, billing model, and node management settings. Even if the mix were possible, stateful pods would be scheduled on whichever node has capacity, so a preemptible node could host them and be terminated without notice, jeopardizing data durability and application availability.

• ✗

  Set pod priority class to 'high' for stateful workloads

  Why it's wrong here

  Pod priority classes influence the order of eviction during resource contention and allow higher-priority pods to preempt lower-priority ones, but they have no bearing on where a pod is initially scheduled. A stateful pod with a high priority can still be placed on a preemptible node because no node-level constraint is applied, and when GKE reclaims that preemptible instance, the pod is terminated despite its priority.

• ✓

  Create a separate node pool for preemptible VMs and use tolerations for stateless pods

  Why this is correct

  If the preemptible node pool is tainted (as GKE does automatically with preemptible=true), attaching the matching toleration to only stateless pods lets them take advantage of the cheaper preemptible nodes while stateful pods, lacking that toleration, are forced onto the regular, untainted node pool. This cleanly separates the two workload classes and prevents stateful services from ever being scheduled on a preemptible VM.

• ✗

  Use node affinity rules to schedule stateful pods on regular nodes

  Why it's wrong here

  Node affinity lets you specify requirements or preferences for the node labels that stateful pods run on, but it does not restrict other pods from also scheduling onto those same regular nodes. Regular nodes can become overcommitted by stateless pods, and the stateful pods may still face resource contention; taints, by contrast, repel any pod that lacks the corresponding toleration, providing an absolute guarantee of node-pool exclusivity.

Go deeper

Related to this question