Professional Cloud DevOps Engineer
Prepare and test your skills
Prepare and test your skills
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.
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?
A trace waterfall visualization (or Gantt chart) in Cloud Trace displays the lifecycle of a request as a tree of nested, timed spans. Spans represent discrete units of contiguous work, while parent-child relationships depict service call hierarchies and nested sub-operations.
get_user_profile (50 ms – 150 ms) and fetch_loyalty_points (50 ms – 170 ms) share the exact same start offset (50 ms). Because their execution windows overlap under the parent checkout_handler, they run concurrently. The subsequent step (process_order) starts at 170 ms, exactly when the slower parallel span finishes.process_order, reserve_inventory runs from 180 ms to 330 ms, after which call_payment_gateway begins at 330 ms. Because their execution windows do not overlap, these operations execute sequentially.http_post_external_psp takes 1,060 ms out of the total 1,450 ms request duration (over 73% of total request time). Because it sits directly on the sequential critical path, optimizing or asynchronously handling this external payment gateway call is the key to reducing endpoint latency.This interpretation directly reflects the exact timeline and structural dependencies of the distributed trace, correctly recognizing both parallel execution windows and sequential blocking operations.
Keep the momentum going with these hand-picked practice scenarios
Want more questions like this?
Get a free certification question every week.
Still curious? Scout, our AI tutor, can explain this concept further and answer your follow-up questions.