GCP-PCDE

Google Cloud Professional Cloud DevOps Engineer (GCP-PCDE)

The Professional Cloud DevOps Engineer certification validates your ability to build software delivery pipelines, deploy and monitor services, and manage incident responses on Google Cloud. This professional-level certification is designed for engineers who leverage Google Cloud technologies and tools to build reliable, highly available systems using site reliability engineering (SRE) principles. The exam covers bootstrapping a Google Cloud organization, building and implementing CI/CD pipelines, applying SRE practices to a service, implementing service monitoring strategies, and optimizing service performance. Candidates are expected to have 3+ years of industry experience including at least 1 year designing and managing solutions using Google Cloud. A strong grasp of DevOps culture, automation, observability, and incident management is essential for success on this exam.

Exam Details

Domain Weights

Study Tips

• Master the Google SRE book concepts including SLIs, SLOs, SLAs, error budgets, and toil reduction; these are foundational to the exam
• Understand Cloud Build, Artifact Registry, Cloud Deploy, and how they integrate into a full CI/CD pipeline on Google Cloud
• Practice incident management workflows including blameless postmortems, on-call rotations, and escalation procedures
• Know the complete Cloud Operations suite: Cloud Monitoring, Cloud Logging, Cloud Trace, Cloud Profiler, and Error Reporting
• Study deployment strategies thoroughly: rolling updates, blue/green, canary deployments, and traffic splitting on GKE and Cloud Run
• Understand Infrastructure as Code with Terraform on Google Cloud and how to manage infrastructure lifecycles
• Know binary authorization, vulnerability scanning, and supply chain security for container images

Resource Hierarchy and Organization Setup

Bootstrapping a Google Cloud organization involves establishing the foundational structure for managing resources, identity, networking, and security. A well-designed resource hierarchy is critical for managing policies, billing, and access at scale. The hierarchy flows from the Organization node down through Folders, Projects, and individual Resources. IAM policies and organization policies set at higher levels are inherited by child resources, enabling centralized governance while allowing team-level flexibility.

Infrastructure as Code (IaC)

Exam Tip: Terraform is heavily tested on this exam. Understand the plan/apply workflow, state locking with Cloud Storage backends, modules for reusability, and how to use the Google Cloud provider. Also know when to use Config Connector for Kubernetes-native infrastructure management.

Identity and Access Management for DevOps

• Service Accounts: Use dedicated service accounts per application and CI/CD pipeline; avoid using default service accounts; apply least privilege; prefer Workload Identity over service account keys
• Workload Identity Federation: Allows external workloads (GitHub Actions, GitLab CI, Jenkins) to authenticate to Google Cloud without service account keys; maps external identity tokens to GCP IAM
• Workload Identity (GKE): Maps Kubernetes service accounts to Google Cloud service accounts; eliminates the need for exported service account keys on GKE pods
• Organization Policies: Constraints that restrict how resources can be configured; examples include restricting VM external IPs, enforcing uniform bucket-level access, and disabling service account key creation
• VPC Service Controls: Define security perimeters around Google Cloud resources to prevent data exfiltration; restricts API access based on network context and identity attributes

Networking Foundations

• VPC Design: Plan IP address ranges (CIDR blocks) carefully; use custom-mode VPCs for production; enable Private Google Access for instances without external IPs to reach Google APIs
• Cloud NAT: Provides outbound internet access for VMs without external IPs; fully managed, no VM-based NAT gateway needed; configure per-region with automatic IP allocation
• Private Service Connect: Private endpoints for consuming Google APIs and partner services; keeps traffic on the Google network; provides granular control over which APIs are accessible
• DNS Management: Cloud DNS for managed authoritative DNS; private DNS zones for internal name resolution; DNS peering for cross-VPC resolution; response policies for custom DNS behavior

CI/CD Pipeline Architecture on Google Cloud

A robust CI/CD pipeline on Google Cloud automates the process from code commit to production deployment. The pipeline typically starts with source code in a repository, triggers automated builds and tests through Cloud Build, stores artifacts in Artifact Registry, and deploys through Cloud Deploy with approval gates and progressive rollout strategies. The goal is to increase deployment frequency while maintaining reliability, enabling teams to ship changes faster with confidence.

Cloud Build Configuration

Deployment Strategies

Exam Tip: Understand the trade-offs between deployment strategies. Canary deployments are preferred when you want to validate changes with real traffic before full rollout. Blue/green is best when you need instant rollback. Know how Cloud Deploy implements these strategies for GKE and Cloud Run.

Supply Chain Security

