Google Cloud · GCP-PCNE · Advanced

Professional Cloud Network Engineer — Questions d'entraînement et examen blanc

Name: Pass-IT
Author: Pass-IT

Entraîne-toi avec des questions GCP-PCNE réalistes, alignées sur les objectifs de l’examen. Alex explique chaque réponse et ton score de préparation te montre quoi travailler ensuite.

Acheter l’accès à GCP-PCNE pour $29.99 Vérifie gratuitement si tu es prêt

Un seul paiement. Accès à vie à cette certification.

Essaie d’abord 5 questions →

55Questions

120minDurée

Vérifié auprès de Google Cloud · août 2026Version actuelle de l’examen

Aperçu

À propos de l’examen

La certification Professional Cloud Network Engineer valide ton expertise dans la conception, le déploiement et la gestion de l’infrastructure réseau Google Cloud, y compris l’architecture de réseaux à haute disponibilité, évolutifs, résilients et sécurisés. Le professionnel certifié configure et gère les VPC, le routage, les services de sécurité réseau, le load balancing, Cloud NAT et Cloud DNS, et met en place la connectivité hybride et multicloud via Cloud Interconnect et Cloud VPN. Cette expertise couvre aussi le diagnostic, la supervision et le dépannage des opérations réseau avec Google Cloud Observability et Network Intelligence Center.

C’est une certification de niveau professionnel, pensée pour les ingénieurs et architectes réseau qui conçoivent et administrent des infrastructures réseau sur Google Cloud. Google recommande au moins trois ans d’expérience du métier, dont un an passé à concevoir et gérer des solutions sur Google Cloud. Elle ouvre la porte à des postes de cloud network engineer, d’architecte réseau ou d’ingénieur infrastructure.

Domaines

Contenu de l’examen

La conception et la planification d’un réseau VPC pèsent le plus lourd avec 21 %, juste devant sa mise en œuvre à 20 % : à elles deux, ces sections représentent plus de 40 % de l’examen, soit de l’architecture et de la configuration VPC bien concrète. Au programme : gestion des adresses IP, peering face aux topologies Network Connectivity Center, subnets et règles de firewall, plus les spécificités réseau de GKE comme les alias IP et Dataplane V2. Les services réseau managés et la connectivité hybride/multicloud sont à égalité, 16 % chacun : load balancing, Cloud CDN et Cloud DNS d’un côté, VPN site-to-site, Cloud Interconnect et configuration BGP du Cloud Router de l’autre. La supervision et le dépannage opérationnels prennent 14 %, et la sécurité réseau (Cloud NGFW, Cloud NAT et Cloud Armor) ferme la marche à 13 %.

Avec une telle concentration sur la conception et l’implémentation, l’examen avantage nettement celui qui a déjà monté une topologie VPC multirégion plutôt que d’avoir seulement lu dessus. Les questions testent régulièrement des cas limites, peering non transitif ou MTU incohérents, qui n’apparaissent qu’en configuration réelle.

Plan de l’examen : GCP-PCNE

Designing and planning a Google Cloud VPC network~21%

Concevoir l'architecture réseau globale, les réseaux VPC, des réseaux hybrides/multi-cloud résilients et le réseau GKE

≈ 21 h

Implementing a VPC network~20%

Configurer les VPC, le routage VPC, Network Connectivity Center et les clusters GKE

≈ 20 h

Configuring managed network services~16%

Configurer le load balancing, Cloud CDN, Cloud DNS et Cloud NAT

≈ 16 h

Configuring and implementing hybrid and multicloud network interconnectivity~16%

Configuring Cloud Interconnect, site-to-site IPSec VPN, Cloud Router, and Network Connectivity Center

≈ 16 h

Managing, monitoring, and troubleshooting network operations~14%

Journalisation et surveillance avec Google Cloud Observability, dépannage de la connectivité, utilisation de Network Intelligence Center

≈ 14 h

Configuring, implementing and managing a cloud network security solution~13%

Google Cloud Armor, Cloud NGFW, Cloud NAT, Secure Web Proxy, IDS et Packet Mirroring

≈ 13 h

Format

Format de l’examen et types de questions

