Google PCA: DevOps, ingénierie de livraison et infrastructure en tant que code — Guide d'étude

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

Fait partie du Google Professional Cloud Architect — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Google, ou passez des tests chronométrés sur ExamRoll.io.

Vue d’ensemble

Le DevOps, l’ingénierie de la livraison (Delivery Engineering) et l’Infrastructure as Code (IaC) sur Google Cloud se concentrent sur la livraison continue de changements fiables avec une traçabilité, une automatisation et une sécurité robustes. Les architectures doivent être optimisées pour des cycles de feedback courts, des déploiements reproductibles, une infrastructure immuable et des garde-fous qui s’adaptent à la croissance de l’organisation. Sur Google Cloud, cela combine généralement les bonnes pratiques de gestion de code source ; l’intégration continue (CI) avec Cloud Build ; la gestion des artefacts avec Artifact Registry ; le déploiement continu (CD) avec Cloud Deploy ; Kubernetes avec GKE en utilisant des manifestes, Helm ou Kustomize ; GitOps pour le contrôle de la dérive de configuration ; et l’IaC avec Terraform ou les modèles de déploiement Google Cloud. L’excellence opérationnelle exige une livraison progressive (blue-green, canary, répartition du trafic et feature flags), des contrôles de la chaîne d’approvisionnement logicielle (analyse, provenance, signature), des portes de test et de déploiement, et une gouvernance qui équilibre vitesse, sécurité, auditabilité et responsabilité (ownership).

CI/CD, gestion du code source et orchestration des livraisons

Principes du CI/CD
- Maintenir la branche master/main dans un état livrable ; pratiquer le développement basé sur le tronc (trunk-based development) avec des branches de fonctionnalités à courte durée de vie.
- Automatiser le build, le test, l’analyse et le packaging à chaque changement ; exiger une revue de code avec des approbations obligatoires et des vérifications de statut.
- Maintenir une traçabilité complète du commit → build → digest de l’artefact → livraison en environnement ; intégrer les SHA des commits et les métadonnées de build dans les images et les annotations de déploiement.
- Modes de défaillance : les branches à longue durée de vie, les transferts manuels, les tests instables (flaky tests), les builds non reproductibles et l’absence d’immuabilité des artefacts entraînent des surprises tardives et des rollbacks.
Gestion du code source, branches, pull requests, revue de code et traçabilité
- Utiliser des branches protégées, des revues obligatoires et la signature des commits. Tagger les livraisons (releases) et maintenir un changelog généré à partir des commits de fusion (merge commits).
- Appliquer les fichiers CODEOWNERS et les métadonnées de responsabilité de service (service ownership) pour renforcer la gouvernance par domaine.
- Lier les commits aux tickets et aux déploiements ; exporter les logs et les métadonnées de CI/CD vers Cloud Logging et BigQuery pour l’audit et les métriques DORA.
Cloud Build
- Déclencheurs (Triggers) : se déclenchent sur des événements Git (branche, tag, PR), des invocations manuelles ou via Pub/Sub. Paramétrer avec des substitutions pour la version, l’environnement et les feature flags afin de garder des pipelines DRY (Don’t Repeat Yourself).
- Étapes de build (Build steps) : exécuter des builders officiels ou des conteneurs que vous définissez ; utiliser des étapes parallèles lorsqu’elles sont indépendantes pour réduire la latence ; utiliser des caches pour les dépendances de langage afin d’accélérer les builds.
- Artefacts (Artifacts) : pousser les images vers Artifact Registry avec des tags et des digests immuables ; stocker les SBOMs et les logs de build ; publier les rapports de test en tant qu’artefacts de build.
- Sécuriser les identités de build : exécuter Cloud Build avec un compte de service dédié appliquant le moindre privilège et, si possible, la fédération d’identité de charge de travail (Workload Identity Federation) par dépôt. Pour les réseaux privés ou pour éviter le trafic sortant (egress), utiliser des pools privés (Private Pools). Limiter les clés de compte de service ; préférer les jetons à courte durée de vie.
- Exemple (raccourci) :
  - cloudbuild.yaml:
    - steps:
      - name: gcr.io/cloud-builders/docker args: [build, -t, $REGION-docker.pkg.dev/$PROJECT/app/web:$COMMIT_SHA, .]
      - name: gcr.io/cloud-builders/docker args: [push, $REGION-docker.pkg.dev/$PROJECT/app/web:$COMMIT_SHA]
    - substitutions:
      - _ENV=staging
