Google PCNE: Automatisation du réseau, gouvernance et opérations liées aux coûts — Guide d'étude

By Laurynas Brazys · 22 August 2026 · #google #PCNE #certification #exam-prep #study-guide

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

L’automatisation du réseau, la gouvernance et la gestion des coûts sur Google Cloud sont des disciplines indissociables qui déterminent la fiabilité, la sécurité et la rentabilité de l’exécution de vos réseaux à grande échelle. Une pratique efficace combine une hiérarchie de ressources bien structurée et un modèle IAM de moindre privilège avec l’infrastructure as code et des workflows événementiels, le tout soutenu par des budgets, des quotas et une auditabilité clairs. L’état final est un provisionnement prévisible, un minimum de changements manuels, des preuves de conformité défendables et une économie unitaire transparente pour le réseau.

Gouvernance et contrôle d’accès

Hiérarchie des ressources
- Organisation → Dossiers → Projets constitue le plan de contrôle pour l’héritage des autorisations et les garde-fous de stratégies (policy guardrails). Placez la production et la non-production dans des dossiers distincts pour isoler les stratégies et les quotas. Utilisez des étiquettes (labels) sur les VPC, les sous-réseaux, les routeurs, les règles de transfert et les instances pour la répartition des coûts et le ciblage des ressources.
- Le Shared VPC consolide le routage et la connectivité dans un projet hôte tout en déléguant le calcul (compute) aux projets de service. Ne partagez que les sous-réseaux dont chaque projet de service a besoin pour suivre le principe d’exposition explicite des réseaux et pour réduire l’exposition involontaire des routes.
IAM et moindre privilège
- Séparez l’administration du réseau de l’administration de la sécurité. Le rôle Compute Network Admin accorde un contrôle total sur les constructions réseau et un accès en lecture seule aux règles de pare-feu, tandis que le rôle Security Admin gère les règles de pare-feu et les certificats SSL. Cette séparation évite les opérateurs disposant de droits excessifs et s’aligne sur la gestion des changements (change control).
- Attribuez des rôles ciblés :
  - Pour modifier les règles de pare-feu, utilisez le rôle Security Admin sur le Shared VPC.
  - Pour gérer les rattachements VLAN et d’autres ressources réseau principales, le rôle Compute Network Admin est approprié.
  - Pour l’automatisation sur des ressources spécifiques, accordez des autorisations au niveau de la ressource plutôt que des rôles à l’échelle du projet lorsque cela est possible, ou créez un rôle personnalisé limité aux autorisations requises.
- Préférez l’usurpation d’identité de compte de service (impersonation) et les jetons à courte durée de vie aux clés persistantes. Interdisez la création de clés de compte de service via une stratégie d’organisation lorsque c’est possible. Utilisez Workload Identity Federation pour supprimer complètement les clés pour l’automatisation sur site (on-prem) ou multi-cloud.
- Suivez le principe du moindre privilège pour les tâches du plan de données (data plane). Par exemple, une tâche lisant des données depuis Cloud Storage n’a besoin que du rôle de lecteur d’objets de stockage (storage object viewer) sur le bucket cible, et non du rôle d’éditeur (editor) sur l’ensemble du projet.
Stratégies d’organisation
- Appliquez par défaut la règle « pas d’IP externe » pour les VM ; utilisez Private Google Access et Cloud NAT pour atteindre les API Google sans adresses publiques.
- Limitez le peering et le partage externe aux modèles approuvés (par exemple, restreignez les configurations de peering de VPC pour éviter la prolifération).
- Restreignez la création de clés de compte de service et leur utilisation pour limiter la prolifération des identifiants.
- Modes de défaillance et compromis :
  - Des rôles hérités trop larges au niveau du dossier peuvent silencieusement accorder un accès en écriture à de nombreux projets. Examinez les liaisons de rôles (role bindings) avec une analyse des autorisations effectives.
  - Bloquer les adresses IP externes des VM sans planifier Private Google Access et Cloud NAT entraîne des pannes lors de l’appel des services Google.
  - La conversion d’un VPC du mode automatique au mode personnalisé sans refactoriser les modèles qui supposaient des sous-réseaux automatiques casse les déploiements ; référencez explicitement les sous-réseaux personnalisés par la suite.

Automatisation, IaC et opérations événementielles

