GCP Professional Cloud DevOps Engineer: The Cert That Proves You Own the Delivery Pipeline

Domain 1 — Bootstrapping a Google Cloud Organisation for DevOps (~17%)

Before a pipeline can run, the organisational structure and permissions model that governs it must exist. This domain tests:

• Resource hierarchy design: Organisation → Folder → Project → Resource. Policy inheritance flows downward; the exam tests where to attach IAM bindings and Organisation Policy constraints to enforce least-privilege at scale without blocking legitimate cross-project access patterns.
• IAM for CI/CD workloads: Service account design for Cloud Build workers (the service account that executes build steps needs access to Artifact Registry, GCS, and the target deployment surface but nothing else). Workload Identity Federation for authenticating external CI runners (GitHub Actions, GitLab CI, Jenkins on-premises) to GCP APIs without static service account keys — this is the exam-preferred pattern over key files because it eliminates key rotation and leakage risk entirely.
• Binary Authorization: a deploy-time admission controller that allows only container images attested by authorised attestors to run on GKE or Cloud Run. The policy is evaluated at pod scheduling, not at image build time. The exam tests how to design a Binary Authorization policy chain (build attestor → QA attestor → security attestor) where each stage signs the image digest and the policy enforces all three attestations before a production deployment can proceed.
• Organisation Policy Service: constraint-based guardrails applied at folder or organisation scope that enforce baseline security posture — for example, constraints/compute.requireShieldedVm, constraints/iam.disableServiceAccountKeyCreation, or constraints/run.allowedIngress restricting Cloud Run services to internal traffic only. These take effect at resource creation, not at runtime, which distinguishes them from IAM conditions and VPC firewall rules.

Domain 2 — Building and Implementing CI/CD Pipelines (~23%)

The highest-weighted domain. Tests end-to-end pipeline design on GCP-native tooling:

• Cloud Build: the serverless build execution engine. cloudbuild.yaml defines a sequence of steps, each running a Docker image. Build triggers connect source events (push to branch, tag creation, pull request) in Cloud Source Repositories, GitHub, or GitLab to build execution. Substitution variables ($BRANCH_NAME, $SHORT_SHA, $REPO_NAME) parameterise builds without hard-coding environment-specific values. Build caching via GCS or Kaniko layers reduces build times for dependency-heavy workloads. Private pools run builds in a dedicated VPC for workloads that need access to private resources not reachable from the public build environment.
• Artifact Registry: the managed repository for container images (Docker), language packages (npm, PyPI, Maven, Go), and Helm charts. Format-specific repositories with fine-grained IAM on individual repos replace the legacy Container Registry. Vulnerability scanning on push surfaces CVEs before images reach a deployment target. Remote and virtual repositories proxy and aggregate public upstream registries for build environments that require supply-chain controls or air-gapped access.
• Cloud Deploy: managed continuous delivery with explicit promotion between delivery pipeline stages (dev → staging → production). Each release targets a delivery pipeline; promotion is manual by default (requires a human or automated approval step to advance). Rollback reinstates the previous successful release. Supports GKE, Cloud Run, and Anthos targets. The exam tests Cloud Deploy against the pattern where direct ad-hoc deployment to production must be eliminated: Cloud Deploy’s audit trail and promotion gating make it the architectural answer for regulated or high-reliability environments.
• Deployment strategies: Rolling update (GKE replaces pods incrementally, keeping a minimum available percentage during the update — suitable when the application handles mixed-version traffic gracefully). Blue/green (two parallel environments; traffic switches atomically via load balancer reconfiguration — zero-downtime, easy instant rollback, higher cost during the transition). Canary (a weighted traffic split routes a small percentage to the new version while the majority continues to hit the stable version — GKE traffic management via Istio or Gateway API, Cloud Run traffic splitting natively). A/B testing (canary variant with user-segment-based routing rather than random weighted split — requires request-header or cookie-based routing rules). The exam maps stated requirements (zero downtime, instant rollback, production traffic validation before full rollout, cost minimisation) to the correct strategy.
• GitOps: Config Sync (part of GKE Enterprise / Anthos Config Management) watches a Git repository as the single source of truth for GKE cluster configuration and synchronises the cluster state to match the repo. Policy Controller enforces constraints (OPA Gatekeeper) across all managed clusters. The exam presents GitOps as the answer for multi-cluster configuration drift prevention, where an operator modifying cluster state directly must be detected and reconciled back to the declared Git state.

