Pourquoi les gens ratent HashiCorp Terraform Associate (003)

L'examen pose : 'Tu lances terraform plan, il montre 5 ressources à supprimer que tu n'as PAS modifiées dans ton code — que s'est-il passé ?'. La bonne réponse demande de comprendre : (a) que le state local diverge du state distant, (b) que `terraform refresh` ou `terraform state list` peuvent diagnostiquer, (c) que `terraform import` réconcilie. Sans avoir vécu un state drift, tu réponds 'je ne sais pas'.

L'examen distingue très précisément : (a) le bloc `terraform { required_version = ">= 1.0" }` qui contraint la version du binaire Terraform, (b) le bloc `terraform { required_providers { aws = { source = "hashicorp/aws", version = "~> 5.0" } } }` qui déclare les providers + leurs versions, et (c) le bloc `provider "aws" { region = "..." }` qui configure une instance de provider. Confondre les trois te fait rater toutes les questions sur les contraintes de version.

L'examen demande : 'Quelle est la meilleure approche pour gérer dev / staging / prod ?'. La réponse 'workspaces' (terraform workspace new staging) est piégée — c'est juste pour des variations mineures du MÊME state. Pour de vrais environnements, la bonne pratique est : 1 répertoire par env avec backend séparé OU 1 module réutilisable instancié N fois. L'examen teste cette nuance.

Quand tu fais `terraform destroy -target=aws_instance.web`, Terraform supprime aussi tout ce qui DÉPEND de cette ressource (security groups attachés en exclusif, EIP, etc.) — pas l'inverse. L'examen teste si tu comprends la direction des dépendances et pourquoi `-target` est dangereux en prod (peut casser des ressources que tu n'avais pas l'intention de toucher).

Depuis l'exam 003, HashiCorp a augmenté la part dédiée à Terraform Cloud : workspaces TFC, VCS integration, Sentinel policies, runs UI vs CLI, private module registry. Si tu n'as utilisé que Terraform CLI avec backend S3, tu n'as jamais vu un workspace TFC ni un Sentinel policy.