L'état, c'est le registre que Terraform tient des ressources réelles correspondant à chaque adresse de configuration, plus les attributs mis en cache qu'il utilise pour calculer un plan. Pour une équipe, il doit vivre dans un backend distant avec verrouillage, par exemple S3 avec son support natif de lockfile ou un backend géré, pour que deux apply ne puissent pas tourner en même temps. Ne le committez jamais dans git, puisqu'il contient des secrets en clair, et découpez-le par rayon d'impact plutôt que de garder un seul fichier géant.
Pourquoi les recruteurs posent cette question
L'état, c'est là que les équipes se font mal, donc cette question sépare ceux qui ont fait tourner Terraform en production de ceux qui ont suivi un tutoriel. Le recruteur veut entendre parler de verrouillage, de backends distants, de secrets dans l'état et de découpage des fichiers d'état. Les relances vont en général vers la récupération : ce que vous faites quand l'état dérive, quand quelqu'un supprime une ressource à la main, ou quand un apply est interrompu en plein milieu.
Comment structurer votre réponse
- Définissez l'état comme la correspondance entre la configuration et les ressources réelles.
- Expliquez pourquoi l'état distant avec verrouillage est obligatoire en équipe.
- Couvrez les secrets dans l'état et le contrôle d'accès sur le backend.
- Décrivez votre découpage de l'état et pourquoi le rayon d'impact le guide.
Exemple de réponse
L'état, c'est la carte entre ce que j'ai écrit en code et ce qui existe réellement chez le fournisseur, indexée par adresse de ressource, plus un cache d'attributs pour qu'un plan n'ait pas à tout relire de zéro. En équipe, il va dans un backend distant avec verrouillage, comme ça deux personnes qui lancent apply en même temps ne peuvent pas le corrompre. Ce qui surprend les gens, c'est que l'état contient les attributs des ressources tels quels, donc les mots de passe de base de données et les clés générées y sont en clair ; ça veut dire que le bucket est chiffré, versionné, et restreint au rôle du pipeline, pas lisible par tout le monde. Sur l'organisation, je découpe par rayon d'impact et par fréquence de changement. Le réseau et les comptes changent rarement et ont leur propre état, chaque service ou environnement a le sien, et ils se lisent entre eux via des data sources ou des outputs publiés plutôt qu'un module racine qui contient tout. La raison pratique, c'est qu'un fichier d'état de cinq cents ressources rend chaque plan lent et chaque erreur énorme. Pour la récupération, je m'appuie sur le versioning du bucket plus state mv et import, jamais sur une édition du fichier à la main.
Vous passez cet entretien bientôt ? GhostPilot écoute votre appel en direct, repère la question dès qu'elle est posée et affiche une réponse structurée à l'écran en temps réel. Essayez-le lors de votre prochain entretien blanc, ou prenez un Session Pass à $29, sans abonnement, pour le jour J.
Voir comment ça marcheQuestions de relance à prévoir
- Que faites-vous si quelqu'un supprime une ressource depuis la console ?
- Comment refactoreriez-vous la structure des modules sans détruire de ressources ?
- Comment sortez-vous d'un verrou d'état laissé par un apply qui a planté ?
Autres questions pour Ingénieur DevOps
Votre recruteur posera sa propre version de celle-ci. Collez votre véritable fiche de poste dans le Question Predictor gratuit et obtenez les 20 questions que ce poste a le plus de chances de poser, avec ce que chacune cherche vraiment à sonder.
Prédire mes questions