Google PCD: Livraison continue, configuration et automatisation de l'infrastructure — Guide d'étude

By Laurynas Brazys · 3 September 2026 · #google #PCD #certification #exam-prep #study-guide

Fait partie du Google Professional Cloud Developer — 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

La livraison continue sur Google Cloud intègre l’automatisation des builds, la gestion des artefacts, l’orchestration des déploiements, l’infrastructure en tant que code (Infrastructure as Code) et une gouvernance forte pour livrer des changements de manière répétée et sécurisée. Des pipelines robustes associent des artefacts immuables et une configuration déclarative à des politiques et une auditabilité. Cette section explique les choix de conception, les pratiques opérationnelles et les modes de défaillance courants lors de la mise en œuvre de bout en bout de Cloud Build, Cloud Deploy, Artifact Registry, Terraform, Kubernetes, des feature flags et des contrôles de gouvernance.

Orchestration du build et du déploiement

Cloud Build

Déclencheurs : Connectez les builds à des événements de source (push sur une branche, tags, PR) ou à des planifications. Préférez les regex de branche ou de tag pour garantir que seules les références prévues déclenchent un build. Les déclencheurs peuvent s’exécuter avec un compte de service spécifique pour appliquer le moindre privilège ; ne vous fiez pas au compte par défaut si les builds nécessitent un accès étendu aux API.
Étapes de build : Chaque étape s’exécute dans un conteneur. Utilisez des builders spécialisés (docker, gcloud) ou des builders personnalisés lorsque la chaîne d’outils par défaut est insuffisante. Séparez les étapes pour la compilation, les tests unitaires, les tests d’intégration, le linting, les analyses de sécurité et le packaging des artefacts afin que les échecs soient attribuables et mis en cache efficacement.
Substitutions : Utilisez les variables intégrées (PROJECT_ID, SHORT_SHA) et les substitutions personnalisées (préfixées par $_) pour des builds paramétrés. Maintenez les valeurs spécifiques à l’environnement en dehors de la logique de build ; passez-les en tant que substitutions ou résolvez-les plus tard lors du déploiement.
Comptes de service : Le compte de service Cloud Build (PROJECT_NUMBER@cloudbuild.gserviceaccount.com) nécessite des rôles explicites (par exemple, écriture dans Artifact Registry, administrateur de release Cloud Deploy). Attribuez des rôles minimaux et limitez leur portée par projet. Pour les ressources privées, utilisez des pools privés (Private Pools) avec une connectivité VPC.
Artefacts : Publiez des images immuables dans Artifact Registry et, en option, téléversez des artefacts non-conteneur dans Cloud Storage via la section artifacts. Taguez les images à la fois avec une version sémantique et le digest du commit ; utilisez les digests d’image dans les déploiements pour éviter la dérive des tags (tag drift).

Exemple de configuration Cloud Build :

cloudbuild.yaml: steps:
- name: gcr.io/cloud-builders/docker args: [“build”,"-t","$REGION-docker.pkg.dev/$PROJECT_ID/app/app:${SHORT_SHA}","."]
- name: gcr.io/cloud-builders/docker args: [“push”,"$REGION-docker.pkg.dev/$PROJECT_ID/app/app:${SHORT_SHA}"]
- name: gcr.io/cloud-builders/gcloud args: [“deploy”,“releases”,“create”,“app-${SHORT_SHA}”,"–delivery-pipeline=app-pipeline","–images=app=$REGION-docker.pkg.dev/$PROJECT_ID/app/app@sha256:${COMMIT_SHA}"] substitutions: _REGION: us-central1 serviceAccount: projects/$PROJECT_ID/serviceAccounts/cb-deployer@$PROJECT_ID.iam.gserviceaccount.com
Exemple de déclencheur : gcloud builds triggers create cloud-source-repositories –repo=my-repo –branch-pattern=^main$ –build-config=cloudbuild.yaml –service-account=cb-deployer@$PROJECT_ID.iam.gserviceaccount.com

Cloud Deploy