Domain 3 — Applying SRE Practices to a Service (~25%)

The deepest domain and the one most distinct from equivalent AWS or Azure certifications. Google’s SRE framework is not a vendor abstraction — it is the operational philosophy the exam tests directly, drawn from the public SRE Book and Site Reliability Workbook.

• SLI/SLO/SLA hierarchy: a Service Level Indicator (SLI) is the quantitative measure of service behaviour from the user’s perspective — availability (percentage of successful requests), latency (99th percentile response time), throughput, or error rate. A Service Level Objective (SLO) is the target value or range for the SLI over a rolling window (e.g. 99.5% of requests complete successfully over a 28-day rolling window). An SLA is the contractual consequence of missing the SLO. The exam tests the distinction: SLIs are measurements, SLOs are targets, SLAs are consequences. Candidates must know how to select an appropriate SLI for a given service type (request-driven services vs pipeline/batch services vs storage systems have different natural SLIs).
• Error budget: the complement of the SLO. A 99.5% availability SLO implies a 0.5% error budget over the window — the amount of permitted unreliability. When the budget is full, teams deploy features at full velocity. As the budget burns, deployment velocity is gated or halted and reliability work takes priority. When the budget is exhausted, all feature releases stop until the budget replenishes or the SLO is renegotiated. The exam presents error budget burn rate scenarios: a service consuming 10% of its monthly error budget in two hours is on track to exhaust it in 20 hours — the correct action is to halt deployments and engage the on-call team, not to wait until the budget is fully consumed.
• Toil reduction: toil is manual, repetitive, automatable operational work that scales linearly with service size and produces no lasting value. The SRE principle is to cap toil at 50% of team capacity and spend the remainder on engineering work that eliminates future toil. The exam tests recognition of toil in a scenario description (manual approval gates that could be automated, repeated manual scaling operations, recurring runbook steps that could be codified) and asks candidates to identify the automation that eliminates it.
• Postmortem culture: blameless postmortems focus on systemic causes rather than individual mistakes. A postmortem includes a timeline of events, root cause analysis, impact quantification, action items with owners and deadlines, and a lessons-learned section. The exam tests what a postmortem must include (action items are mandatory; blaming individuals is excluded) and when a postmortem is required (typically when an incident breaches the error budget or causes user-visible impact above a threshold).
• Capacity planning: load testing to establish service headroom, defining the point at which the service degrades under traffic (the knee of the curve), and provisioning buffer capacity to absorb demand spikes without SLO impact. GKE Horizontal Pod Autoscaler (CPU/memory metrics or custom metrics from Cloud Monitoring) and Vertical Pod Autoscaler (right-sizing container resource requests) are the GCP tools the exam maps to capacity management.

Domain 4 — Implementing Service Monitoring Strategies (~20%)

The Google Cloud Observability Suite is the toolset this domain tests in depth. The exam distinguishes which tool addresses which observability gap:

• Cloud Monitoring: metrics collection, custom metrics via the Cloud Monitoring API or OpenTelemetry, dashboards, and alerting policies. An alerting policy defines a condition (metric threshold, absence of data, forecast crossing a threshold) and a notification channel (email, PagerDuty, Slack via Pub/Sub). Alerting on SLO burn rate rather than raw error count is the exam-preferred approach: a fast burn rate alarm triggers even when the absolute error count is low but the rate of consumption indicates budget exhaustion is imminent — earlier warning, fewer false positives at normal traffic volumes.
• Cloud Logging: structured log ingestion at scale. Log sinks export log data to BigQuery (SQL-based long-term analysis and audit), Cloud Storage (archive compliance), or Pub/Sub (real-time streaming to external SIEM or processing pipeline). Log-based metrics create Cloud Monitoring metrics from log entries matching a filter — the pattern for alerting on application-level events that only appear in logs, not in infrastructure metrics. Log exclusions reduce ingestion cost by discarding high-volume, low-signal log entries before they land in the log bucket.
• Cloud Trace: distributed request tracing across microservices and serverless functions. Trace automatically collects spans from App Engine, Cloud Run, and GKE workloads using the OpenTelemetry SDK or the Cloud Trace API. The exam answer when a scenario asks how to identify which microservice in a distributed system causes p99 latency degradation is Cloud Trace — not Cloud Monitoring, which aggregates infrastructure metrics without call-chain correlation.
• Cloud Profiler: continuous production profiling of CPU time, heap allocation, and wall time for Go, Java, Python, and Node.js services running on GCP compute. Profiler adds negligible overhead (<1%) and is designed to run continuously in production rather than on-demand in staging only. The exam uses Profiler scenarios for diagnosing sustained CPU saturation or memory leak patterns that do not produce obvious log errors but do manifest in latency and resource metrics.
• Error Reporting: aggregates and deduplicates application exceptions across Cloud Logging, App Engine, Cloud Functions, Cloud Run, GKE, and Compute Engine. Groups identical stack traces into a single error event with occurrence count, first-seen and last-seen timestamps, and affected version information. The exam answer when a scenario asks for the fastest way to triage which exceptions are most impactful in production is Error Reporting, not manual log search.

Domain 5 — Optimizing Service Performance (~15%)

• Identifying performance bottlenecks: the diagnostic chain runs from Cloud Monitoring (resource saturation signals: CPU, memory, disk I/O, network throughput) → Cloud Trace (call-chain latency) → Cloud Profiler (code-level CPU/heap) → Cloud Logging (error patterns). The exam presents a symptom (p99 latency spike, OOM kills, sustained high error rate) and asks which diagnostic tool reveals the root cause and in what order to apply them.
• Rightsizing: Vertical Pod Autoscaler recommendations adjust container CPU and memory request/limit values based on observed utilisation. GKE Node Auto-provisioning creates node pools matched to pending pod requirements instead of requiring manual node pool configuration. Cloud Run automatically scales to zero and up to the configured maximum concurrency; the concurrency setting (requests handled per container instance simultaneously) is the primary knob for cost vs latency under variable load.
• Caching and CDN: Cloud CDN integrated with HTTP(S) Load Balancing caches responses at Google edge PoPs for cacheable content types (static assets, API responses with appropriate Cache-Control headers). The exam tests when to apply CDN (high cache-hit ratio expected, global users, read-heavy content) vs when it adds no value (highly personalised responses, write-heavy APIs, non-cacheable authentication endpoints). Memorystore (managed Redis or Memcached) provides in-memory caching for session state, frequently-read database results, and rate-limiting counters — the exam answer when database read IOPS are saturated but the access pattern is repetitive and latency-sensitive.
• Database optimisation: Cloud Spanner query insights surface slow queries and their execution plans. Cloud SQL Insights identifies top wait events and query latency outliers. BigQuery slot utilisation and query plan analysis via the INFORMATION_SCHEMA views identify expensive scan patterns. The exam asks candidates to interpret a provided query plan or utilisation chart and identify the optimisation (index addition, partition pruning, slot reservation, query rewrite) that addresses the stated performance problem.
• Load shedding and rate limiting: the design pattern for protecting a service from overload. Google Cloud Armor rate-based rules reject requests exceeding a configured threshold at the global load balancer edge — before traffic reaches the backend, protecting capacity for legitimate users. The exam tests load shedding as the answer when a scenario describes a service that degrades for all users during traffic spikes rather than gracefully rejecting excess requests.