Google PCA Ensure solution and operations reliability Practice Question
Your service has a 99.99% uptime SLO (monthly error budget ~ 4 minutes). Which TWO monitoring practices best support this SLO? (Choose 2)
⚠ Common exam trap
PCA often tests the difference between resource metrics (CPU, memory) and user-centric SLIs — candidates pick CPU alerts because they are familiar, missing that SLOs must be measured with user-facing indicators and error budget burn.
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
✓
Use a combination of availability (e.g., HTTP 200 rate) and latency (e.g., p99) as SLIs.
Option B is correct because a 99.99% uptime SLO is best measured with SLIs that reflect user-perceived health, so combining an availability SLI (the proportion of successful HTTP 200 responses) with a latency SLI (such as p99 request duration) captures both whether requests succeed and whether they are served acceptably fast. Option E is correct because with a monthly error budget of roughly 4 minutes, tracking error budget consumption and alerting on a burn rate threshold (for example, a fast-burn alert at 14.4x over 1 hour or a slow-burn alert at 6x over 6 hours) detects when the budget is being exhausted too quickly and enables timely action. Option A is not correct because CPU utilization is a resource metric, not a direct SLI for an uptime SLO, and an 80% average threshold does not reliably indicate user-visible failures. Option C is not correct because relying only on synthetic monitoring from multiple locations omits real user traffic and can miss failures that affect actual customers. Option D is not correct because alerting on every 5xx error immediately is too noisy and does not account for error budget policy or burn rate.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Monitor CPU utilization and alert when average exceeds 80%.
Why it's wrong here
CPU utilisation is a leading indicator, not user-visible availability, so it cannot measure the 99.99% uptime SLO or burn its four-minute error budget. It is tempting because resource alerts are standard operational hygiene, but this SLO requires request-success and latency SLI monitoring, which directly quantify user-facing failures.
- ✓
Use a combination of availability (e.g., HTTP 200 rate) and latency (e.g., p99) as SLIs.
Why this is correct
Availability alone misses degraded-but-successful responses, which still breach user expectations on a 99.99% target. Pairing HTTP 200 rate with p99 latency captures both failure and slowness, so the SLI reflects the actual user experience the SLO promises.
- ✗
Use only synthetic monitoring from multiple locations.
Why it's wrong here
Synthetic probes from multiple locations only exercise scripted paths, so real user failures never consume the error budget and remain invisible. It is tempting because synthetic checks suit availability verification of known endpoints and external reachability, but the SLO needs real-traffic SLI measurement, not simulated requests.
- ✗
Alert on every 5xx error immediately.
Why it's wrong here
Alerting on every 5xx immediately floods responders with noise, so genuine error-budget burn is buried and the 4-minute monthly budget is consumed before anyone reacts. It is tempting because per-error alerting suits low-traffic services where each failure is individually significant, but here burn-rate alerting is required.
- ✓
Track error budget consumption and alert when burn rate exceeds a threshold.
Why this is correct
A 99.99% SLO leaves roughly four minutes monthly, so waiting for full outage detection is too slow. Burn-rate alerting tracks how fast the error budget depletes, triggering early when consumption outpaces the sustainable rate, giving time to react before the budget exhausts.
Go deeper
Related to this question
Learn chapter
IAM Policies, Service Accounts, and Auditing
Key term
SLO
A Service Level Objective is a measurable target for a specific aspect of a service's performance or reliability that a team commits to meeting over a defined period.
Key term
Latency
Latency is the time delay between a request being sent over a network and the response being received, often measured in milliseconds.
About these practice questions
This PCA question is part of Courseiva's 807-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Google Cloud exam blueprint
This PCA 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 PCA exam.