Google Cloud Professional Cloud DevOps Engineer — study guide
Prepared 21 October 2026. Read progressively over the 24-week plan. Follow the documentation links for implementation details and changing product behavior. This is an objective-mapped guide, not an exhaustive product manual or a prediction of actual exam questions.
0. Foundations
Cloud computing provides compute, storage and networking through APIs. Managed services reduce some operational work; you still own application behavior, permissions, configuration and costs.
A project groups resources and is an important API/quota/administrative boundary. A billing account pays for linked projects. A region is a geographic area; a zone is a deployment area within a region. A regional deployment is not automatically resilient to a regional outage. Resource hierarchy.
Authentication establishes who calls; authorization decides what they may do. A principal receives access. A role contains permissions; a binding grants that role on a resource. A service account is a workload identity. A downloaded key is one credential mechanism, not the identity itself. IAM.
HTTP uses requests and responses. A 2xx response generally indicates successful protocol handling, 4xx a client request problem, and 5xx a server failure. Application success may require more than HTTP 200. Latency is elapsed request time; throughput is work per interval. An average can hide poor tail behavior.
Git records changes; branches and pull requests support review. CI builds/tests frequently. CD manages delivery through environments. A container image packages a runnable filesystem and metadata; a container is a running instance. A digest identifies image content; a tag is a reference that can move unless constrained. Kubernetes schedules pods and reconciles desired state. GKE is managed Kubernetes; Cloud Run runs suitable containerized workloads without a cluster that you operate.
Infrastructure as code records intended resources in versioned configuration. Terraform compares configuration, state and provider observations to propose changes. Plan success is not a guarantee of application safety.
Logs describe events; metrics aggregate measurements; traces follow requests; profiles attribute resource use to code. Explain which one answers your question before choosing a tool.
Before continuing, explain: image/container, identity/permission, region/zone, CI/CD, metric/log, and code rollback/database recovery.
1. Organization and infrastructure — about 20%
1.1 Hierarchy, IAM, networking and residency
Match organization/folder/project boundaries to ownership and policy inheritance. Separate production from experiments through appropriate projects, identities and governance. An organization per team is usually unnecessary; multiple organizations can still be legitimate for particular business/trust requirements. Avoid the old absolute rule of exactly one organization per company.
Allow grants accumulate across applicable hierarchy and group memberships. Removing a project grant does not remove an inherited grant. Defining a custom role does not grant access: the binding determines its scope. An applicable deny overrides an allow for supported permissions, subject to conditions/exceptions. Do not assume a universal 'deny every possible API permission' shortcut exists. Deny policies.
Organization policies constrain supported resource configurations. Check constraint type, resource support, inheritance and enforcement. compute.vmExternalIpAccess is a list constraint. Location restrictions do not migrate existing data or prove every service's residency behavior: inspect backups, replicas and processing. Organization policies, locations.
| Requirement | Starting point | Verify |
|---|---|---|
| Central networking across workload projects | Shared VPC | Host/service projects, scoped subnet use, firewall ownership |
| Connect independently administered VPCs | VPC Network Peering | Address overlap, routes, non-transitivity, firewalls |
| Privately consume one published service | Private Service Connect | Supported producer/consumer configuration |
| Limit supported Google API data movement | VPC Service Controls | Services, perimeter rules, IAM, connectivity |
| Restrict arbitrary internet destinations | Network/proxy egress controls | Actual routing and egress path |
Read Shared VPC, peering, PSC, and VPC Service Controls. Docker Hub is not a Google service-perimeter egress target.
For external CI, prefer Workload Identity Federation where supported. Constrain issuer/audience and tenant/repository claims, then authorize resource access directly or through scoped impersonation. Short-lived credentials still convey powerful permissions while valid. GKE federation supports direct resource grants and a service-account impersonation pattern; the latter is not mandatory for every supported use. External federation, GKE federation.
Service Account User (actAs) and Token Creator are not interchangeable. Privileged Access Manager supports approved, expiring elevation. Include impersonation edges when reviewing effective privilege. Impersonation, PAM.
1.2 Infrastructure management
- Terraform plans and manages infrastructure. Protect state; review replacements/deletions; isolate environments and execution identities.
- Infrastructure Manager offers a Google-managed Terraform workflow.
- Config Connector represents supported Google Cloud resources through Kubernetes APIs/controllers.
- Helm packages/templates Kubernetes configuration; Kustomize customizes plain manifests with bases/overlays.
- Cloud Foundation Toolkit provides reusable foundations/blueprints. Inspect what a blueprint creates.
A GCS backend supports locking. Bucket versioning is a separate recovery setting. State can contain sensitive values; protect backend access and test recovery. GCS backend, Infrastructure Manager, Config Connector, Helm, Kustomize.
Make automation idempotent and observable: stable identifiers, reconciliation of existing state, bounded retries, explicit failures and least privilege. Practice a Python script that reports drift before changing anything.
1.3 CI/CD architecture
A common path is source → Cloud Build tests/build → Artifact Registry digest → Cloud Deploy release → target rollout → verification. Skaffold supports rendering/deployment. Helm/Kustomize can supply target configuration. Understand Git, Jenkins and Argo CD as alternative/complementary tools; Packer builds machine images and kpt manages Kubernetes configuration.
A private build pool does not automatically solve DNS, routing, peering transit, firewall, service IAM or perimeter restrictions. Inspect the actual supported path to a private database. Ordinary VPC peering through an intermediate network is not transitive. Private pools, Cloud Deploy.
When GitOps is authoritative, update the declaration. Competing controllers can repeatedly undo each other's changes.
1.4 Environments, fleets and upgrades
Preview environments need isolated data/credentials, ownership, expiry and teardown. Untrusted PR code must not inherit production credentials. Test in representative environments while acknowledging differences in production load.
Fleet registration does not automatically enforce every desired policy. Roll configuration through waves with health gates and reversal plans. For GKE upgrades, understand release channels, maintenance settings, version compatibility, disruption budgets and spare capacity. One replica with zero voluntary disruptions can block maintenance. Fleets, upgrades, Config Sync.
1.5 Development and AI assistance
Cloud Shell is useful for browser administration. Cloud Workstations provides managed development environments with configurable images, networking, storage and idle lifecycle. Browser access alone does not make their controls equivalent. Cloud Shell, Workstations.
Understand Gemini Code Assist for development, Gemini Cloud Assist for operations, and Gemini CLI for supported terminal work. Validate generated code/commands and cited evidence; keep normal review/testing controls. Particular investigation features have current access and support limitations. Code Assist, Cloud Assist, investigations.
2. CI/CD and continuous testing — about 25%
2.1 Pipeline design
Run fast deterministic tests early, integration tests against realistic isolated dependencies, and appropriate end-to-end/load/security gates. Required repository checks enforce merges; a build trigger alone does not. PR deployments can be valid isolated previews. Distinguish their trust boundary from production promotion.
Standard repositories store artifacts; remote repositories proxy/cache supported upstreams; virtual repositories provide an ordered access point to compatible upstream repositories. Configure authentication, priority and consumption paths. Cleanup retention must preserve recovery artifacts. A cache does not eliminate every upstream dependency. Build schema, triggers, repositories, cleanup.
For ML, version data/code/parameters, record lineage and evaluate business and segment-level outcomes. Monitor live quality/drift and retain recovery options. Higher average accuracy alone may be insufficient. Vertex AI Pipelines.
2.2 Delivery and rollback
| Pattern | Purpose | Concern |
|---|---|---|
| Rolling | Replace capacity gradually | Mixed versions, surge capacity |
| Canary | Evaluate a limited population | Sample size, representation, health criteria |
| Blue/green | Switch to a prepared parallel environment | Extra capacity, routing and state |
| Feature flag | Separate deployment from activation | Tested kill switch and flag lifecycle |
| Shadow/dark launch | Compare new behavior without serving its output | Duplicate writes, privacy and extra load |
Cloud Deploy documents native standard and canary strategies. Do not invent a blueGreen strategy switch from the general architecture pattern. Check supported runtimes and customization. Strategies.
Promote the tested digest; render and validate target-specific configuration. Different environments need not have byte-identical manifests. A release captures deployable information; a rollout applies it to a target. Verification runs defined checks; remediation requires configured or operator action. Verification, rollback.
Code rollback cannot undo external state automatically. Use compatible expand/contract migrations when appropriate: add compatible structures, migrate consumers/data, remove old structures after the rollback window. Maintain source → build → digest → approval → release → rollout evidence.
2.3 Configuration and secrets
Separate build and runtime principals. Grant access at the smallest useful scope. Secret retrieval does not prevent a program from printing values: avoid shell tracing, environment dumps, build layers and unsafe arguments. Rotation needs an application consumption/refresh strategy. Secret practices, build secrets.
Parameter Manager stores versioned workload configuration and can reference secrets. Certificate Manager handles supported TLS certificate lifecycle/integrations. KMS manages cryptographic keys; rotation does not universally re-encrypt existing ciphertext. Retain required old versions until dependent data no longer needs them. Parameters, certificates, rotation.
2.4 Supply-chain security
Scanning yields vulnerability findings. Provenance records build information. Verified attestations assert specified checks for an artifact. Binary Authorization enforces configured trust requirements. A signature issued before tests is not evidence that tests passed. A KMS-backed signer is useful, but avoid claiming every valid attestation must use KMS.
SLSA describes supply-chain security properties. Understand trustworthy provenance, builder identity and digest binding; it does not prove an application is bug-free. New findings require ongoing assessment after admission. Emergency bypasses need authorization, audit and follow-up. Binary Authorization, SLSA, provenance.
3. Site reliability engineering — about 18%
3.1 SLIs, SLOs and budgets
An SLI measures behavior; an SLO sets a target over a defined population/window; an SLA is a contractual commitment. Define good and eligible events around user availability, latency, freshness or correctness. HTTP success alone may not mean business success.
SLI = good eligible events / total eligible events
Allowed bad events = total eligible events × (1 − SLO)
Budget used = observed bad events / allowed bad events
Burn rate = observed bad-event ratio / (1 − SLO)
Approximate budget fraction used = burn rate × elapsed time / SLO period
The time approximation for request budgets assumes suitably steady traffic. Prefer actual event counts when traffic varies. Downtime minutes directly describe time-based availability, not every request-based SLO.
Exactly 30 days contains 43,200 minutes. A time-based 99.9% target permits 43.2 minutes; 99.95% permits 21.6; 99.99% permits 4.32. For 2 million requests at 99.95%, the allowance is 1,000 bad requests. Keep fractions, percentages and units consistent.
Useful SRE workbook starting examples for 30-day budgets: page at 14.4× over 1h with 5m confirmation, OR 6× over 6h with 30m confirmation. A lower urgency example uses 1× over 3 days with 6h confirmation. Within a branch use AND. Tune thresholds to the service rather than treating examples as mandatory constants. Alerting on SLOs.
Define an agreed budget policy: when to slow feature work, prioritize reliability and allow justified security/reliability exceptions. Do not hide failures with retrospective measurement changes. Internal targets should support customer commitments, considering both measurement definitions and investment. SLO implementation, budget policy.
3.2 Lifecycle and capacity
Before launch define owners, dependencies, targets, monitoring, capacity and recovery. Before retirement identify consumers, migration, retained data and obsolete credentials. Measure toil and invest in repeatable improvements; Google's 50% operational-work principle is an organizational model, not a product limit. Toil.
HPA changes pod count; cluster autoscaling supplies node capacity for schedulable demand. Requests, affinity/taints and shape constraints matter. Autoscaling cannot bypass quota or an overloaded database. Quota permits consumption; reservations address matching capacity; commitments concern pricing/usage obligations. HPA, cluster autoscaler, reservations.
Learn managed instance group, Cloud Run and GKE scaling as different control loops. Dynamic Workload Scheduler flex-start can help supported jobs with flexible start times obtain scarce resources; check resource eligibility, duration and scheduling semantics. Cloud Run autoscaling, flex-start.
3.3 Incidents
Restore service using evidence-based mitigation: compatible rollback, a tested flag, traffic draining/shifting, shedding noncritical load or adding useful capacity. Check destination headroom before failover; unlimited retries/concurrency may amplify overload.
Coordinate incident command, operations and communication and record a timeline. After recovery, examine systemic conditions without blame and assign verifiable improvements. Practice controlled failures with a hypothesis, limited scope and abort criteria. Incident management, postmortems.
4. Observability and troubleshooting — about 25%
4.1 Collection
Use Ops Agent for supported VM telemetry, OpenTelemetry for applications/context, and managed Prometheus collection for compatible metrics. Audit logs, VPC Flow Logs and Cloud Service Mesh telemetry answer different questions. One does not automatically supply every other signal.
Use bounded metric dimensions such as service/version/result, not unique user IDs. Use latency distributions for tail behavior. Store per-request detail in protected logs/traces. Redact unnecessary sensitive values before export; display filters do not erase stored data. Ops Agent, Managed Prometheus.
Uptime probes check endpoints; synthetic monitors can exercise workflows with assertions. Use safe test accounts/side effects and test notification delivery. Synthetic monitoring.
4.2 Logs
Sinks route; buckets store; views restrict accessible subsets when paired with IAM; scopes define query sets. A narrow grant does not remove a broader grant. Aggregated sinks need correct descendant scope/filter and destination permissions. One sink exclusion does not remove all copies. Routing, views, scopes.
Use log buckets for Logging analysis/retention, BigQuery for appropriate SQL analysis, Pub/Sub for streaming integrations and Cloud Storage for suitable archives. Retention locks constrain later changes; _Required is not an arbitrary central catch-all destination.
Example Logs Explorer filter:
resource.type="cloud_run_revision"
resource.labels.service_name="payments"
severity>=ERROR
Use a precise time range, labels and correlation identifiers. SQL belongs in supported analytics interfaces; the Logging query language differs. Query language, buckets.
4.3 Metrics and alerting
Metrics scopes support multi-project visibility with appropriate IAM. Distinguish counters, gauges and distributions. rate(http_requests_total[5m]) estimates a counter's per-second change; a raw counter is not a rate. Sum compatible rates before calculating ratios. Do not average instance p99s into a global p99: combine compatible histograms/distributions. Scopes, PromQL functions.
Inspect alignment, aggregation, retest duration, missing data and notification channels. A two-minute spike does not meet five minutes of continuous breach. Log-based metrics are metrics; do not assume they are the only way to alert on log events or that every native metric is instantaneous. Log-based metrics, metric alerts.
Dashboards should answer health, impact and change questions. Maintain owners/runbooks and test third-party notification integrations. An open incident does not prove a responder received a page.
4.4 Traces
Propagate context across HTTP, RPC and queues and populate supported log-correlation fields. Waterfalls show concurrency: overlapping spans are not sequential durations to add. Combine traces with profiles/metrics to distinguish dependencies from local work. Trace, context propagation.
Head sampling decides early; tail sampling selects from received traces. A collector cannot recover upstream discarded spans. Outcome-based sampling biases raw event counts; use suitable metrics or sound statistical adjustment for population estimates. Monitor collector capacity/drops. Sampling.
Use Gemini analysis as evidence-linked hypotheses, checking timestamps, access and current capability limitations.
4.5 Troubleshooting
Establish impact and time; preserve evidence and mitigate; follow the failing request through DNS/connectivity, authentication, authorization, configuration, application, dependencies and capacity. Test a hypothesis, verify user recovery and record preventive work.
| Symptom | Useful evidence | Avoid assuming |
|---|---|---|
| CrashLoopBackOff | Previous logs, events, exit reason | Every crash is CPU shortage |
| OOMKilled | Memory peaks, limits, profiles | Low average rules out memory problems |
| Pending pod | Events, requests, affinity/taints, node fit | More replicas make an oversized pod fit |
| Running without traffic | Readiness, endpoints, routing | Running means ready |
| Build push denied | Execution identity, repository IAM | Developer permissions equal build permissions |
| Cloud Run latency | Cold starts, concurrency, CPU, dependencies | Max instances is the only lever |
| Missing telemetry | Collection health, IAM, routes | Missing means healthy zero |
Practice kubectl describe pod, kubectl logs --previous, rollout status/events and service endpoints. Startup probes protect initialization; readiness controls traffic eligibility; liveness detects a condition needing restart. Pod debugging, probes.
5. Performance and cost — about 12%
5.1 Performance evidence
Profiler attributes supported resource usage to code; profile types vary by runtime. Error Reporting groups supported application errors. Query Insights helps inspect database load, plans and waits. Recommender/Active Assist findings need validation against workload/recovery requirements. Profiler, Error Reporting, Query Insights, Recommender.
Measure a baseline, change one justified factor and validate performance/cost under representative demand. Low CPU does not rule out memory, I/O, locking or connection pressure. More frontend instances can worsen database exhaustion.
5.2 FinOps
Remove verified waste and right-size before committing. Buy against a defensible eligible baseline and check terms, SKU coverage and utilization. Cloud Run can benefit from eligible Compute flexible commitments. Sustained-use discounts cover eligible Compute Engine usage, not every machine family or cloud service. Price commitments do not universally reserve capacity. Cloud Run commitments, SUD eligibility.
Spot fits recoverable jobs with checkpointing/retry and suitable deadlines. For GKE assess requests, scheduling and node utilization; Autopilot does not automatically make all idle applications free. For Cloud Run test concurrency, minimum instances, resources and billing mode. CPU allocation does not guarantee an instance exists indefinitely for durable background work. Spot, Cloud Run billing.
Cost attribution needs owners, labels/project mapping and billing export; not every cost contains every label. Account for credits and repeated fields without multiplying rows. Evaluate data placement and Network Service Tiers against topology and user performance. Billing schema, network tiers.
Alerts-only budgets can drive automation but are not precise instantaneous ceilings. Handle delay, retries, authorization and action scope. Spend-cap budgets are a separate eligible-service feature with limitations. Avoid either universal claim: 'every budget caps spending' or 'no spend cap exists.' Notifications, spend caps.
6. Scenario reasoning and revision
Identify the outcome and hard constraints: least privilege, residency, recovery, auditability, latency, effort or cost. Locate the failing layer and actual identity. Eliminate options violating a requirement; choose a supported maintainable solution meeting the whole scenario. Manual approval may be correct when required. 'Manual is always wrong' is not a rule.
For multi-select, evaluate options independently and select the requested count. For calculations state denominator/window/units. Distinguish a useful investigation from a proven root cause. A guessed correct answer needs revision.
Explain these contrasts without notes: Shared VPC/peering/PSC; IAM/org policy/perimeter; actAs/token minting; Config Connector/Config Sync/Terraform; repository modes; scanning/provenance/attestation/enforcement; canary/blue-green/flags; request/time budgets; HPA/node scaling; quota/reservation/commitment; sink/bucket/view/scope; counter/gauge/distribution; head/tail sampling; alerts-only/spend-cap budgets.
Complete the readiness checklist and recheck the official exam guide before booking.