Les pipelines de livraison (delivery pipelines) définissent des étapes (stages) et des cibles (targets) ordonnées. Les cibles référencent des clusters GKE, des services Cloud Run ou d’autres runtimes pris en charge. Marquez les étapes de production avec requireApproval pour contrôler la promotion.
Les déploiements (rollouts) associent une release à une cible ; la promotion fait avancer une release à travers les cibles. Utilisez la livraison progressive (canary, blue/green) et des hooks pour les vérifications avant (predeploy) et après (postdeploy) le déploiement.
Modes de défaillance : L’utilisation de tags modifiables provoque des mises à niveau involontaires ; épinglez toujours les digests. Des permissions IAM manquantes pour le compte de déploiement bloquent les déploiements. Des manifestes qui ne peuvent être rendus ou une dérive de configuration spécifique à l’environnement entraînent des échecs de promotion ; validez les manifestes pendant le build.

Exemples de définitions Cloud Deploy :

delivery-pipeline.yaml: apiVersion: deploy.cloud.google.com/v1 kind: DeliveryPipeline metadata: name: app-pipeline serialPipeline: stages:
- targetId: dev
- targetId: prod strategy: standard: verify: true requireApproval: true
targets.yaml: apiVersion: deploy.cloud.google.com/v1 kind: Target metadata: name: dev gke: cluster: projects/PROJECT/locations/REGION/clusters/DEV_CLUSTER
Définition de la cible de production
apiVersion: deploy.cloud.google.com/v1 kind: Target metadata: name: prod gke: cluster: projects/PROJECT/locations/REGION/clusters/PROD_CLUSTER
Release et promotion : gcloud deploy releases create app-20260903-1 –delivery-pipeline=app-pipeline –region=us-central1 –images=app=us-central1-docker.pkg.dev/PROJECT/app/app@sha256:IMAGE_DIGEST gcloud deploy releases promote –delivery-pipeline=app-pipeline –release=app-20260903-1 –region=us-central1

Artefacts et intégrité de la chaîne d’approvisionnement

Artifact Registry

Dépôts : Créez des dépôts distincts par équipe ou par environnement pour délimiter les permissions IAM et le nettoyage. Utilisez des dépôts régionaux proches des builders et des runtimes pour réduire l’egress et la latence. Les formats de package incluent les images Docker et les packages de langage (Maven, npm, PyPI).
Rétention : Définissez des politiques de nettoyage pour supprimer les tags non référencés ou anciens, en conservant une fenêtre de sécurité pour le rollback. Évitez une rétention agressive qui supprimerait la dernière version fonctionnelle connue.
Provenance et SBOM : Activez la provenance de build pour que les images portent des attestations conformes à SLSA. Générez des SBOM (Software Bill of Materials) pendant le build et stockez-les en tant qu’attestations, améliorant ainsi le tri des vulnérabilités.
Analyse des vulnérabilités : Activez l’analyse de conteneurs et interrompez le build ou bloquez la promotion lorsque des CVE de gravité élevée sont détectées sans correctifs disponibles ou exceptions de politique.
Compromis : La centralisation de tous les artefacts dans un seul projet simplifie la gouvernance mais peut créer un large rayon d’impact (blast radius) ; des dépôts par environnement ou par application réduisent le risque mais ajoutent une surcharge de gestion.

Application de la sécurité de la chaîne d’approvisionnement

Binary Authorization sur GKE peut exiger des attestations (par exemple, « buildé par Cloud Build dans le projet X », « aucune CVE critique »). Intégrez-le avec les portes de contrôle (gates) de Cloud Deploy pour arrêter les releases non conformes.
Modes de défaillance : Se fier à des tags modifiables, à une analyse désactivée ou à des pulls non authentifiés peut conduire à ce que des logiciels non vérifiés atteignent la production. Épinglez les digests et exigez des attestations.

Infrastructure as Code et GitOps

Terraform

