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.

• ✗

  Manually add VMs when traffic increases

  Why it's wrong here

  Manual scaling requires an operator to detect rising traffic, then provision new VMs by hand, which takes minutes and cannot keep up with sudden, unpredictable spikes. This approach is slow and error-prone, and if the spike is short-lived, the added capacity may appear too late or persist long after demand falls, wasting money. It also lacks integration with health checks, so manually added instances may not be properly registered or may receive traffic before they're ready.

• ✗

  Use a GPU-accelerated VM for compute

  Why it's wrong here

  GPU-accelerated VMs like A2 or G2 are designed for massively parallel workloads such as machine learning training, 3D rendering, or video transcoding, not for serving standard web traffic. Web servers are constrained by CPU, memory, and network bandwidth, and GPU instances carry a significant hourly cost premium and often have limited regional availability. Even with GPUs, you would still need an autoscaling mechanism to add or remove instances, so this choice does not address the need to absorb sudden traffic spikes.

• ✓

  Create a managed instance group with autoscaling

  Why this is correct

  A managed instance group with an autoscaling policy automatically adjusts the number of VM instances based on load signals such as CPU utilization, requests per second, or Cloud Monitoring custom metrics. The autoscaling controller provisions additional instances when a spike begins and removes them when demand drops, all without human intervention. Using an instance template and health checks, the MIG also replaces unhealthy VMs, ensuring that the load balancer only routes traffic to ready instances, which makes it ideal for handling sudden traffic spikes.

• ✗

  Use a single large VM and rely on Cloud Load Balancing

  Why it's wrong here

  A single large VM has an absolute limit on vCPUs, memory, and network throughput, and Cloud Load Balancing merely distributes traffic across the existing backend instances; it cannot create or destroy VMs to match load. If traffic exceeds that one machine's capacity, the load balancer will continue sending requests to an overloaded instance, leading to latency and errors. This design also creates a single point of failure—if the VM fails, the entire service goes down. To handle spikes, you need a scalable backend like a managed instance group, not just a bigger instance.

Go deeper

Related to this question