Home Microsoft Exams Google Cloud Exams

Loading page

Curious about new developments and updates? Follow our social media.

Get a free certification question every week.

Microsoft Exams

AZ-104 Administrator
AZ-204 Developer
AZ-900 Fundamentals
All Microsoft Exams

Google Cloud Exams

Associate Data Practitioner
All Google Cloud Exams

Terms Privacy Cookies About Pricing

© 2026 StudyCerts. All rights reserved.

StudyCerts is an independent service and is not affiliated with, endorsed by, or sponsored by any certification body or cloud provider.

Loading page

Home
Google Cloud Exams
Professional Cloud DevOps Engineer
Analyzing trace waterfalls and spans
An e-commerce checkout service deployed on Google Cloud expe…

Professional Cloud DevOps Engineer

Professional Cloud DevOps Engineer

Advanced

Prepare and test your skills

Description
Sample Question
Free Trial
Practice Test

Advanced

Prepare and test your skills

Description
Sample Question
Free Trial
Practice Test

Analyze Span Attributes Trace Waterfall Root Cause

Section: Analyzing trace waterfalls and spans

Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.

...

...

...

...

...

Explanations

...

View source documentation

Related questions

Keep the momentum going with these hand-picked practice scenarios

AdvancedProfessional Cloud DevOps Engineer

An e-commerce backend running on Google Cloud experiences periodic latency spikes during high-traffic sales events. When inspecting distributed trace waterfalls in Cloud Trace, the DevOps team identifies an elongated span corresponding to a database query operation within the ordering service. You need to correlate this trace span with Cloud Logging entries and Cloud Monitoring metrics to determine whether the latency spike is caused by unoptimized application query logic or infrastructure-level resource constraints. Which diagnostic workflow should you use?

Analyzing trace waterfalls and spans

AdvancedProfessional Cloud DevOps Engineer

A DevOps engineer is analyzing distributed traces in Google Cloud Observability to diagnose high latency in an e-commerce application. A transaction on the /checkout endpoint takes 1,450 ms to complete. Inspection of the Gantt chart and span tree in Cloud Trace Explorer displays the following span execution details: | Span Name | Parent Span | Start Offset | Duration | | :--- | :--- | :--- | :--- | | checkout_handler | None (Root) | 0 ms | 1,450 ms | | ├── validate_cart | checkout_handler | 10 ms | 40 ms | | ├── get_user_profile | checkout_handler | 50 ms | 100 ms | | ├── fetch_loyalty_points | checkout_handler | 50 ms | 120 ms | | ├── process_order | checkout_handler | 170 ms | 1,250 ms | | │ ├── reserve_inventory | process_order | 180 ms | 150 ms | | │ └── call_payment_gateway | process_order | 330 ms | 1,080 ms | | │ └── http_post_external_psp | call_payment_gateway | 340 ms | 1,060 ms | | └── send_confirmation_email | checkout_handler | 1,420 ms | 30 ms | Based on this trace waterfall visualization, what does the execution timeline reveal about the application's critical path and primary latency bottleneck?

Analyzing trace waterfalls and spans

AdvancedProfessional Cloud DevOps Engineer

An enterprise organization is establishing a centralized logging strategy across its Google Cloud resource hierarchy. The DevOps and security engineering teams have established three specific requirements for handling incoming audit logs: Requirement 1: Store logs for 7 years to meet strict regulatory compliance mandates at the lowest possible storage cost. Requirement 2: Perform multi-dimensional, ad-hoc SQL queries to correlate log activity with existing enterprise business data. Requirement 3: Stream log events in near real-time to an external Security Information and Event Management (SIEM) tool (such as Splunk or Datadog) for immediate automated alerting. Which log routing architecture should the DevOps engineer implement to satisfy all three requirements?

Exporting and retaining logs (e.g., routing to BigQuery, Pub/Sub, Cloud Storage)

AdvancedProfessional Cloud DevOps Engineer

Your team manages automated CI/CD artifact lifecycles across development and production environments using Google Cloud Artifact Registry. Frequent automated pipeline runs are rapidly inflating cloud storage costs with intermediate untagged layers and expired preview builds. You need to configure automated repository cleanup policies to enforce the following governance and retention criteria: Retain the 10 most recent artifact versions unconditionally, regardless of age or tag status. Protect all production-ready releases tagged with the prod- prefix from deletion indefinitely. Automatically remove untagged container image versions that are older than 14 days. Automatically remove feature branch builds tagged with the feat- prefix that are older than 30 days. Which cleanup policy configuration should you implement in Artifact Registry?

Artifact management with Artifact Registry

AdvancedProfessional Cloud DevOps Engineer