L’examen te propose 50 à 60 questions à choix unique et à choix multiples dans une fenêtre de 120 minutes, avec une répartition d’environ 80 % de questions à réponse unique pour 20 % à réponses multiples. Six domaines sont couverts : conception VPC, implémentation, services réseau managés, connectivité hybride et multicloud, exploitation, sécurité réseau. Les questions portent autant sur la compréhension conceptuelle que sur la configuration concrète, et ce sur toute la pile réseau de Google Cloud.

Types de questions : GCP-PCNE

Choix multiple80%

Choisis la seule bonne réponse parmi quatre ou cinq options — le format de base de l’examen.

Réponse multiple20%

Plusieurs réponses sont correctes et il te les faut toutes ; l’énoncé indique combien en cocher.

Google Cloud confirme ces types de questions — aucune répartition en pourcentage n’est publiée ; les parts reflètent notre banque de questions alignée sur l’examen.

Essaie maintenant

Essaie cinq questions GCP-PCNE

Cinq questions tirées de notre banque Professional Cloud Network Engineer. Réponds à une — Alex t’explique le pourquoi.

L’examen et l’app sont en anglais — ces questions d’exemple, nous les avons traduites.

Configurer et implémenter l'interconnexion réseau hybride et multicloud1 / 5

Tu as créé une passerelle HA VPN et configuré un tunnel unique depuis l'interface 0 de HA VPN vers l'unique adresse IP externe de la passerelle peer on-premises. Le BGP est établi et le trafic circule, mais un audit constate que le déploiement ne remplit pas les conditions du SLA de disponibilité de 99.99%. Que dois-tu changer ?

AlexExplication complète d’Alex

Les passerelles HA VPN exposent toujours deux interfaces avec deux adresses IP externes situées dans des zones de disponibilité edge distinctes de Google Cloud, et le SLA dépend de la répartition des tunnels plutôt que du nombre d'interfaces côté peer. Si le peer possède deux interfaces, tu associes l'interface 0 à l'interface 0 du peer et l'interface 1 à l'interface 1 du peer ; s'il n'en possède qu'une, les deux interfaces HA VPN y terminent leurs tunnels. Côté Google Cloud, un full mesh n'est explicitement pas requis pour le SLA de 99.99%, même si certains fournisseurs de VPN en recommandent un.

Sourcecloud.google.com

Configurer, implémenter et gérer une solution de sécurité réseau dans le cloud2 / 5

Ton organisation utilise des stratégies de pare-feu hiérarchiques au niveau de l'organisation ainsi que des règles de pare-feu VPC. Avec l'ordre par défaut AFTER_CLASSIC_FIREWALL, quelle est la séquence d'évaluation ?

AlexExplication complète d’Alex

D'après la documentation officielle (cloud.google.com/firewall/docs/firewall-policies-rule-eval-order), l'ordre d'application AFTER_CLASSIC_FIREWALL évalue : (1) les stratégies de pare-feu hiérarchiques, (2) les stratégies de pare-feu système régionales, (3) les règles de pare-feu VPC, (4) les stratégies de pare-feu réseau globales, (5) les stratégies de pare-feu réseau régionales, (6) les règles de pare-feu implicites. Les stratégies hiérarchiques sont toujours évaluées en premier, quel que soit l'ordre d'application. AFTER_CLASSIC_FIREWALL (valeur par défaut) préserve la rétrocompatibilité en évaluant les anciennes règles VPC avant les stratégies de pare-feu réseau plus récentes. Chaque niveau peut autoriser, refuser ou utiliser goto_next pour poursuivre l'évaluation. L'option « Règles VPC, puis stratégies hiérarchiques… » inverse l'ordre entre les stratégies hiérarchiques et les règles VPC. Les options « Stratégies hiérarchiques, puis stratégies réseau… » et « Stratégies réseau, puis stratégies hiérarchiques… » placent à tort les stratégies réseau avant les règles VPC sous le paramètre AFTER_CLASSIC. Ref: cloud.google.com/firewall/docs/firewall-policies-rule-eval-order.

Sourcedocs.cloud.google.com

Gérer, surveiller et dépanner les opérations réseau3 / 5

