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 application's max_instances so it scales to handle the issue automatically.

  Why it's wrong here

  Scaling out by increasing max_instances is a capacity mitigation, not an incident response capability. While it can absorb a traffic spike or resource exhaustion, it does not define who coordinates the response, how severity is assessed, or what steps to take to restore service when the issue is not purely capacity-related. It also ignores the human workflow that must occur before, during, and after any production disruption.

• ✓

  Establish a documented incident response process with defined roles, escalation paths, and runbooks, supported by on-call rotation tooling and Cloud Monitoring alerting.

  Why this is correct

  A documented incident response process with defined roles, escalation paths, and runbooks creates a repeatable, predictable method to manage production disruptions. On-call rotation tooling ensures there is always a responsible engineer who can be alerted immediately, and Cloud Monitoring alerts trigger that rotation based on SLO-oriented metrics. This combination directly addresses the root cause of the issue—the lack of a coordinated response—by turning an unmanaged outage into a structured recovery with clear ownership and steps.

• ✗

  Move all production deployments to Sunday nights to avoid weekday incident risk.

  Why it's wrong here

  Constraining deployments to Sunday nights attempts to lower the probability of deployment-related incidents during business hours, but it does not improve the team's ability to respond when an incident occurs at any other time. Failures can originate from dependency changes, external service degradation, or usage spikes, and without a documented process and runbooks, the response will remain chaotic. It also violates the principle of continuous delivery by introducing unnecessary batch risk into a single deployment window.

• ✗

  Disable monitoring alerts to prevent false alarms that wake engineers unnecessarily.

  Why it's wrong here

  Disabling monitoring alerts removes the notification mechanism entirely, which directly increases mean time to detect (MTTD) and allows silent failures to persist. The underlying complaint is alert fatigue, which should be addressed by tuning alert thresholds, grouping related notifications, and using Cloud Monitoring's alerting policies with appropriate severity levels—not by eliminating the alerts altogether. Without alerts, the on-call rotation has no signal to trigger the incident response process.

Go deeper

Related to this question