Les missions d'ingénieur réseau cloud, ou cloud network engineer, demandent la gestion des VPC et des VNet, des hubs de transit (Transit Gateway, Virtual WAN, Network Connectivity Center), des liens Direct Connect, ExpressRoute ou Cloud Interconnect, de BGP, des pare-feu Palo Alto, Fortinet ou Check Point, du DNS privé et de Terraform. Beaucoup portent sur Google Cloud, d'autres mélangent deux clouds.
Le vivier vient de deux côtés. L'ingénieur réseau du datacenter maîtrise BGP et les pare-feu, mais découvre que le cloud impose ses propres règles de routage et que le peering n'est pas transitif. L'ingénieur cloud connaît les VPC, mais n'a parfois jamais réglé une préférence de chemin. Les questions font apparaître lequel des deux profils se présente.
Le récit d'une interconnexion réellement montée fait la différence : combien de liens, quels préfixes annoncés, comment la bascule a été testée, ce qui a cassé. Un bon profil parle spontanément du trafic retour et du DNS. Le PDF propose six axes, une grille de 1 à 4 et un cas de 20 minutes sur un datacenter relié à AWS et Azure.
Ce qu'un ingénieur réseau cloud configure
Hubs de transit : Transit Gateway, Virtual WAN, Network Connectivity Center
Les routeurs gérés qui relient des dizaines de réseaux en étoile. Transit Gateway sur AWS, avec ses tables de routage, Virtual WAN ou un hub VNet sur Azure, Network Connectivity Center sur Google Cloud. C'est là que se décide qui peut parler à qui, et une erreur dans ces tables ouvre ou coupe des environnements entiers.
Liens privés : Direct Connect, ExpressRoute, Cloud Interconnect
Les connexions privées entre le datacenter et le cloud, dédiées ou fournies par un opérateur partenaire. Elles offrent un débit et une latence stables, mais ne sont pas chiffrées par défaut. Un VPN IPsec sert souvent de secours, et la redondance demande deux liens sur deux emplacements.
BGP
Le protocole qui échange les routes entre le datacenter et le cloud. Le candidat doit savoir régler la préférence de chemin dans les deux sens (AS path, préférence locale, communautés), connaître les limites de préfixes de chaque fournisseur et diagnostiquer une session qui tombe.
DNS hybride
Route 53 Resolver, Azure DNS Private Resolver et Cloud DNS, avec des points d'entrée et de sortie pour que le datacenter résolve les noms privés du cloud et inversement. Les Private Endpoints et PrivateLink en dépendent entièrement. Une bonne partie des incidents réseau cloud sont en réalité des incidents DNS.
Pare-feu cloud et NVA
Pare-feu gérés (AWS Network Firewall, Azure Firewall, Cloud NGFW) ou appliances virtuelles Palo Alto VM-Series et FortiGate, placées dans le hub. Le point sensible est le routage symétrique : le retour d'un flux doit repasser par le même pare-feu, sinon les sessions tombent.
Accès privé aux services : PrivateLink, Private Endpoint, Private Service Connect
Ces mécanismes donnent à un service une adresse privée dans le réseau du consommateur, sans ouvrir de routage complet. Ils servent à consommer un service géré du fournisseur ou à exposer une API interne à d'autres équipes, même quand les plages d'adresses se chevauchent.
Sortie Internet et NAT
NAT gateway sur AWS et Azure, Cloud NAT sur Google Cloud, ou pare-feu central. Sur Azure, les nouveaux VNet créés avec les versions d'API publiées après le 31 mars 2026 ont des sous-réseaux privés par défaut : sans sortie explicite, les VM ne joignent plus Internet.
Terraform réseau et IPAM
Le réseau se décrit en Terraform, avec des modules et un état séparé des applications. Le plan d'adressage vit dans un outil d'IPAM (AWS VPC IPAM, Infoblox) pour éviter les chevauchements. Un apply mal relu peut recréer un sous-réseau en service.
Outils de diagnostic
Flow logs, Reachability Analyzer sur AWS, Network Watcher sur Azure, Connectivity Tests sur Google Cloud. Ils montrent les routes effectives et la règle qui bloque un flux. Un candidat qui les cite sans hésiter a déjà dépanné en production.
Le poste d'ingénieur réseau cloud est une spécialisation : architecture en étoile, interconnexion avec le datacenter, segmentation et filtrage, DNS hybride. Les offres françaises citent les VPC et VNet, Transit Gateway, Network Connectivity Center ou Shared VPC, PrivateLink, Direct Connect, ExpressRoute ou Cloud Interconnect, BGP et OSPF, Palo Alto, Fortinet ou Check Point, Zscaler pour la sortie, Terraform et Ansible. Les certifications AWS Advanced Networking, Azure Network Engineer (AZ-700) et Google Professional Cloud Network Engineer attestent la connaissance des services. La pratique de BGP et du dépannage se vérifie en entretien.
Six savoir-faire réseau à valider
- Routage hub-and-spoke
- Pare-feu et routage symétrique
- Interconnexion hybride et BGP
- DNS hybride et endpoints privés
- Plan d'adressage et sortie Internet
- Diagnostic réseau
Routage, BGP et DNS : les questions à un ingénieur réseau cloud
Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.
Question 1 · confirmé
Vingt VPC AWS doivent joindre le datacenter, et les VPC de développement ne doivent jamais parler à ceux de production. Comment configurez-vous Transit Gateway ?
Une bonne réponsePlusieurs tables de routage sur le Transit Gateway. Les VPC de production sont associés à une table qui reçoit les routes propagées par la production, les services partagés et le datacenter, sans celles du développement. Même logique en sens inverse. Le datacenter arrive par un Direct Connect gateway ou un VPN, et sa table reçoit les routes de tous les environnements autorisés. Des routes blackhole bloquent explicitement ce qui ne doit pas passer. Le Transit Gateway est partagé entre comptes par AWS RAM.
Signal d'alerteUne seule table par défaut où tout le monde propage tout, ou un maillage de peerings entre les vingt VPC.
Question 2 · confirmé à senior
Le trafic entre deux spokes passe par une paire de pare-feu Palo Alto dans le hub, et des sessions se coupent au hasard. Que suspectez-vous ?
Une bonne réponseUn routage asymétrique : l'aller traverse un pare-feu, le retour en traverse un autre qui ne connaît pas la session et la rejette. Sur AWS, le mode appliance de l'attachement du VPC d'inspection garde un flux dans la même zone de disponibilité, ou un Gateway Load Balancer garantit l'affinité. Sur Azure, des UDR cohérentes dans les deux spokes et un load balancer interne en HA ports devant les pare-feu. La personne vérifie les routes effectives des deux côtés et les journaux de session des pare-feu.
Signal d'alerteOuvrir plus de règles sur les pare-feu, ou augmenter les timeouts de session sans chercher le chemin réel des paquets.
Question 3 · confirmé
Un circuit ExpressRoute en peering privé, et un VPN site à site en secours. Comment se passe la bascule, et qu'est-ce qui peut mal tourner ?
Une bonne réponsePour un même préfixe, Azure préfère ExpressRoute au VPN. Mais la règle du préfixe le plus long passe avant : si le VPN annonce un préfixe plus précis, tout le trafic y part. Côté datacenter, une préférence locale plus forte sur ExpressRoute, sinon le retour revient par le VPN. BFD accélère la détection de panne. La personne connaît la limite de 4 000 préfixes IPv4 sur le peering privé (10 000 avec l'option premium) : au-delà, la session BGP tombe.
Signal d'alerte« Azure bascule tout seul », sans parler de préfixes, de préférence locale ni de sens du retour.
Question 4 · confirmé
Les serveurs du datacenter doivent joindre un compte de stockage Azure exposé par un Private Endpoint, par son nom habituel. Que mettez-vous en place ?
Une bonne réponseUne zone DNS privée privatelink.blob.core.windows.net liée au VNet hub, avec l'enregistrement du Private Endpoint. Un Azure DNS Private Resolver avec un point de terminaison entrant dans le hub. Sur les DNS du datacenter, un redirecteur conditionnel vers ce point d'entrée pour la zone publique blob.core.windows.net, car les clients demandent le nom public et la chaîne CNAME mène vers privatelink. La personne teste la résolution depuis un serveur du datacenter avant d'ouvrir les flux.
Signal d'alerteUn fichier hosts sur chaque serveur, ou créer la zone privatelink sur les DNS internes et la remplir à la main.
Question 5 · confirmé à senior
Trois clouds, deux datacenters et des sites distants : comment construisez-vous le plan d'adressage IP ?
Une bonne réponseDes blocs réservés par cloud, par région et par environnement, sans chevauchement avec le datacenter ni les sites. Des VPC et VNet assez grands pour Kubernetes, dont les pods consomment des adresses. Des blocs alignés pour agréger les annonces BGP et rester sous les limites de préfixes. Un outil d'IPAM (AWS VPC IPAM, Infoblox ou équivalent) comme source de vérité, et des plages attribuées par Terraform depuis cet outil.
Signal d'alerte10.0.0.0/16 partout parce que c'est la valeur par défaut, et les conflits découverts au premier peering.
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
Ingénieur réseau cloud : réponses aux questions fréquentes
D'où viennent les bons profils d'ingénieur réseau cloud ?
Souvent du réseau de datacenter. BGP, les pare-feu et le dépannage se transposent directement. L'adaptation porte sur les règles propres au cloud : peering non transitif, tables de routage gérées, routage symétrique à garantir à la main, DNS privé lié aux endpoints, Terraform à la place de la ligne de commande. Il doit avoir déjà construit au moins un réseau cloud réel, même petit.
Les certifications des fournisseurs suffisent-elles pour juger un ingénieur réseau cloud ?
Elles aident à trier. AWS Certified Advanced Networking Specialty, Azure Network Engineer Associate (AZ-700) et Google Professional Cloud Network Engineer sont les plus ciblées. Côté éditeurs, les certifications Palo Alto, Fortinet ou Cisco montrent le socle réseau. Une certification ne dit pas si la personne a déjà réglé une préférence de chemin ou dépanné un DNS hybride. Mieux vaut un exemple précis avec ses chiffres : nombre de liens, préfixes, bascules testées.
Un exercice sur schéma vaut-il mieux qu'un test technique ?
Un exercice sur schéma en entretien marche bien. Le support est une topologie avec un hub, deux spokes et un datacenter, et une panne : un flux qui ne revient pas, un nom privé qui ne se résout pas. La personne raisonne à voix haute. En vingt minutes, on voit si elle pense au chemin de retour et au DNS, ce qu'un long test écrit montre mal.
Où s'arrête le rôle de l'architecte cloud, où commence celui de l'ingénieur réseau ?
L'architecte cloud conçoit l'ensemble de la plateforme : comptes, identité, sécurité, réseau, services. L'ingénieur réseau cloud va plus loin sur le réseau et le construit : tables de routage, sessions BGP, pare-feu, DNS, Terraform réseau. Dans une grande équipe plateforme, l'architecte fixe les principes et l'ingénieur réseau les met en œuvre et les exploite.
Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.
