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.

• ✗

  Purchase reserved capacity for peak load and configure it to be active only on weekdays.

  Why it's wrong here

  Reserved capacity, such as committed use discounts, is intended for stable, predictable baseline usage, not for dynamic peak demand. You cannot schedule reserved capacity to be 'active only on weekdays'; a commitment applies continuously 24/7 once purchased, so paying for peak-level capacity would leave that capacity idle and expensive during nights and weekends. Even if you could purchase enough fixed capacity to cover the morning spike, it remains statically allocated and cannot automatically scale down when demand falls, making it the opposite of an auto-scaling solution.

• ✓

  Configure autoscaling on the application's infrastructure to automatically scale up for load and scale down during off-peak hours.

  Why this is correct

  Configuring autoscaling on the application's infrastructure directly addresses the requirement for automatic response to load. An autoscaler continuously monitors metrics such as CPU utilization, request count, or custom application metrics and dynamically adjusts the number of VM instances in a managed instance group. For the predictable 9 AM weekday spike, you can combine scheduled autoscaling (proactively adding capacity before the spike) with reactive autoscaling (handling unexpected bursts in real time). When traffic decreases during off-peak hours, the autoscaler automatically terminates excess instances, ensuring cost efficiency without human involvement.

• ✗

  Deploy additional VMs manually each weekday morning and terminate them at night.

  Why it's wrong here

  Manually deploying additional VMs each weekday morning and terminating them at night requires ongoing human effort, which violates the explicit 'without manual intervention' requirement. This approach is also inherently fragile—it cannot react to unexpected traffic spikes earlier or later than the scheduled window, and any miscalculation in VM count leads to either over-provisioning or performance degradation. Additionally, manual instance creation takes time to become ready, so users may experience latency during the provisioning window.

• ✗

  Use Cloud Monitoring to send an email alert when CPU exceeds 80% so the team can manually scale.

  Why it's wrong here

  Using Cloud Monitoring to send an email alert when CPU exceeds 80% still relies on a human to read the alert and manually adjust the infrastructure, which is why it fails the 'no manual intervention' requirement. Email notifications are asynchronous and can be missed, delayed, or acted on inconsistently, meaning the application could experience sustained overload while waiting for someone to respond. This approach also lacks any closed-loop feedback: there is no mechanism to automatically add or remove instances based on the alert, so it is not a scaling mechanism at all.

Go deeper

Related to this question