I went into the Professional Cloud DevOps Engineer expecting a CI/CD exam. It isn't one. It's an SRE exam wearing a DevOps hat, and that misunderstanding cost me about two weeks of misdirected study.
Here are the eight things I'd hand my past self.
1. This is Google's SRE book, examined
If you haven't read Site Reliability Engineering and The Site Reliability Workbook, that's your gap. Not because the exam quotes them, but because the entire question style assumes their worldview.
SLIs, SLOs, error budgets, toil, blameless postmortems — these aren't vocabulary items to memorise, they're the framework the correct answers are derived from. When a scenario says "the team is burning through their error budget," the exam expects you to know that the SRE-correct response is to freeze feature releases and redirect to reliability work. If you don't have that reflex, you'll pick the technically reasonable answer instead of the intended one.
Read the free online chapters on SLOs, error budgets, and eliminating toil. Highest-return few hours in the whole prep.
2. Know how to construct an SLI, not just define one
"An SLI is a service level indicator" gets you nothing. The exam wants you to build one from a scenario.
Given "users complain the checkout page is slow," a good SLI is the proportion of HTTP requests to /checkout served in under 300ms, measured at the load balancer. Note the components: a ratio of good events to valid events, a specific threshold, and a specific measurement point.
Then the SLO is the target over a window (99.5% over 28 days), and the error budget is what's left over (0.5%, which is roughly 3.4 hours in 28 days). Be able to do that arithmetic quickly — questions do ask.
Measurement point matters more than people expect. Measured at the server, you miss network and client latency. Measured at the client, you include things you don't control. Scenarios exploit that distinction.
3. Cloud Operations suite in real depth
Formerly Stackdriver, and the naming drift in older material is a genuine hazard.
You need working fluency in:
- Cloud Monitoring — metrics, custom metrics, uptime checks, alerting policies, notification channels
- Cloud Logging — log sinks, exclusion filters (a cost-control answer that comes up repeatedly), log-based metrics, retention
- Cloud Trace — distributed tracing and latency analysis
- Cloud Profiler — CPU and heap profiling in production
- Error Reporting — aggregation and dedup of exceptions
The distinction that catches people: when do you reach for Trace versus Profiler? Trace tells you which service in a request path is slow. Profiler tells you which function inside a service is burning CPU. A scenario about a slow microservice chain wants Trace; a scenario about one service with high CPU and no obvious cause wants Profiler.
4. Alerting questions are about alert quality
There's a recurring theme: the team is drowning in alerts and ignoring them. The wrong answers add more alerts or raise thresholds arbitrarily. The right answer is almost always to alert on symptoms rather than causes, tie alerting to SLO burn rate rather than raw metrics, and delete alerts that aren't actionable.
Understand multi-window, multi-burn-rate alerting — fast burn catches acute outages, slow burn catches steady degradation. It shows up.
5. The deployment strategy questions have precise answers
Blue/green, canary, rolling, and recreate. Each has a distinct cost, risk, and rollback profile, and the scenario tells you which one it wants if you read for the constraint.
- Instant rollback required, budget for double capacity → blue/green
- Limit blast radius, gradual confidence, need real production traffic to validate → canary
- Resource-constrained, some capacity reduction acceptable → rolling
- Downtime acceptable, simplest → recreate
Also know traffic splitting on Cloud Run and GKE, and where Cloud Deploy fits as a delivery pipeline orchestrator versus Cloud Build as the build engine.
6. GKE operations, not GKE fundamentals
The exam assumes you can run a cluster. What it tests is operating one: node pools and autoscaling (cluster autoscaler vs HPA vs VPA and when each applies), workload identity for pod-level GCP auth, pod disruption budgets, resource requests and limits and what happens when you get them wrong, and multi-cluster patterns.
Debugging questions here are practical: a pod is CrashLoopBackOff, or pending and unschedulable, or being OOMKilled. Know what you'd check and in what order.
7. Incident response has a right structure
Roles matter: incident commander, communications lead, operations lead. The exam wants clean separation — the person fixing it isn't the person updating stakeholders.
Postmortems are blameless, focused on systemic contributing factors, and produce tracked action items. Any answer option that includes identifying who made the mistake is wrong, every time.
8. Test yourself early, because your instincts are the problem
This is the one that actually mattered.
I've done DevOps work for years, so I assumed I'd be strong on the operational domains and weak on the Google-specific tooling. Exactly backwards. The tooling I picked up in days. Where I lost points was on SRE doctrine — because I kept answering with what my previous teams did rather than what Google's model prescribes, and those diverge more than you'd think.
The only way I found that out was doing timed questions in week two instead of week five. A set of free GCP Professional Cloud DevOps Engineer practice questions run cold is a brutally efficient diagnostic — and the domain-level breakdown in the full Cloud DevOps Engineer prep is what showed me the shape of the problem rather than just a score I could rationalise.
Logistics
Two hours, roughly 50–60 questions, $200 plus tax, two-year validity with a cheaper renewal exam. Google changed exam delivery providers during 2026, so give yourself scheduling headroom.
Timeline
Practising SRE or platform engineer already on GCP: three to four weeks, mostly SLO/error-budget doctrine and the Cloud Operations suite.
DevOps engineer from another cloud: five to six weeks. The concepts transfer, the doctrine and the tooling both need work.
Developer with no operational background: this is the wrong exam for now. Run something in production first — the questions assume you've been paged.
The exam rewards a specific way of thinking about reliability. Learn the way of thinking and the tooling questions answer themselves.
Top comments (0)