Courseiva
Scaling with Google Cloud operationseasyMultiple ChoiceObjective-mapped

Cloud Digital Leader Scaling with Google Cloud operations Practice Question

A developer is troubleshooting a slow response from a Cloud Run service. Which Google Cloud service can they use to trace requests across microservices?

⚠ Common exam trap

Test-takers frequently confuse Cloud Trace with Cloud Logging, thinking that log aggregation alone can reconstruct request paths, but Cloud Trace is the only service that provides distributed tracing with explicit span context propagation across microservices.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

Cloud Trace

Cloud Trace is the correct service because it is specifically designed for distributed tracing, collecting latency data from applications and displaying it in a trace timeline. It can trace requests as they propagate across multiple microservices, including Cloud Run services, by using trace context propagation headers (e.g., `X-Cloud-Trace-Context`). This allows the developer to identify bottlenecks and slow components in a request path.

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 provides continuous profiling of CPU and memory consumption across a service, identifying which functions consume the most resources, but it does not capture per-request latency, trace spans, or the end-to-end path of a specific request. Therefore, it cannot pinpoint where a particular slow response spends its time in terms of request propagation through services or API calls.

  • Cloud Trace

    Why this is correct

    Cloud Trace collects and aggregates latency data (trace spans) from distributed services, allowing developers to view the end-to-end journey of a single request, including delays in each service, RPC calls, and external API calls. It provides a waterfall view, which directly helps diagnose slow responses by identifying the bottleneck span. This makes it the correct tool for troubleshooting response latency.

  • Cloud Logging

    Why it's wrong here

    Cloud Logging stores structured and unstructured log entries, but logs alone do not contain the distributed latency information needed to correlate a slow request across services unless you explicitly integrate Cloud Trace and use trace IDs as log correlation keys. Without this integration, you can only see individual service logs, missing the holistic view that reveals where the delay occurs. Thus, Logging is insufficient for direct end-to-end latency analysis.

  • Cloud Debugger

    Why it's wrong here

    Cloud Debugger lets you take snapshot captures of the state of a running application at specific lines of code without stopping it, useful for inspecting variable values and logic, but it does not record request timing, traversal paths, or span durations. It operates in a point-in-time manner rather than capturing the whole request lifecycle, so it cannot show why a response is slow across distributed components. Hence, it is not the tool for latency analysis.

About these practice questions

One of 829 original GCDL practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

This GCDL practice question is part of Courseiva's free Google Cloud certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the GCDL exam.