Configuration et modules : Factorisez des modules réutilisables avec des entrées/sorties claires et des versions sémantiques. Publiez les modules dans un dépôt ou un registre partagé ; épinglez les versions pour éviter les changements inattendus.
État (State) : Utilisez le backend GCS pour l’état distant avec IAM au niveau du bucket, le versionnement des objets et CMEK. Protégez l’état des modifications humaines et assurez son chiffrement. Évitez les secrets dans l’état en les lisant depuis Secret Manager au moment de l’application (apply) et en utilisant les sources de données (data sources) avec parcimonie. terraform { backend “gcs” { bucket = “tf-state-prod” prefix = “networking” } }
Plans et applications (Applies) : Exécutez terraform plan avec -out et faites en sorte qu’une personne ou un portail automatisé examine le diff ; n’appliquez que le plan précédemment approuvé. Utilisez -refresh-only ou -detailed-exitcode dans les tâches de détection de dérive (drift).
Séparation des environnements : Utilisez des projets, des buckets d’état et des comptes de service distincts pour chaque environnement. Préférez une structure de répertoires par environnement avec des fichiers de variables plutôt que des workspaces pour les organisations complexes. Ne partagez jamais l’état entre les environnements.
Modes de défaillance : Les applications concurrentes corrompent l’état ; imposez la sérialisation avec la CI/CD et le verrouillage (locking) (GCS utilise les préconditions d’objet). Les modifications manuelles dans la console provoquent une dérive (drift) ; restreignez les mutations directes et exécutez des tâches de plan périodiques.

Configuration déclarative Kubernetes

Manifestes : Gardez les objets Kubernetes déclaratifs ; évitez les commandes impératives kubectl dans les flux de production. Épinglez les digests d’images et les requêtes/limites de ressources.
Kustomize : Utilisez une base + des superpositions (overlays) pour gérer les patchs spécifiques à l’environnement sans forker les charts. kustomization.yaml (overlay): resources:
- ../../base patches:
- target: kind: Deployment name: api patch: |
  - op: replace path: /spec/replicas value: 3
Helm : Utilisez des fichiers de valeurs (values files) par environnement ; documentez la précédence (les valeurs en ligne de commande écrasent les fichiers de valeurs, qui écrasent les valeurs par défaut du chart). Générez les templates et faites le rendu en CI (skaffold render ou helm template) afin que les configurations au moment du déploiement soient immuables.
GitOps : Stockez l’état désiré dans Git. Utilisez Cloud Deploy ou Config Sync pour réconcilier les clusters avec Git. Les PRs (Pull Requests) deviennent la surface de contrôle des changements avec des pistes d’audit et des vérifications de politiques. Évitez les modifications par kubectl exec qui ne sont pas capturées dans Git.

Sécurité des Mises en Production, Configuration et Gouvernance

Feature flags et configuration d’exécution

Les feature flags (indicateurs de fonctionnalité) découplent le déploiement de la mise en production (release) ; livrez du code dormant et activez-le par cohorte, pourcentage ou région. Stockez les définitions des flags dans un système à faible latence et à haute disponibilité (Firestore, Memorystore) et mettez-les en cache avec des TTL courts. Journalisez les évaluations pour la traçabilité.
Déploiement progressif : Combinez la répartition du trafic (Cloud Run) ou les sous-ensembles canary (GKE) avec des flags pour minimiser le rayon d’impact (blast radius). Utilisez des métriques de santé et des déclencheurs de rollback automatisés basés sur les SLO.
Rollback sécurisé : Préférez les désactivations rapides via les feature flags. Pour un rollback de binaire, promouvez la dernière release fonctionnelle connue (known-good) ou réappliquez le digest du manifeste précédent.

Variables d’environnement, précédence, secrets

La précédence suit généralement l’ordre suivant : flags d’exécution > variables d’environnement > fichiers de configuration > valeurs par défaut du code. Documentez et standardisez cela à travers les services.
Injectez la configuration avec des ConfigMaps et des variables d’environnement ; utilisez Secret Manager ou les Secrets Kubernetes pour les valeurs sensibles. Effectuez une rotation régulière et évitez d’intégrer (bake) les secrets dans les images.
Exemples d’injection de secrets :
- Variable d’environnement Cloud Run :

undefined

CSI Secret Manager pour GKE :

undefined

Portails de qualité (Quality Gates) dans la CI/CD

