Quel récit un intervieweur attend-il : écrire, prévoir, faire approuver, appliquer ?

Le récit, pas le catalogue HCL

L’intervieweur Terraform expérimenté n’achète pas une liste de resources. Il achète une discipline :

1. Écrire l’intention dans le code, revue, petite, dans le bon root (rayon d’impact).
2. Prévoir : plan contre le state distant, refresh compris. Lire les -/+ et les moins avant les plus.
3. Faire approuver : un humain (ou deux) qui a le contexte métier — « cette base, on peut la remplacer ? ». Le commentaire CI est une aide, pas une signature aveugle.
4. Appliquer le plan sauvé, avec lock, depuis la CI, avec les droits du rôle adéquat. Puis vérifier le réel (health, DNS, un smoke), pas seulement le code de sortie zéro.

Cette boucle est ce que HashiCorp vend depuis le début : l’infrastructure comme changement examiné, pas comme script. Le state, le backend, le lock, les modules ne sont que des pièces pour que la boucle tienne à plusieurs.

Ce qui fait rater l’entretien

« Je apply depuis mon laptop, je connais le compte. » « On auto-approve, on a confiance. » « Le plan GitHub suffisait, j’ai relancé apply sans fichier. » « J’ai target pour aller plus vite. » Chacune de ces phrases dit que le récit n’est pas installé.

À l’inverse, raconter un incident (dérive console, lock oublié, module qui recrée un VPC) et ce que l’équipe a changé (découpage, moved, plan file) pèse plus que dix types AWS récités.

La relance probable

« Et si le plan est trop long pour être lu ? »

Alors le root est trop gros, ou le changement est trop gros. On découpe le state ou la PR. Un plan illisible n’est pas un argument pour skip la lecture : c’est un signal d’architecture.