Un ingénieur Terraform écrit et maintient le code qui crée les réseaux, les comptes, les clusters et les bases d'une organisation. Sur beaucoup de missions, il reprend un existant : des centaines de ressources, un state partagé entre plusieurs équipes, des modules recopiés d'un dépôt à l'autre. Les offres citent aussi OpenTofu, le fork open source lancé en 2023 après le passage de Terraform sous licence BSL. Terragrunt, Atlantis et HCP Terraform reviennent souvent pour exécuter les plans.
Le niveau s'entend vite dans la manière de parler du state. Un junior connaît plan et apply. Un confirmé sait où le state est stocké, qui peut le lire, comment il est verrouillé et ce qu'il fait quand il ne correspond plus au cloud. La certification HashiCorp Terraform Associate valide les bases du langage. Elle ne dit rien de la reprise d'une production.
L'entretien part d'une modification réelle : renommer une ressource, passer de count à for_each, importer un bucket créé dans la console. La personne dit ce que le plan doit afficher avant l'apply, et ce qui ferait renoncer la personne. Le PDF contient 30 questions sur six axes, un cas de 20 minutes et une grille de 1 à 4.
L'outillage Terraform qu'un ingénieur IaC utilise au quotidien
HCL, le langage de Terraform
Un langage déclaratif où l'on décrit des ressources, des variables, des outputs et des modules. for_each, dynamic et les expressions conditionnelles génèrent beaucoup de ressources avec peu de lignes, et produisent aussi du code illisible quand on en abuse. La personne doit savoir rester simple.
Le state et les backends distants
Le fichier d'état relie le code aux ressources réelles. En équipe, il vit dans un backend distant : bucket S3, compte de stockage Azure, bucket GCS ou HCP Terraform. Il contient souvent des secrets en clair. Sur S3, le verrou passe désormais par un fichier (use_lockfile), et l'ancien verrou par table DynamoDB est déprécié.
Providers, modules et registre
Les providers traduisent le code en appels aux API d'AWS, d'Azure, de GCP, de Kubernetes ou de Datadog. Les modules regroupent des ressources réutilisables, publiés sur le registre public ou sur un registre privé. Un ingénieur confirmé fixe les versions des deux et sait lire le fichier .terraform.lock.hcl.
OpenTofu
Le fork open source de Terraform, placé sous l'égide de la Linux Foundation. La syntaxe reste très proche, et OpenTofu ajoute ses propres fonctions, comme le chiffrement du state côté client ou for_each sur les blocs provider. Un candidat qui a travaillé avec l'un passe à l'autre sans difficulté, à condition de connaître ces écarts.
HCP Terraform et Terraform Enterprise
Les offres d'HashiCorp, racheté par IBM en 2025, pour exécuter les plans à distance, stocker les states, gérer des workspaces et appliquer des politiques Sentinel ou OPA. HCP Terraform est le nouveau nom de Terraform Cloud depuis 2024. Beaucoup de CV emploient encore l'ancien.
Terragrunt
Un outil qui enveloppe Terraform ou OpenTofu. Il évite de répéter la configuration du backend et des providers dans chaque dossier et enchaîne des composants qui dépendent les uns des autres. On le trouve sur les infrastructures découpées en dizaines de states.
Atlantis, Spacelift et la CI
Ces outils évitent que quelqu'un applique depuis son poste. Atlantis lance le plan sur chaque merge request et l'apply après approbation. Spacelift et env0 font la même chose en service géré, et d'autres équipes passent par GitLab CI ou GitHub Actions. Reste à savoir qui a le droit d'appliquer, et avec quels identifiants.
tflint, Checkov, Trivy et terraform test
Les contrôles qui tournent avant la relecture humaine. tflint détecte les erreurs propres à un provider, Checkov et Trivy (qui a intégré tfsec) signalent les configurations dangereuses, terraform test vérifie le comportement d'un module. Un profil qui n'en cite aucun n'a probablement jamais tenu un pipeline Terraform.
Les intitulés varient : ingénieur Terraform, expert infrastructure as code, ingénieur cloud DevOps, lead IaC. Le travail aussi. Certains postes consistent à écrire les modules standard que les équipes produit consomment. D'autres demandent de reprendre une infrastructure créée à la main et de la passer en code sans coupure. D'autres encore font tourner une plateforme Terraform pour des dizaines d'équipes, avec HCP Terraform, Atlantis ou Spacelift. Dans tous les cas, Terraform ne remplace pas la connaissance du cloud. Un ingénieur qui ne comprend pas le réseau AWS ou les rôles IAM écrira un code valide qui crée une infrastructure fausse. L'entretien vérifie au moins un cloud en profondeur.
Les compétences Terraform évaluées pendant l'entretien
- Gestion du state et verrouillage
- HCL avancé : for_each, dynamic, expressions
- Conception et versionnement de modules
- Refactoring et import sans destruction
- Pipeline plan/apply et contrôles automatiques
- Secrets, identités et sécurité du code
Cinq questions techniques pour un ingénieur Terraform
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é
Deux personnes lancent terraform apply en même temps sur le même state. Que se passe-t-il, et comment l'empêchez-vous ?
Une bonne réponseSans verrou, les deux exécutions partent du même state et la dernière écriture l'emporte. Des ressources sortent du state ou sont créées en double. Un backend distant avec verrouillage bloque la seconde exécution. Sur S3, c'est l'option use_lockfile, l'ancien verrou par table DynamoDB étant déprécié ; azurerm et GCS verrouillent sans configuration supplémentaire. Un bon profil ajoute que l'apply ne devrait partir que de la CI, et qu'il ne lance force-unlock qu'après avoir vérifié qu'aucune exécution ne tourne encore.
Signal d'alerte« Terraform gère ça tout seul », sans savoir où vit le state. Un state commité dans Git. Un force-unlock lancé par réflexe dès qu'un verrou gêne.
Question 2 · confirmé
Vous passez une liste de sous-réseaux de count à for_each. Que montre le plan, et comment évitez-vous la recréation ?
Une bonne réponseLes adresses changent, par exemple de aws_subnet.this[0] à aws_subnet.this["eu-west-3a"], donc le plan propose de détruire puis recréer chaque sous-réseau. Il ajoute un bloc moved par élément (ou terraform state mv sur une version ancienne) et relance le plan jusqu'à ne voir que des déplacements. Il sait dire pourquoi for_each vaut mieux ici : avec count, retirer un élément au milieu de la liste décale tous les index suivants et recrée les ressources concernées.
Signal d'alerteAppliquer quand même parce que « ce ne sont que des sous-réseaux », sans voir que les instances et les interfaces réseau qui en dépendent partent avec. Ne pas connaître le bloc moved.
Question 3 · confirmé
Un bucket et une base PostgreSQL ont été créés à la main dans la console. Comment les faites-vous entrer dans Terraform ?
Une bonne réponseUn bloc import avec l'identifiant réel de chaque ressource, puis terraform plan -generate-config-out pour obtenir une première version du code, qu'il nettoie et range dans le bon module. Il relance le plan jusqu'à zéro changement avant d'appliquer. Il pense aux ressources liées que la console a créées en silence : politique du bucket, chiffrement, groupe de paramètres, groupe de sécurité. Sur la base, il ajoute prevent_destroy.
Signal d'alerteSupprimer la base pour la recréer proprement avec Terraform. Ou une série de terraform import lancés à la main sans relire le plan qui suit.
Question 4 · senior
Comment organisez-vous le code et les states pour trois environnements et une vingtaine de composants ?
Une bonne réponseUn state par environnement et par composant (réseau, données, cluster, applicatif) pour limiter les dégâts d'une erreur et garder des plans courts. Les modules sont versionnés et appelés par tag ou depuis un registre privé. Ce qui change d'un environnement à l'autre passe par des variables, ou par Terragrunt quand le nombre de dossiers grandit. Les dépendances entre states passent par des outputs lus avec une data source. Il dit aussi quand il évite les workspaces de la CLI : comptes, droits ou structures différents selon l'environnement.
Signal d'alerteUn seul state pour toute l'infrastructure. Ou des dossiers dev, recette et prod copiés-collés, qui divergent au fil des mois sans que personne ne le voie.
Question 5 · confirmé
Le mot de passe d'une base apparaît en clair dans le state et dans les logs de la CI. Qu'est-ce qui a mal tourné, et que changez-vous ?
Une bonne réponseLe state stocke les attributs en clair, et sensitive ne fait que masquer la valeur dans le plan et dans la sortie console. Il restreint l'accès au backend (chiffrement, droits limités, versioning) et sort le secret du code : génération et stockage dans Secrets Manager ou Vault, ou option du service qui gère lui-même le mot de passe. Sur les versions récentes, il cite les ressources éphémères et les arguments write-only, qui évitent d'écrire la valeur dans le state. La CI s'authentifie par OIDC, sans clé longue durée.
Signal d'alerte« J'ai mis sensitive = true, donc c'est chiffré. » Des clés d'accès dans un fichier tfvars versionné.
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 Terraform : les questions fréquentes
Terraform ou OpenTofu : l'un des deux est-il indispensable sur le CV ?
Non. OpenTofu est un fork de Terraform, la syntaxe et les providers sont presque les mêmes. Un ingénieur Terraform passe sur OpenTofu en quelques jours, et inversement. Les écarts portent sur des fonctions récentes : chiffrement du state et for_each sur les providers côté OpenTofu, Stacks et intégration avec HCP Terraform côté HashiCorp. Mieux vaut savoir avec quel outil la personne a tenu une production, et sur quel cloud.
La certification Terraform Associate est-elle un bon filtre ?
Elle montre que la personne connaît le langage, les commandes, le rôle du state et des modules. C'est un bon signal pour un profil junior. Elle ne vérifie ni la reprise d'une infrastructure existante, ni le découpage des states, ni la gestion d'un incident. Pour un poste confirmé ou senior, un import réel, un refactoring mené sans destruction ou un state restauré comptent, avec le plan affiché à chaque étape.
Quel test technique est donné à un ingénieur Terraform ?
Un petit dépôt avec un module, un state et un défaut connu suffit : count à remplacer par for_each, ressource à renommer, bucket à importer. La personne lance le plan, explique ce qu'elle lit et propose la correction. En trente à quarante-cinq minutes, on voit si elle relit le plan avant d'agir. Un exercice à faire chez soi pendant plusieurs jours apprend moins et décourage les bons profils.
Un ingénieur Terraform doit-il connaître un cloud en particulier ?
Oui, au moins un en profondeur. Terraform décrit des ressources, mais c'est le cloud qui fixe ce qu'elles font : réseau, IAM, chiffrement, quotas. Un profil qui écrit un HCL propre sans comprendre une table de routage ou une politique IAM produira une infrastructure fragile. La question porte sur le cloud du poste, AWS, Azure ou GCP, avec la même exigence que pour Terraform.
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.
