Familiarity with Google Cloud Observability solutions

Sorrento Booking's checkout request passes through six Cloud Run services and a Cloud SQL database. The 95th percentile checkout latency has grown from 400 ms to 1.8 seconds, and each service's own metrics look normal. The team needs to see how long each hop in a single checkout request takes and which call is slow.

What should the team do?

1. AInstrument the services with OpenTelemetry, propagate trace context between them, and analyze the requests in Cloud TraceDistributed tracing records spans for each service call within one request, so Cloud Trace shows the latency of every hop and exposes the slow dependency.
2. BEnable Cloud Profiler on all six servicesProfiler shows CPU and memory use by function within each service, but it does not connect the calls of one request across services.
3. CCreate a Cloud Monitoring dashboard with request latency for each servicePer-service latency charts are already normal by service and cannot show how latency adds up across hops in a single request.
4. DIncrease the log level to DEBUG on every service and search for slow entriesVerbose logs add cost and lack the parent-child timing structure that shows which hop is slow.

Ralston Analytics runs a Go API on GKE whose CPU usage has risen 40 percent since a release, although request volume is unchanged. Load tests in staging do not reproduce the increase, so the team needs to find which functions consume CPU and memory in production with minimal overhead and without attaching a debugger.

Which tool should the team use?

1. ACloud Trace with a sampling rate of 100 percentTrace shows latency of requests across services and spans, but it does not show which functions inside the process consume CPU or memory.
2. BUptime checks in Cloud MonitoringUptime checks verify availability from external locations and provide no insight into code-level resource use.
3. CCloud Profiler with the Go profiling agent enabled in the serviceCloud Profiler continuously samples CPU and heap usage in production with low overhead and shows flame graphs by function, which identifies the code that changed.
4. DLog-based metrics that count requests per endpointRequest counts confirm that volume is unchanged but do not explain where CPU time goes.

Marlow Retail's on-call engineers receive alerts from Cloud Monitoring that say only 'Policy triggered', and they spend the first 20 minutes of each incident working out what the alert means and who owns the service. Alerts for the checkout service also go to a shared email inbox that nobody watches at night. The operations manager wants to shorten the time to respond.

Which two actions should you take? Each correct answer presents part of the solution.

1. AAdd documentation to each alerting policy that describes the impact, links to the runbook and dashboard, and names the owning teamPolicy documentation is included in notifications, so the responder immediately sees what is wrong, how to start mitigating, and who owns the service.
2. BRoute checkout alerts to an on-call notification channel such as a paging integration, and keep email only for low-severity policiesNotification channels should match urgency; urgent alerts must reach the person on call, not an unwatched inbox.
3. CLower every alert threshold so incidents are detected earlierLower thresholds increase alert volume and fatigue without explaining alerts or reaching the right person.
4. DSend all alerts from every service to every engineerBroadcasting alerts spreads responsibility so that no one owns the response and increases fatigue.
5. EDisable alert auto-close so incidents stay open until someone notices themLeaving incidents open does not help responders understand them or receive them sooner.

Halden Bank has defined an availability SLO of 99.9 percent of successful requests over a rolling 30 days for its mobile API. The current alert fires whenever the error rate exceeds 1 percent for one minute, which pages on-call engineers several times a week for brief spikes that do not threaten the SLO. Engineers also missed a slow, steady error increase that consumed most of the error budget.

How should you change the alerting?

1. ARaise the threshold to a 5 percent error rate for one minuteA higher static threshold reduces noise but would miss the slow, steady increase that already caused harm.
2. BReplace paging with a daily email that lists the error rateDaily summaries are too slow to protect a 30-day budget during a fast-burning incident.
3. CAlert on CPU utilization above 80 percent on the API backendsCPU is a cause-based signal that may not correlate with user-facing errors and adds noise rather than reducing it.
4. DCreate an SLO in Cloud Monitoring and use burn-rate alerting policies, with a fast-burn policy that pages and a slow-burn policy over a longer window that creates a ticketBurn-rate alerts fire on how quickly the error budget is being consumed, so brief harmless spikes stay quiet while both fast and slow budget threats are caught.