Cloud Digital Leader Scaling with Google Cloud operations Practice Question

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 Logging — search logs for error messages across all 15 services.

  Why it's wrong here

  Cloud Logging stores individual log entries; searching for error messages across 15 services can reveal that errors occurred, but it cannot reconstruct the causal sequence of a single distributed request. Without trace context propagation (e.g., a shared trace ID and span hierarchy), you cannot determine which service call added latency or how the request flowed between services. Log-based troubleshooting is also reactive—you see the failure after the fact, but you lack the time-ordered, cross-service view needed to pinpoint why a specific slow request lagged.

• ✓

  Cloud Trace — captures distributed request traces showing end-to-end latency across all microservices.

  Why this is correct

  Cloud Trace is purpose-built for distributed performance debugging: it captures an end-to-end trace for each sampled request, recording each service call as a span with parent-child relationships to reconstruct the exact request path across your 15 microservices. The Gantt chart view shows the duration of every span, the critical path, and the service-to-service latency, so you can immediately spot which service added the most time to a slow request. Cloud Trace also correlates with Cloud Logging via trace IDs, letting you inspect error logs within the same trace. This makes it the only option that directly answers 'which service is the latency culprit?' for a specific request flow.

• ✗

  Cloud Monitoring dashboards — create per-service CPU utilization graphs.

  Why it's wrong here

  Cloud Monitoring dashboards that graph CPU utilization per service show aggregate resource consumption over time, but they are not transaction-level data. A slow request can be caused by a database query, network contention, thread pool exhaustion, or a blocked dependency—any of which may occur without high CPU usage. CPU graphs cannot correlate a specific user request across multiple services, nor do they reveal the call order or per-span latency that distributed tracing provides. While such dashboards are useful for capacity planning, they fail the core diagnostic need here: identifying the exact service responsible for a given request's end-to-end delay.

• ✗

  Security Command Center — scan for misconfigurations causing performance issues.

  Why it's wrong here

  Security Command Center (SCC) is a security and compliance tool that scans for misconfigurations, vulnerabilities, and policy violations, such as open firewall ports or overly permissive IAM roles. It does not ingest request latency data, trace spans, or application performance metrics, so it cannot diagnose why one microservice added 800 ms to a request. Even if a misconfiguration indirectly degrades performance (e.g., by blocking a healthy backend), the failure would surface as an error or timeout—not as a trace that shows the latency contribution of each service hop. SCC answers 'is this environment secure?' not 'which service is slow?'.

Go deeper

Related to this question