• Binary Authorization: Ensures only signed and attested container images are deployed to GKE; create attestors and policies; integrates with Cloud Build to automatically attest built images
• Artifact Registry Vulnerability Scanning: Automatically scans container images for known CVEs; on-push and continuous scanning modes; integrates with Security Command Center for centralized findings
• SLSA Framework: Supply-chain Levels for Software Artifacts; defines levels of supply chain integrity; Cloud Build provides SLSA Level 3 provenance for builds; verifiable build metadata
• Software Delivery Shield: End-to-end software supply chain security solution; integrates source protection, build integrity, artifact scanning, and deployment policies into a unified framework

SRE Core Concepts

Site Reliability Engineering (SRE), pioneered by Google, is a discipline that applies software engineering principles to infrastructure and operations problems. SRE focuses on creating scalable and reliable systems through automation, measurement, and a culture of continuous improvement. The Professional Cloud DevOps Engineer exam heavily tests SRE principles because they form the foundation of reliable service management on Google Cloud.

Error Budget Policy

Exam Tip: Error budgets are one of the most tested concepts. Understand that error budgets create a data-driven balance between reliability and velocity. When the budget is healthy, teams can ship faster. When exhausted, focus shifts entirely to reliability improvements.

Incident Management

Blameless Postmortem Principles

• Focus on Systems: Examine the systems and processes that allowed the failure, not the individuals involved; assume people acted with good intentions given the information available
• Document Everything: Record the incident timeline, detection method, response actions, root cause analysis, and contributing factors in a structured postmortem document
• Actionable Items: Every postmortem must produce specific, measurable action items with owners and deadlines; track completion of action items
• Share Widely: Publish postmortems across the organization; encourage a culture where sharing failures is valued as a learning opportunity
• Prevent Recurrence: Focus on systemic improvements: better monitoring, automated rollbacks, improved testing, and defense in depth rather than adding more manual procedures

Cloud Operations Suite

Google Cloud Operations Suite (formerly Stackdriver) provides a comprehensive set of tools for monitoring, logging, tracing, and debugging applications running on Google Cloud. Effective monitoring is the foundation of SRE practice, enabling teams to measure SLIs, track SLOs, detect incidents, and optimize performance. The suite integrates tightly with GKE, Cloud Run, Compute Engine, and other Google Cloud services to provide automatic metric collection and log aggregation.

SLO Monitoring in Cloud Monitoring

Alerting Best Practices

Exam Tip: Multi-window, multi-burn-rate alerting is the recommended approach for SLO-based alerting. A 5% budget consumption in 1 hour is urgent (fast burn), while 10% consumption in 3 days is less urgent but still important (slow burn). Know how to configure these in Cloud Monitoring.

Logging Strategy

• Log Router: Cloud Logging routes all logs through the log router; configure inclusion and exclusion filters; route to multiple destinations simultaneously; control which logs are stored and where
• Log Sinks: Export logs to Cloud Storage (long-term archive), BigQuery (analytics and querying), Pub/Sub (real-time processing), or another project (centralized logging)
• Log-Based Metrics: Create custom metrics from log entries; count specific events or extract numeric values; use in dashboards and alerting policies; system and user-defined types
• Audit Logs: Admin Activity (always on, free), Data Access (configurable), System Event, and Policy Denied logs; essential for compliance and security forensics
• Structured Logging: Use JSON-formatted log entries with standardized fields; enables better filtering, searching, and metric extraction; integrate with Cloud Trace via trace ID

GKE Performance Optimization

Cloud Run Performance

Cost Optimization Strategies

Reliability Patterns

• Multi-Zonal Deployments: Distribute workloads across multiple zones within a region for high availability; GKE regional clusters span 3 zones by default; Cloud Run is automatically multi-zonal
• Multi-Regional Deployments: Distribute across multiple regions for disaster recovery; use global load balancing to route traffic to the nearest healthy region; increases availability SLO but adds complexity and cost
• Circuit Breaker Pattern: Prevent cascading failures by stopping requests to failing services; return fallback responses; allow gradual recovery with half-open state; implement with Istio or application-level libraries
• Retry with Exponential Backoff: Retry failed requests with increasing delay between attempts; add jitter to prevent thundering herd; set maximum retry limits; essential for handling transient failures
• Chaos Engineering: Intentionally inject failures to test system resilience; verify monitoring and alerting; validate incident response procedures; Google uses tools like DiRT (Disaster Recovery Testing)

Exam Tip: Know the full GKE autoscaling stack: HPA scales pods, VPA right-sizes pods, Cluster Autoscaler scales nodes, and NAP provisions node pools. Understand when to use each and how they work together. Also understand Cloud Run scaling settings and their cost implications.