Google ACE Practice Question: Your team is planning a GKE cluster for a…

Answer analysis

Option-by-option breakdown

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

• ✗

  Use separate GKE clusters: one for payment services and one for everything else.

  Why it's wrong here

  Separate GKE clusters do physically isolate payment workloads from other workloads, but they come with redundant control planes, separate VPCs or peering, distinct IAM policies, and double the upgrade and monitoring burden. For most organizations, taints and tolerations achieve the required isolation within a single cluster at far lower cost and complexity. This option is overkill unless there is a strict regulatory or business need for full cluster-level separation.

• ✓

  Apply taints to the dedicated node pool and tolerations to payment service pod specs.

  Why this is correct

  Tainting a dedicated node pool with, for example, 'payments=true:NoSchedule' and adding a matching toleration to payment pod specs guarantees that only pods with that toleration can be scheduled there. The kube-scheduler filters out tainted nodes for pods that lack the toleration, so non-payment workloads stay away. Combined with a nodeSelector or node affinity for that pool, this is the standard GKE pattern for isolating sensitive workloads inside one cluster.

• ✗

  Use Kubernetes NetworkPolicy to restrict network access between payment pods and other pods.

  Why it's wrong here

  NetworkPolicy is a firewall rule for pod-to-pod traffic, not a scheduling constraint. It can block payment pods from talking to other pods, but it does nothing to prevent the kube-scheduler from placing unrelated workloads on the same physical node as payment containers. Because those co-located pods share the node's runtime and kernel, NetworkPolicy cannot provide the CPU, memory, or security isolation that dedicated nodes require.

• ✗

  Set resource requests and limits so payment services consume all resources on their nodes.

  Why it's wrong here

  Setting resource requests and limits only tells the scheduler how much CPU/memory a pod needs and the kubelet how much to throttle or limit. Even if payment services claim large requests, the scheduler can still co-locate other pods on the same node as long as the sum of requested resources stays under the allocatable capacity. It is not an exclusivity mechanism, and while resource limits can constrain performance, they do not prevent multi-tenancy on the same node.

Go deeper

Related to this question