PCDOE Implementing service monitoring strategies Practice Question
A company runs a multi-region web application on Google Kubernetes Engine (GKE) using Cloud Load Balancing and Cloud Armor. They use Cloud Monitoring to track user-facing latency. Recently, they noticed that the p99 latency has increased from 200ms to 2s during peak hours, but only for users in the US region. The team suspects a specific backend service in us-central1 is causing the spike. They have set up a dashboard showing latency by region, but the latency metric is aggregated globally, not broken down by region. What should they do to pinpoint the issue?
⚠ Common exam trap
Test-takers frequently assume per-pod metrics (Option C) are sufficient for user-facing latency analysis, but GKE Dashboard metrics are infrastructure-focused and lack the regional breakdown needed to isolate a specific backend service's impact on global p99 latency.
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
✓
Create a custom log-based metric that extracts latency per region from application logs.
Creating a custom log-based metric that extracts latency per region from application logs allows you to break down the globally aggregated latency metric into per-region slices. This directly addresses the need to isolate the us-central1 backend service's impact on p99 latency during US peak hours, without requiring additional infrastructure or third-party tools.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Deploy a sidecar proxy in each pod to collect detailed latency data and export it to a third-party tool.
Why it's wrong here
This adds unnecessary complexity and cost; Cloud Monitoring already supports custom metrics without third-party tools.
- ✗
Use Cloud Monitoring's 'Service Monitoring' to set up a service SLO and create a burn-rate alert.
Why it's wrong here
Service Monitoring helps define and track SLOs, but it won't provide per-region granularity; it uses the same aggregated metrics.
- ✗
Use the GKE Dashboard to view per-pod latency metrics.
Why it's wrong here
The GKE Dashboard shows pod-level metrics but not latency broken down by external user region; it cannot isolate the regional backend issue.
- ✓
Create a custom log-based metric that extracts latency per region from application logs.
Why this is correct
Log-based metrics allow you to parse latency values and labels (e.g., region) from structured logs, providing per-region latency data to pinpoint the issue.
Go deeper
Related to this question
About these practice questions
Courseiva writes every PCDOE question from scratch — 486 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This PCDOE 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 PCDOE exam.