Your microservices application running on Google Kubernetes Engine (GKE) is experiencing high p99 latency spikes during peak hours. The application communicates internally with a Cloud SQL database and externally with a third-party payment gateway via an Internal Application Load Balancer and Cloud NAT. You need to distinguish whether the root cause of the latency bottleneck is caused by internal application processing, internal network round-trip time (RTT), or external service dependencies. Which observability strategy should you implement?

Performance and latency issues

AdvancedProfessional Cloud Data Engineer

A data engineering team manages a real-time analytics web application deployed on a Managed Instance Group (MIG) behind an external Application Load Balancer. During periods of heavy data ingestion, some virtual machines become temporarily busy and are slow to respond to requests. The current configuration uses a single, aggressive health check for both the load balancer and the MIG's autohealing policy. As a result, the autohealer mistakes these busy instances for failed instances and prematurely recreates them, which reduces overall system availability and causes cascading failures. What should you do to ensure the system gracefully handles temporary load spikes while still automatically recovering from true application failures?

Designing system for fault tolerance and managing restarts

Want more questions like this?

Get a free certification question every week.

Last updated August 28, 2026

Are you ready for the Professional Cloud DevOps Engineer?

50 questions in the full practice test

More Analyzing trace waterfalls and spans practice questions

Get a free certification question with a full explanation every week.

Professional Cloud DevOps Engineer

Provider: Google Cloud
Passing score: 70%
Questions: 50
Duration: 90 minutes

Other sections in this exam

Bootstrapping and maintaining a Google Cloud organization
Building and implementing CI/CD pipelines, including continuous testing, for application, infrastructure, and machine learning workloads
Applying site reliability engineering practices
Implementing observability practices and troubleshooting issues
Optimizing performance and cost

Ask Scout

Still curious? Scout, our AI tutor, can explain this concept further and answer your follow-up questions.

An e-commerce checkout service deployed on Google Cloud experiences periodic latency spikes and intermittent transaction failures. While inspecting distributed trace waterfalls in Cloud Trace, a DevOps engineer observes the following behavior across slow requests:

The root span duration exceeds 4,500 ms (normal baseline is 250 ms).
An intermediate span named InventoryService.reserveStock shows normal execution time (40 ms), but its child span for Cloud Spanner database operations shows long duration (over 3,800 ms).
The Spanner span metadata displays standard query execution times of under 15 ms, but contains custom span attributes showing connection wait times exceeding 3,700 ms, accompanied by related application logs with serviceruntime.googleapis.com rate limiting warnings and thread pool exhaustion.
Concurrently, Cloud Monitoring indicates that the Cloud Spanner instance smoothed CPU utilization remains low (under 25%).

What is the primary root cause indicated by this trace waterfall and span metadata analysis?

Database client connection pool exhaustion and client-side contention delaying request acquisition before reaching Cloud Spanner

Network packet loss and routing latency in the VPC between the inventory service and the database instance

Cloud Trace ingestion rate limits dropping spans and artificially elongating trace waterfall durations

Cloud Spanner backend storage saturation causing high disk I/O wait times during transaction commits

Database client connection pool exhaustion and client-side contention delaying request acquisition before reaching Cloud Spanner

What Client-Side Database Contention Is

Client-side connection pool exhaustion occurs when application instances exhaust their configured maximum pool of database client sessions or TCP connections. In distributed tracing, this manifests as high total span latency for database operations even when the remote database itself executes queries swiftly.

How It Meets the Scenario Findings

Span metadata discrepancy: The trace waterfall shows the overall database span taking over 3,800 ms, yet the internal query execution attribute is only 15 ms. The custom attributes pinpoint over 3,700 ms spent waiting to acquire a connection handle from the local client pool.
Low backend CPU: Cloud Spanner smoothed CPU utilization is healthy (< 25%), confirming that the database engine is not experiencing query contention or lock waits on the server side.
Application logs: Correlated application logs confirming thread wait states and connection starvation align directly with client-side connection pool misconfiguration.

Key Advantages and Diagnostic Indicators

Accurate bottleneck identification: Differentiating between client wait time and remote server execution time prevents unnecessary database scaling.
Span attribute correlation: Examining granular attributes (e.g., db.connection_wait_ms vs db.execution_time_ms) pinpoints whether latency is in-flight or on-node.
Holistic observability: Correlating trace waterfalls with server CPU metrics provides conclusive proof of client versus server bottlenecks.

Why This Is Optimal

Evaluating span metadata and comparing individual child span durations against backend resource utilization is the definitive method to isolate client connection pool bottlenecks from true database performance degradation.

Network packet loss and routing latency in the VPC between the inventory service and the database instance

Cloud Trace ingestion rate limits dropping spans and artificially elongating trace waterfall durations

Cloud Spanner backend storage saturation causing high disk I/O wait times during transaction commits