Tu as déployé un tunnel VPN, mais tu remarques que le tunnel est établi alors qu'aucun trafic ne circule. Les sessions BGP apparaissent comme établies, mais aucune route n'est échangée. Quelle est la cause la plus probable ?

AlexExplication complète d’Alex

Quand un tunnel VPN est établi (IKE a réussi) et que les sessions BGP apparaissent comme établies mais qu'aucun trafic ne circule, la cause est l'absence de routes annoncées. D'après la documentation (cloud.google.com/network-connectivity/docs/router/concepts/advertised-routes), Cloud Router dispose de deux modes d'annonce : le mode par défaut (annonce automatiquement les plages des sous-réseaux) et le mode personnalisé (nécessite une configuration explicite des préfixes). Si Cloud Router est en mode personnalisé sans préfixes configurés, ou si le routeur on-premises n'a aucune annonce BGP, aucun des deux côtés n'apprend de routes pour joindre les réseaux de l'autre. Une clé pré-partagée IKE qui ne correspond pas (l'option « La clé pré-partagée IKE est incorrecte ») empêcherait totalement l'établissement du tunnel. Cloud NAT (l'option « Cloud NAT perturbe le trafic VPN ») fonctionne indépendamment du trafic du plan de données VPN. Les problèmes de MTU (l'option « La MTU du tunnel VPN est réglée trop bas ») provoquent des pertes de paquets ou de la fragmentation, pas des routes manquantes. Correctif : vérifie le mode d'annonce de Cloud Router et les exports BGP on-premises. Ref: cloud.google.com/network-connectivity/docs/router/concepts/advertised-routes.

Sourcedocs.cloud.google.com

Implémenter un réseau VPC4 / 5

Tu as un cluster GKE et tu veux configurer le source NAT (SNAT) pour que le trafic des Pods qui sort du cluster utilise l'adresse IP du nœud au lieu de l'adresse IP du Pod. Quand dois-tu configurer IP Masquerade ?

AlexExplication complète d’Alex

L'IP masquerade (SNAT) dans GKE remplace l'IP source du Pod par l'IP du nœud pour le trafic sortant. D'après la documentation (cloud.google.com/kubernetes-engine/docs/concepts/ip-masquerade-agent), c'est nécessaire quand des destinations hors du VPC n'ont pas de routes vers la plage CIDR des Pods — par exemple des réseaux on-premises connectés via VPN/Interconnect. Sans SNAT, le trafic retour ne peut pas être routé vers les IP des Pods. GKE contrôle le masquerading via le DaemonSet ip-masq-agent et la liste nonMasqueradeCIDRs de sa ConfigMap. Le flag --disable-default-snat conserve les IP des Pods pour toutes les destinations lorsqu'aucun ip-masq-agent n'est présent. Le trafic entre Pods dans les clusters VPC-native n'a pas besoin de SNAT (le VPC dispose de routes vers les CIDR des Pods). Le trafic des Pods vers le control plane (l'option « Quand les Pods doivent communiquer avec le control plane GKE ») et celui de Private Google Access (l'option « Quand les Pods doivent accéder aux API Google Cloud via Private… ») circulent au sein du réseau de Google et ne nécessitent pas de masquerading. Ref: cloud.google.com/kubernetes-engine/docs/concepts/ip-masquerade-agent.

Sourcedocs.cloud.google.com

Configuration des services réseau gérés5 / 5

Quel type de load balancer Google Cloud dois-tu choisir pour répartir du trafic TCP non HTTP provenant de clients externes vers des backends situés dans une seule région, tout en conservant l'adresse IP source du client ?

AlexExplication complète d’Alex

D'après la doc (cloud.google.com/load-balancing/docs/passthrough-network-load-balancer), les NLB passthrough transmettent les paquets avec les IP source et destination inchangées : 'les paquets sont reçus par les VM de backend avec les adresses IP source et destination, le protocole et les ports du paquet inchangés.' Le NLB passthrough externe régional (basé sur Maglev) prend en charge TCP, UDP, ESP, GRE, ICMP et ICMPv6. Il conserve nativement l'IP source du client grâce au Direct Server Return (DSR). L'option « Global external Application Load Balancer » (Application LB externe global) ne gère que le HTTP(S), pas un TCP quelconque. L'option « Internal passthrough Network Load Balancer » (NLB passthrough interne) sert du trafic interne, pas des clients externes. L'option « Regional external proxy Network Load Balancer » (NLB proxy externe régional) termine les connexions et en ouvre de nouvelles vers les backends, ce qui fait perdre l'IP source d'origine, sauf si tu utilises le protocole PROXY (des en-têtes réservés au HTTP ne fonctionnent pas pour du trafic non HTTP). Ref : cloud.google.com/load-balancing/docs/passthrough-network-load-balancer.

Sourcecloud.google.com

Commence gratuitement

Banque de questions

310 questions, construites comme l’examen

Chaque domaine de l’examen GCP-PCNE a assez de questions dans la banque pour être travaillé en profondeur. Un examen blanc te pose 55 questions d’affilée, sur le même chrono de 120 minutes que le jour de l’examen.

Procès-verbal : GCP-PCNE

Contrôle du programme auprès de Google Cloud14 août 2026

dernière vérification auprès de la source officielle Google Cloud

Couverture du programme22 objectifs officiels

répartis sur 6 domaines, d’après le guide officiel de l’examen

Taille de la banque310 questions

= 5 examens blancs complets de 55 questions — jamais deux fois la même question

Couverture des domainesles 6 domaines à leur pondération officielle

Designing and planning a Google Cloud VPC network 62 · Implementing a VPC network 59 · Configuring managed network services 56 · Configuring and implementing hybrid and multicloud network interconnectivity 48 · Managing, monitoring, and troubleshooting network operations 41 · Configuring, implementing and managing a cloud network security solution 44

Validation canonique310 sur 310

chacune vérifiée avec la documentation officielle Google Cloud — réponse, options et explication, source citée

Méthodologie documentée ouvertement.Comment les questions sont créées →

Planification

Se préparer à GCP-PCNE

Le temps qu’il te faut dépend de ton expérience pratique. Le reste est fixé par l’éditeur : comment l’examen se déroule, quand tu peux le repasser et combien de temps la certification reste valable.

L’examen se passe chez Pearson VUE, en ligne avec surveillance à distance ou dans un centre d’examen, et il est proposé en anglais et en japonais. La certification reste valable 2 ans, avec un renouvellement possible pendant la période d’éligibilité au renouvellement.

Ton plan : GCP-PCNE

Préparation

Temps de préparation60–150 h

en général environ 60 h si tu travailles déjà avec ces technologies, environ 150 h en partant de zéro

NiveauAvancé

À maîtriser avantAucun prérequis officiel. Il est conseillé d'avoir au moins 3 ans d'expérience professionnelle, dont au moins 1 an à concevoir et gérer des solutions sur Google Cloud.

Le jour J et après

Mode de passageSurveillé en ligne (Pearson VUE) ou surveillé sur place dans un centre d'examen

Politique de reprisePolitique standard de nouvelle tentative des certifications Google Cloud : 14 jours d'attente après la première tentative, 60 jours après la deuxième, 365 jours après le troisième échec.

Validité2 ans

La validité de la certification dépend d'un renouvellement effectué dans la période d'éligibilité.

Guide officielVoir sur le site de l’éditeur

Ces heures sont notre propre estimation de planification — Google Cloud ne publie aucun temps de préparation pour cet examen. Un point de départ pour ton agenda, pas un objectif.

Attention

Erreurs courantes

Le VPC Network Peering n’est pas transitif, alors que les topologies Network Connectivity Center, elles, gèrent la transitivité. L’examen revient sans arrêt sur cette distinction, et c’est typiquement le genre de détail qu’on inverse sous pression. Les variantes Dedicated, Partner et Cross-Cloud de Cloud Interconnect n’offrent pas le même niveau de SLA (99,9 % contre 99,99 %), et les tiers Essentials, Standard et Enterprise de Cloud NGFW se confondent très vite entre eux. Private Google Access et Private Service Connect répondent à des problèmes de connectivité voisins mais bien distincts, et le réseau propre à GKE (alias IP, plages secondaires, Dataplane V2) piège les candidats dont l’expérience réseau est antérieure aux plateformes de conteneurs. Les routes statiques et les policy-based routes se comportent elles aussi autrement dans les scénarios hybrides que ce à quoi tu t’attends si tu viens d’un environnement purement on-premise.

Points de vigilance : GCP-PCNE

01VPC Design Patterns
Mal cerner le Shared VPC, le VPC peering et les situations où chaque topologie s’impose
02Hybrid Connectivity
Confondre Cloud Interconnect (Dedicated/Partner), Cloud VPN et Network Connectivity Center
03Load Balancing
Ne pas maîtriser les différents types de load balancer (internal/external, régional/global, L4/L7) ni savoir lequel choisir selon le cas
04Private Google Access
Se tromper sur Private Google Access, Private Service Connect et l’accès VPC serverless
05Firewall Policies
Mélanger les VPC firewall rules, les firewall policies et les hierarchical firewall policies
06DNS Configuration
Passer à côté de Cloud DNS, du DNS peering et des zones DNS privées dans les environnements hybrides

Pass-IT t’entraîne précisément sur ces points faibles — adaptatif et espacé →

Questions

Questions fréquentes

Quelles sont les erreurs fréquentes à l’examen Professional Cloud Network Engineer ?

Les pièges fréquents incluent : VPC Design Patterns, Hybrid Connectivity, Load Balancing, Private Google Access, Firewall Policies, DNS Configuration. Concentre ton temps de révision sur ces points pour ne pas perdre de points.

Quelle certification cloud est la meilleure pour un ingénieur réseau ?

Sur Google Cloud, c'est celle-ci : le Professional Cloud Network Engineer, c'est aux quatre cinquièmes de la conception de VPC, de l'implémentation, des services managés et de la connectivité hybride. Ailleurs, les équivalents sont Microsoft AZ-700 pour le réseau Azure et, côté neutre, CompTIA Network+ pour les fondamentaux sous-jacents. Choisis selon la plateforme qu'utilise ton employeur, car les concepts se transposent, mais pas les examens.

Comment l'examen Cloud Network Engineer est-il pondéré ?

Designing and planning a VPC network est la plus grosse section avec 21%, devant Implementing a VPC network à 20%. Managed network services et Hybrid and multicloud interconnectivity pèsent 16% chacune, Operations 14% et Network security 13%. À elle seule, la partie VPC représente plus de deux cinquièmes de l'examen.

Quelle expérience l'examen Cloud Network Engineer suppose-t-il ?

Google Cloud recommande trois ans d'expérience ou plus dans le secteur, dont au moins un an sur sa propre plateforme, et n'exige rien. Le catalogue prévoit environ 100 heures. L'expérience réseau classique se transpose bien, mais la section sur la connectivité hybride est propre aux produits Google Cloud et doit s'apprendre de zéro.

Combien de temps dure la certification Cloud Network Engineer ?

Deux ans, avec un renouvellement à faire dans une fenêtre d'éligibilité avant la date d'expiration. Il n'existe pas de voie par formation continue, donc le renouvellement passe par un examen.

Au bout de combien de temps peux-tu repasser l'examen Cloud Network Engineer ?

Quatorze jours après le premier échec, 60 jours après le deuxième et 365 jours après le troisième. Google Cloud applique cette progression à toute sa gamme Professional.

Pass-IT est un outil de révision indépendant, ni affilié à Google Cloud ni approuvé par Google Cloud ; Google Cloud et les noms d’examens sont des marques de leurs propriétaires respectifs.

Une certification. Un seul paiement.

Accès complet à GCP-PCNE

Accède à toute la banque de questions de cette certification. Alex explique chaque réponse et ton score de préparation te montre quoi travailler ensuite.

Acheter l’accès à GCP-PCNE pour $29.99Un seul paiement. Accès à vie à cette certification.

Vérifie gratuitement si tu es prêt20 questions. Sans carte. Vois quoi travailler avant d’acheter.

Atteins 80 % de préparation et réussis — ou tu es remboursé.

Comment fonctionne le score →