Infrastructure as Code avec Terraform
- Utilisez une conception modulaire : un module par primitive (VPC, sous-réseau, pare-feu, Cloud Router, Cloud NAT, rattachement d’interconnexion), puis composez des piles (stacks) d’environnement. Versionnez les modules et épinglez les versions dans les piles qui les consomment pour contrôler les déploiements.
- Stockez l’état à distance avec un verrouillage (par exemple, Cloud Storage avec un verrouillage de type Dynamo via un modèle de backend) pour empêcher les modifications concurrentes. Chiffrez et sauvegardez l’état ; traitez l’état comme une donnée sensible.
- Gestion de la dérive (drift) :
  - Appliquez les changements via des pull requests et terraform plan dans la CI pour révéler l’état prévu par rapport à l’état réel. Exécutez une détection de dérive planifiée (plan -detailed-exitcode) et émettez des alertes lorsque la dérive apparaît.
  - Évitez les modifications gcloud ad-hoc en production ; si des correctifs d’urgence sont nécessaires, enregistrez-les et réconciliez-les immédiatement dans le code.
- Idempotence et garde-fous : Toujours planifier, examiner et appliquer. Utilisez des applications ciblées (targeted applies) pour minimiser le rayon d’impact (blast radius). Utilisez la validation des variables et la policy-as-code (par exemple, Sentinel ou OPA) pour bloquer les anti-modèles comme les CIDR qui se chevauchent ou les pare-feux ouverts.
gcloud, API et workflows
- Utilisez gcloud et REST pour les tâches opérationnelles à faible latence, mais encapsulez-les dans des scripts reproductibles. Gérez la cohérence à terme (eventual consistency) et les limites de débit des API avec des tentatives répétées (retries) et un backoff exponentiel.
- Opérations événementielles :
  - Utilisez Cloud Scheduler + Pub/Sub + Cloud Run/Cloud Functions pour automatiser les tâches de routine telles que la vérification des quotas, les audits d’utilisation de Cloud NAT ou l’échantillonnage des journaux de pare-feu.
  - Diffusez (stream) les journaux d’activité d’administration (Admin Activity) et d’accès aux données (Data Access) vers Pub/Sub pour déclencher des workflows de garde-fou (par exemple, annuler automatiquement une modification non autorisée d’une règle de pare-feu).
- Exemples d’extraits de code
  - Attribuer un rôle :

undefined

- Créer une route pour les API Google afin de contourner une route par défaut vers un NGFW :
  -

undefined

Pièges opérationnels
- Les conditions de concurrence (race conditions) lorsque plusieurs pipelines gèrent des ressources partagées (par exemple, des pare-feux dans un VPC commun) provoquent des instabilités (flapping). Utilisez des conventions de propriété et des pipelines limités à la portée d’un dossier (folder-scoped).
- L’instabilité des API sous un parallélisme élevé déclenche des erreurs de quota ; limitez (throttle) et regroupez (batch) les opérations par région et par type de ressource.

Gestion des coûts, des quotas et de la capacité

Quotas et limites d’API
- Suivez les quotas par projet et par région (adresses, règles de transfert, règles de pare-feu, rattachements d’interconnexion, routeurs). Automatisez la surveillance des quotas et demandez des augmentations avant le déploiement de nouveaux environnements. Intégrez des vérifications de quotas préalables dans la CI pour un échec rapide.
- Provisionnez à grande échelle avec :
  - Le sharding régional (créez des ressources par région pour éviter les conflits de quotas régionaux).
  - La pré-allocation (réservez des adresses et configurez des routeurs avant les pics d’activité).
  - Les déploiements par étapes (créez, validez, puis rattachez les backends).
Économie de la sortie de données (egress) et de la topologie
- Le trafic inter-régions au sein d’un même VPC entraîne des coûts de sortie de données inter-régions. Placez les charges de travail qui communiquent entre elles dans la même région ou répliquez les données régionalement lorsque la latence et le coût sont des facteurs importants.
- Pour les utilisateurs proches de us-east1 et europe-west1, un VPC unique avec des sous-réseaux régionaux permet une communication privée RFC1918, minimisant la surcharge liée au NAT et au peering tout en permettant une politique et un routage simples.
- Utilisez VPC Network Peering pour une connectivité à faible surcharge entre projets ou départements, sans NAT et sans routage transitif ; conservez des blocs CIDR qui ne se chevauchent pas. Utilisez des VPC distincts pour isoler les départements qui ne doivent pas communiquer.
- Cloud CDN réduit la sortie de données et améliore la latence pour le trafic HTTP(S) ; un équilibreur de charge HTTP(S) mondial sert de plan de contrôle pour le CDN. Un équilibreur de charge réseau n’améliorera pas la latence globale des applications web car il ne dispose pas de distribution en périphérie (edge) ni de mise en cache.
- Choisissez judicieusement l’interconnexion : Dedicated Interconnect avec des rattachements VLAN dans un projet hôte centralise l’administration et réduit le coût par projet pour une connectivité sur site (on-prem) partagée et à grande échelle. Cloud VPN avec Cloud Router est adapté pour une connectivité rapide et chiffrée entre organisations, avec la possibilité d’évoluer plus tard vers une interconnexion.
Répartition des coûts, budgets et prévisions
- Taguez toutes les ressources réseau avec des libellés (labels) pour le département, l’environnement et le centre de coûts. Exportez les données de facturation vers BigQuery et dérivez les coûts unitaires (par exemple, $/Go de sortie de données par service).
- Créez des budgets au niveau du projet, du dossier ou du libellé. Envoyez des alertes à Pub/Sub et connectez-les à des répondeurs ChatOps ou Cloud Run. Automatisez les actions en cas de dépassement (par exemple, réduire l’échantillonnage des journaux ou réduire la taille des environnements de test non critiques).
- Optimisez la sortie de données (egress) :
  - Préférez Private Google Access et Cloud NAT aux adresses IP externes pour contrôler les chemins de sortie et centraliser la facturation.
  - Pour les topologies en tunnel forcé, ajoutez des routes personnalisées pour les API Google vers la passerelle Internet par défaut ou configurez Private Google Access pour les environnements sur site (on-prem) afin d’éviter le trafic en épingle à cheveux (hairpinning) à travers des pare-feu tiers.
  - Prévoyez la capacité en analysant les VPC Flow Logs et les journaux de l’équilibreur de charge ; corrélez avec la saisonnalité. Dimensionnez correctement les passerelles NAT et la capacité d’interconnexion avant les pics d’activité.

