3 of the 3 questions we have for this objective, shown with the answer and the reasoning.
Assisting with the support of deployed solutions
At 02:10, Yarrow Payments' error rate jumps from 0.1 percent to 30 percent, beginning five minutes after a configuration change to the payment service was rolled out through Cloud Deploy. The on-call engineer starts reading code to find the root cause while customers continue to see failures. The incident commander must direct the response.
What should the incident commander instruct the team to do first?
- AContinue the root cause investigation so the fix is correct the first timeRoot cause analysis matters, but it can take hours while customers are affected; mitigation comes first when a likely trigger is known.
- BRoll back the payment service to the previous release, confirm that the error rate recovers, and then investigate the cause in a blameless postmortemRolling back the recent change is the fastest low-risk mitigation, restoring service before diagnosis; the postmortem then records the root cause and follow-up actions without blame.
- COpen a Customer Care case and wait for Google to investigateThe timing points to the company's own change, which the team can reverse immediately; waiting delays recovery.
- DScale the payment service to three times its current capacityAdding capacity does not fix errors caused by a bad configuration and adds cost.
Why: Incident response follows a clear order: mitigate impact, then diagnose, then prevent recurrence. When a failure begins right after a change, rolling back that change is usually the fastest and safest mitigation, which is why reliable release tooling with one-step rollback is part of operational readiness. After service is restored, a blameless postmortem documents the timeline, root cause, and actions so the organization learns without discouraging honest reporting. The trap is the natural engineering instinct to understand the bug before acting.
Assisting with the support of deployed solutions
Thornbury Logistics' operations team wants to be notified automatically when a Google Cloud service incident affects the products and regions that its own projects use, and wants these notifications delivered through its existing Cloud Monitoring alerting channels instead of checking a public status page.
What should the team use?
- AUptime checks against each Google Cloud API endpointUptime checks test your own endpoints and would produce noisy, indirect signals about Google services.
- BRecommender insights for each projectRecommender suggests cost, security, and performance improvements; it does not report service incidents.
- CPersonalized Service Health with alerting policies on its incident eventsPersonalized Service Health shows Google Cloud incidents relevant to your projects and can trigger Cloud Monitoring alerts to existing notification channels.
- DAccess Transparency logsAccess Transparency records actions taken by Google staff on your content, not service incidents.
Why: Supporting deployed solutions includes knowing quickly whether a problem is in your workload or in the platform. Personalized Service Health filters Google Cloud incidents to the products and locations that your projects use and integrates with Cloud Monitoring alerting, Pub/Sub, and the API. This shortens triage, because responders can see platform incidents next to their own alerts. The distractors are real services that answer unrelated questions.
Assisting with the support of deployed solutions
Ardent Trading is moving its order-matching platform to Google Cloud. Leadership requires the fastest possible initial response from Google for production-down incidents, a named technical contact at Google who understands the architecture, and help reviewing operational readiness before major launches.
Which Google Cloud Customer Care offering should you recommend?
- ABasic Support included with every accountBasic support covers billing and account questions and does not provide technical case response targets for production incidents.
- BStandard SupportStandard Support provides technical cases but with slower response targets for urgent issues and no named technical contact.
- CEnhanced SupportEnhanced Support provides faster response for critical issues than Standard, but it does not include a Technical Account Manager or launch readiness reviews.
- DPremium SupportPremium Support has the fastest initial response target for critical cases and includes a Technical Account Manager who supports architecture and launch planning.
Why: Customer Care tiers differ mainly in response targets, hours of coverage, and proactive services. For a business-critical workload where leadership asks for the fastest response, a named technical contact, and launch help, Premium Support is the fit because it includes a Technical Account Manager and proactive services. Enhanced Support is the common trap because it improves response times without the named contact. Architects should match the support tier to the business impact of downtime, just as they match the architecture to the SLO.