Google Cloud Professional Cloud DevOps Engineer
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 DevOps Engineer (PCDOE) valide la capacité à appliquer les principes de l'ingénierie de la fiabilité des sites (SRE) de Google aux services de production sur Google Cloud. L'examen combine le contenu DevOps classique (CI/CD avec Cloud Build et Cloud Deploy, GitOps, Artifact Registry, IaC avec Terraform) avec l'approche SRE distinctive de Google — SLO, SLI, budgets d'erreurs, réduction du travail ingrat, culture du postmortem. Il couvre également la suite complète Cloud Operations (Logging, Monitoring, Trace, Profiler, Error Reporting), les opérations GKE au quotidien, et le FinOps. Le PCDOE est l'équivalent GCP de l'AWS DevOps Engineer Professional et de l'Azure AZ-400 — plus proche dans l'esprit du livre Google SRE que d'une certification DevOps axée sur les outils.
Hiérarchie des ressources, stratégies d'organisation, IAM de base, garde-fous réseau et sécurité, IaC avec Terraform et Cloud Foundation Toolkit. 20 %.
Plus grand domaine avec 23 %. Cloud Build, Cloud Deploy, Skaffold, Artifact Registry, stratégies de déploiement (blue-green, canary, rolling), GitOps avec Config Sync. Fort accent sur les scénarios de conception de pipelines.
À égalité pour le plus grand domaine avec 23 %. Conception de SLI / SLO / budget d'erreurs, identification et réduction du travail ingrat, planification de la capacité, pratiques d'astreinte, postmortems. Inspiré directement du livre Google SRE.
Routage et récepteurs Cloud Logging, métriques basées sur les logs, tableaux de bord et alertes Cloud Monitoring, Cloud Trace, Cloud Profiler, Error Reporting. 22 %.
Plus petit domaine à 12 %, mais à haute densité. Redimensionnement de GKE, familles de machines Compute Engine, FinOps avec Active Assist et Recommender, ajustement de l'autoscaling.
Les services que vous rencontrerez à l'examen et pourquoi chacun compte.
Service CI géré qui exécute des builds, des tests et des images conteneur sur des workers hébergés par Google, piloté par un fichier cloudbuild.yaml déclaratif.
Pourquoi il est à l'examen : Le Domaine 2 (Pipelines CI/CD) désigne Cloud Build comme l'exécuteur de build PCDOE natif canonique — le substrat pour les créations d'images, l'attestation et les déclencheurs de pipeline.
Service de livraison continue géré qui promeut des images conteneur à travers des cibles GKE / Cloud Run ordonnées avec des approbations et un rollback.
Pourquoi il est à l'examen : Le Domaine 2 teste les modèles de livraison progressive (canary, bleu/vert) — Cloud Deploy est la réponse équivalente à AWS CodeDeploy sur GCP.
Registre unifié pour les packages Docker, Helm, Maven, npm, Python, Go et OS avec isolation VPC-SC et analyse des vulnérabilités.
Pourquoi il est à l'examen : Le Domaine 2 + le Domaine 5 mettent l'accent sur la provenance des artefacts et l'analyse des vulnérabilités — Artifact Registry est le point d'accès de la chaîne d'approvisionnement et la source d'images pour Cloud Deploy.
Hébergement Git géré intégré aux déclencheurs Cloud Build, Cloud Logging et Cloud Identity IAM pour les workflows de contrôle de code source.
Pourquoi il est à l'examen : Le Domaine 2 s'attend à une source de vérité intégrée pour les déclencheurs Cloud Build et les déploiements Cloud Deploy — CSR est l'équivalent de AWS CodeCommit.
Kubernetes géré avec les modes Standard et Autopilot, des plans de contrôle régionaux, une entrée multi-clusters et des mises à niveau de pools de nœuds gérées.
Pourquoi il est à l'examen : Le Domaine 3 (Pratiques SRE) et le Domaine 4 (Observabilité) reposent sur GKE — le déploiement de charges de travail, l'autoscaling conscient des SLO et les mises à niveau continues sont tous centrés sur GKE.
Contrôleur de configuration GitOps qui synchronise l'état déclaratif du cluster (Kustomize, Helm, Config Sync) et applique les contraintes du Policy Controller (OPA Gatekeeper) sur les flottes.
Pourquoi il est à l'examen : Le Domaine 1 (Initialisation d'une organisation Google Cloud) et le Domaine 3 (Pratiques SRE) testent GitOps et le concept de politique en tant que code — ACM est la réponse GCP nommée.
Add-on Kubernetes qui gère les ressources GCP (jeux de données BigQuery, sujets Pub/Sub, liaisons IAM) comme des CRD réconciliées à partir des manifestes de cluster.
Pourquoi il est à l'examen : Le Domaine 1 teste l'infrastructure déclarative sous forme GitOps — Config Connector permet aux équipes de plateforme de déployer le provisionnement GCP parallèlement aux charges de travail avec le même kubectl apply.
HashiCorp Terraform avec les fournisseurs officiels google + google-beta, ainsi que les modules Cloud Foundation Toolkit et la bibliothèque de politiques Terraform-validator.
Pourquoi il est à l'examen : Le Domaine 1 désigne Terraform comme l'outil IaC de facto pour les zones d'atterrissage, les projets, les réseaux et l'IAM — le PCDOE attend une maîtrise de la structure des modules et de la stratégie d'état.
Runtime de conteneur serverless (piloté par requête ou événement) avec répartition du trafic par révision, sidecars et mTLS géré via Cloud Service Mesh.
Pourquoi il est à l'examen : Le Domaine 2 teste la livraison progressive pour les services sans état — les révisions Cloud Run et la répartition du trafic sont le primitif canary canonique.
Calcul serverless piloté par événement (déclencheurs HTTP et Eventarc) pour une interconnexion légère entre Pub/Sub, Cloud Storage et Firestore.
Pourquoi il est à l'examen : Le Domaine 4 (Observabilité) cite Functions comme le substrat pour l'automatisation de la réponse aux incidents et les runbooks événementiels.
Orchestration serverless qui enchaîne les API Google Cloud et les endpoints HTTP avec des réessais, des étapes parallèles et une gestion structurée des erreurs.
Pourquoi il est à l'examen : Le Domaine 4 attend une remédiation automatisée — Workflows est l'équivalent de AWS Step Functions pour la réponse aux incidents et les playbooks de rollback multi-services.
Service de file d'attente de tâches entièrement géré avec limitation de débit, déduplication et cibles HTTP / App Engine pour un travail asynchrone et exactement une fois.
Pourquoi il est à l'examen : Le Domaine 5 (Performance et Coût) teste les modèles de délestage de charge — Cloud Tasks dissocie les producteurs à fort trafic des consommateurs à débit limité et atténue les pics de coût.
Mode de fonctionnement de GKE où Google gère les nœuds, l'autoscaling et le dimensionnement des pools de nœuds — facturé par pod avec une disponibilité garantie par SLA.
Pourquoi il est à l'examen : Le Domaine 5 désigne Autopilot comme le compromis coût/effort opérationnel pour les équipes qui souhaitent une fiabilité de qualité SRE sans gérer les pools de nœuds.
Regroupement logique de plusieurs clusters GKE à travers des projets, régions et environnements on-prem avec l'activation de fonctionnalités à l'échelle de la flotte (Config Sync, Policy Controller, Identity).
Pourquoi il est à l'examen : Le Domaine 1 + le Domaine 3 testent les opérations multi-clusters — les flottes sont l'unité de propagation de la politique et de l'identité pour les équipes de plateforme gérant de nombreux clusters.
Plateforme open-source de livraison continue multi-cloud avec support natif GKE / Cloud Run, étapes de jugement manuel et analyse canary automatisée.
Pourquoi il est à l'examen : Le Domaine 2 contraste Cloud Deploy (géré, avec opinion) avec Spinnaker (auto-hébergé, multi-cloud) — savoir quand chacun convient est une distinction récurrente du PCDOE.
IAM Google Cloud avec des liaisons conditionnelles, plus Workload Identity qui fédère les pods GKE / externes vers les comptes de service Google sans clés à longue durée de vie.
Pourquoi il est à l'examen : Le Domaine 1 + le Domaine 3 reposent sur l'authentification sans clé — Workload Identity est la manière canonique pour les pipelines et les pods d'assumer des identités GCP avec le moindre privilège.
Pile d'observabilité intégrée — Cloud Logging pour l'agrégation des journaux, Cloud Monitoring pour les métriques et les alertes, Cloud Trace pour la latence et Cloud Profiler pour l'échantillonnage continu CPU/heap.
Pourquoi il est à l'examen : Le Domaine 4 (Observabilité et Dépannage) est la raison d'être de cette suite ; le PCDOE attend une utilisation fluide de MQL, des métriques basées sur les journaux et des vérifications de disponibilité.
Error Reporting agrège et groupe les traces de pile de Cloud Logging en problèmes exploitables ; Cloud Debugger capture l'état de l'application à partir du code de production en cours d'exécution sans redéploiement.
Pourquoi il est à l'examen : Le Domaine 4 teste le triage d'incidents en direct — Error Reporting détecte les régressions, Debugger inspecte l'état sans forcer un rollback.
Définitions SLO natives sur Service Monitoring avec des alertes de taux d'épuisement du budget d'erreur glissantes et des politiques de vitesse de publication basées sur le budget.
Pourquoi il est à l'examen : Le Domaine 3 (Pratiques SRE) est construit autour des SLI/SLO/budgets d'erreur — le PCDOE attend des candidats qu'ils traduisent les attentes des utilisateurs en politiques d'alerte de taux d'épuisement.
$135k–$185k–$280k USD annuel
Cette fourchette reflète les salaires des ingénieurs SRE et DevOps basés aux États-Unis, où GCP est la plateforme principale. Les SRE L5 des FAANG dépassent les 300 000 $ en rémunération totale. Les rôles purement opérationnels ont tendance à être moins rémunérés ; les postes d'ingénieur SRE senior / ingénieur de production dans les entreprises numériques natives de GCP ont tendance à être mieux rémunérés. La certification est un signal fort, mais elle s'associe mieux à une expérience d'astreinte en production démontrée.
Source : levels.fyi 2025–2026 (SRE Google L4–L5, ingénieurs plateforme seniors chez les licornes "GCP-shop" et FAANG), U.S. BLS OEWS May 2024 (15-1244 network and computer systems administrators, 15-1252 software developers). Les chiffres sont approximatifs ; la rémunération réelle dépend du rôle, de la région et de l'expérience.
La demande pour le PCDOE a augmenté régulièrement à mesure que la culture "SRE-first" de GCP s'est exportée vers ses clients. Forte demande dans les entreprises numériques natives de GCP (Spotify, Snap, PayPal, plusieurs grands détaillants, studios de jeux) où le modèle SRE est déjà adopté, et chez les partenaires Google Cloud qui développent des pratiques de services gérés. La certification s'associe naturellement avec Kubernetes CKA / CKAD et Terraform Associate pour former un profil SRE cloud-native solide. Les titulaires signalent constamment une forte réactivité des recruteurs pour les rôles d'ingénieur SRE et d'ingénieur plateforme senior. Le PCDOE signale également la maîtrise du livre Google SRE, ce qui est en soi un signal d'embauche dans les entreprises qui ont adopté le modèle SRE.
Il n'y a pas de prérequis formels. Google recommande trois ans ou plus d'expérience dans l'industrie et un an ou plus de conception et de gestion de solutions sur Google Cloud. En pratique, le PCDOE n'est pas une première certification GCP crédible — les candidats qui réussissent ont déployé des systèmes en production et ont effectué des rotations d'astreinte.
L'Associate Cloud Engineer (ACE) est le jalon le plus courant, mais n'est pas strictement requis si vous gérez déjà des environnements de production AWS ou Azure. La lecture du livre Google SRE ("Site Reliability Engineering") et du SRE Workbook fait partie intégrante de la préparation — de nombreuses questions d'examen paraphrasent directement des passages. La maîtrise de Kubernetes (Deployments, Services, HPA, PodDisruptionBudgets), de Terraform et des pipelines Cloud Build est requise. Le parcours d'apprentissage officiel DevOps Engineer sur Google Cloud Skills Boost (environ 40 à 60 heures) couvre le programme.
Le PCDOE est classé professionnel et est modérément difficile — le contenu spécifique au SRE (SLO, budgets d'erreurs, travail ingrat) déroute davantage les candidats traditionnellement axés sur les opérations que les ingénieurs en fiabilité des sites expérimentés. Prévoyez 80 à 130 heures d'étude sur 8 à 12 semaines si le PCDOE est votre première certification professionnelle GCP, ou 40 à 70 heures sur 4 à 6 semaines si vous détenez déjà l'ACE et une expérience SRE d'astreinte. 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 constitué par les questions sur la philosophie SRE — la réponse attendue de Google repose souvent sur des distinctions subtiles (quand dépenser le budget d'erreurs plutôt que de geler les déploiements, quand la réduction du travail ingrat vaut la peine d'être automatisée plutôt que d'être acceptée). Le deuxième écueil concerne les modèles de production GKE, en particulier la conception des pools de nœuds, les PodDisruptionBudgets et Workload Identity. Google ne publie pas de scores numériques — seulement réussite/échec. La certification est valide pendant deux ans et le renouvellement nécessite de repasser l'examen en cours.
Guide d'examen actuel mis à jour fin 2023 pour ajouter Cloud Deploy, la couverture Config Sync / GitOps et les scénarios GKE Autopilot actualisés. Pondération accrue du domaine de la philosophie SRE.
Mise à jour majeure qui a introduit Cloud Build comme surface CI principale et a aligné le contenu SLO / budget d'erreurs avec le SRE Workbook.
PCDOE (Google Cloud Professional Cloud DevOps Engineer) 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.
PCDOE 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 PCDOE est de Non publié. L'examen contient 50 questions et dure 2 h.
Les frais d'examen PCDOE 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 PCDOE. 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.