Ingénieur DevOps Cloud Professionnel (PCDOE) sur GCP : ce qui est réellement à l'examen
Le PCDOE teste les pratiques SRE et DevOps sur GCP — Cloud Build, Cloud Deploy, pipelines GKE, conception de SLO, réponse aux incidents. Voici à quoi s'attendre et comment il se compare aux AZ-400 et DOP-C02.
Le PCDOE — Professional Cloud DevOps Engineer — est la certification DevOps de Google orientée SRE. 200 $, deux heures, environ 50 questions, validité de deux ans. Si vous avez déjà passé un examen professionnel Google, c'est le format standard. Ce qui n'est pas standard, c'est la densité des études de cas. Le PCDOE a la réputation d'être l'un des examens professionnels Google les plus difficiles à réussir du premier coup, et la raison en est presque entièrement que les questions sont longues, très axées sur des scénarios, et supposent que vous avez réellement géré un service en production.
Les taux de réussite ne sont pas publiés — Google ne publie pas non plus de scores numériques, seulement une mention "réussite/échec" — mais le taux de réussite anecdotique au premier essai, issu des discussions de groupes d'étude, est nettement inférieur à celui de l'ACE et légèrement inférieur à celui du PCA. Prenez cela avec des pincettes habituelles. Les taux de réussite auto-déclarés sont biaisés par les personnes qui ont échoué et veulent exprimer leur frustration.
Ce que l'examen couvre réellement
Le guide officiel divise le PCDOE en cinq domaines. La pondération est réorganisée tous les deux ans, mais la structure reste cohérente :
- Application des principes d'ingénierie de la fiabilité des sites (SRE). Conception de SLO et SLI, budgets d'erreur, réduction de la pénibilité, post-mortems sans blâme. Directement tiré du livre SRE de Google — lisez au moins les chapitres sur les SLO, les alertes et la réponse aux incidents si vous ne l'avez pas fait.
- Construction et implémentation de pipelines CI/CD. Cloud Build, Artifact Registry, Cloud Deploy, Skaffold pour les workflows du local au cluster, intégration avec GitHub / GitLab. Analyse de conteneurs avec Artifact Analysis. Binary Authorization pour les images signées.
- Implémentation de stratégies de surveillance des services. Cloud Monitoring, Cloud Logging, Cloud Trace, Cloud Profiler, Error Reporting. L'ensemble de la suite "Cloud Operations" (anciennement Stackdriver — la documentation utilise encore "Cloud Ops" mais les recruteurs et les anciens ingénieurs utiliseront les deux noms indifféremment).
- Optimisation des performances des services. Réglage des charges de travail GKE, autoscaling (HPA, VPA, cluster autoscaler), optimisation des coûts, planification de la capacité.
- Gestion des incidents de service. Rotations d'astreinte, gestion des incidents, runbooks, rédactions post-mortem. Oui, ils posent des questions sur les processus, pas seulement sur les outils.
Les questions d'étude de cas sont la partie difficile. Vous recevrez un scénario décrivant une entreprise fictive — son architecture, ses points faibles actuels, la structure de son équipe — et trois ou quatre questions qui vous obligent à retenir tout cela simultanément. La lecture rapide est la cause d'échec de nombreuses personnes. Les questions sont conçues de manière à ce que la réponse évidente devienne fausse une fois que vous avez relu attentivement le scénario.
Ce que vous devez réellement savoir
Tous les services GCP n'apparaissent pas. Voici la liste approximative des sujets, pondérée par leur fréquence d'apparition dans les rapports d'étude :
| Service / sujet | Poids à l'examen |
|---|---|
| Cloud Build, Cloud Deploy, Artifact Registry | Élevé |
| GKE operations, autoscaling, workload identity | Élevé |
| SLO / SLI / error budget math | Élevé |
| Cloud Monitoring, alerting policies, dashboards | Élevé |
| Cloud Logging, log-based metrics, log routing | Moyen |
| Binary Authorization, container scanning | Moyen |
| Cloud Trace, Profiler, Error Reporting | Moyen |
| Terraform / Config Connector basics | Moyen |
| Anthos / multi-cluster (plus léger qu'auparavant) | Faible |
| Pub/Sub, Cloud Tasks pour les modèles asynchrones | Faible |
Vous n'avez pas besoin de mémoriser chaque clé YAML de Cloud Build. Vous devez savoir reconnaître quand Cloud Build est la bonne réponse par rapport à Cloud Deploy ou à un CI tiers combiné à Cloud Deploy. L'examen adore les questions du type "l'entreprise X utilise Y, que doit-elle faire ensuite".
Comparaison avec AZ-400 et DOP-C02
Les trois certifications couvrent des sujets similaires au niveau conceptuel — pipelines, surveillance, réponse aux incidents, IaC, sécurité — mais avec des accents différents.
| PCDOE | AZ-400 | DOP-C02 | |
|---|---|---|---|
| Coût | $200 | $165 | $300 |
| Durée | ~2h, ~50 q | ~150 min, ~50 q | ~3h, ~75 q |
| Validité | 2 years | 1 year, renouvellement gratuit | 3 years |
| Profondeur SRE / SLO | Élevée | Faible | Moyenne |
| Focus CI/CD natif | Cloud Build / Deploy | Azure DevOps + GitHub | CodePipeline / CodeBuild |
| Focus IaC | Terraform, Config Connector | Bicep, ARM, Terraform | CloudFormation, CDK |
| Partie la plus difficile | Densité des études de cas | Étendue d'Azure DevOps | Questions verbeuses du DOP-C02 |
Le PCDOE s'appuie le plus sur les concepts SRE — SLO, budgets d'erreur, pénibilité — car Google a littéralement inventé ce vocabulaire. L'AZ-400 s'appuie sur Azure DevOps (le produit) et l'intégration de GitHub Actions. Le DOP-C02 couvre la plus grande surface, mais avec une profondeur de scénario moins importante que le PCDOE.
Si vous travaillez sur GCP, le PCDOE est le choix évident. Si vous travaillez sur Azure, l'AZ-400. Si vous travaillez sur AWS, le DOP-C02. Les compétences se chevauchent fortement et les pipelines se ressemblent presque une fois que l'on fait abstraction des noms de services. Chercher des certifications DevOps entre différents clouds est rarement la bonne approche — la certification qui correspond à votre travail quotidien sera celle pour laquelle vous pourrez réellement étudier en utilisant votre travail réel.
À qui s'adresse cette certification
Honnêtement, trois catégories de personnes :
Ingénieurs SRE / DevOps seniors déjà sur GCP. C'est le public pour lequel l'examen est conçu. Si vous avez été d'astreinte pour un service fonctionnant sur GKE pendant au moins un an, les questions ressembleront à des prolongements des discussions que vous avez déjà eues au sein de votre équipe. Trois à six semaines de préparation ciblée sont généralement suffisantes.
Ingénieurs plateforme venant d'AWS ou d'Azure. Les concepts SRE se transfèrent un pour un. Les noms de services, non. Prévoyez 2 à 3 mois d'étude pour transposer vos connaissances existantes sur Cloud Build, Cloud Deploy et la suite Cloud Ops. Construisez un petit projet qui réalise du CI via Cloud Build, déploie sur GKE via Cloud Deploy et émet des SLO vers Cloud Monitoring. Ce seul projet couvre peut-être 40% de l'examen.
Personnes en reconversion visant un titre DevOps. Honnêtement, c'est un objectif ambitieux. Le PCDOE suppose que vous avez traversé de véritables incidents de production. Si ce n'est pas le cas, les questions d'étude de cas vous sembleront étrangères d'une manière qu'aucun cours vidéo ne pourra corriger. Passez d'abord le CKA ou le KCNA, travaillez dans un rôle de plateforme pendant un an, puis revenez au PCDOE.
Notes d'étude du terrain
Quelques points qui déroutent systématiquement les gens :
Le livre SRE est une lecture obligatoire, pas facultative. Les ouvrages de Google Site Reliability Engineering et The Site Reliability Workbook sont tous deux disponibles gratuitement en ligne. Les chapitres sur les SLO / budgets d'erreur sont directement évaluables. Les ignorer et se fier aux supports de cours est la raison la plus courante pour laquelle des ingénieurs compétents échouent à cet examen.
Cloud Deploy est plus récent et bénéficie d'une pondération disproportionnée. Il est passé en disponibilité générale (GA) en 2022. Les guides d'étude antérieurs le couvrent insuffisamment. Passez un week-end à réaliser le démarrage rapide officiel de Cloud Deploy de bout en bout avec deux environnements et un déploiement canari — cela correspond directement à plusieurs questions d'examen.
Connaissez la différence entre les pools privés Cloud Build et les pools par défaut. Lorsque les questions impliquent des builds internes au VPC, les pools privés sont généralement la réponse. Les questions génériques du type "nous voulons des builds plus rapides" concernent généralement le type de machine ou la taille du pool de workers.
Binary Authorization apparaît plus souvent que prévu. Le scénario "nous devons appliquer des images signées en production" est presque garanti d'apparaître sous une forme ou une autre.
En résumé
Le PCDOE est une certification professionnelle solide si vous pratiquez réellement le DevOps sur GCP. Il offre une rémunération à peu près équivalente à celle du PCA sur des marchés similaires — 150 000 à 200 000 $ de salaire de base pour les rôles d'ingénieur DevOps / SRE senior dans les grandes métropoles américaines, avec une rémunération totale (FAANG et ad-tech) dépassant les 250 000 $ une fois que les actions s'accumulent. La certification n'est pas un multiplicateur de salaire en soi ; c'est l'expérience SRE sous-jacente qui l'est. Le PCDOE ne fait que rendre cette expérience lisible pour les recruteurs.
Si vous étudiez, parcourez la banque de questions PCDOE sur CertLabPro ou commencez un examen chronométré. Les questions d'étude de cas dans la banque sont celles qui correspondent le plus à la forme de l'examen réel — les simples "dumps" de questions de rappel ne vous préparent pas à ce qui apparaît réellement.
Si vous hésitez à vous lancer : rédigez-vous des post-mortems au travail ? Si oui, cette certification vous semblera évidente. Si non, passez d'abord par un ou deux incidents réels, puis revenez-y.