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.

• ✗

  Increase the CPU request limit for all pods.

  Why it's wrong here

  Increasing CPU request limits only changes the amount of CPU reserved for each pod at the scheduler level; it does not alter what metric the HorizontalPodAutoscaler (HPA) observes. HPA can scale on CPU utilization, but request latency is an application-level performance signal that CPU requests do not influence. In fact, raising CPU request limits can reduce node density (fewer pods per node) and may indirectly worsen latency by forcing more nodes, without improving autoscaling responsiveness to traffic spikes.

• ✓

  Configure the HPA to use custom metrics based on request latency.

  Why this is correct

  Configuring the HPA to consume custom metrics from the Kubernetes Custom Metrics API (e.g., using the Stackdriver adapter or Prometheus adapter) allows it to scale based on request latency metrics such as p95 or p99 duration. This directly measures user-facing performance so the HPA adds pods when latency rises, not just when CPU is saturated. This approach responds to application-level bottlenecks, which is the correct fix for latency-driven scaling on Google Kubernetes Engine.

• ✗

  Create multiple node pools with different machine types.

  Why it's wrong here

  Creating multiple node pools with different machine types is a form of infrastructure scaling that changes the shape of the cluster's nodes, not the HPA's scaling decision. The HPA operates at the pod level and continues to use its configured metric (e.g., CPU or custom latency) regardless of which node pool a pod runs in. While node pools support autoscaling at the node level (Cluster Autoscaler) and can host heterogeneous workloads, they do not enable latency-based pod autoscaling—the HPA still needs a custom metric to react to request latency.

• ✗

  Manually scale the deployment during expected spikes.

  Why it's wrong here

  Manually scaling the deployment in anticipation of spikes relies on human prediction, which is error-prone and cannot adapt to sudden or unexpected traffic increases. Once the spike begins, manual intervention incurs a delay while the new pods are scheduled and start serving, potentially causing latency spikes. The HPA, by contrast, automatically and continuously compares the observed latency metric against a target and adjusts the replica count within seconds to minutes, providing the automated, fine-grained response needed for dynamic web traffic.

Go deeper

Related to this question