Google Cloud • PCD
Validates expertise in building and deploying scalable, secure, and highly available applications using Google Cloud tools and best practices.
Questions
600
Duration
120 minutes
Passing Score
Not disclosed
Difficulty
ProfessionalLast Updated
Jan 2026
The Google Cloud Certified Professional Cloud Developer (PCD) certification validates a practitioner's ability to design, build, test, deploy, and manage scalable, secure, and highly available cloud-native applications on Google Cloud. The exam covers the full application development lifecycle on Google Cloud, assessing proficiency with compute platforms such as Cloud Run, Google Kubernetes Engine (GKE), App Engine, and Cloud Functions, as well as managed data stores including Cloud SQL, AlloyDB, Spanner, Firestore, Bigtable, and Cloud Storage. Candidates must demonstrate fluency in integrating Google Cloud services—such as Pub/Sub, Eventarc, Cloud Tasks, Cloud Scheduler, API Gateway, and Cloud Endpoints—into event-driven and API-centric architectures.
The certification also tests knowledge of modern DevOps practices, including CI/CD pipeline construction with Cloud Build and Cloud Deploy, container image management via Artifact Registry, supply chain security with Binary Authorization, and application security using IAM, Identity-Aware Proxy, Secret Manager, and Cloud KMS. Observability skills—covering Cloud Monitoring, Cloud Logging, Cloud Trace, and Cloud Profiler—are also assessed, reflecting Google Cloud's emphasis on instrumenting applications to produce actionable metrics, logs, and traces.
This certification is designed for software engineers and developers who build and deploy applications on Google Cloud as part of their day-to-day responsibilities. Ideal candidates have hands-on experience with cloud-native patterns such as microservices, containerization, and serverless computing, and are comfortable with at least one general-purpose programming language. The exam is equally relevant to full-stack developers, backend engineers, and DevOps engineers who own the deployment and operational health of cloud-hosted applications.
Professionals transitioning from on-premises or other cloud environments who want to formalize their Google Cloud development skills will also benefit. Google recommends candidates have at least three years of industry experience, including one or more years of designing and managing solutions on Google Cloud.
Google Cloud does not enforce formal prerequisites for the Professional Cloud Developer exam; any candidate may register directly. However, Google recommends a minimum of three years of industry software development experience, with at least one year spent designing and managing solutions on Google Cloud. Candidates should be comfortable working with cloud-native application architectures, container orchestration, RESTful and gRPC APIs, managed databases, and serverless platforms before attempting the exam.
A strong practical foundation is more valuable than theoretical study alone. Candidates without significant hands-on Google Cloud experience are advised to complete the Professional Cloud Developer learning path on Google Cloud Skills Boost, which includes guided labs covering Cloud Run, GKE, Cloud Build, Cloud Functions, and core data services before sitting for the exam.
The Professional Cloud Developer exam consists of 50–60 multiple-choice and multiple-select questions and must be completed within 120 minutes. The registration fee is $200 USD plus applicable taxes. The exam is available in English and Japanese and can be taken either via online proctoring (remote, from any location with a webcam and stable internet connection) or in person at an authorized Kryterion testing center worldwide.
Google does not publicly disclose a specific passing score for this exam. Scoring uses a compensatory model in which overall performance across all domains determines the outcome, rather than requiring minimum scores in each individual section. The certification is valid for two years, after which candidates must recertify through the renewal process.
The Professional Cloud Developer certification is recognized by organizations that run production workloads on Google Cloud, making it a strong differentiator for software engineers, DevOps practitioners, and cloud architects operating in GCP environments. Certified professionals typically pursue roles such as Cloud Application Developer, Site Reliability Engineer, Cloud Solutions Engineer, and DevOps Engineer. The certification demonstrates mastery of the full cloud-native development lifecycle—from architecture design through deployment and observability—which aligns with the skillsets most in demand at enterprises undergoing cloud modernization.
Salary data from multiple industry sources places certified Google Cloud Professional Cloud Developer professionals in the $140,000–$180,000 USD range in the United States, varying by role, seniority, and geography. Compared to associate-level Google Cloud certifications, the PCD signals hands-on production experience and is often weighted alongside certifications like the AWS Certified Developer – Associate or Microsoft Azure Developer Associate, though the PCD's scope—covering security, CI/CD pipelines, and multi-service integration in depth—is generally considered broader.
5 sample questions with correct answers and explanations. Start a practice session to test yourself across all 600 questions.
1. You're migrating from Cloud Functions to Cloud Run for better control over runtime and dependencies. Cloud Functions automatically handle request timeout limits of 9 minutes. What timeout configuration should you set in Cloud Run to match this behavior?
Explanation
Cloud Run's maximum request timeout is 300 seconds (5 minutes) for requests through the standard endpoint, not 9 minutes like Cloud Functions. For operations requiring longer processing, the cloud-native pattern uses asynchronous processing with Cloud Tasks or Pub/Sub rather than long-running HTTP requests. Requests trigger background jobs that process asynchronously and store results. Setting timeout to 540 seconds fails - Cloud Run doesn't support it. Setting to 3600 seconds also fails for the same reason. Cloud Run doesn't automatically match Cloud Functions behavior - you must configure timeouts explicitly and redesign long-running operations as asynchronous jobs.
2. Your company deploys applications using GitOps principles with Cloud Build and Cloud Deploy. Application configurations are stored in a Git repository. The security team requires that production deployments must only occur from commits that have passed security scanning. How should you enforce this requirement?
Explanation
Binary Authorization with vulnerability scan attestations provides automated enforcement at deployment time. Cloud Build scans containers during build, creates attestations for passing scans, and Binary Authorization prevents deploying images without valid attestations to production. This enforces policy without manual intervention. Manual review is error-prone and doesn't scale. Git branch protection ensures code review but doesn't verify security scanning occurred for deployed artifacts. Failing builds that don't pass scanning helps but doesn't prevent manual deployment of non-scanned images; Binary Authorization provides enforcement at deployment time.
3. A global e-commerce platform uses Cloud SQL PostgreSQL in us-central1. The database contains product catalog data that is read-heavy with 95% read and 5% write operations. European customers experience high latency when browsing products. How should you reduce latency for European users while maintaining data consistency?
Explanation
Cloud SQL read replicas in europe-west1 serve read traffic locally to European users, significantly reducing latency for the 95% read-heavy workload. Writes continue to the primary instance in us-central1. Read replicas maintain eventual consistency with the primary instance, which is acceptable for product catalog data. Cloud Spanner provides global consistency but at higher cost and complexity for this use case. Cloud CDN caches HTTP responses, not database queries. Bidirectional replication between Cloud SQL instances is not a supported feature; Cloud SQL uses primary-replica architecture.
4. A data science team needs fully customizable development environments with GPU support, persistent home directories, and pre-installed ML libraries. Environments should automatically shut down after 2 hours of inactivity to control costs. Developers access environments through VS Code or JupyterLab. Should you use Cloud Shell or Cloud Workstations?
Explanation
Cloud Workstations is purpose-built for this use case, offering custom machine types including GPU options, configurable idle/running timeouts for cost control, persistent home directories, and multiple IDE choices including VS Code and JupyterLab. It supports custom container images for pre-installed libraries. Cloud Shell is a lightweight browser-based terminal environment with limited customization, no GPU support, fixed machine types, and 5GB of persistent storage - it's designed for quick administrative tasks, not development workstations. Cloud Workstations is not free but provides the flexibility and customization required for this scenario.
5. A development team uses Cloud Build for CI/CD. Their Python tests require a PostgreSQL database. They want to run integration tests that connect to PostgreSQL during the build. What Cloud Build configuration approach should they use?
Explanation
Cloud Build supports service containers that run alongside build steps and provide services like databases. Configuring a PostgreSQL service container makes the database available on localhost to all build steps. The service container starts automatically and is torn down when the build completes. This provides isolated, reproducible test environments without requiring Cloud SQL or manual database installation. Service containers are designed specifically for CI/CD scenarios where builds need dependencies like databases, caching systems, or message queues. Installing PostgreSQL with apt-get in a build step is fragile, requires elevated permissions, and doesn't provide a clean separation between build infrastructure and build logic. Cloud SQL connections work but incur costs for maintaining a persistent database, require network configuration, and create state management challenges for parallel builds. Using docker-compose in Cloud Build is possible but more complex than native service containers, and Cloud Build's service container feature provides better integration with build steps. Service containers offer the cleanest solution: declarative configuration, automatic lifecycle management, and network isolation per build.
One-time access to this exam