Google Cloud Professional Cloud Developer
Dernière révision : mai 2026
Une référence concise des modèles d'architecture évalués par l'examen PCD. Lisez de haut en bas ou sautez à une section.
Les microservices nécessitent une communication synchrone de type requête/réponse et une communication asynchrone basée sur les événements.
Utilisez gRPC ou HTTP pour les appels synchrones. Utilisez Pub/Sub pour la diffusion d'événements asynchrones et la distribution.
Pourquoi: Pub/Sub découple entièrement les services pour la fiabilité et une mise à l'échelle indépendante. Les appels directs fournissent des réponses synchrones à faible latence.
Un service de calcul sans état (Cloud Run, Cloud Functions) doit traiter des fichiers temporaires.
Utilisez Cloud Storage pour toutes les opérations d'E/S de fichiers temporaires.
Pourquoi: Le système de fichiers local des plateformes serverless est éphémère, en mémoire et non partagé. Cloud Storage fournit un stockage durable et évolutif accessible par toutes les instances.
Gérez la configuration et les secrets spécifiques à l'environnement pour les charges de travail GKE en suivant les principes des 12 facteurs.
Utilisez les ConfigMaps K8s pour la configuration non sensible. Utilisez Secret Manager pour les valeurs sensibles, accessibles en toute sécurité via Workload Identity.
Pourquoi: Secret Manager est une solution plus sécurisée, gérée et auditable que les K8s Secrets. Workload Identity évite la gestion et la distribution des clés de compte de service.
L'application présente des pics de trafic extrêmes mais de longues périodes d'inactivité où le coût doit être minimisé.
Utilisez Cloud Run avec `min-instances` réglé sur 0.
Pourquoi: Cloud Run peut réduire son échelle jusqu'à zéro, éliminant ainsi tous les coûts de calcul pendant les périodes d'inactivité. GKE et Compute Engine nécessitent un nombre minimal de nœuds/instances en fonctionnement.
Implémentez de manière cohérente les tentatives, les disjoncteurs et le mTLS sur l'ensemble des microservices sans modifier le code de l'application.
Déployez un maillage de services (Anthos Service Mesh) sur GKE.
Pourquoi: Un maillage de services injecte la résilience, la sécurité et l'observabilité au niveau de la plateforme, ce qui maintient le code de l'application propre et assure un comportement cohérent.
Exposez les services backend à des partenaires externes ou à des applications mobiles avec limitation de débit, clés API et analyses d'utilisation.
Utilisez API Gateway devant les services backend (par exemple, Cloud Run, GKE).
Pourquoi: API Gateway fournit une solution entièrement gérée pour les préoccupations liées au cycle de vie des API (sécurité, surveillance, versioning), les déchargeant du service backend.
Sélectionnez un stockage durable, évolutif et fortement cohérent pour un journal d'événements en ajout seulement.
Utilisez Cloud Spanner pour le stockage des événements.
Pourquoi: Spanner offre une scalabilité horizontale avec une forte cohérence globale, essentielle pour maintenir l'intégrité d'un journal d'événements à grande échelle.
Une API pour une tâche de longue durée doit répondre immédiatement pendant que le traitement se poursuit en arrière-plan.
Le point d'API met en file d'attente une tâche dans Pub/Sub ou Cloud Tasks et renvoie un 202 Accepted avec un ID de tâche. Un travailleur distinct (Cloud Run, Cloud Function) traite la tâche.
Pourquoi: Cela découple le temps de réponse visible par l'utilisateur du temps de traitement en arrière-plan, améliorant l'expérience utilisateur et la fiabilité du système. Utilisez Cloud Storage pour les mises à jour de statut.
Maintenir la cohérence des données entre plusieurs microservices sans base de données partagée.
Implémentez le modèle Saga en utilisant un orchestrateur (Cloud Workflows) ou une chorégraphie (événements Pub/Sub) avec des transactions de compensation.
Pourquoi: Évite les validations en deux phases complexes et sujettes aux blocages, privilégiant la cohérence éventuelle qui est mieux adaptée aux systèmes distribués.
L'application appelle une API tierce limitée en débit où les données changent rarement.
Utilisez Memorystore for Redis comme cache distribué. Implémentez le modèle cache-aside avec TTL. Utilisez un verrou distribué (par exemple, Redis SETNX) pour éviter les ruées de cache.
Pourquoi: Un cache distribué partage les données entre toutes les instances de l'application, réduisant drastiquement les appels à l'API externe, améliorant la latence et respectant les limites de débit.
Une équipe de développement a besoin d'environnements de développement cohérents, préconfigurés et sécurisés avec accès aux ressources VPC privées.
Utilisez Cloud Workstations.
Pourquoi: Cloud Workstations fournit des environnements de développement gérés basés sur des conteneurs avec une sécurité intégrée et un accès VPC, résolvant le problème du "ça marche sur ma machine".
Une application SaaS exige que les locataires disposent de données, de clés de chiffrement et d'une résidence des données complètement isolées.
Utilisez un modèle un projet par locataire. Gérez le provisionnement et la configuration de manière centralisée à l'aide d'IaC (Terraform).
Pourquoi: Fournit le plus haut niveau d'isolation pour IAM, la facturation, les quotas, la mise en réseau et l'emplacement des données, souvent requis par les entreprises ou les clients réglementés.
Faites en sorte que seules les images de conteneurs fiables et scannées provenant d'un pipeline officiel puissent être déployées en production.
Utilisez Cloud Build pour générer la provenance SLSA, Artifact Registry pour l'analyse des vulnérabilités et Binary Authorization pour appliquer les politiques de déploiement basées sur les attestations.
Pourquoi: Crée une chaîne de confiance cryptographique vérifiable et incontournable du code au déploiement, empêchant le déploiement d'artefacts compromis ou non scannés.
Déployez une nouvelle version d'un service Cloud Run, testez-la sans impact pour les utilisateurs et basculez le trafic instantanément.
Déployez la nouvelle révision avec `--no-traffic`. Testez en utilisant l'URL de révision unique ou une balise de révision. Basculez 100 % du trafic vers la nouvelle révision une fois validée.
Pourquoi: La gestion native du trafic de Cloud Run permet des déploiements sûrs et sans temps d'arrêt en validant la nouvelle version avant qu'elle ne reçoive du trafic de production.
Déployez progressivement une nouvelle version, en analysant automatiquement les métriques et en annulant en cas d'échec.
Utilisez Cloud Deploy avec une stratégie de déploiement Canary. Intégrez-le à Cloud Monitoring pour l'analyse automatisée des métriques et les déclencheurs de rollback.
Pourquoi: Cloud Deploy automatise l'ensemble du flux de travail de livraison progressive, y compris l'analyse des métriques et les contrôles de sécurité, réduisant ainsi l'effort manuel et les risques.
Gérez les manifestes Kubernetes pour les environnements de développement, de préproduction et de production sans dupliquer le code.
Utilisez Kustomize ou Helm. Définissez une configuration de base et créez des surcouches ou des fichiers de valeurs spécifiques à l'environnement pour y appliquer les différences.
Pourquoi: Suit le principe DRY, ce qui facilite la gestion des configurations et réduit le risque de dérive d'environnement.
Réduisez la taille des images de conteneurs pour des déploiements plus rapides et une surface d'attaque plus petite.
Utilisez des builds multi-étapes. Une étape de `build` utilise une image SDK/JDK complète ; l'étape finale copie uniquement l'artefact compilé dans une image de base `distroless` minimale.
Pourquoi: L'image finale ne contient que l'application et ses dépendances d'exécution, supprimant tous les outils de build, les shells et les gestionnaires de paquets.
Déployez automatiquement des environnements éphémères pour chaque pull request à des fins de validation avant la fusion.
Utilisez des déclencheurs Cloud Build sur les événements de pull request pour déployer sur Cloud Run avec une balise de révision (par exemple, `pr-123`). Utilisez un autre déclencheur à la fermeture de la pull request pour nettoyer la révision balisée.
Pourquoi: Les balises de révision fournissent des URL uniques et temporaires pour chaque pull request sans la surcharge de création de nouveaux services, ce qui les rend rentables et faciles à automatiser.
Améliorez la vitesse et la fiabilité des builds CI/CD en mettant en cache les dépendances logicielles publiques (par exemple, de npm, Maven Central).
Utilisez un dépôt distant Artifact Registry, qui agit comme un cache de passage pour le dépôt public.
Pourquoi: Améliore les performances des builds, protège les builds des pannes de registre public et permet l'analyse des vulnérabilités sur les artefacts mis en cache.
Stockez et verrouillez en toute sécurité l'état Terraform pour les exécutions concurrentes de pipelines CI/CD.
Utilisez un backend Cloud Storage pour l'état Terraform, avec les rôles IAM appropriés pour le compte de service Cloud Build.
Pourquoi: Cloud Storage fournit un backend durable, versionné et verrouillable, empêchant la corruption de l'état due aux builds concurrents.
Un service Cloud Run ou Cloud Function doit accéder à une ressource (par exemple, Cloud SQL, Memorystore) sur un réseau VPC privé.
Configurez un connecteur d'accès VPC Serverless.
Pourquoi: Le connecteur agit comme un pont réseau, permettant le trafic sortant de l'environnement serverless vers le VPC cible sans exposer publiquement les ressources.
Une application stateful sur GKE nécessite une identité stable et un stockage persistant qui survit aux pannes de pod/nœud.
Utilisez un StatefulSet avec un Headless Service pour l'identité. Utilisez un PersistentVolumeClaim (PVC) avec un Persistent Disk régional pour le stockage.
Pourquoi: Il s'agit du modèle Kubernetes canonique pour les charges de travail stateful, garantissant la persistance des données, la haute disponibilité et la nomination/mise en réseau prévisible des pods.
Un pod sur GKE doit accéder aux API GCP en toute sécurité sans gérer de clés de compte de service statiques.
Configurez et utilisez Workload Identity.
Pourquoi: Workload Identity lie un compte de service Kubernetes à un compte de service Google, permettant aux pods d'utiliser des identifiants GCP de courte durée obtenus à partir du serveur de métadonnées.
Exécutez une tâche par lots qui prend des heures à s'achever (par exemple, le traitement d'un fichier volumineux, l'agrégation quotidienne de données).
Utilisez les tâches Cloud Run, déclenchées par Eventarc ou Cloud Scheduler.
Pourquoi: Les tâches Cloud Run sont conçues pour les tâches de longue durée (jusqu'à 24h), s'adaptent à zéro et sont plus rentables et plus simples qu'un cluster GKE ou une VM dédié pour les charges de travail par lots.
Déployez une application multi-conteneurs sur Cloud Run où un conteneur principal a besoin d'un sidecar pour la journalisation, les métriques ou comme proxy.
Déployez le service Cloud Run avec plusieurs images de conteneurs spécifiées, une comme conteneur principal et les autres comme sidecars.
Pourquoi: Le support multi-conteneurs natif de Cloud Run permet le modèle sidecar pour les charges de travail serverless sans la complexité de GKE.
Les migrations de base de données doivent être terminées avant qu'une nouvelle révision Cloud Run ne reçoive du trafic.
Exécutez les migrations pendant le démarrage du conteneur et utilisez une sonde de démarrage Cloud Run qui ne passe qu'après le succès des migrations.
Pourquoi: La sonde de démarrage retarde le routage du trafic jusqu'à ce que le conteneur soit entièrement prêt, garantissant que le schéma de la base de données est correct avant que toute requête ne soit servie.
Une application GKE doit être mise à l'échelle en fonction d'une métrique personnalisée comme la profondeur de la file d'attente de Pub/Sub, et pas seulement du CPU/de la mémoire.
Utilisez le Horizontal Pod Autoscaler (HPA) configuré pour lire les métriques personnalisées de Cloud Monitoring.
Pourquoi: Cela permet à l'autoscaling d'être piloté par la logique métier ou des indicateurs de charge spécifiques à l'application, offrant une mise à l'échelle plus précise que les métriques de ressources génériques.
Un service orienté message doit traiter chaque message exactement une fois, malgré les tentatives et les livraisons potentiellement en double.
Combinez Pub/Sub (avec une livraison au moins une fois ou exactement une fois) avec un consommateur idempotent. Le consommateur suit les ID de message traités dans un stockage persistant (par exemple, Firestore, Memorystore).
Pourquoi: Pub/Sub garantit la livraison, mais le consommateur est responsable de l'idempotence pour gérer les tentatives au niveau de l'application et réaliser un traitement véritablement "exactement une fois".
Les événements liés à la même entité (par exemple, un utilisateur spécifique) doivent être traités dans l'ordre où ils ont été générés.
Publiez des messages sur Pub/Sub avec un `orderingKey`. Activez l'ordonnancement des messages sur l'abonnement.
Pourquoi: Pub/Sub garantit que les messages avec la même clé d'ordonnancement sont livrés dans l'ordre, tandis que les messages avec des clés différentes peuvent être traités en parallèle pour la scalabilité.
Assurez-vous qu'une tâche (par exemple, générer un rapport utilisateur quotidien) ne s'exécute qu'une seule fois, même si plusieurs événements déclencheurs arrivent.
Utilisez Cloud Tasks. Créez des tâches avec des noms explicites (par exemple, `report-userX-2024-10-26`). Cloud Tasks dédupliquera les requêtes pour créer une tâche avec un nom existant.
Pourquoi: Cela décharge la logique de déduplication au service de file d'attente, simplifiant le code de l'application et empêchant le travail redondant.
Un message Pub/Sub échoue systématiquement après plusieurs tentatives et bloque la file d'attente.
Configurez une rubrique de messages non distribuables (DLQ) sur l'abonnement Pub/Sub et définissez un nombre maximal de tentatives de livraison.
Pourquoi: Pub/Sub déplace automatiquement le message "poison" vers la DLQ, permettant aux autres messages d'être traités et préservant le message échoué pour analyse.
Un processus métier implique une séquence d'appels de services avec une logique conditionnelle, une gestion des erreurs et de longues attentes.
Utilisez Cloud Workflows pour définir et exécuter la logique d'orchestration.
Pourquoi: Cloud Workflows est un orchestrateur serverless qui gère l'état, les tentatives et les longues attentes, offrant une meilleure fiabilité et visibilité que des fonctions chaînées manuellement.
Un service Cloud Function ou Cloud Run ne devrait être déclenché que par des événements cloud spécifiques (par exemple, certains types de fichiers dans Cloud Storage).
Utilisez un déclencheur Eventarc avec un filtrage CEL (Common Expression Language) sur les attributs d'événement.
Pourquoi: Le filtrage se produit avant l'invocation du service, ce qui économise des coûts et des cycles de calcul en ne traitant pas les événements non pertinents.
Limitez le débit des appels sortants vers une API tierce depuis un service mis à l'échelle horizontalement comme Cloud Run.
Mettez en file d'attente les appels API en tant que tâches dans une file d'attente Cloud Tasks avec des `rateLimits` configurées (par exemple, le nombre maximal de dispatches par seconde).
Pourquoi: Cloud Tasks fournit une limitation de débit centralisée et serverless qui fonctionne sur toutes les instances mises à l'échelle sans nécessiter de compteurs distribués complexes.
Authentifiez en toute sécurité les appels entre deux services Cloud Run (ou Cloud Functions).
Accordez au compte de service appelant le rôle IAM `roles/run.invoker` sur le service appelé. L'appelant envoie un jeton d'identité signé par Google avec sa requête.
Pourquoi: Il s'agit de la méthode native, sécurisée et sans clé pour l'authentification de service à service, tirant parti de l'infrastructure d'identité de Google.
Un service basé sur les événements doit réagir aux modifications au niveau des lignes dans une base de données Cloud SQL en quasi temps réel.
Utilisez Datastream (CDC) pour diffuser les modifications de la base de données vers Pub/Sub. Utilisez Eventarc pour déclencher un service Cloud Run à partir de la rubrique Pub/Sub.
Pourquoi: Il s'agit d'un modèle découplé et fiable qui évite l'interrogation de la base de données et ne nécessite pas de modifier l'application écrivant dans la base de données.
Un processus métier de longue durée doit se mettre en pause pour attendre un événement externe, comme un humain cliquant sur un lien d'approbation dans un e-mail.
Utilisez Cloud Workflows avec un point de terminaison de rappel. Le workflow se met en pause (jusqu'à un an) jusqu'à ce qu'il reçoive une requête HTTP sur son URL de rappel unique.
Pourquoi: Les rappels permettent aux workflows d'attendre des événements externes sans consommer de ressources de calcul, ce qui les rend idéaux pour les processus de longue durée impliquant une intervention humaine.
Une application serverless sensible à la latence connaît des réponses initiales lentes après des périodes d'inactivité.
Configurez `min-instances` à 1 ou plus. Pour les démarrages à froid inévitables, utilisez `startup-cpu-boost`. Optimisez également l'application (image plus petite, initialisation plus rapide).
Pourquoi: `min-instances` est le moyen le plus efficace d'éliminer les démarrages à froid mais entraîne des coûts. `startup-cpu-boost` accélère le processus de démarrage lui-même.
Une requête est lente ou échoue à travers plusieurs microservices, et le goulot d'étranglement n'est pas évident à partir des journaux ou des métriques de service individuelles.
Utilisez Cloud Trace avec propagation de contexte. Instrumentez les applications pour transférer les en-têtes de trace (par exemple, W3C Trace Context).
Pourquoi: Cloud Trace fournit une visualisation en cascade du cycle de vie complet de la requête à travers tous les services, identifiant la source de la latence ou des erreurs.
Une application est lente en production, et il n'est pas clair si le problème est lié au CPU, à une fuite de mémoire ou aux E/S.
Utilisez Cloud Profiler pour analyser en continu l'utilisation du CPU et du tas de mémoire en production.
Pourquoi: Cloud Profiler identifie les goulots d'étranglement de performance au niveau du code (chemins critiques, fuites de mémoire) avec un très faible impact, sans avoir besoin de reproduire les problèmes dans un environnement de test.
Passez des alertes de seuil simples (par exemple, "latence > 500ms") à des alertes plus significatives basées sur des objectifs de niveau de service (SLO).
Définissez les SLI et les SLO dans Cloud Monitoring. Créez des politiques d'alerte basées sur le "taux de consommation" du budget d'erreur.
Pourquoi: Les alertes basées sur le taux de consommation sont plus sensibles aux changements significatifs et moins bruyantes que les alertes de seuil simples, indiquant quand vous êtes sur une trajectoire pour manquer votre SLO.
Agrègez les exceptions d'application de plusieurs services pour suivre la fréquence, visualiser les traces de pile et être informé des nouveaux types d'erreurs.
Utilisez Cloud Error Reporting.
Pourquoi: Error Reporting ingère, groupe et analyse automatiquement les exceptions des journaux structurés, fournissant un tableau de bord centralisé pour la gestion des erreurs d'application.
Surveillez, visualisez et alertez sur des métriques commerciales personnalisées (par exemple, commandes par minute, inscriptions d'utilisateurs).
Instrumentez le code de l'application à l'aide du SDK OpenTelemetry. Configurez l'exportateur pour envoyer les métriques à Cloud Monitoring.
Pourquoi: C'est la norme moderne et agnostique vis-à-vis des fournisseurs pour l'instrumentation personnalisée. Elle permet de suivre n'importe quelle métrique et de tirer parti de toutes les fonctionnalités de Cloud Monitoring pour celle-ci.
