The e-commerce application experiences a major traffic spike every Monday morning precisely at 9:00 AM, which often overwhelms the Compute Engine Managed Instance Group (MIG) before autoscaling can fully respond. How can the architect ensure the infrastructure is ready for the spike *proactively*?

The problem describes a predictable, recurring traffic spike that overwhelms the system before reactive autoscaling can respond. The key requirement is a proactive solution. Configuring a Cloud Scheduler job to call the Compute Engine API and increase the Managed Instance Group's (MIG) size 15 minutes before the known spike is a proactive, schedule-based scaling approach. This ensures that the necessary number of virtual machine instances are provisioned, initialized, and ready to serve traffic before the load increases, directly addressing the scenario's core issue.

A. Increasing the autoscaling cool-down period would make the autoscaler slower to respond to load changes, exacerbating the problem of being overwhelmed.

B. Switching to a GKE Cluster does not inherently solve the problem. GKE's autoscaling is also primarily reactive and would face the same delay in responding to a sudden spike.

C. Reducing the target CPU utilization is still a reactive measure. It would trigger scaling sooner once the spike begins, but it would not pre-provision instances before the spike occurs.

1. Google Cloud Documentation, "Autoscaling groups of instances": This document explicitly describes schedule-based autoscaling for predictable loads. It states, "If you have predictable workloads, you can configure schedule-based autoscaling to scale your MIGs in anticipation of traffic increases... You can create one or more scaling schedules to configure the minimum number of VM instances required in the MIG during scheduled periods." This directly supports the methodology in option D.

Source: Google Cloud Documentation, "Autoscaling groups of instances", Section: "Schedule-based autoscaling".

2. Google Cloud Documentation, "Scaling based on schedules": This guide provides a step-by-step tutorial on implementing the exact solution described in option D. It details how to create a scaling schedule that sets the min-num-replicas for a MIG at a specific time and day, using tools like gcloud or the API, which can be automated by Cloud Scheduler.

Source: Google Cloud Documentation, "Scaling based on schedules".

3. Google Cloud Documentation, "Autoscaler properties": This page explains the coolDownPeriodSec property. It defines the cool-down period as the time the autoscaler waits after a scaling activity before it can start another. Increasing this value would delay subsequent scaling actions, making option A incorrect.

Source: Google Cloud Documentation, "Autoscaler properties", Section: "coolDownPeriodSec".