Top 15 Questions d’Entretien Cloud (AWS, Azure, GCP)

Huit ans à faire passer des entretiens cloud, et le pattern se confirme d’année en année. Les candidats qui décrochent le poste ne sont jamais ceux qui récitent le plus de services. Jamais. Ce sont ceux qui savent raisonner à voix haute quand on les met sous pression.

Le truc c’est que la plupart des guides de préparation te donnent des réponses toutes faites. Sauf qu’un recruteur expérimenté détecte ça en trente secondes. Ce qui suit, c’est ce que j’aurais aimé qu’on me dise avant mes premiers entretiens — et ce que je cherche maintenant de l’autre côté de la table.

Les fondamentaux ne sont pas “faciles”

On a cette idée reçue que les questions junior sont simples. Franchement ? C’est faux. La différence entre IaaS, PaaS et SaaS, tout le monde peut la réciter. Mais expliquer qui gère quoi avec un vrai cas vécu — “on est passé de EC2 à App Engine parce qu’on perdait deux jours par mois à patcher l’OS” — là, tu marques des points.

Même chose pour les régions et zones de disponibilité. Répondre “c’est un emplacement géographique”, c’est insuffisant. Parle du pourquoi : multi-AZ pour la résilience, choix de région pour la latence ET la conformité RGPD. Les recruteurs veulent sentir que tu as déjà réfléchi à ces arbitrages en situation réelle.

Le stockage, pareil. S3 pour l’objet, EBS pour le bloc, EFS pour le partage. La question piège classique : “Pourquoi pas tout mettre en S3 ?” Parce qu’un volume bloc se monte comme un disque, avec une latence prévisible. Du stockage objet, non. Et les load balancers — Layer 4 vs Layer 7, ok, mais mentionne surtout l’auto-scaling qui va avec. Un ALB sans auto-scaling group derrière, ça n’a aucun sens.

Le niveau intermédiaire, là où 80% des candidats se plantent

C’est brutal mais c’est la réalité. La reprise après sinistre ? RPO et RTO, si tu connais pas ces acronymes, arrête tout et apprends-les avant l’entretien. Les quatre stratégies — backup & restore, pilot light, warm standby, multi-site active-active — c’est du classique. Mais sois honnête : la plupart des boîtes sont en backup & restore et prétendent être en warm standby. Dis ce que tu as vraiment mis en place, pas ce que tu as lu.

Le modèle de responsabilité partagée, c’est la question piège par excellence. Mon exemple préféré : une base RDS exposée en 0.0.0.0/0 parce que quelqu’un avait ouvert le security group “pour tester”. C’est pas AWS le responsable. C’est toi. Point.

Et puis l’optimisation des coûts… Tout le monde dit “right-sizing” en entretien. Personne le fait vraiment. Les instances réservées pour le stable, spot pour le batch, tagging pour savoir qui dépense quoi — ça, c’est le discours. La réalité ? Ces volumes EBS détachés qui traînent depuis six mois et que personne n’a supprimés. Parle de ça, c’est beaucoup plus crédible.

Petite parenthèse sur le scaling. Vertical = plus gros serveur (avec un plafond). Horizontal = plus de serveurs (mais ton app doit être stateless). Si t’as des sessions en mémoire, t’as un problème. La plupart des candidats oublient ce détail.

Ce qu’on attend vraiment d’un profil senior

Ici, on te demande plus de réciter. On te demande de penser. Et parfois de contredire les idées reçues.

Le multi-cloud, par exemple. La réponse populaire c’est “ça évite le vendor lock-in, donc c’est bien”. Sauf que… non. La complexité opérationnelle explose, les coûts de transfert inter-cloud sont énormes, les APIs sont incohérentes entre providers. L’approche pragmatique : multi-cloud au niveau stratégie, mono-cloud par workload. Dire ça en entretien, ça montre une vraie maturité.

Zero-trust, migration monolithe-microservices, pipelines CI/CD cloud-native — ces sujets reviennent systématiquement. Le piège commun ? Rester théorique. Pour le zero-trust, donne un cas concret de mise en oeuvre avec mTLS entre services. Pour la migration, parle du Strangler Fig pattern, mais surtout dis que c’est pas toujours la bonne décision. Un monolithe bien structuré vaut mieux que des microservices mal découpés. Les recruteurs senior veulent entendre cette nuance.

Ma question préférée à poser en entretien ? La latence intermittente en microservices. Parce qu’elle révèle ta méthodologie, pas tes connaissances. Tracing distribué pour localiser le service fautif, logs corrélés, et surtout une approche ordonnée : reproduire, isoler, mesurer, corriger, vérifier. Les cold starts Lambda, la contention de base, les limites de connexions — les causes sont multiples. C’est ta démarche qui compte.

Le vrai différenciateur (et ce n’est pas technique)

Franchement, la technique ne suffit pas. Ce qui fait la différence, c’est ta capacité à argumenter des compromis. Pourquoi ce choix plutôt qu’un autre ? Qu’est-ce que tu as sacrifié ? Quel était le contexte business ?

Parle d’erreurs commises. D’une prod qui a planté un vendredi soir. De ce que t’en as tiré. Ce vécu-là vaut plus que toutes les certifications du monde — et c’est exactement ce qui te distingue de quelqu’un qui a juste bachoté les docs la veille.

Structure ta réponse en couches quand on te demande de sécuriser une app : réseau, identité, données, application, monitoring. Pas parce que c’est une formule magique, mais parce que ça montre que tu as une grille de lecture. Et les recruteurs adorent les grilles de lecture.

FAQ

Faut-il être certifié pour décrocher un poste cloud ? Les certifs (Solutions Architect, Azure Administrator, GCP Professional) montrent un socle, oui. Mais elles convainquent rarement seules. Préparer une certif, c’est un bon cadre d’étude. Ce qui fait vraiment pencher la balance, c’est l’expérience pratique, les projets concrets.

Je dois maîtriser AWS, Azure ET GCP ? Non. Maîtrise un provider en profondeur et aie une compréhension conceptuelle des autres. Les fondamentaux — réseau, stockage, compute, sécu — sont les mêmes partout. Un recruteur préfère quelqu’un de solide sur un cloud que superficiel sur trois.

Comment pratiquer quand on n’a jamais touché de vrai projet ? Free tier. Monte un VPC avec sous-réseaux publics et privés. Déploie une app conteneurisée. Configure un pipeline CI/CD de bout en bout. Rien ne remplace la pratique. Et documente ce que tu fais — c’est un portfolio que tu pourras montrer en entretien.

Tu veux un plan complet ? Les questions cloud ne sont qu’une partie du puzzle. Pour la vision globale — coding, system design, comportemental et timing — lis comment préparer un entretien technique en 2026.

C’est parti ? Rejoindre l’accès anticipé →