Les tests unitaires s’exécutent à chaque commit ; un retour rapide est primordial.
Les tests d’intégration s’exécutent sur des environnements éphémères ou des bacs à sable (sandboxes) avec des données pré-chargées (seeded).
Vérifications de sécurité : SAST, analyse des dépendances, analyse de vulnérabilités des conteneurs, vérifications des politiques d’IaC (Conftest, Policy Controller). Bloquez les fusions (merges) ou les promotions en cas de découvertes critiques.
Vérifications de déploiement : Les actions de prédéploiement (predeploy) et de post-déploiement (postdeploy) de Cloud Deploy valident la disponibilité (readiness), la sécurité des migrations de base de données et les tests de fumée (smoke tests).

Stratégie de branches, revue de code, versionnage, traçabilité

Préférez le développement basé sur le tronc (trunk-based) avec des branches de fonctionnalités à courte durée de vie et des revues de PR (Pull Request) obligatoires. Imposez des vérifications requises et un historique linéaire pour l’auditabilité.
Versionnage : Tags de version sémantique pour les releases ; digests d’image et SHA de commit pour l’immuabilité. Évitez les tags mouvants comme latest dans les déploiements de production.
Traçabilité : Annotez les builds et les releases avec les ID de commit, de PR et de ticket. Émettez des événements de déploiement vers Logging ; attachez des libellés (labels) aux ressources pour le suivi des coûts et de la propriété.

Dérive d’infrastructure, politique, audit, contrôle des changements

Détection de dérive (drift) : Planifiez l’exécution de terraform plan -detailed-exitcode ; alertez sur les codes de sortie non nuls. Pour les clusters, Config Sync assure la convergence à terme vers Git.
Application des politiques (Policy enforcement) : Utilisez les Règles d’administration (Organization Policy) comme garde-fous (par exemple, restreindre les adresses IP externes), Policy Controller pour les contraintes KRM, et Binary Authorization pour la politique sur les images.
Journaux d’audit : Activez les journaux d’audit sur l’activité d’administration (Admin Activity) et l’accès aux données (Data Access) ; routez-les vers des projets centralisés avec des récepteurs (sinks) et une rétention alignée sur la conformité. Cloud Asset Inventory alimente l’historique des changements et l’analyse des accès.
Contrôle des changements : Approbations manuelles pour les promotions en production, avec des justifications capturées sous forme d’annotations. Les fenêtres de gel (freeze windows) peuvent être encodées comme des vérifications de politique dans la CI/CD. Assurez-vous que les procédures de rollback d’urgence sont documentées et testées.

Scénario de Problème Pratique

L’entreprise Acme Retail doit déployer un nouveau order-service sur GKE à travers les environnements de développement et de production avec des déploiements canary sécurisés, une application stricte des politiques et une traçabilité complète des releases. L’équipe doit standardiser l’infrastructure gérée par Terraform, la configuration Kubernetes déclarative avec Kustomize, et une CI/CD auditable utilisant Cloud Build et Cloud Deploy.

Approche :

Établir les dépôts d’artefacts et les identités

Créez les dépôts régionaux Artifact Registry order-docker-dev et order-docker-prod. Accordez au compte de service Cloud Build dans le projet de l’application les rôles roles/artifactregistry.writer et aux nœuds d’exécution GKE le rôle roles/artifactregistry.reader pour le dépôt approprié.
Justification : Des dépôts séparés réduisent le rayon d’impact et simplifient les politiques de cycle de vie. Des permissions IAM explicites évitent les privilèges par défaut excessifs.

Définir Terraform pour l’infrastructure avec une séparation des environnements

Créez les répertoires terraform/envs/dev et terraform/envs/prod. Chaque configuration inclut un backend GCS avec des buckets d’état (state) distincts, un module de cluster GKE, et des liaisons IAM pour le compte de service Cloud Deploy. Exécutez terraform init, plan -out=plan.bin, et apply plan.bin dans une tâche de CI contrôlée (gated) par environnement.
Justification : Un état et des projets par environnement préviennent les impacts accidentels inter-environnements ; les fichiers de plan (plan files) permettent la revue et un contrôle des changements auditable.

Créer la base Kubernetes déclarative et les superpositions (overlays) Kustomize