Cloud Deploy
- Livraisons (Releases) et cibles (targets) : modéliser un pipeline de livraison avec promotion entre les cibles (ex: dev → staging → prod). Une livraison (release) capture une référence d’artefact immuable et une configuration de déploiement.
- Approbations et promotion : exiger des approbations manuelles ou automatisées avec un contrôle basé sur les rôles. La promotion doit être une action rapide et à faible risque car l’artefact et les manifestes restent inchangés.
- Déploiement Canary et rollback : définir des stratégies pour une exposition progressive, des vérifications de santé (health checks) et un rollback automatique en cas d’erreurs de SLO. Enregistrer chaque promotion, approbateur et résultat de vérification pour l’audit.
- Modes de défaillance : des artefacts modifiables entre les environnements, l’utilisation manuelle de kubectl en production ou l’omission de la vérification pré-déploiement provoquent une dérive (drift) et des pannes non traçables.

Infrastructure en tant que code et gestion de la configuration

Terraform
- Modules : capturent des modèles réutilisables (par ex., VPC, clusters GKE, comptes de service, liaisons IAM). Versionnez et épinglez les versions des modules ; publiez des registres de modules internes.
- État distant : stockez dans Cloud Storage avec le versioning, une politique de rétention et une CMEK ; activez le verrouillage ; restreignez l’accès via IAM et l’accès uniforme au niveau du bucket ; sauvegardez l’état.
- Plans et vérifications de politique : exécutez

undefined

dans la CI ; exigez une revue humaine du plan ; appliquez la politique en tant que code (OPA/Conftest, Sentinel ou Policy Controller) pour bloquer les violations (par ex., buckets publics, liaisons IAM larges).

Promotion d’environnement : utilisez des espaces de travail (workspaces) distincts ou des états/backends distincts par environnement ; promouvez les changements via les mêmes versions de modules et variables ; ne modifiez jamais manuellement les ressources cloud. Les entrées sensibles doivent provenir de Secret Manager ou de l’automatisation, jamais codées en dur.
Modes de défaillance : fuite de secrets dans l’état, changements concurrents sans verrouillage, dérive due à des modifications hors bande et dépendances implicites qui cassent la destruction/remplacement.
Modèles de déploiement Google Cloud et configuration déclarative
- Utilisez des outils déclaratifs (Terraform, Google Cloud Deployment Manager ou Kubernetes Configuration as Code) pour définir l’état souhaité plutôt que des scripts d’étapes impératives.
- Préférez l’infrastructure immuable : remplacez les modèles d’instance et mettez à jour les MIG ; déployez de nouveaux GKE Deployments plutôt que de patcher les pods en place. Les modèles immuables simplifient le rollback et l’audit.
- Deployment Manager prend en charge les modèles Jinja/Python pour les ressources Google Cloud mais est limité à Google Cloud ; Terraform offre un écosystème et des outils de politique plus larges. Sélectionnez en fonction de la standardisation et des compétences de l’organisation.
Manifestes Kubernetes, Helm, Kustomize et GitOps
- Manifestes : conservez des modèles de base avec des surcouches (overlays) par environnement ; paramétrez uniquement ce qui doit varier par environnement (par ex., réplicas, limites, points de terminaison).
- Helm : empaquetez, modélisez (template) et versionnez les services avec des charts ; verrouillez les dépendances ; épinglez les digests d’image. Mode de défaillance : le sur-templating obscurcit l’intention et complique la revue.
- Kustomize : gérez les surcouches (base + patchs d’environnement) ; plus simple que Helm lorsque Kubernetes pur est suffisant.
- GitOps : un contrôleur (par ex., Config Sync, Argo CD, Flux) réconcilie en continu les clusters avec l’état souhaité dans Git ; chaque changement est une PR avec une revue et une piste d’audit. Détectez et corrigez automatiquement la dérive.

Livraison progressive, chaîne d’approvisionnement, tests et vérification

