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.
Keep the momentum going with these hand-picked practice scenarios
Want more questions like this?
Get a free certification question every week.
Last updated
An online retail platform running microservices on Google Kubernetes Engine (GKE) with Cloud Service Mesh triggers an alert due to a violation of its user-facing latency Service Level Objective (SLO).
A DevOps engineer investigates the incident in Cloud Monitoring Metrics Explorer and correlates the following multi-dimensional golden signal metrics across tiers:
StudyCerts
StudyCertshttps/total_latencies at the 95th percentile, with steady request volume.How should the DevOps engineer interpret these correlated metrics to identify the root cause of the degradation?
A Cloud Service Mesh DNS resolution failure occurred at the sidecar proxy level, preventing healthy backend instance groups from registering with the external load balancer.
The external Application Load Balancer experienced a frontend network throughput bottleneck, which delayed packet delivery to clients and created backpressure that saturated the backend CPU.
An unmanaged sudden spike in external user traffic overloaded the Istio ingress gateway, resulting in misrouted requests and false-positive CPU saturation metrics on the backend.
The backend service experienced resource saturation (CPU exhaustion), which degraded its processing capacity, leading to backend 5xx errors and upstream response delays that cascaded to the frontend load balancer.
A Cloud Service Mesh DNS resolution failure occurred at the sidecar proxy level, preventing healthy backend instance groups from registering with the external load balancer.
The external Application Load Balancer experienced a frontend network throughput bottleneck, which delayed packet delivery to clients and created backpressure that saturated the backend CPU.
An unmanaged sudden spike in external user traffic overloaded the Istio ingress gateway, resulting in misrouted requests and false-positive CPU saturation metrics on the backend.
The backend service experienced resource saturation (CPU exhaustion), which degraded its processing capacity, leading to backend 5xx errors and upstream response delays that cascaded to the frontend load balancer.
Correlating golden signals across architectural boundaries allows engineers to trace the causal relationship between underlying infrastructure constraints and user-facing SLO degradation. When analyzing multi-tier distributed applications, saturation metrics (such as container CPU utilization) often represent the foundational catalyst for downstream performance anomalies.
https/total_latencies on the external load balancer.RESPONSE_FLAGS and upstream status codes with workload CPU reveals whether the proxy layer or application backend is failing.Analyzing telemetry in a structured top-down or bottom-up flow—connecting saturation, error rate, and latency—establishes a definitive causal chain. This accurately targets remediation efforts (such as horizontal pod autoscaling or query optimization) directly at the backend microservice.