Placez les manifestes Kubernetes dans k8s/base pour le Deployment, le Service et les HPA avec des images épinglées par leur digest. Créez k8s/overlays/dev et k8s/overlays/prod avec les replicas, les requêtes de ressources et les patchs de configuration. Utilisez une classe CSI Secret Manager pour les identifiants de base de données.
Justification : Une source de vérité unique avec des overlays élimine la dérive et maintient les configurations DRY (Don’t Repeat Yourself) tout en permettant des différences sécurisées spécifiques à chaque environnement.

Implémenter Cloud Build avec des étapes de test et de packaging distinctes

Le fichier cloudbuild.yaml inclut les étapes suivantes : lint et tests unitaires, tests d’intégration sur un namespace de développement jetable, build du conteneur et push vers le dépôt de l’environnement, analyse SBOM et de vulnérabilités, et génération de la provenance. Le déclencheur s’exécute sur les PR vers main pour les tests et sur les fusions (merges) pour le packaging. Les builds s’exécutent en tant qu’un compte de service cb-deployer à moindre privilège.
Justification : Les échecs précoces coûtent moins cher ; la séparation des préoccupations améliore l’observabilité et permet des relances ciblées. Le moindre privilège réduit le risque lié à la chaîne d’approvisionnement (supply chain).

Configurer le pipeline de livraison Cloud Deploy avec une approbation manuelle pour la production et une stratégie canary

Définissez un DeliveryPipeline avec des cibles dev et prod. L’étape de production (prod) requiert une approbation et utilise une stratégie canary (par exemple, 10 % puis 100 %). Utilisez des hooks de prédéploiement (predeploy) pour les vérifications de compatibilité de schéma et les tests de fumée ; le post-déploiement (postdeploy) vérifie les SLO.
Justification : La livraison progressive limite le rayon d’impact et introduit des portails de qualité automatisés, tandis que l’approbation manuelle impose une intervention humaine (human-in-the-loop) pour la production.

Mettre en place le GitOps et l’application des politiques

Protégez la branche main avec des revues requises et des vérifications réussies. Utilisez les contraintes de Policy Controller pour bloquer les pods privilégiés et interdire les tags modifiables. Activez Binary Authorization pour exiger la provenance de Cloud Build et des attestations « aucune CVE élevée » avant l’admission.
Justification : La politique en tant que code (Policy-as-code) empêche les configurations risquées d’atteindre le cluster et fournit une application cohérente.

Gérer la configuration et les feature flags pour une release sécurisée

Stockez la configuration d’exécution non secrète dans des ConfigMaps ; les secrets sont fournis via le CSI de Secret Manager. Introduisez un feature flag order_new_flow lu depuis Firestore avec un déploiement initial à 1 % en production ; les flags sont mis en cache avec un TTL court et journalisés.
Justification : Les flags découplent la release du déploiement, permettant une désactivation instantanée si des problèmes surviennent sans avoir à faire un rollback du binaire.

Assurer l’observabilité, la détection de dérive et la traçabilité

Annotez les builds et les releases avec le SHA du commit, le numéro de la PR et le ticket de changement. Routez les événements Cloud Deploy et les journaux d’audit GKE vers un projet Logging central. Des tâches nocturnes terraform plan alertent en cas de dérive ; Config Sync surveille la divergence KRM, en la réconciliant avec Git.
Justification : Une provenance complète et des pistes d’audit accélèrent la réponse aux incidents ; la détection de dérive continue maintient l’intégrité de l’infrastructure.

Gérer les rollbacks et le contrôle des changements

En cas d’incident, désactiver d’abord order_new_flow via le flag. Si nécessaire, promouvez la release réussie précédente dans Cloud Deploy vers dev et prod. Toutes les promotions en production nécessitent une référence de ticket dans les annotations de la release et une approbation du SRE d’astreinte (on-call).
Justification : Les flags fournissent une atténuation instantanée ; les releases immuables permettent un rollback prévisible. Les approbations et les annotations satisfont à la gouvernance opérationnelle et à la conformité.

← Identité · Tous les domaines · Observabilité →

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