Feature flags et gestion du trafic
- Les feature flags découplent le déploiement de la mise en production (release) ; utilisez-les pour une exposition progressive, des tests A/B et des interrupteurs d’urgence (kill switches). Assurez-vous que les états des flags sont versionnés et auditables ; retirez les flags obsolètes.
- Répartition du trafic : sur Cloud Run, utilisez le routage basé sur un pourcentage entre les révisions ; sur GKE, utilisez un service mesh ou des contrôleurs d’ingress qui prennent en charge le routage pondéré. Pour les API sous un seul nom d’hôte/TLS, conservez des services backend distincts par chemin derrière le HTTP(S) Load Balancer ; le routage par chemin isole proprement les anciennes/nouvelles versions tout en préservant une URL et un certificat uniques.
- Blue-green : exécutez deux piles prêtes pour la production ; basculez le trafic de manière atomique via le load balancer, les sélecteurs de service ou le trafic de révision de Cloud Run. Permet un rollback instantané mais double le coût en régime de croisière.
- Canary et déploiement progressif : augmentez progressivement le trafic à partir d’une petite portion tout en mesurant les signaux de référence (golden signals) et les KPI métier ; automatisez le rollback en cas de régression.
Contrôles de la chaîne d’approvisionnement logicielle
- Analyse d’images : activez l’analyse de vulnérabilités d’Artifact Analysis ; faites échouer les builds en cas de vulnérabilités critiques ou d’images de base connues comme défectueuses ; maintenez une cadence de correctifs.
- Provenance et signature : générez une provenance de build conforme à SLSA dans Cloud Build ; signez les artefacts avec Cosign ; appliquez des politiques de Binary Authorization exigeant des attestations avant le déploiement.
- Gestion des dépendances : épinglez les versions et les digests, maintenez des SBOM, intégrez (vendor) les dépendances critiques et vérifiez les sommes de contrôle (checksums). Les modes de défaillance incluent la dérive des dépendances transitives et les registres compromis.
Pyramide de tests, portes de déploiement et vérification post-déploiement
- Pyramide : mettez l’accent sur les tests unitaires rapides ; ajoutez des tests d’intégration et de contrat ; exécutez des tests de bout en bout ciblés. Conservez des données de test réalistes et anonymisées (utilisez Cloud DLP pour supprimer les PII).
- Portes de déploiement : appliquez des seuils pour le taux de réussite des tests, l’état des vulnérabilités, la conformité aux politiques et la revue de code avant la promotion ; exigez une approbation manuelle pour la production lorsque le risque est élevé.
- Vérification post-déploiement : exécutez des tests de fumée (smoke tests), des vérifications synthétiques et des analyses canary à l’aide de Cloud Monitoring, Error Reporting et Trace. Si les KPI se dégradent, déclenchez un rollback automatisé et ouvrez un incident avec le contexte capturé.
- Diagnostics opérationnels : déployez l’agent Cloud Logging si nécessaire et instrumentez les services pour Trace et Debugger. Conservez des runbooks pour une remédiation sûre (par ex., redimensionner un disque persistant en ligne et exécuter

undefined

avec un temps d’arrêt minimal).

Gouvernance, sécurité, auditabilité et propriété

Rapidité et sécurité
- Le développement basé sur le tronc (trunk-based development) avec des PRs à courte durée de vie et une revue obligatoire maintient le flux sans sacrifier la qualité.
- Les pipelines en libre-service avec des modèles pour les stacks courants (GKE + Helm, Cloud Run, Dataflow) accélèrent les équipes et réduisent le risque lié aux solutions sur mesure.
Accès, identité et approbations
- Utiliser des comptes de service dédiés par étape de pipeline avec le moindre privilège et la fédération d’identité de charge de travail (Workload Identity Federation) ; éviter les clés statiques.
- Séparer les tâches : les développeurs construisent ; les gestionnaires de versions (release managers) approuvent la promotion en production ; les opérateurs d’exécution possèdent la configuration d’exécution et les budgets.
Auditabilité et conformité
- Exporter les journaux Cloud Build, Cloud Deploy et Cloud Audit Logs vers BigQuery. Utiliser les vues de jeux de données et IAM pour partager des données d’audit ciblées avec les auditeurs. Conserver les métriques à long terme en les exportant vers Cloud Storage ou BigQuery conformément à la politique.
- Enregistrer les digests d’artefacts dans les métadonnées de déploiement. Maintenir un SBOM et une provenance de bout en bout pour chaque version.
Propriété et SLO
- Chaque service a un propriétaire, une rotation d’astreinte, des SLO et des budgets d’erreur qui conditionnent les mises en production. Lier les politiques de déploiement à la conformité des SLO pour éviter de pousser des changements lorsque le budget est épuisé.
Compromis et pièges courants
- Coût du blue-green vs. vitesse de restauration (rollback) ; confiance du canary vs. temps de déploiement complet.
- Cohérence de GitOps vs. flexibilité opérationnelle ; autoriser des procédures d’urgence (break-glass) contrôlées avec journalisation et PRs de suivi.
- L’excès de modèles (templating) réduit la lisibilité ; garder la configuration explicite et minimale.
- Une politique centralisée prévient les erreurs de configuration mais doit être déployée de manière itérative pour éviter de bloquer inutilement les équipes.

Scénario de problème pratique

Entreprise : Borealis Fintech

Défi : Borealis lance une nouvelle API de paiement sur GKE tout en maintenant les versions v1 et v2 sous le même nom d’hôte et certificat TLS. Ils ont besoin d’une traçabilité de bout en bout, d’une livraison progressive avec canary et feature flags, de contrôles stricts de la chaîne d’approvisionnement (supply-chain) et de promotions auditées entre les environnements de développement, de pré-production (staging) et de production. Ils souhaitent également utiliser GitOps pour la configuration du cluster et Terraform pour les ressources de la plateforme.

