Google ACE Practice Question: Ensuring Successful Operation of a Cloud Solution

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 Profiler

  Why it's wrong here

  Cloud Profiler uses statistical CPU and heap sampling to build flame graphs that reveal functions consuming the most CPU time or memory. In a multi-service application, the bottleneck is often a downstream call waiting on I/O, queues, or a slow peer — not a hotspot in your own code. Profiler does not capture request-level start/end timestamps or per-hop latency, so it cannot show which service is the slow link.

• ✗

  Cloud Logging

  Why it's wrong here

  Cloud Logging collects and stores log entries with timestamps, but it has no built-in trace propagation or span model unless you integrate Cloud Trace and add structured trace fields. You could correlate entries manually across services; however, that is brittle and lacks the precomputed latency percentiles and aggregated metrics needed to quickly isolate a slow component. For latency troubleshooting, logs are a complementary debugging aid, not the primary signal.

• ✓

  Cloud Monitoring

  Why this is correct

  Cloud Monitoring ingests service-level metrics such as request count, latency, and error rate from GKE, Compute Engine, and App Engine, and can display them in dashboards with percentile aggregations. You can create alerting policies and SLOs to detect when one service's latency breaches a threshold. This metric-centric view identifies which service is slow and when, but does not give the end-to-end span journey through each internal call — that is Cloud Trace's role.

• ✓

  Cloud Trace

  Why this is correct

  Cloud Trace captures latency data for requests as they traverse services by using trace IDs and spans, and it visualizes a waterfall timeline that shows the critical path. Each span records the time spent in a service or an internal operation (for example, a database query or HTTP call), letting you pinpoint exactly which component adds the most delay. This makes it the most direct tool for diagnosing which part of a multi-service application is slow.

• ✗

  Cloud Debugger

  Why it's wrong here

  Cloud Debugger attaches to a running application and lets you set snapshot or logpoint breakpoints that capture local variables, call stack, and execution state at a specific line, without restarting or stopping the service. It is designed for inspecting behavior and state at a moment in time, not for measuring latency distributions or aggregating timing across requests. Debugger tells you what the code is doing, not how long it takes.

Go deeper

Related to this question