Auditabilité et excellence opérationnelle

Journalisation et preuves
- Cloud Audit Logs :
  - Les journaux d’activité d’administration (Admin Activity logs) capturent les modifications du plan de contrôle apportées aux VPC, routes, pare-feu, routeurs et équilibreurs de charge ; ils sont toujours activés. Conservez-les de manière centralisée et acheminez-les vers un projet de sécurité avec CMEK si nécessaire.
  - Les journaux d’accès aux données (Data Access logs) pour les API de mise en réseau peuvent être volumineux ; activez-les de manière sélective et appliquez un échantillonnage ou des récepteurs (sinks).
- Les journaux de flux VPC (VPC Flow Logs) et la journalisation des règles de pare-feu (Firewall Rules Logging) fournissent des preuves au niveau du plan de données pour la réponse aux incidents et la conformité. Stockez-les pendant l’horizon de rétention requis et indexez-les avec BigQuery pour les investigations.
- Enregistrements des modifications : Exigez que chaque modification du réseau provienne de l’IaC avec un artefact de plan immuable et une référence de ticket. Pour les modifications manuelles exceptionnelles, capturez la commande gcloud, l’opérateur, l’horodatage et la justification dans un registre central.
Identifiants sécurisés et contrôle des risques liés à l’automatisation
- Éliminez les clés de compte de service à longue durée de vie. Utilisez les conditions IAM (IAM Conditions) pour limiter la portée de l’automatisation par ressource, heure ou adresse IP. Protégez les autorisations à haut risque (par exemple, compute.firewalls.update, compute.routers.updateBgpPeer) avec des flux de travail d’approbation.
- Appliquez le moindre privilège au CI/CD, utilisez des comptes de service par environnement et effectuez une rotation fréquente des jetons. Utilisez VPC Service Controls pour la protection du périmètre de service là où des risques d’exfiltration de données existent.
Runbooks, cycle de vie et amélioration continue
- Maintenez des runbooks pour les opérations de routine : intégrer (onboarding) un projet à un VPC partagé (Shared VPC), créer un appairage de VPC (VPC peering), établir un Cloud VPN avec IKEv2, promouvoir les règles Cloud Armor du mode aperçu (preview) au mode d’application (enforce).
- Définir des politiques de cycle de vie :
  - Promotion Sandbox → Staging → Production avec des modules Terraform identiques et des variables spécifiques à la région.
  - Playbooks de démantèlement pour supprimer en toute sécurité l’appairage, le NAT et les routes.
- Amélioration continue :
  - Les revues post-incident doivent alimenter les modules (par exemple, en ajoutant un refus de sortie par défaut avec des listes d’autorisation explicites, ou la journalisation NAT par défaut).
  - Examinez régulièrement les politiques d’organisation, les étiquettes et les budgets pour détecter toute dérive par rapport à la posture souhaitée.

Scénario de problème pratique

Contoso Retail opère en Amérique du Nord et en Europe. Les utilisateurs et les services s’exécutent principalement dans us-east1 et europe-west1. La sécurité exige une route par défaut vers un NGFW tiers, aucune adresse IP externe sur les VM et une connectivité centralisée sur site (on-prem). L’entreprise a également besoin d’une allocation claire des coûts par département et de garde-fous automatisés.

Établir la gouvernance et la topologie