Approche :

Établir le contrôle de source et la stratégie de branches
- Créer un mono-repo avec des répertoires de services et un dépôt d’infrastructure séparé. Appliquer la protection de la branche principale (main), les revues de PR obligatoires, les CODEOWNERS et les commits signés. Justification : un flux basé sur le tronc avec une propriété claire et un historique prêt pour l’audit.
Construire les artefacts avec Cloud Build et Artifact Registry
- Définir un fichier cloudbuild.yaml pour construire et pousser les images taguées par $COMMIT_SHA et annotées avec le SBOM et la provenance. Utiliser un compte de service Cloud Build dédié avec le moindre privilège et un pool privé (Private Pool). Justification : des builds reproductibles et isolés avec des digests traçables.
- Exemple :

undefined

Mettre en œuvre les contrôles de la chaîne d’approvisionnement logicielle
- Activer l’analyse de vulnérabilités dans Artifact Registry. Générer la provenance et signer les images avec Cosign dans les étapes post-build de Cloud Build. Configurer Binary Authorization pour exiger les signatures et la réussite de l’analyse avant le déploiement sur GKE. Justification : bloquer les artefacts non fiables ou vulnérables au moment de l’application de la politique.
Modéliser la livraison avec Cloud Deploy
- Définir un pipeline de livraison avec les cibles dev, staging, prod et une stratégie canary pour la production. Exiger une approbation manuelle pour la production avec des approbateurs basés sur les rôles. Justification : une promotion immuable et des approbations auditables.
- clouddeploy.yaml (extrait) :

undefined

Router les API v1 et v2 sous le même nom d’hôte
- Configurer un Load Balancer HTTP(S) externe avec des services de backend distincts pour les chemins /v1 et /v2, chacun pointant vers le NEG GKE correspondant. Justification : une isolation propre basée sur les chemins, le même certificat et DNS, et une déployabilité indépendante.
- Exemple (extrait) :

undefined

Gérer l’infrastructure avec Terraform
- Créer des modules pour VPC, GKE, Artifact Registry, les comptes de service et IAM. Stocker l’état distant dans un bucket Cloud Storage protégé par CMEK avec gestion des versions et rétention. Appliquer les politiques OPA dans la CI pour prévenir les changements à risque. Justification : un provisionnement de plateforme réutilisable, révisable et gouverné.

undefined

Configurer Kubernetes avec Helm/Kustomize et GitOps
- Maintenir des manifestes de base pour l’API et des superpositions (overlays) par environnement en utilisant Kustomize. Utiliser Config Sync ou Argo CD pour réconcilier les clusters avec l’état Git. Justification : des opérations déclaratives, auditables et résistantes à la dérive.
Livraison progressive avec canary et feature flags
- Utiliser le canary de Cloud Deploy pour la production et un SDK de feature flags (OpenFeature) pour contrôler l’accès à la nouvelle logique. Commencer à 5% du trafic, promouvoir automatiquement si les SLO sont sains ; restaurer (rollback) automatiquement en cas de dégradation, et utiliser le flag comme interrupteur d’urgence (kill switch). Justification : réduire le rayon d’impact et découpler le déploiement de la mise en production (release).
Portails de qualité et vérification
- Étapes du pipeline : tests unitaires → tests d’intégration sur un environnement éphémère → analyse de conteneur → vérifications de politiques → tests de bout en bout en pré-production (staging) → canary en production avec vérification automatisée basée sur les SLO (Cloud Monitoring, Error Reporting, Trace). Justification : un feedback rapide et précoce, une sécurité renforcée avant la production, et des vérifications de santé objectives post-déploiement.
Opérations, journalisation et audit
- Installer les agents Cloud Logging/Monitoring pour les VM de support et activer les journaux/métriques des charges de travail GKE. Exporter les journaux de CI/CD et d’audit vers BigQuery avec des vues ciblées pour les auditeurs. Maintenir des runbooks (y compris des procédures de restauration sécurisée et de basculement d’urgence du DNS ou du LB). Justification : une observabilité pour une remédiation rapide et des preuves prêtes pour la conformité.

Cette conception préserve la rapidité grâce à un flux basé sur le tronc et des pipelines automatisés ; la sécurité avec le canary, les feature flags et Binary Authorization ; l’auditabilité avec des artefacts immuables, des approbations et des journaux centralisés ; et une propriété claire via les CODEOWNERS et des environnements contrôlés par GitOps.

← Opérations · Tous les domaines · Coûts →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →