Questions d'entretien Terraform : guide complet Infrastructure as Code 2026

Les questions d'entretien sur Terraform evaluent la capacite d'un candidat a gerer une infrastructure cloud de facon declarative, a manipuler le state avec rigueur et a concevoir des modules reutilisables. Avec Terraform 1.14 qui prend desormais en charge les variables dans les sources de modules et HCP Terraform qui elargit sa plateforme d'execution managee, les recruteurs en 2026 attendent une maitrise solide des fondamentaux HCL ainsi qu'une comprehension du paysage Infrastructure as Code en constante mutation.

Concepts fondamentaux de Terraform

Qu'est-ce que Terraform et en quoi differe-t-il des autres outils IaC ?

Terraform est un outil declaratif d'Infrastructure as Code qui gere des ressources cloud a travers des fichiers de configuration ecrits en HCL (HashiCorp Configuration Language). Contrairement aux outils imperatifs comme Ansible ou les scripts shell, Terraform maintient un fichier state qui suit l'etat actuel de l'infrastructure et calcule un diff (le "plan") avant d'appliquer la moindre modification.

Les differenciateurs principaux : Terraform est agnostique vis-a-vis des fournisseurs cloud (AWS, Azure, GCP et des centaines de providers), utilise un workflow plan-before-apply qui previent les surprises, et gere les dependances entre ressources a travers un graphe acyclique dirige (DAG) interne.

Une reponse solide en entretien mentionne egalement le changement d'ecosysteme : depuis l'adoption par HashiCorp de la licence BSL en 2023, OpenTofu a emerge comme fork open-source sous la Linux Foundation. Les deux outils partagent la meme syntaxe HCL mais divergent dans leurs fonctionnalites. Terraform 1.14 se concentre sur l'integration plateforme avec HCP, tandis qu'OpenTofu 1.9 privilegie le chiffrement du state et les backends dynamiques.

Le workflow Terraform : init, plan, apply, destroy

Les quatre commandes principales constituent le cycle de vie de toute operation Terraform :

# 1. Initialize - downloads providers and modules
terraform init

# 2. Plan - shows what will change without modifying anything
terraform plan -out=tfplan

# 3. Apply - executes the planned changes
terraform apply tfplan

# 4. Destroy - tears down all managed resources
terraform destroy

terraform init telecharge les plugins des providers et initialise le backend. terraform plan compare l'etat desire (fichiers de configuration) a l'etat reel (fichier state) et produit un ensemble de modifications. terraform apply execute ces modifications. Sauvegarder le plan dans un fichier avec -out garantit que le plan exact, tel qu'il a ete revu, soit applique -- une pratique indispensable dans les pipelines CI/CD.

Gestion du state : le sujet d'entretien le plus frequent

Qu'est-ce que le state Terraform et pourquoi est-il essentiel ?

Le state Terraform est un fichier JSON (terraform.tfstate) qui etablit la correspondance entre les ressources declarees dans la configuration et les objets d'infrastructure reels. Sans state, Terraform ne peut determiner ce qui existe, ce qui a change ou ce qui doit etre supprime.

Le fichier state contient les identifiants des ressources, les valeurs de leurs attributs et les metadonnees de dependance. Perdre le state signifie que Terraform perd la trace de toutes les ressources gerees, ce qui impose un import manuel de chaque objet ou, pire, laisse des ressources cloud orphelines qui continuent a generer des couts.

Comment gerer le state en production ?

Les fichiers state locaux sont inacceptables pour un travail en equipe. La configuration standard en production repose sur un backend distant avec verrouillage :

# backend.tf
terraform {
  backend "s3" {
    bucket         = "company-terraform-state"
    key            = "prod/networking/terraform.tfstate"
    region         = "eu-west-1"
    dynamodb_table = "terraform-locks"
    encrypt        = true
  }
}

Cette configuration stocke le state dans S3 avec chiffrement cote serveur et utilise DynamoDB pour le verrouillage du state. Le verrou empeche deux ingenieurs (ou deux pipelines CI) d'executer apply simultanement, ce qui corromprait le state.

HCP Terraform (anciennement Terraform Cloud) propose une alternative managee qui gere le stockage du state, le verrouillage, l'historique des executions et le RBAC sans infrastructure supplementaire. Pour les organisations deja investies dans l'ecosysteme HashiCorp, cette solution elimine la charge operationnelle liee a la maintenance de buckets S3 et de tables DynamoDB.

Bonnes pratiques pour le fichier state

• Ne jamais versionner terraform.tfstate dans un depot de code source. Le fichier peut contenir des secrets (mots de passe de bases de donnees, cles API) en clair.
• Activer le chiffrement au repos sur le backend (S3 SSE, chiffrement GCS ou chiffrement Azure Storage).
• Utiliser des fichiers state separes par environnement. Un fichier state unique pour dev, staging et production est une recette pour une destruction accidentelle.
• Mettre en place le verrouillage du state. Tout backend distant qui le supporte doit avoir le verrouillage active.
• Utiliser terraform state list et terraform state show pour inspecter le state sans le modifier.

Modules : composants d'infrastructure reutilisables

Comment fonctionnent les modules Terraform ?

Un module est un repertoire contenant des fichiers .tf qui encapsulent un ensemble de ressources. Toute configuration Terraform constitue techniquement un module (le module racine). Les modules enfants sont appeles depuis le module racine pour favoriser la reutilisation et imposer des standards.

# main.tf - calling a module
module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "5.16.0"

  name = "production-vpc"
  cidr = "10.0.0.0/16"

  azs             = ["eu-west-1a", "eu-west-1b", "eu-west-1c"]
  private_subnets = ["10.0.1.0/24", "10.0.2.0/24", "10.0.3.0/24"]
  public_subnets  = ["10.0.101.0/24", "10.0.102.0/24", "10.0.103.0/24"]

  enable_nat_gateway = true
  single_nat_gateway = true
}

Terraform 1.14 a introduit une amelioration significative : les variables et les locals peuvent desormais etre utilises dans les attributs source et version des modules. Il s'agissait auparavant d'une limitation stricte qui forcait des contournements comme Terragrunt pour le sourcing dynamique de modules.

Qu'est-ce qui caracterise un module bien concu ?

Un module de qualite production respecte les principes suivants :

• Entrees et sorties claires : chaque variable dispose d'une description, d'une contrainte de type et d'une valeur par defaut pertinente lorsque c'est applicable. Les outputs exposent les valeurs dont les modules en aval ont besoin.
• Portee minimale : un module gere un composant logique unique (un VPC, un cluster de base de donnees, un namespace Kubernetes), pas un environnement entier.
• Aucune valeur codee en dur : la configuration du provider, la region, les identifiants de compte et les valeurs specifiques a un environnement proviennent de variables, jamais de valeurs litterales a l'interieur du module.
• Versions semantiques : les modules publies utilisent le versioning semantique. Fixer version = "5.16.0" previent les changements incompatibles inattendus.

Workspaces, environnements et structure de projet

Comment gerer plusieurs environnements ?

Trois patterns courants existent, chacun avec des compromis distincts :

| Pattern | Mecanisme | Ideal pour | Risque | |---------|-----------|------------|--------| | Workspaces | terraform workspace select prod | Projets simples, meme config par env | Backend partage, risque d'apply sur le mauvais workspace | | Repertoire par env | Repertoires separes dev/, staging/, prod/ | Isolation totale entre environnements | Duplication de code | | Terragrunt | Wrapper DRY generant les configs backend | Grands deploiements multi-comptes | Dependance a un outil supplementaire |

L'approche par repertoire par environnement avec modules partages est la plus repandue en production. Chaque repertoire d'environnement contient un main.tf qui appelle les memes modules avec des valeurs de variables differentes, et chacun dispose de son propre fichier state isole.

Quelle est la difference entre workspaces et isolation par repertoire ?

Les workspaces creent des fichiers state nommes au sein du meme backend. Changer de workspace avec terraform workspace select staging modifie le fichier state que Terraform lit et ecrit, mais la configuration reste identique.

La limitation : les workspaces partagent la meme configuration backend et la meme configuration des providers. L'isolation par repertoire offre des frontieres plus strictes, ou chaque environnement peut utiliser un compte AWS different, un backend state different, voire des versions de providers differentes. Pour les environnements reglementes exigeant un controle strict du rayon d'impact, l'isolation par repertoire est le choix le plus sur.

Providers, data sources et cycle de vie des ressources

Que sont les providers et comment les configurer ?

Les providers sont des plugins qui traduisent la configuration HCL en appels API vers des plateformes specifiques. Le provider AWS appelle l'API AWS, le provider Kubernetes communique avec le serveur API Kubernetes, et ainsi de suite.

# providers.tf
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.80"
    }
  }
}

provider "aws" {
  region = var.aws_region

  default_tags {
    tags = {
      Environment = var.environment
      ManagedBy   = "terraform"
      Team        = var.team_name
    }
  }
}

La contrainte de version ~> 5.80 autorise les mises a jour de patch (5.80.x) mais bloque les montees de version mineure, equilibrant stabilite et correctifs de securite. Le bloc default_tags applique un etiquetage coherent sur chaque ressource creee par le provider, un point de discussion frequent en entretien pour la gouvernance et l'allocation des couts.

Data sources versus ressources

Les ressources (blocs resource) creent, mettent a jour et suppriment de l'infrastructure. Les data sources (blocs data) lisent l'infrastructure existante sans la gerer.

# Data source - reads an existing AMI, does not create anything
data "aws_ami" "ubuntu" {
  most_recent = true
  owners      = ["099720109477"] # Canonical

  filter {
    name   = "name"
    values = ["ubuntu/images/hvm-ssd-gp3/ubuntu-noble-24.04-amd64-server-*"]
  }
}

# Resource - creates an EC2 instance using the data source
resource "aws_instance" "web" {
  ami           = data.aws_ami.ubuntu.id
  instance_type = "t3.micro"
}

Les data sources sont evalues pendant le plan, ce qui les rend utiles pour referencer une infrastructure partagee (VPC crees par une autre equipe), rechercher des valeurs dynamiques (derniers identifiants AMI) ou lire une configuration externe (parametres SSM, secrets Vault).

Sujets avances : import, moved blocks et tests

Comment fonctionne terraform import ?

terraform import associe une ressource cloud existante a un bloc resource Terraform. Le scenario typique : l'infrastructure a ete creee manuellement (ClickOps) ou par un autre outil, et l'equipe souhaite desormais que Terraform la gere.

Terraform 1.5+ a introduit les blocs import directement dans la configuration, remplacant le workflow exclusivement en ligne de commande :

# import.tf
import {
  to = aws_s3_bucket.legacy_data
  id = "my-legacy-bucket-name"
}

resource "aws_s3_bucket" "legacy_data" {
  bucket = "my-legacy-bucket-name"
}

Executer terraform plan avec ce bloc genere un plan qui adopte le bucket existant dans le state. Cette approche declarative de l'import est auditable dans les pull requests, reproductible, et ne necessite pas d'acces CLI direct au state.

Que sont les blocs moved ?

La refactorisation du code Terraform (renommer des ressources, les deplacer dans des modules) necessitait historiquement des commandes terraform state mv. Le bloc moved gere cela de maniere declarative :

# Renamed a resource from "web" to "app"
moved {
  from = aws_instance.web
  to   = aws_instance.app
}

Terraform reconnait le deplacement pendant le plan et met a jour le state automatiquement, evitant un cycle destruction-recreation. Cette fonctionnalite est precieuse lors de la restructuration de configurations volumineuses en modules.

Comment fonctionnent les tests Terraform ?

Terraform 1.6+ inclut un framework de tests natif utilisant des fichiers .tftest.hcl :

# tests/vpc.tftest.hcl
run "creates_vpc_with_correct_cidr" {
  command = plan

  assert {
    condition     = aws_vpc.main.cidr_block == "10.0.0.0/16"
    error_message = "VPC CIDR block does not match expected value"
  }
}

run "creates_three_private_subnets" {
  command = plan

  assert {
    condition     = length(aws_subnet.private) == 3
    error_message = "Expected 3 private subnets"
  }
}

Terraform 1.14 a etendu ce framework avec des blocs mock acceptant des fonctions, skip_cleanup pour debugger les tests echoues et des blocs backend au sein des blocs run pour un state de test isole. Les tests natifs eliminent le besoin d'outils externes comme Terratest pour les validations de base.

Terraform dans les pipelines CI/CD

A quoi ressemble un pipeline Terraform en production ?

Un pipeline CI/CD robuste pour Terraform impose des controles de securite a chaque etape :

1. Lint et validation : terraform fmt -check et terraform validate detectent les problemes de syntaxe.
2. Plan sur PR : chaque pull request execute terraform plan et publie le resultat en commentaire de PR. Aucun apply sans un plan revise.
3. Verifications de politiques : des outils comme OPA (Open Policy Agent), Sentinel (HCP Terraform) ou Checkov valident le plan par rapport aux politiques organisationnelles (pas de buckets S3 publics, chiffrement obligatoire, tags requis).
4. Apply au merge : apres approbation de la PR et validation des politiques, terraform apply s'execute automatiquement a partir du fichier plan sauvegarde.
5. Sauvegarde du state : apres l'apply, le pipeline verifie l'integrite du state et le versioning du backend capture la nouvelle version.

La regle d'or : aucun humain ne devrait jamais executer terraform apply sur la production depuis une machine locale. Tous les apply en production passent par le pipeline.

Conclusion

Points cles pour la preparation aux entretiens Terraform :

• La gestion du state est le sujet le plus determinant. Comprendre les backends distants, le verrouillage, le chiffrement et les strategies de reprise apres sinistre avant de se presenter en entretien.
• La conception de modules distingue les profils juniors des profils seniors. Demontrer la capacite a construire des modules reutilisables, versiones, avec des interfaces claires et une portee minimale.
• Maitriser le workflow plan/apply en profondeur. Expliquer pourquoi la sauvegarde des plans dans des fichiers est importante, comment le DAG determine l'ordre d'execution et ce que fait -target (et pourquoi son usage doit rester exceptionnel).
• Terraform 1.14 apporte les variables dans les sources de modules, des tests etendus et une integration HCP plus etroite. Mentionner les fonctionnalites actuelles demontre un engagement actif dans l'ecosysteme.
• Aborder le paysage Terraform vs OpenTofu avec honnetete. Comprendre la scission de licence, la divergence fonctionnelle et les cas d'usage de chaque outil demontre une maturite architecturale au-dela de la simple connaissance syntaxique.
• Reviser les fondamentaux des entretiens DevOps en parallele de Terraform, car les recruteurs melangent frequemment les questions IaC avec des sujets d'infrastructure plus larges.
• Explorer les concepts de deploiement Kubernetes puisque Terraform provisionne frequemment les clusters sur lesquels les workloads Kubernetes s'executent.