Comment organisez-vous le CI/CD Terraform : fmt, validate, plan, apply ?

Questions d’entrevue Terraform

Intermédiaireci-cdworkflow

L’ordre n’est pas cosmétique

  • terraform fmt -check : le diff HCL reste lisible. Ce n’est pas de la qualité « nice to have » : un plan illisible se fait approuver les yeux fermés.
  • terraform validate : graphe et types, sans credentials complets parfois. Ça attrape l’erreur stupide avant le refresh coûteux.
  • terraform plan -out=… : le seul artefact qu’un humain approuve. Commentaire de PR pour le plan spéculatif ; artefact privé pour le plan d’apply.
  • terraform apply planfile : exécute ce plan, pas un nouveau calcul silencieux. HashiCorp documente ce couple pour une raison.

La PR n’applique pas la prod. L’apply est un job de la branche protégée, souvent manuel (environment GitHub, fenêtre, deux paires d’yeux). Les credentials : OIDC vers le cloud, pas de clé statique dans les variables.

Ce que l’intervieweur écoute

« Init, plan, apply » sans fmt/validate ni plan file : junior qui a fait le tutoriel. Senior : lock file commité, versions CLI épinglées dans le runner, backend distant, pas d’apply concurrent (un pipeline par state), et le refus du apply -auto-approve sur un root destructif.

La relance probable

« Pourquoi pas apply à chaque merge ? »

Parce qu’un merge peut être un revert, un conflict mal résolu, ou un module bump. L’humain lit les moins. L’auto-approve se discute pour un sandbox. En prod, c’est un choix de risque explicite, pas un défaut GitHub Actions recopié.

Toutes les questions Terraform