Cloud Digital Leader Why Cloud Technology Can Transform Business 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 Cloud Load Balancing to distribute traffic and add more VM instances manually.

  Why it's wrong here

  Cloud Load Balancing distributes incoming traffic across VM instances, but it has no autoscaling capability. Adding instances manually requires an operator to observe player counts and run resize commands, creating a reactive, error-prone process that cannot respond quickly to traffic surges. A managed instance group with autoscaling, in contrast, adjusts instance count automatically based on metrics without human involvement.

• ✗

  Use Cloud Functions to spin up new game server VMs when player count exceeds a threshold.

  Why it's wrong here

  Cloud Functions can indeed call the Compute API to create new game server VMs when a threshold is breached, but this orchestration is brittle: function execution has timeouts and cold starts, the create VM call is asynchronous, and concurrent invocations can trigger duplicate VMs. Autoscaling in a managed instance group uses the group's own controller to converge toward a target metric reliably, without racing or external state. This is why autoscaling is the recommended pattern for dynamic VM pools.

• ✗

  Pre-provision a fixed number of VMs with GPUs to handle peak load at all times.

  Why it's wrong here

  Pre-provisioning a fixed fleet of GPU VMs sized for peak concurrent player count ensures capacity is never lacking, but it keeps the same expensive resources running even during low-player off-peak hours. This dramatically expands compute costs and does not adjust to demand, eliminating the financial benefit of cloud elasticity. Autoscaling only starts instances when demand justifies them, so it aligns spending with actual usage.

• ✓

  Create a managed instance group with autoscaling based on a custom metric representing concurrent players.

  Why this is correct

  Create a managed instance group and configure autoscaling with a custom metric representing concurrent players; the MIG controller continuously samples this metric and adjusts the number of game server VM replicas to hit the target value you specify. This is exactly the native pattern for player-count-based scaling, because it uses a first-party scaling policy rather than an external orchestration layer. You can also set a cool-down period and max/min instance limits to prevent flapping.

Go deeper

Related to this question