Créez un projet hôte Shared VPC avec un seul VPC et deux sous-réseaux régionaux dans us-east1 et europe-west1. Justification : Un seul VPC avec des sous-réseaux régionaux permet une communication RFC1918 directe entre les régions avec un routage et des politiques simples, minimisant la surcharge par projet.
Partagez uniquement les sous-réseaux nécessaires à trois projets de service (Marketing, Supply, Finance). Justification : Le partage au niveau du sous-réseau limite l’exposition des routes et du pare-feu tout en préservant un contrôle centralisé.
Créez un VPC distinct pour un système Finance hérité qui doit être isolé ; n’appairez que Marketing et Supply là où c’est nécessaire. Justification : L’appairage de VPC (VPC peering) fournit une connectivité privée à faible latence pour les deux départements tout en préservant l’isolement par rapport à Finance.

Configurer l’accès sécurisé aux services Google sans IP publiques

Activez l’accès privé à Google (Private Google Access) sur tous les sous-réseaux partagés. Justification : Les instances sans IP externe peuvent atteindre les API Google de manière privée.
Comme la route par défaut mène à un NGFW, ajoutez une route statique personnalisée pour 199.36.153.8/30 vers la passerelle Internet par défaut. Justification : Garantit que les appels aux API Google ne passent pas en épingle à cheveux (hairpin) à travers le pare-feu, ce qui réduit la latence et évite un point d’étranglement unique.

Centraliser la connectivité sur site (on-prem)

Déployez Dedicated Interconnect et des rattachements de VLAN (VLAN attachments) dans le projet hôte Shared VPC, en les rattachant à un Cloud Router par région. Justification : L’interconnexion centralisée réduit les coûts et la duplication opérationnelle ; Cloud Router fournit un routage dynamique pour la croissance.
Accordez le rôle Administrateur de réseau Compute (Compute Network Admin) aux opérateurs réseau, et Administrateur de la sécurité (Security Admin) à l’équipe de sécurité. Justification : Applique le principe du moindre privilège et la séparation des tâches ; les administrateurs réseau ne peuvent pas modifier les pare-feu sans l’approbation de la sécurité.

Automatiser le provisionnement et les garde-fous

Implémentez des modules Terraform pour le VPC, les sous-réseaux, les routeurs, le NAT, l’appairage et les politiques de pare-feu. Stockez l’état à distance avec verrouillage ; imposez des revues de pull-request avec terraform plan dans le CI. Justification : Des changements reproductibles et versionnés avec contrôle de la dérive minimisent les pannes.
Ajoutez une politique OPA pour bloquer les CIDR qui se chevauchent et l’entrée (ingress) ouverte sur 0.0.0.0/0 vers les sous-réseaux internes. Justification : Empêche les erreurs de configuration courantes au moment de la revue.
Utilisez Cloud Scheduler pour publier des vérifications de quota quotidiennes sur Pub/Sub ; un service Cloud Run appelle l’API Service Usage pour vérifier la marge disponible pour les adresses, les règles de transfert et les rattachements d’interconnexion. Justification : Évite les échecs de déploiement dus à l’épuisement des quotas.

Optimiser les coûts et les allouer avec précision

Appliquez les étiquettes env, dept et service à toutes les ressources réseau via Terraform. Exportez la facturation vers BigQuery et définissez des budgets par département avec des alertes vers Pub/Sub. Justification : Une allocation transparente des coûts et des avertissements précoces sur les pics permettent une action proactive.
Placez un équilibreur de charge HTTP(S) mondial devant les propriétés web publiques et activez Cloud CDN. Justification : Améliore la latence pour les utilisateurs mondiaux et réduit la sortie (egress) en servant le contenu mis en cache en périphérie (edge).

Renforcer l’auditabilité et la réponse aux incidents

Acheminez les journaux d’activité d’administration (Admin Activity) et de règles de pare-feu (Firewall Rules Logging) vers un projet de journalisation central avec CMEK. Justification : Des enregistrements de modifications infalsifiables et des preuves au niveau du plan de données satisfont aux exigences de conformité.
Pour les clients suspectés d’être abusifs, déployez une règle Cloud Armor en mode aperçu (preview) sur l’équilibreur de charge HTTP(S) et examinez les journaux avant de l’appliquer. Justification : Minimise la perturbation pour les utilisateurs tout en validant l’atténuation.

Documenter et itérer

Publiez des runbooks pour l’intégration d’un projet à un Shared VPC, la création d’un appairage de VPC entre Marketing et Supply, et la construction d’un Cloud VPN basé sur des politiques pour les partenaires qui n’ont pas BGP. Justification : Une exécution standardisée réduit le MTTR et la variance.
Après chaque fenêtre de modification, capturez les métriques (temps de déploiement, erreurs, sortie $/Go, taux de succès du cache) et intégrez les améliorations dans les modules et les politiques. Justification : L’amélioration continue intègre la fiabilité et le contrôle des coûts dans les opérations quotidiennes.

← Observabilité du réseau · Tous les domaines

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