Google Cloud Professional Cloud Developer
225 questions de pratique
Dernière révision : April 2026
Notes personnelles et liens de ressources pour votre parcours d'étude
Filtrer par Certification
Le Google Cloud Professional Cloud Developer (PCD) valide la capacité à créer des applications évolutives, sécurisées et cloud-natives sur Google Cloud. L'examen met l'accent sur l'ingénierie réelle : le choix entre Cloud Run, GKE, App Engine et Cloud Functions pour une charge de travail donnée ; la conception de systèmes événementiels avec Pub/Sub et Eventarc ; la mise en œuvre de l'observabilité avec Cloud Trace et Cloud Profiler ; et l'intégration avec Cloud SQL, Spanner, Firestore et Memorystore. Le style des questions est axé sur des scénarios — de courtes histoires sur les exigences d'une équipe avec quatre options plausibles, dont l'une est la réponse la plus idiomatique de Google Cloud. Le PCD est l'analogue GCP de l'AWS Developer Associate, un cran au-dessus, ou de l'Azure AZ-204 avec un contenu architectural plus approfondi. Il cible les développeurs backend, les ingénieurs full-stack et les ingénieurs plateforme qui déploient réellement du code sur GCP.
Le domaine le plus important (25 %). Modèles 12-factor, compromis microservices vs. monolithe, choix de la bonne option de calcul (Cloud Run vs. GKE vs. Cloud Functions vs. App Engine), conception événementielle avec Pub/Sub. Très axé sur les scénarios de compromis.
Développement local avec Cloud Code, constructions de conteneurs avec Cloud Build et Buildpacks, modèles de tests unitaires / d'intégration / de charge, gestion des dépendances. 20 %.
Déploiements blue-green et canary sur Cloud Run et GKE, répartition du trafic, Artifact Registry, modèles de pipeline de déploiement avec Cloud Build, identité de service et Workload Identity. 20 %.
Modèles Pub/Sub (push vs. pull, livraison exactement une fois), Eventarc, Cloud Tasks, Cloud Scheduler, intégrations avec Cloud SQL / Spanner / Firestore / Memorystore. 20 % — très axé sur les modèles idiomatiques.
Cloud Logging, Cloud Monitoring, Cloud Trace, Cloud Profiler, rapports d'erreurs, ajustement de l'autoscaling, ingénierie consciente des coûts. 15 %.
Les services que vous rencontrerez à l'examen et pourquoi chacun compte.
Runtime de conteneurs serverless entièrement géré qui s'adapte à zéro, avec révisions, répartition du trafic, ajustement de la concurrence et facturation à la requête.
Pourquoi il est à l'examen : Le Domaine 1 (Conception d'applications natives du cloud) considère Cloud Run comme la primitive de calcul par défaut pour les services conteneurisés sans état — attendez-vous à des questions sur la concurrence, les démarrages à froid et le retour arrière des révisions.
Service de calcul serverless événementiel (2e génération basé sur Cloud Run) déclenché par les événements HTTP, Pub/Sub, Cloud Storage, Eventarc et Firestore.
Pourquoi il est à l'examen : Le Domaine 1 + le Domaine 4 (Intégration de services Google Cloud) testent les Functions pour l'intégration légère entre services et les modèles de mappage de sources d'événements.
PaaS entièrement géré pour les applications web avec des environnements Standard (mise à l'échelle par requête) et Flexible (basés sur des conteneurs), répartition du trafic et déploiements versionnés.
Pourquoi il est à l'examen : Le Domaine 3 (Déploiement d'applications) teste la répartition du trafic d'App Engine, les déploiements versionnés et le choix entre Standard et Flexible — un élément de confusion récurrent face à Cloud Run.
Kubernetes géré avec les modes Autopilot et Standard, Workload Identity, ingress multi-cluster et mesh de services Anthos intégré.
Pourquoi il est à l'examen : Le Domaine 1 + le Domaine 3 testent les compromis entre GKE Autopilot et Standard, Workload Identity pour l'authentification pod vers Google API, et les stratégies de déploiement rolling vs. bleu/vert.
Service CI géré piloté par `cloudbuild.yaml` qui construit des images conteneur, exécute des tests, signe des artefacts et les pousse vers Artifact Registry.
Pourquoi il est à l'examen : Le Domaine 2 (Création et test d'applications) désigne Cloud Build comme le service CI canonique — attendez-vous à des questions sur les étapes de build, les substitutions et les déclencheurs.
Dépôts Git privés gérés intégrés aux déclencheurs Cloud Build, Cloud Logging et à l'accès aux dépôts basé sur IAM.
Pourquoi il est à l'examen : Le Domaine 2 + le Domaine 3 couvrent CSR comme source native Google pour les déclencheurs Cloud Build, souvent contrasté avec les dépôts GitHub/GitLab mis en miroir.
Service de livraison continue géré pour GKE, Cloud Run et Anthos avec des pipelines de livraison déclaratifs, des portes de promotion et un retour arrière automatisé.
Pourquoi il est à l'examen : Le Domaine 3 (Déploiement d'applications) teste la progression des pipelines Cloud Deploy (dev → staging → prod), les portes d'approbation et la sémantique de retour arrière.
Stockage unifié pour les images conteneur, Maven, npm, Python, Go et les paquets OS avec accès contrôlé par IAM, analyse des vulnérabilités et dépôts distants/virtuels.
Pourquoi il est à l'examen : Le Domaine 2 + le Domaine 3 attendent Artifact Registry (successeur de Container Registry) comme le stockage d'images consommé par Cloud Build → déploiements Cloud Run / GKE.
Base de données de documents serverless (Firestore en mode Native ou Datastore) avec des écouteurs en temps réel, synchronisation hors ligne et règles de sécurité ; Firebase Realtime DB pour les applications JSON-tree héritées.
Pourquoi il est à l'examen : Le Domaine 1 teste Firestore pour les charges de travail de documents à faible latence avec poussée en temps réel vers les clients mobiles/web — un contraste récurrent avec Cloud Spanner et Bigtable.
Base de données relationnelle globalement distribuée, fortement cohérente avec mise à l'échelle horizontale, instances régionales/multi-régionales et prise en charge des dialectes SQL + GoogleSQL.
Pourquoi il est à l'examen : Le Domaine 1 nomme Spanner chaque fois qu'une question exige une sémantique relationnelle à l'échelle planétaire ou une disponibilité à cinq neuf — le distingue de Cloud SQL et Firestore.
Messagerie asynchrone globale avec livraison au moins une fois, abonnements push et pull, clés d'ordonnancement, sujets de lettres mortes et Pub/Sub Lite pour les charges de travail régionales à haut débit.
Pourquoi il est à l'examen : Le Domaine 4 (Intégration de services Google Cloud) teste Pub/Sub comme la primitive de découplage canonique pour les backends événementiels — le choix entre pull et push et la sémantique DLQ sont des questions courantes.
Files d'attente de tâches asynchrones gérées avec planification par tâche, contrôle du débit/concurrence, réessais avec back-off exponentiel et cibles HTTP / App Engine.
Pourquoi il est à l'examen : Le Domaine 4 distingue Cloud Tasks (contrôle explicite et dédupliqué par tâche) de Pub/Sub (flux de diffusion) — une paire de distracteurs récurrente de style DVA.
Orchestrateur de workflows serverless utilisant un DSL YAML/JSON pour enchaîner les API HTTP, Cloud Functions, Cloud Run et Google Cloud avec des réessais et des étapes parallèles.
Pourquoi il est à l'examen : Le Domaine 4 contraste Workflows (orchestration durable) avec la diffusion brute de Pub/Sub — les questions testent les réessais d'étapes, les branches parallèles et l'utilisation des connecteurs.
Apigee fournit une gestion complète du cycle de vie des API (proxies, monétisation, analyses, OAuth) ; API Gateway est une passerelle gérée légère pour les backends serverless.
Pourquoi il est à l'examen : Le Domaine 4 teste Apigee pour le cycle de vie des API d'entreprise (portail développeur, quota, proxies OAuth) et API Gateway pour l'exposition des API serverless — le choix entre eux est un scénario récurrent.
Couche de gestion d'API OpenAPI/gRPC pour les backends App Engine, GKE et Compute Engine avec proxy ESP/ESPv2, authentification, surveillance et application des quotas.
Pourquoi il est à l'examen : Le Domaine 4 maintient Cloud Endpoints dans le champ d'application pour les backends auto-hébergés sur GKE/Compute Engine où Apigee est excessif mais API Gateway ne convient pas.
Infrastructure d'événements pour livrer plus de 130 sources d'événements Google Cloud à Cloud Run, Cloud Functions et GKE via des déclencheurs Pub/Sub ou de journaux d'audit au format CloudEvents.
Pourquoi il est à l'examen : Le Domaine 4 nomme Eventarc chaque fois qu'un événement doit transiter d'un service Google Cloud (par exemple Cloud Storage, journaux d'audit) vers une cible serverless avec un format CloudEvents standard.
Identité à l'échelle du projet et de l'organisation avec rôles prédéfinis et personnalisés, comptes de service, Workload Identity Federation et politiques basées sur les ressources.
Pourquoi il est à l'examen : Le Domaine 5 (Gestion des performances des applications / Sécurité) teste la conception de rôles à privilège minimum, l'usurpation d'identité de compte de service et Workload Identity pour l'authentification pod vers Google API sans clés statiques.
Cloud KMS gère les clés de chiffrement gérées par le client (CMEK / HSM externe) ; Secret Manager stocke les clés API, les informations d'identification de base de données et les jetons avec versioning et rotation.
Pourquoi il est à l'examen : Le Domaine 1 + le Domaine 3 attendent Secret Manager pour l'injection de crédentiels d'exécution et Cloud KMS comme magasin de clés de support — les distinguer des variables d'environnement est une question récurrente.
Cloud Trace pour l'analyse de latence distribuée, Cloud Profiler pour le profilage CPU/mémoire en production et Cloud Debugger (déprécié ; remplacement Snapshot Debugger) pour l'inspection de l'état en direct.
Pourquoi il est à l'examen : Le Domaine 5 (Gestion des performances des applications) est largement axé sur Cloud Operations Suite — attendez-vous à des questions sur les chaînes de traçage à travers Cloud Run/Functions et le diagnostic des points chauds basé sur le profilage.
Cloud Logging agrège les journaux structurés de tous les services Google Cloud avec des sinks, des métriques basées sur les journaux et Logs Explorer ; Error Reporting regroupe et alerte sur les exceptions d'application.
Pourquoi il est à l'examen : Le Domaine 5 teste la journalisation structurée depuis Cloud Run/Functions, les alertes basées sur les journaux via Cloud Monitoring et les regroupements Error Reporting — la surface canonique pour "où est le bug".
$130k–$180k–$270k USD annuel
Cette fourchette reflète les ingénieurs backend seniors / cloud-natives basés aux États-Unis où GCP est la plateforme principale. La rémunération totale (TC) d'un ingénieur logiciel FAANG L5 dépasse 300 000 $. La certification est un signal fort mais ne débloque pas à elle seule ces salaires — elle complète 5 à 10 ans et plus d'expérience avérée en ingénierie logicielle.
Source : levels.fyi 2025–2026 (ingénieurs logiciels Google L4–L5, backends seniors FAANG et d'entreprises unicornes centrées sur GCP), U.S. BLS OEWS May 2024 (15-1252 développeurs logiciels). Les chiffres sont approximatifs ; la rémunération réelle dépend du rôle, de la région et de l'expérience.
Le PCD est moins souvent demandé que les certifications de la filière architecte, mais constitue un fort différenciateur sur les offres d'emploi pour ingénieurs backend seniors et ingénieurs plateforme dans les entreprises fortement utilisatrices de GCP. La demande se concentre chez Spotify, Snap, PayPal, Wayfair, plusieurs grands détaillants, les studios de jeux et les partenaires Google Cloud. La certification est également appréciée chez Google même — les parcours d'ingénierie client et de développeur-évangéliste la citent fréquemment comme étant préférée. Le PCD s'associe naturellement à la certification Kubernetes CKAD et à Terraform Associate pour former un profil de développeur cloud-native solide. Il est moins souvent utilisé comme filtre d'embauche que l'ACE ou le PCA, mais les titulaires signalent constamment une meilleure réponse des recruteurs pour les rôles d'ingénieur senior.
Il n'y a pas de prérequis formels. Google recommande trois ans ou plus d'expérience industrielle, dont au moins un an de conception et de développement d'applications sur Google Cloud. En pratique, le PCD n'est pas une première certification GCP judicieuse pour les non-développeurs — les candidats qui réussissent peuvent lire et écrire confortablement en Go, Java, Python ou Node.js et ont livré des applications non triviales.
L'Associate Cloud Engineer (ACE) est le jalon le plus courant mais n'est pas strictement requis si vous écrivez déjà du code de production sur AWS ou Azure. Une aisance avec les conteneurs, les bases de Kubernetes (Deployments, Services, ConfigMaps), les concepts CI/CD et au moins une des principales bases de données SQL ou de documents est effectivement requise. Le parcours d'apprentissage officiel Cloud Developer sur Google Cloud Skills Boost (environ 50 à 70 heures de laboratoires et de lectures) est une bonne base, mais la plupart des candidats qui réussissent le complètent avec des projets personnels Cloud Run / GKE.
Le PCD est classé professionnel et est réellement axé sur des scénarios. Prévoyez 80 à 130 heures d'étude sur 8 à 12 semaines si le PCD est votre première certification professionnelle GCP, ou 40 à 70 heures sur 4 à 6 semaines si vous détenez déjà l'ACE et avez une solide expérience en ingénierie backend. L'examen comporte 50 à 60 questions à choix multiples / à sélection multiple en 120 minutes, administrées via Pearson VUE (Google a migré de Kryterion / Webassessor début 2026).
Le principal écueil est le choix entre Cloud Run, GKE, App Engine et Cloud Functions pour un scénario donné — la réponse "préférée" de Google dépend souvent de critères subtils de mise à l'échelle, de latence ou de surcharge opérationnelle qui ne sont pas évidents à partir de la seule documentation. Le deuxième écueil concerne la sémantique de livraison de Pub/Sub (au moins une fois vs. exactement une fois, push vs. pull, sujets de lettres mortes). Google ne publie pas de scores numériques — seulement réussi/échoué. La certification est valide deux ans et la recertification exige de repasser l'examen actuel.
Guide d'examen actuel mis à jour fin 2023 pour ajouter les jobs Cloud Run, étendre la couverture d'Eventarc et mettre à jour les scénarios Workload Identity de GKE. Suppression de l'accent sur l'environnement flexible App Engine hérité.
Mise à jour majeure qui a introduit Cloud Run comme option de calcul de premier ordre et a étendu le domaine de l'observabilité.
PCD (Google Cloud Professional Cloud Developer) est un examen de niveau Professional un examen exigeant, riche en scénarios, qui requiert une expérience pratique approfondie et la capacité de prendre des décisions d'arbitrage architectural. La plupart des candidats ont besoin de 150 à 300 heures d'étude réparties sur 3 à 6 mois pour les examens de niveau professionnel et expert. Ces examens exigent généralement une compétence préalable de niveau associé. La plupart des candidats qui obtiennent des scores constamment supérieurs au seuil de réussite lors des examens pratiques réussissent dès leur première tentative.
La plupart des candidats ont besoin de 150 à 300 heures d'étude réparties sur 3 à 6 mois pour les examens de niveau professionnel et expert. Ces examens exigent généralement une compétence préalable de niveau associé. Le temps nécessaire pour réussir varie considérablement en fonction de l'expérience antérieure. Les ingénieurs ayant une expérience pratique en production avec la technologie sous-jacente en ont généralement besoin de moins ; les candidats novices sur la plateforme devraient viser la limite supérieure de cette fourchette.
PCD est une certification reconnue dans l'écosystème GCP et signale des connaissances validées aux employeurs, recruteurs et clients. Sa valeur en termes de temps et de coût dépend de votre rôle et de vos objectifs — elle est la plus avantageuse pour les ingénieurs cloud, architectes et consultants qui travaillent quotidiennement avec GCP ou souhaitent évoluer vers des rôles similaires.
Le score de réussite pour le PCD est de Non publié. L'examen contient 50 questions et dure 2 h.
Les frais d'examen PCD sont de $200 USD. Les frais sont fixés par GCP et peuvent varier selon la région ; confirmez toujours le prix actuel sur la page de certification officielle de GCP avant de réserver.
Les certifications Google Cloud Professional sont valides pendant 2 ans. Recertifiez-vous en repassant la version actuelle de l'examen.
Oui. Vous pouvez passer l'examen en ligne (supervisé via le navigateur sécurisé du fournisseur, disponible 24h/24 et 7j/7 dans la plupart des régions) ou dans un centre de test Pearson VUE en personne pendant les heures ouvrables. Les deux formats utilisent les mêmes questions, la même limite de temps et le même score de réussite.
CertLabPro propose 15 modes d'étude à travers la banque de questions pratiques pour le PCD. Le mode de simulation d'examen reproduit l'examen réel : 50 questions en 2 h, avec le même seuil de réussite de Non publié. Le mode navigation vous permet de lire chaque Q&A de manière statique.