Google Cloud • PCDOps
Validates ability to bootstrap and maintain a Google Cloud organization, implement CI/CD pipelines, apply site reliability engineering practices, implement observability, and optimize performance and cost.
Questions
1132
Duration
120 minutes
Passing Score
Not disclosed
Difficulty
ProfessionalLast Updated
Jan 2026
The Google Cloud Certified - Professional Cloud DevOps Engineer certification validates a practitioner's ability to design, implement, and operate production systems on Google Cloud using DevOps and Site Reliability Engineering (SRE) principles. The exam covers the full spectrum of modern cloud operations: bootstrapping and governing a Google Cloud organization with Infrastructure as Code, building and securing CI/CD pipelines using services such as Cloud Build, Cloud Deploy, Artifact Registry, and Binary Authorization, and applying SRE concepts including SLIs, SLOs, error budgets, and burn rate alerting.
Candidates are also tested on implementing Google Cloud Observability using Cloud Monitoring, Cloud Logging, Error Reporting, and Cloud Trace to detect, diagnose, and remediate issues across applications and infrastructure. The certification has been updated with a dedicated focus on continuous testing for machine learning workloads and FinOps practices, reflecting the evolving demands placed on DevOps engineers managing heterogeneous, cost-sensitive cloud environments. The exam was last substantially revised in the 2024–2025 timeframe and aligns with Google's own DORA (DevOps Research and Assessment) research methodology.
This certification is designed for DevOps Engineers, Site Reliability Engineers (SREs), Platform Engineers, and Cloud Infrastructure Engineers who are responsible for building and maintaining production systems on Google Cloud. Ideal candidates have at least three years of industry experience overall, including a minimum of one year designing and managing production workloads on Google Cloud.
Professionals in roles such as Cloud Architect, Infrastructure Automation Engineer, or Release Engineer who are transitioning into SRE or DevOps functions will also find this certification highly relevant. It is particularly well-suited for those working in organizations that use Google Kubernetes Engine (GKE), Cloud Run, or Compute Engine at scale and need to demonstrate proficiency in delivery pipelines, reliability engineering, and observability.
Google Cloud does not enforce any formal prerequisite certifications for this exam. However, candidates are strongly advised to have hands-on experience with Google Cloud services before attempting the exam, particularly Cloud Build, Cloud Deploy, GKE, Cloud Monitoring, and Cloud Logging. Familiarity with Infrastructure as Code tools such as Terraform is also expected.
Recommended background knowledge includes a solid understanding of Linux systems administration, containerization (Docker and Kubernetes), version control with Git, and fundamental software development practices. Candidates who hold the Associate Cloud Engineer certification will find that credential a useful stepping stone, as it builds foundational knowledge of Google Cloud resource hierarchy, IAM, and core compute and networking services that are tested indirectly in this exam.
The Professional Cloud DevOps Engineer exam consists of approximately 50–60 multiple-choice and multiple-select questions. The exam must be completed within 120 minutes (2 hours) and is available in English and Japanese. Candidates may take the exam either online via remote proctoring or in person at an authorized testing center. The registration fee is $200 USD plus applicable taxes.
Google does not publicly disclose the passing score threshold for this exam. Questions are scenario-based and assess practical judgment across real-world DevOps and SRE situations rather than rote memorization. There are no unscored pilot questions officially confirmed by Google. Certification is valid for two years, after which candidates must renew through the designated renewal process.
Earning the Professional Cloud DevOps Engineer certification positions candidates for roles such as Senior DevOps Engineer, Site Reliability Engineer, Platform Engineer, and Cloud Infrastructure Lead at organizations running workloads on Google Cloud. According to publicly available compensation data, certified Google Cloud professionals in DevOps and SRE roles in the United States typically command salaries ranging from $130,000 to $185,000 per year depending on experience, geography, and company size. The SRE and DevOps specialization is among the higher-paying tracks within the Google Cloud certification portfolio.
The certification signals proficiency in DORA-aligned delivery practices, which are increasingly required by enterprises undergoing cloud-native transformation. Unlike the AWS DevOps Professional (DOP-C02) or Azure DevOps Engineer Expert (AZ-400), this certification places a distinctive emphasis on SRE methodology as codified by Google, making it particularly valuable at organizations that have adopted the Google SRE model or that use GKE and Anthos as core infrastructure. Demand for certified Google Cloud DevOps professionals has grown alongside Google Cloud's expanding enterprise market share.
5 sample questions with correct answers and explanations. Start a practice session to test yourself across all 1132 questions.
1. A service team wants to reduce change failure rate from 15% to <5%. What practices should they implement? (Select two!)
Explanation
Change failure rate reduction: (1) Automated testing: unit, integration, end-to-end tests catch issues before production, (2) Progressive deployment: canary/blue-green with metric-based rollback detects issues with minimal user impact, (3) Feature flags: decouple deployment from release, enable gradual rollout, (4) Environment parity: staging mirrors production for realistic testing. Infrequent deploys increase change size and risk. Skipping testing increases failures. Team size doesn't directly reduce failure rate. Off-hours deployment doesn't prevent failures.
2. Litware needs to aggregate logs from multiple GKE clusters across different projects for centralized analysis. What should you configure?
Explanation
Organization-level aggregated sinks with includeChildren automatically collect logs from all projects and resources including GKE clusters, providing centralized collection without per-cluster configuration. Individual cluster configuration creates management overhead. Custom Fluentd deployment duplicates native logging infrastructure. Separate queries don't provide aggregation.
3. Contoso wants to implement SLIs for their user-facing API service. They serve 10 million requests daily with varying response times. Which SLI approach best measures user-perceived reliability?
Explanation
Valid-request SLIs based on latency thresholds best represent user experience because they measure what users actually perceive - whether their requests complete fast enough. Expressing this as a ratio of requests meeting the latency target (under 200ms) to total requests creates a proper SLI that can be measured against SLO targets. Success ratio based purely on HTTP status codes ignores latency, which significantly impacts user satisfaction. Average response time can hide p99 latency problems affecting a minority of users. Infrastructure metrics like CPU and memory are internal indicators that don't directly measure user-facing service quality.
4. Your GKE cluster must comply with regulations requiring all cluster actions to be auditable. You need to capture who performed what actions and when. What should you enable?
Explanation
GKE audit logging integrates with Cloud Audit Logs to capture administrative actions on the cluster (control plane) and, when enabled, data access events like pod creation and deletion (data plane). This provides comprehensive who/what/when audit trails for compliance. Cloud Logging handles application logs but doesn't automatically capture GKE administrative actions. VPC Flow Logs track network connections, not control plane actions. Cloud Monitoring tracks metrics and performance but doesn't provide detailed action audit trails with user identity information.
5. Your SRE team wants to measure deployment success rate as part of change failure rate tracking. What constitutes a deployment failure?
Explanation
Change failure rate measures deployments that cause production problems: incidents, degraded service, rollbacks, emergency hotfixes, or SLO violations. Define a time window (24-48 hours) to attribute incidents to deployments. This measures real-world impact. Pipeline failures are build/deployment execution failures, not change failures. Slow deployments indicate process inefficiency, not failure. Manual intervention may indicate process gaps but doesn't necessarily mean the change failed.
One-time access to this exam