Google ACE Practice Question: A Cloud Run service handles payment processing

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Cloud Monitoring — check the request_latencies metric distribution

  Why it's wrong here

  Cloud Monitoring aggregates latency data into a time-series metric called 'request_latencies', which is typically a distribution bucketed by value and can be visualized as percentiles such as p50, p95, and p99. While this is excellent for observing overall latency trends and alerting on SLO breaches, it does not expose individual request IDs, timestamps, or the ability to drill down into a specific slow request's execution path. The metric is a summary, not a detailed log or trace, so it cannot tell you which particular request was slowest or identify the root-cause span within that request.

• ✓

  Cloud Trace — sort traces by latency in the last hour

  Why this is correct

  Cloud Trace is the correct choice because it is a distributed tracing system that records each incoming request as a trace, composed of individual spans for every operation within that request. The Trace list view allows you to filter by a specific time range, such as the last hour, and directly sort traces by total latency. This surface immediately surfaces the slowest end-to-end requests, and you can click into a trace to see a detailed waterfall breakdown of where time is spent in the request path.

• ✗

  Cloud Logging — filter for requests with duration > 3s

  Why it's wrong here

  Cloud Logging can capture request logs that may include a 'duration' or 'latency' field, but the presence and format of that field vary widely depending on the application framework, log format, and whether structured logging is used. Filtering on duration is possible but brittle and requires knowing the exact field name and data type, and log entries do not inherently link to a system-level trace or provide a hierarchical span view of the request's internal stages. Cloud Logging is designed for exploring log data, not for dedicated latency triage, so while you might find slow requests, it lacks the purpose-built latency analysis features of Cloud Trace.

• ✗

  Cloud Profiler — view the slowest functions in the last hour

  Why it's wrong here

  Cloud Profiler is a statistical profiler that samples the CPU and heap usage of your application's functions, methods, and threads over time, showing where compute resources are being consumed. It does not capture the end-to-end latency of individual HTTP requests, nor does it associate profiling data with a specific request ID or a trace ID. Even if a function is slow, Profiler only shows that the function consumes CPU time; it cannot distinguish whether that slowness is due to I/O waits, network latency, or database queries, and it lacks the per-request timing breakdown that Cloud Trace provides.

Go deeper

Related to this question