Les entretiens de cloud engineering ont cessé d'être des quiz de culture générale il y a un bon moment. En 2026, presque personne ne vous demande de réciter la différence entre un bucket S3 et un volume EBS. On vous tend un VPC cassé, un plan Terraform qui veut détruire une base de données de production, ou un scénario d'astreinte à 3h du matin, et on regarde comment vous raisonnez. "Je chercherais sur Google" ne compte que si vous savez dire ce que vous chercheriez et pourquoi.
Ce guide couvre les questions que les candidats ingénieur cloud affrontent réellement en ce moment, sur AWS, Azure et GCP, avec une note courte sur la façon d'aborder chacune.
Ce que les entretiens d'ingénieur cloud testent vraiment en 2026
Le titre cache une énorme variance. Un "ingénieur cloud" dans une startup de 30 personnes, c'est une équipe plateforme d'une seule personne qui branche Terraform, la CI/CD et l'astreinte. Le même titre dans une banque, c'est du réseau en profondeur, des garde-fous de conformité et du travail de landing zone. Lisez la description de poste comme si elle faisait partie de l'examen, parce que le processus penche vers ce dans quoi cette équipe est en train de se noyer.
Les signaux de fond, eux, ne bougent pas. Vos interlocuteurs vérifient quatre choses : votre modèle mental du cloud (régions, zones de disponibilité, ce qui tombe quand une AZ s'éteint) ; votre aisance en infrastructure as code (Terraform surtout, avec CloudFormation et Bicep dans certaines boîtes) ; votre jugement opérationnel, puisque le coût, la sécurité et la fiabilité sont désormais des tours à part entière et non des bonus ; et la communication dans l'incertitude, parce que les problèmes cloud sont ambigus et que les bons candidats énoncent leurs hypothèses à voix haute.
Le processus d'entretien : les vraies étapes
La plupart des processus cloud en 2026 comptent quatre à six étapes, et la forme devient prévisible une fois que vous en avez traversé quelques-uns.
- Entretien avec le recruteur (20 à 30 min). Logistique, fourchette de salaire, et sur quels clouds vous avez réellement livré. Soyez précis : "trois ans surtout sur AWS, un peu de GCP" vaut mieux qu'un vague "expérience cloud".
- Entretien technique téléphonique (45 à 60 min). Un échange en direct avec un manager ou un ingénieur senior : des fondamentaux à la volée, plus un ou deux scénarios.
- Exercice pratique ou take-home. De plus en plus le tour central. Écrire un module Terraform, déboguer un déploiement volontairement cassé, ou monter un petit service avec une courte note d'architecture.
- Tour de system design (60 min). Concevoir un système résilient et conscient de son coût. Bien moins axé algorithmes qu'un poste purement logiciel, bien plus axé compromis et domaines de panne.
- Tour comportemental / incident (45 min). Parlez-moi d'une panne, d'une migration, d'un désaccord sur une décision de sécurité. Souvent une plongée en profondeur dans un incident réel que vous avez géré.
Les questions
Fondamentaux
Expliquez-moi de bout en bout ce qui se passe quand un utilisateur atteint une application derrière un Application Load Balancer. Comment l'aborder : résolution DNS, terminaison TLS, le target group du load balancer et ses health checks, les security groups et les subnets sur le chemin, puis le compute et son lien avec le stockage de données. Nommez l'endroit où chaque pièce peut casser.
Expliquez la différence entre une région et une zone de disponibilité, puis concevez un système qui survit à la perte d'une AZ. Comment l'aborder : définissez les deux nettement, puis montrez la conséquence. Multi-AZ pour les services avec état (RDS Multi-AZ, quorum sur trois AZ), compute sans état réparti derrière un load balancer. Signalez que le multi-région est une conversation à part, plus chère, autour du RTO et du RPO, et pas une valeur par défaut.
Qu'est-ce que le modèle de responsabilité partagée, et où les ingénieurs se plantent-ils ? Comment l'aborder : le fournisseur sécurise le cloud, vous sécurisez ce que vous y mettez. L'erreur classique est de croire que service managé veut dire sécurité managée. Un bucket S3 public ou un IAM trop large, c'est votre problème, pas celui du fournisseur.
Infrastructure as code
Votre terraform plan veut détruire et recréer une instance RDS de production. Que faites-vous ?
Comment l'aborder : ne lancez pas apply. Lisez le plan pour trouver l'attribut qui force le remplacement (un champ immuable, une version de moteur, un changement d'AZ). Pensez à create_before_destroy, lifecycle (les blocs), et à state mv ou import comme outils de récupération. Un destroy dans un plan de prod, c'est un arrêt immédiat de la chaîne.
Comment gérez-vous l'état Terraform pour quinze ingénieurs sur trois environnements ?
Comment l'aborder : un backend distant (S3 plus verrouillage DynamoDB, ou Terraform Cloud), une séparation de l'état par environnement, et un contrôle du rayon d'impact pour qu'un changement en staging ne puisse jamais toucher l'état de prod. Bonus pour des identifiants CI en moindre privilège et la détection de dérive avec un plan récurrent qui échoue dès qu'il y a un diff.
Réseau, sécurité et IAM
Concevez un VPC avec des subnets publics et privés sur deux AZ, et expliquez-moi le routage. Comment l'aborder : dessinez-le. Un bloc CIDR pour le VPC, des subnets publics routés vers une internet gateway, des subnets privés routés en sortie via une NAT gateway, une route table par tier. Attendez-vous à la relance : comment les instances privées atteignent-elles les API du cloud sans passer par l'internet public (VPC endpoints) ?
Une instance EC2 dans un subnet privé n'arrive pas à joindre internet. Comment déboguez-vous ? Comment l'aborder : c'est une question de dépannage structuré, pas de culture générale. Travaillez couche par couche, du plus proche au plus loin : egress du security group, network ACLs, la route table du subnet, la santé de la NAT gateway et sa route vers l'IGW, puis le DNS. Racontez ça comme une checklist et nommez l'outil qui confirme chaque étape (reachability analyzer, flow logs).
Une application a besoin d'un accès en lecture à un seul bucket S3. Comment le lui accordez-vous ?
Comment l'aborder : un rôle IAM porté par le compute (instance profile, IRSA sur EKS, ou workload identity) avec une policy étroitement limitée à ce bucket et à ce préfixe. Les réponses pièges, des clés d'accès à longue durée de vie dans l'application ou s3:* sur Resource: *, tombent au premier contact. Dites "moindre privilège" à voix haute.
Comment stockez-vous et faites-vous tourner les secrets d'une application cloud-native ? Comment l'aborder : un coffre à secrets managé (Secrets Manager, Parameter Store ou Vault), récupéré au runtime via l'identité du workload, jamais commité dans git ni cuit dans une image. La règle : l'application ne détient jamais d'identifiant statique à longue durée de vie.
Opérations, fiabilité et coûts
La latence en production vient de tripler et vous n'avez aucune idée du pourquoi. Racontez-moi vos dix premières minutes. Comment l'aborder : c'est le signal réponse à incident. D'abord acquitter et communiquer, lire les signaux d'or (latence, trafic, erreurs, saturation), vérifier les déploiements récents, puis privilégier la mitigation (rollback, scale out) plutôt que la chasse à la cause racine pendant que les clients trinquent. Le calme bat la panique.
La facture mensuelle a bondi de 40 pour cent sans changement de trafic. Comment trouvez-vous la cause ? Comment l'aborder : tags d'allocation de coûts, cost explorer découpé par service et par compte, et les suspects habituels (volumes orphelins, load balancers inutilisés, transfert cross-AZ ou egress, un autoscaling group qui s'emballe, des environnements de dev oubliés). Traitez le coût comme une métrique d'ingénierie, avec des responsables.
Quelle est votre approche des sauvegardes et de la reprise après sinistre, et comment savez-vous qu'elles fonctionnent ? Comment l'aborder : définissez d'abord le RTO et le RPO, puis reliez-les à une stratégie (snapshots, réplication cross-région, infrastructure reconstructible depuis le code). La phrase qui marque : une sauvegarde que vous n'avez jamais restaurée est un espoir, pas une sauvegarde.
Comportemental et profondeur sur les incidents
Parlez-moi du pire incident de production auquel vous avez participé. Quel était votre rôle, et qu'est-ce qui a changé ensuite ? Comment l'aborder : prenez-en un vrai et structurez-le en situation, vos actions précises, la résolution, puis le correctif systémique et le postmortem sans blâme qui ont suivi. On cherche l'appropriation et l'apprentissage, pas à savoir si vous avez déjà cassé quelque chose.
Décrivez une fois où vous n'étiez pas d'accord avec une décision de sécurité ou d'architecture. Comment l'aborder : montrez que vous savez contester avec des données, puis vous aligner. La version mature inclut une fois où vous avez été désavoué et où ça s'est bien passé, plutôt qu'une histoire où vous avez bricolé un contournement en douce.
Les erreurs classiques qui coulent les candidats ingénieur cloud
- Citer des services sans les compromis. "J'utiliserais Kubernetes" n'est pas une réponse. Pourquoi pas ECS, ou Lambda, ou un simple autoscaling group ? Le poste, c'est du jugement, pas du vocabulaire.
- Ignorer le coût. Concevoir un actif-actif sur cinq régions pour un outil interne à douze utilisateurs, ça signale que vous n'avez jamais eu une facture sur le dos.
- Bluffer. Faire semblant de connaître un service que vous n'avez pas utilisé s'effondre à la deuxième relance. "Je n'ai pas fait tourner Aurora en prod, mais voilà comment je raisonnerais" inspire bien plus confiance.
- Deviner le correctif. Sur une question de VPC cassé, une bonne pioche passe pour de la chance. Un dépannage par couches, raconté à voix haute, passe pour de la compétence.
- Traiter la sécurité comme une pièce rapportée. Garder l'IAM et les secrets pour la fin d'un tour de design, c'est un signal d'alarme en 2026.
Comment se préparer (et où un copilote en direct aide)
Construisez, ne vous contentez pas de lire. Ouvrez un compte free tier, écrivez un module Terraform qui monte un VPC avec des subnets publics et privés, cassez volontairement le routage, et réparez-le. Cet exercice à lui seul couvre un tiers des questions ci-dessus.
Répétez les questions de scénario à voix haute, parce que les entretiens cloud récompensent la narration. Répéter la réponse sur les "dix premières minutes d'un incident" jusqu'à ce qu'elle coule tout seul vaut mieux que mémoriser des quotas de service que vous pouvez chercher. Reliez aussi votre parcours aux questions comportementales : une histoire de panne, une de migration, une de désaccord, structurées et prêtes.
Pour les tours en direct, où les questions arrivent plus vite que vous ne pouvez composer une réponse complète, un copilote en temps réel enlève la pression. GhostPilot tourne dans le panneau latéral de Chrome et écoute l'entretien, faisant apparaître une trame structurée à l'instant où la question tombe : les couches à vérifier sur une question de débogage, les compromis à nommer sur une question de design, un rappel vers l'angle coût ou sécurité que vous pourriez oublier sous pression. Il vous donne le squelette, pas un script à lire à voix haute, donc c'est toujours vous qui apportez le vécu, avec vos mots. Plus d'infos sur ghostpilotai.com.
FAQ
Sur quoi me concentrer pour un entretien d'ingénieur cloud junior ? Les fondamentaux avant l'étendue. Connaissez sur le bout des doigts les primitives de compute, de stockage et de réseau d'un seul cloud, comprenez l'IAM et le modèle de responsabilité partagée, et sachez écrire une configuration Terraform de base. Les processus juniors pardonnent les trous sur la mise à l'échelle si vos fondamentaux tiennent.
Combien de certifications cloud faut-il en 2026 ? Une certification de niveau associate (par exemple AWS Solutions Architect Associate) aide à passer le tri des CV, surtout sans grande expérience. Au-delà, les certifications atteignent vite un rendement décroissant. Un petit portfolio Terraform et un vrai projet que vous savez raconter valent mieux qu'un mur de badges.
Les entretiens d'ingénieur cloud incluent-ils encore du code façon LeetCode ? Moins que les postes de développement, mais pas zéro. Attendez-vous à du scripting léger (Python ou Bash pour parser des logs ou appeler une API) plutôt qu'à des algorithmes costauds. Les postes orientés plateforme ou SRE peuvent ajouter un exercice de structures de données, mais l'IaC et les scénarios de design dominent.
En quoi un entretien d'ingénieur cloud diffère-t-il d'un entretien DevOps ou SRE ? Le recouvrement est énorme. L'ingénieur cloud penche vers le provisioning, l'IaC et les services du fournisseur. Le SRE penche vers les maths de la fiabilité, les SLO et la rigueur de l'astreinte. Le DevOps penche vers la CI/CD et l'expérience développeur. Un même processus sert souvent les trois, et ce qui coule les bons candidats partout, c'est de parler en noms de services au lieu de compromis.
Essayez GhostPilot AI
Les entretiens cloud vont vite et les questions de scénario ont rarement une seule bonne réponse, ce qui est exactement là où une trame en temps réel vous aide à rester structuré sous pression. GhostPilot tourne dans le panneau latéral de Chrome, donc quand vous partagez un seul onglet il ne fait pas partie de ce qui est capturé, et l'application desktop Windows optionnelle est invisible à la capture d'écran sur Windows 10 (build 2004 ou ultérieur) et Windows 11. Commencez gratuitement avec des sessions en direct de 10 minutes et des réponses IA illimitées, prenez un Session Pass à $29 (trois entretiens complets de deux heures, paiement unique, sans abonnement), ou passez à Pro à $59/mois ou $192/an ($16/mois en facturation annuelle).