Cloud Digital Leader Scaling with Google Cloud operations 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.

• ✓

  Use committed use discounts (CUDs) for sustained resource usage.

  Why this is correct

  Committed use discounts (CUDs) are the right choice for the always-on, predictable portion of a real-time multiplayer game's compute capacity. By committing to 1- or 3-year usage of vCPUs and memory, you can save up to 57% compared with on-demand pricing, and the commitment has no effect on node preemptibility or workload availability. Because the game servers run continuously to support players, this steady baseline resource usage is an ideal fit for CUDs, directly lowering infrastructure cost without sacrificing reliability.

• ✗

  Use spot VMs with a node taint and toleration for game server pods.

  Why it's wrong here

  Adding a node taint and a matching pod toleration only controls scheduling; it does not make Spot VMs preemptible-proof. Spot VMs are still reclaimable by Compute Engine at any time with a short warning, so a game server pod running on that node can be forcefully evicted mid-session, causing player disconnects and lost progress. Real-time stateful multiplayer workloads require stable nodes; a toleration merely says the pod is willing to run on Spot, but it does not provide any protection against preemption or create a contract for capacity availability.

• ✓

  Use node auto-provisioning to automatically add nodes based on pod resource requests.

  Why this is correct

  Node auto-provisioning is correct because it lets the GKE cluster automatically add node pools with appropriate machine types when existing nodes cannot satisfy pending pod resource requests. This prevents manually overprovisioning large clusters to handle peak load, and it works with the cluster autoscaler to remove underutilized nodes, reducing wasted capacity and cost. For a game with fluctuating player counts, auto-provisioning right-sizes the compute layer to actual pod CPU/memory requests while maintaining performance during traffic spikes.

• ✓

  Deploy GKE clusters in multiple regions and use a multi-cluster ingress.

  Why this is correct

  Deploying GKE clusters in multiple regions and using a multi-cluster ingress is a correct architectural measure for a global real-time game because it routes players to the nearest cluster, reducing geographic latency and improving their experience. Multi-cluster ingress also provides failover: if an entire regional cluster becomes unhealthy, the load balancer can route traffic to healthy clusters in other regions, raising availability. While this option is not primarily a direct cost-reduction mechanism, it is a sound strategy for performance and resiliency, and it complements cost controls like CUDs and auto-provisioning.

• ✗

  Use preemptible VMs for game server pods.

  Why it's wrong here

  Preemptible VMs are unsuitable for game server pods because they have a maximum lifetime of 24 hours and can be terminated even sooner whenever Compute Engine needs the capacity back. When a preemptible VM is stopped, Kubernetes evicts all pods on that node, tearing down in-memory game state and dropping active sessions with no graceful migration. Real-time multiplayer sessions are stateful and fault-intolerant, so the cost savings from preemptibility are not worth the unacceptable risk of sudden player disconnects; these VMs should be reserved for stateless or checkpointed batch workloads.

Go deeper

Related to this question