HashiCorp Terraform Associate
Dernière révision : mai 2026
Une référence concise des modèles d'architecture évalués par l'examen 004. Lisez de haut en bas ou sautez à une section.
Une équipe clique manuellement dans les consoles cloud ; personne ne sait à quoi la production était censée ressembler.
Adopter l'IaC. Les configurations résident dans des fichiers versionnés — ces fichiers sont la source de vérité faisant autorité, pas la console cloud.
Pourquoi: La piste d'audit, la révision par les pairs, le rollback et la réplication découlent tous du contrôle de version. Le provisionnement manuel n'en a aucun.
Choisir entre décrire l'état final désiré et scripter les étapes pour l'atteindre.
Terraform est déclaratif. Vous décrivez la cible ; Terraform détermine les appels API. Ansible, les scripts Bash, les SDK personnalisés sont impératifs.
Pourquoi: Les configurations déclaratives sont idempotentes et convergent quel que soit l'état de départ. Les scripts impératifs doivent raisonner sur chaque transition.
L'ingénieur souhaite que le même `terraform apply` puisse être exécuté de nouveau en toute sécurité sans doubler les ressources.
Idempotent par conception. L'application répétée de la même configuration converge vers le même état — pas de doublons, pas de dérive.
Détecter quand la réalité a divergé de ce que dit la configuration (quelqu'un a cliqué dans la console).
`terraform plan -refresh-only` lit l'état actuel du cloud et signale les différences par rapport à l'état sans proposer de modifications.
Distinguer le provisionnement initial des opérations continues.
Jour 0 = conception et planification. Jour 1 = provisionnement initial (première application). Jour 2 = opérations continues : patchs, mise à l'échelle, rotation des certificats, remédiation de la dérive.
Pourquoi: La majeure partie du travail de production est le Jour 2. Les outils IaC doivent prendre en charge l'itération, pas seulement le premier déploiement.
Réduire le risque de dérive de la console ; exiger que toutes les modifications d'infrastructure passent par une révision.
GitOps avec IaC : git est la source de vérité, les PR déclenchent des plans, les merges déclenchent des apply. Bloquer l'accès direct à la console via SCP/IAM.
La charge de travail s'étend sur AWS et GCP ; l'équipe souhaite un seul outil, un seul flux de travail.
Terraform avec plusieurs providers dans une seule configuration : `hashicorp/aws` + `hashicorp/google`. Les sorties d'un provider alimentent les entrées d'un autre.
Pourquoi: Cœur agnostique aux providers ; les SDK spécifiques au cloud résident dans des providers enfichables. CloudFormation/ARM sont mono-cloud.
Étapes standard du cycle de vie de Terraform.
`init` (téléchargement des providers + backend) → `plan` (prévisualisation) → `apply` (exécution) → `destroy` (démolition). `plan` est en lecture seule et sûr.
Pourquoi Terraform a-t-il besoin d'un fichier d'état au lieu de toujours interroger le cloud à chaque exécution ?
L'état mappe les adresses de configuration (`aws_instance.web`) aux ID de ressources réels, suit les dépendances et met en cache les métadonnées. Sans cela, Terraform ne peut pas savoir quelles ressources cloud il gère et quelles ont été créées ailleurs.
Choisir entre la CLI open-source et HCP Terraform.
Solo / petite équipe / pas d'application de politique → CLI OSS avec backend distant. Équipes multiples / politiques Sentinel/OPA / exécutions pilotées par VCS / identifiants dynamiques → HCP Terraform.
Pourquoi: Les deux exécutent le même binaire Terraform ; HCP ajoute la collaboration, la gouvernance et l'infrastructure de runner distant.
Provisionner des VM vs configurer des logiciels à l'intérieur.
Terraform provisionne les ressources cloud (VM, réseaux, IAM). Ansible/Chef/Puppet configurent les logiciels à l'intérieur des VM. Ils sont complémentaires, pas concurrents.
Entreprise AWS uniquement débattant entre CloudFormation et Terraform.
CloudFormation offre une intégration AWS plus étroite, un rollback natif et aucune gestion de fichier d'état. Terraform l'emporte sur le multi-cloud, un écosystème de modules plus vaste et l'ergonomie HCL. Choisir CloudFormation si AWS-only et que le rollback est primordial ; Terraform autrement.
Épingler la source et la version du provider pour des installations reproductibles.
Déclarer dans `terraform { required_providers { aws = { source = "hashicorp/aws", version = "~> 5.0" } } }`.
Pourquoi: Sans `required_providers` explicites, Terraform suppose des espaces de noms de registre hérités et peut choisir des versions incompatibles.
La configuration a `required_providers` pour AWS mais pas de bloc `provider "aws"`.
Terraform crée une configuration de provider par défaut vide. Le provider AWS lit ensuite `AWS_ACCESS_KEY_ID`/`AWS_PROFILE`/IMDS selon sa précédence standard.
Pourquoi: Un bloc `provider` explicite est facultatif ; il n'est nécessaire que pour remplacer les valeurs par défaut ou aliaser plusieurs instances.
Décider quel opérateur de contrainte de version utiliser.
`~> 5.0` autorise `>= 5.0, < 6.0` (toute version 5.x). `~> 5.0.1` autorise `>= 5.0.1, < 5.1.0` (seulement les mises à jour de patch). `>= 5.0` sans borne supérieure. `= 5.2.0` exact. `!= 5.3.0` exclusion.
Pourquoi: L'opérateur pessimiste `~>` n'autorise la croissance que du composant de version le plus à droite.
Que fait réellement `terraform init` ?
Télécharge les providers selon `required_providers`, initialise le backend, télécharge les sources de modules et écrit `.terraform/` ainsi que `.terraform.lock.hcl`. Requis avant `plan` ou `apply`.
Un fichier `.terraform.lock.hcl` est apparu après `init`. Le committer ou l'ignorer avec gitignore ?
Committez-le. Le fichier de verrouillage enregistre les versions exactes des providers + les sommes de contrôle cryptographiques. Assure que chaque collaborateur et runner CI installe des providers identiques.
Pourquoi: Sans cela, `terraform init` peut choisir une version compatible plus récente sur une machine différente, introduisant des différences inattendues.
Standardiser les espaces blancs, l'alignement et l'indentation dans les fichiers `.tf`.
`terraform fmt` réécrit les fichiers `.tf` sur place selon un style canonique. Exécuter dans les hooks de pre-commit et en CI.
Détecter les erreurs de syntaxe et les incompatibilités de type sans interroger les API cloud.
`terraform validate` vérifie la syntaxe HCL, la cohérence des types, les arguments requis et les références internes. Local uniquement, aucune authentification de provider n'est nécessaire.
Pourquoi: Ne détecte pas les problèmes côté provider (authentification, ressources manquantes) — ceux-ci n'apparaissent qu'au `plan`.
La CI exécute `terraform init` de manière répétée sur de nombreux projets, chacun téléchargeant les mêmes providers à partir de zéro.
Définir `TF_PLUGIN_CACHE_DIR` (ou `plugin_cache_dir` dans la configuration CLI). Les providers sont téléchargés une seule fois et liés symboliquement dans les répertoires `.terraform/` de chaque projet.
Les adresses source des providers suivent quel format ?
`<hostname>/<namespace>/<type>` — par exemple `registry.terraform.io/hashicorp/aws`. Le nom d'hôte omis utilise par défaut le Registre Public Terraform. Namespace = fournisseur. Type = nom du provider.
Empêcher les collaborateurs d'exécuter une version CLI Terraform incompatible.
`terraform { required_version = ">= 1.5, < 2.0" }`. La CLI refuse de fonctionner si la version en cours d'exécution ne correspond pas.
Choisir l'authentification du provider pour un runner CI/CD.
Meilleur : identifiants dynamiques de courte durée (OIDC trust pour AWS/Azure/GCP, identifiants de provider dynamiques HCP Terraform). Acceptable : variables d'environnement (`AWS_ACCESS_KEY_ID`). À éviter : identifiants codés en dur dans le bloc `provider`.
Pourquoi: Les secrets statiques de longue durée dans la configuration sont la principale cause d'incidents de fuite d'identifiants.
Où résident les paramètres de haut niveau ?
Un bloc `terraform { ... }` contient `required_version`, `required_providers`, `backend`, `cloud` et les expérimentations. Plusieurs blocs `terraform` à travers les fichiers sont fusionnés.
La ressource existe dans l'état mais ne devrait plus être gérée par Terraform ; la ressource cloud doit continuer à fonctionner.
`terraform state rm <addr>`. Supprime de l'état sans détruire la ressource cloud.
Nom d'une ressource refactorisé ou déplacée dans un module ; veut éviter la destruction/recréation.
`terraform state mv <old> <new>`. Met à jour le mappage de l'état sans toucher aux ressources cloud.
Pourquoi: Dans Terraform 1.1+, préférer le bloc `moved` en HCL — il est révisable, contrôlé par version et fonctionne dans les plans de PR.
L'URL du registre de provider interne a changé ; l'état existant référence toujours l'ancienne adresse source.
`terraform state replace-provider <old-source> <new-source>`. Réécrit les références de provider dans l'état.
L'apply a crashé en cours d'exécution ; le verrou DynamoDB est bloqué et d'autres ingénieurs sont empêchés d'avancer.
`terraform force-unlock <LOCK_ID>` (l'ID de verrou est dans le message d'erreur). Vérifier que personne d'autre n'est en cours d'exécution avant de déverrouiller.
Pourquoi: Les verrous ne sont pas automatiquement libérés en cas de crash car la phase de nettoyage n'a jamais été exécutée.
Un bucket S3 existant créé manuellement doit être géré par Terraform sans recréation.
Écrire le bloc de ressource, puis `terraform import aws_s3_bucket.legacy legacy-bucket-name`. L'état enregistre maintenant le bucket existant ; les plans suivants n'afficheront que la dérive.
Besoin d'importer de nombreuses ressources de manière reproductible via la CI plutôt que par des commandes CLI ad-hoc.
Utiliser le bloc `import` (Terraform 1.5+) : `import { to = aws_s3_bucket.legacy, id = "legacy-bucket-name" }`. Les importations se produisent pendant `apply`, sont versionnées et fonctionnent dans la sortie du plan.
Déboguer une erreur de provider cryptique ; besoin de traces HTTP complètes.
`TF_LOG=TRACE` (le plus verbeux). `TF_LOG_PATH=./tf.log` écrit dans un fichier. Autres niveaux : DEBUG, INFO, WARN, ERROR.
Tester une expression comme `merge()` ou `cidrsubnet()` par rapport à l'état actuel sans l'appliquer.
`terraform console` ouvre une REPL interactive avec la configuration et l'état actuels dans le champ d'application. Utile pour prototyper des locals et des outputs.
Visualiser le DAG de dépendances d'une configuration complexe.
`terraform graph | dot -Tsvg > graph.svg` produit une visualisation Graphviz des dépendances de ressources.
Lire une sortie Terraform depuis un script CI.
`terraform output -json <name>` émet du JSON sûr pour l'analyse avec `jq`. `terraform output` sans option est formaté pour les humains et non sûr pour les scripts.
Forcer la recréation d'une seule ressource à la prochaine application.
`terraform apply -replace=aws_instance.web` (Terraform 1.x). La commande `terraform taint` héritée est obsolète.
Pourquoi: `-replace` est révisable dans la sortie du plan ; `taint` modifiait l'état silencieusement avant le plan suivant.
Inspecter ce qui est actuellement suivi dans l'état.
`terraform state list` affiche toutes les adresses de ressources. `terraform state show <addr>` affiche les attributs d'une ressource. Pour les ressources indexées, utiliser des guillemets : `terraform state show 'aws_instance.web[0]'`.
Choisir une source de module.
Chemin local → `./modules/vpc`. Registre public → `terraform-aws-modules/vpc/aws`. Git → `git::https://github.com/org/repo.git//path?ref=v1.0`. S3/HTTP/Mercurial également pris en charge.
Épingler un module de registre pour n'autoriser que les mises à jour de patch.
`version = "~> 3.5.2"` autorise `>= 3.5.2, < 3.6.0`. Pour la tolérance aux mises à jour mineures, utiliser `~> 3.0` (toute version 3.x). Les modules de chemin local ne prennent pas en charge `version`.
Modules internes uniquement avec une visibilité à l'échelle de l'organisation.
Registre de modules privés HCP Terraform. Adresse : `app.terraform.io/<org>/<name>/<provider>`. Versions détectées à partir des tags Git suivant semver (`v1.2.0`).
Le registre public et le registre privé HCP Terraform détectent les versions de modules via quel mécanisme ?
Tags Git suivant le versionnement sémantique (`v1.2.0` ou `1.2.0`). Pousser un nouveau tag → nouvelle version disponible.
Exposer l'ARN d'un bucket créé à la configuration appelante.
À l'intérieur du module : `output "bucket_arn" { value = aws_s3_bucket.this.arn }`. L'appelant le lit comme `module.<name>.bucket_arn`.
Paramétrer un module afin que les appelants puissent fournir CIDR, nom, tags.
Les blocs `variable` à la racine du module définissent les entrées. Les appelants les passent en ligne : `module "vpc" { source = "...", cidr = "10.0.0.0/16" }`.
Le module reçoit un mot de passe de base de données en entrée ; la valeur ne doit jamais apparaître dans la sortie de la CLI.
Marquer la variable `sensitive = true`. La sortie d'apply/plan affiche `(valeur sensible)`. Remarque : toujours stockée en clair dans l'état.
Construire un module "plateforme" qui appelle en interne des modules VPC + EKS + RDS.
Un module peut appeler d'autres modules. Relier les sorties de l'un comme entrées du suivant : `eks_subnet_ids = module.vpc.private_subnet_ids`.
Instancier le même module N fois avec des entrées différentes (par exemple, un par région).
`module "regional" { for_each = toset(["us-east-1", "eu-west-1"]), source = "...", region = each.key }`. Référence via `module.regional["us-east-1"].output_name`.
Le module a besoin d'un provider aliasé (par exemple, pour une région non par défaut).
L'appelant passe le bloc `providers = { aws = aws.us_west }` dans l'invocation du module. Le module déclare `configuration_aliases = [aws.us_west]` dans `required_providers`.
Adresser un module de registre public.
`<NAMESPACE>/<NAME>/<PROVIDER>` — par exemple `terraform-aws-modules/vpc/aws`. Les tags Git déterminent les versions.
Réutiliser le même module sur les environnements dev/staging/prod.
Deux modèles : (1) Workspaces avec une configuration racine + des fichiers `*.tfvars` par workspace. (2) Configurations racines par environnement (`envs/dev/main.tf`, `envs/prod/main.tf`) appelant chacune des modules partagés. Le modèle 2 est plus courant pour l'isolation multi-équipes.
S'assurer que la CI applique exactement ce qui a été examiné dans le plan, sans dérive entre les étapes.
`terraform plan -out=tfplan` enregistre le plan. Ensuite, `terraform apply tfplan` applique ce plan exact. Refuser de re-planifier élimine le risque de time-of-check/time-of-use.
Décoder les symboles de sortie du plan : `+`, `-`, `~`, `-/+`, `<=`.
`+` créer. `-` détruire. `~` mettre à jour sur place. `-/+` détruire puis créer (remplacer). `<=` lire (source de données). Le symbole de remplacement signifie qu'un attribut `forces replacement` a changé.
Réparer rapidement une ressource cassée sans toucher au reste de la configuration.
`terraform apply -target=aws_instance.web`. À utiliser avec parcimonie — contourne le suivi des dépendances et peut laisser l'état incohérent. Documenter pourquoi chaque `-target` a été utilisé.
Pourquoi: HashiCorp indique explicitement que `-target` est destiné au dépannage exceptionnel, et non au flux de travail normal.
Forcer la recréation d'une ressource spécifique.
`terraform apply -replace=aws_instance.web`. Remplace le workflow obsolète `terraform taint`.
Détruire tout ce qui est dans la configuration actuelle.
`terraform destroy` (ou `terraform apply -destroy`). Planifie l'inverse de la configuration. Nécessite une confirmation sauf si `-auto-approve`.
Détruire une ressource sans affecter les autres.
`terraform destroy -target=aws_instance.web`. Mêmes mises en garde que `-target` pour apply — à utiliser avec parcimonie.
Détecter la dérive sans proposer de modifications.
`terraform plan -refresh-only`. Actualise l'état à partir des ressources réelles et signale les différences mais ne génère aucun plan de modification de ressource.
Pourquoi: Remplace la commande `terraform refresh` autonome obsolète.
La ressource A doit exister avant la ressource B, mais B ne référence pas les attributs de A.
Ajouter `depends_on = [resource_a.name]` à B. À utiliser uniquement lorsque les références d'attributs implicites ne peuvent pas exprimer la dépendance (par exemple, une politique IAM doit se propager avant qu'EC2 ne l'utilise).
Remplacer une ressource sans interruption de service.
`lifecycle { create_before_destroy = true }`. Terraform crée d'abord la nouvelle ressource, redirige les références, puis détruit l'ancienne.
Pourquoi: La valeur par défaut est destroy-then-create, ce qui provoque une interruption. Remarque : les ressources dépendantes doivent également prendre en charge le changement.
Empêcher la destruction accidentelle de la base de données de production par `terraform destroy`.
`lifecycle { prevent_destroy = true }`. Entraîne l'échec de `terraform plan` si une destruction est proposée pour cette ressource.
Pourquoi: Garde-fou de dernière ligne — ne protège pas contre `terraform state rm` suivi d'un destroy.
L'application définit un tag à l'exécution que Terraform ne cesse de réinitialiser.
`lifecycle { ignore_changes = [tags["LastDeployed"]] }`. Terraform ignore la dérive sur ces attributs.
Remplacer une instance EC2 chaque fois qu'un launch template associé change (sans modifier l'EC2 directement).
`lifecycle { replace_triggered_by = [aws_launch_template.web.latest_version] }` (Terraform 1.2+). L'instance est remplacée lorsque l'une des valeurs listées change.
Le pipeline CI/CD s'applique après un job de plan réussi ; pas d'humain au clavier.
`terraform apply -auto-approve` ignore la confirmation interactive. À combiner avec un fichier de plan enregistré (`terraform apply tfplan`) pour rendre la CI déterministe.
Le fournisseur cloud limite le débit de Terraform ; de nombreuses créations de ressources échouent par intermittence.
`terraform apply -parallelism=5` (par défaut 10) limite les opérations de ressources concurrentes.
Deux ressources n'ont aucune dépendance l'une envers l'autre.
Terraform les crée en parallèle. Le DAG n'applique le séquençage que le long des arêtes de référence.
Pourquoi: Les ressources à la même profondeur du DAG s'exécutent concurremment jusqu'à `-parallelism`.
Variable définie dans `terraform.tfvars`, variable d'environnement `TF_VAR_region`, ET drapeau CLI `-var=region=...`.
Le plus prioritaire l'emporte : CLI `-var` / `-var-file` > `*.auto.tfvars` (ordre lexical) > `terraform.tfvars` > `TF_VAR_*` env > valeur par défaut de la variable.
Passer des valeurs de variables spécifiques à l'environnement sans enregistrer les secrets dans Git.
`terraform apply -var-file=prod.tfvars`. Les fichiers `*.auto.tfvars` se chargent automatiquement. `terraform.tfvars` se charge également automatiquement.
Refactoriser le nom/chemin d'une ressource en HCL sans destruction/recréation.
`moved { from = aws_instance.old_web; to = aws_instance.new_web }` (Terraform 1.1+). Révisable dans le plan de PR ; remplace `terraform state mv` ad-hoc.
Pourquoi: Réside en HCL, versionné, idempotent entre collaborateurs. `state mv` est un effet de bord CLI à usage unique.
Supprimer une ressource de la configuration sans la détruire.
`removed { from = aws_instance.legacy; lifecycle { destroy = false } }` (Terraform 1.7+). Remplace `terraform state rm` ad-hoc. Définir `destroy = true` pour aussi détruire.
La CI doit savoir si un plan contient des modifications sans analyser le texte.
`terraform plan -detailed-exitcode`. 0 = pas de modifications, 1 = erreur, 2 = modifications présentes. Pilote les jobs de PR "plan-only".
Que contient réellement l'état ?
Mappage adresse de ressource → ID de ressource cloud, instantanés d'attributs, métadonnées du graphe de dépendance et références de module/provider. Utilisé pour planifier les différences et détecter la dérive.
Un seul ingénieur qui prototype localement — l'état local est-il acceptable ?
Oui pour un travail solo jetable. Terraform écrit `terraform.tfstate` à côté de la configuration. Passer à un backend distant dès qu'une deuxième personne, un runner CI ou un environnement de production est impliqué.
Une équipe a besoin d'un état partagé entre les ingénieurs, avec verrouillage + versionnement, hébergé sur AWS.
Backend S3. Configurer `bucket`, `key`, `region`. Ajouter `dynamodb_table` pour le verrouillage de l'état. Activer le versionnement du bucket + le chiffrement côté serveur SSE-KMS.
Pourquoi: S3 + DynamoDB est le backend distant canonique hébergé sur AWS. Le versionnement permet de récupérer un état corrompu ou écrasé accidentellement.
État partagé hébergé sur Azure sans identifiants statiques en CI.
Type de backend `azurerm`. Définir `use_msi = true` (Managed Identity) ou `use_oidc = true` pour que le runner s'authentifie via son identité. Le lease de blob natif gère le verrouillage.
État partagé hébergé sur GCP avec versionnement d'objets.
Type de backend `gcs`. Configurer `bucket` + `prefix`. GCS dispose de générations d'objets intégrées (versionnement) ; verrouillage via GCS object lock.
Deux ingénieurs exécutent `apply` simultanément sur le même état sauvegardé sur S3.
La table de verrouillage DynamoDB empêche les écritures concurrentes. Le premier acquiert le verrou, le second voit une erreur `state lock failed` et doit attendre ou `force-unlock` si le verrou est obsolète.
Pourquoi: Sans DynamoDB, les applies concurrents peuvent corrompre le fichier d'état S3.
HCP Terraform — dois-je configurer DynamoDB ?
Non. HCP Terraform gère l'état, le verrouillage et le chiffrement nativement. Il suffit de déclarer `cloud { ... }` au lieu d'un backend.
Migrer de l'état local vers le backend S3.
Ajouter le bloc `backend "s3"`. Exécuter `terraform init -migrate-state`. Terraform copie l'état local vers S3 et demande confirmation.
La configuration du backend a changé (par exemple, nouveau bucket) mais vous ne voulez pas migrer l'état existant.
`terraform init -reconfigure`. Réinitialise le backend et ignore le cache local existant. À utiliser lorsque vous démarrez intentionnellement à neuf.
Gérer dev / staging / prod avec une seule configuration racine.
Workspaces — `terraform workspace new staging`, `terraform workspace select prod`. Chacun a son propre fichier d'état. Référence via `terraform.workspace` en HCL.
Pourquoi: Option légère. Pour une véritable isolation (IAM différents, comptes séparés), préférer des configurations racines par environnement.
Où le backend local stocke-t-il l'état des workspaces ?
Workspace `default` → `terraform.tfstate` dans la racine du projet. Autres workspaces → `terraform.tfstate.d/<NAME>/terraform.tfstate`.
Exécuter `terraform workspace select prod` alors que des ressources de staging existent.
Les ressources de staging ne sont pas affectées. Le changement de workspace modifie uniquement le fichier d'état que Terraform lira ensuite — c'est un changement de pointeur local.
Voir les workspaces disponibles et celui qui est actif.
`terraform workspace list` (l'astérisque marque le courant). `terraform workspace show` imprime uniquement le nom actuel.
L'équipe de sécurité demande comment Terraform gère les mots de passe RDS dans l'état.
Les valeurs sensibles sont stockées en **texte clair** dans l'état. Mesures d'atténuation : chiffrer le backend au repos (S3 SSE-KMS, HCP natif), restreindre l'accès IAM au bucket d'état et éviter de placer des secrets dans Terraform lorsque cela est possible.
Pourquoi: Le flag `sensitive = true` ne fait que masquer les valeurs de la sortie CLI, pas de l'état.
La conformité exige le chiffrement au repos de l'état.
S3 : activer SSE-KMS sur le bucket. Azure : chiffrement du compte de stockage (ON par défaut). GCS : clés de chiffrement gérées par le client. HCP Terraform : chiffré nativement au repos.
Un ingénieur a exécuté `terraform destroy` sur la production par erreur. L'état est maintenant vide.
Restaurer la version précédente du fichier d'état à partir du versionnement S3, puis exécuter `terraform plan` pour voir ce que Terraform pense maintenant devoir être créé/importé. Combiner avec une restauration côté cloud (snapshots, `aws backup`) pour les ressources détruites.
Le fichier d'état semble incorrect ; tenté de l'éditer directement.
Ne le faites pas. Utilisez les sous-commandes `terraform state` (`mv`, `rm`, `replace-provider`, `pull`, `push`). Les modifications manuelles du JSON ignorent les vérifications d'intégrité et corrompent la lignée.
Inspecter le JSON de l'état distant brut, ou pousser un fichier d'état récupéré.
`terraform state pull` écrit l'état distant actuel sur stdout. `terraform state push <file>` écrase l'état distant avec le fichier donné. Le push est destructeur — sauvegardez d'abord.
Transmettre un token API temporaire via Terraform sans qu'il n'atterrisse dans l'état.
Marquer la variable `ephemeral = true` (Terraform 1.10+). Les valeurs éphémères ne sont jamais persistées dans les fichiers d'état ou de plan. Pour les exporter via une sortie de module, marquer également la sortie `ephemeral = true`.
Pourquoi: `sensitive` est masqué dans la CLI mais stocké en texte clair dans l'état. `ephemeral` n'est jamais stocké.
Différence entre un argument `sensitive` et un argument en écriture seule (par exemple `password_wo`).
`sensitive` est stocké en texte clair dans l'état, seulement masqué dans la CLI. L'écriture seule n'est **jamais** stockée dans l'état. Pour détecter les changements sur les attributs en écriture seule, Terraform utilise un champ de version compagnon (par exemple `password_wo_version`).
Afficher un élément d'une ressource `count` dans l'état.
Mettre l'adresse entre guillemets : `terraform state show 'aws_instance.web[0]'`. Sans guillemets, le shell peut interpréter les crochets.
Différentes équipes doivent fonctionner indépendamment sans empiéter sur l'état des autres.
Un fichier d'état par équipe (ou par environnement par équipe). Backends/buckets séparés. Utiliser la source de données `terraform_remote_state` pour lire un autre état en lecture seule.
L'équipe réseau gère le VPC ; l'équipe d'application a besoin de l'ID du VPC.
`data "terraform_remote_state" "network" { backend = "s3"; config = { bucket = "...", key = "network/terraform.tfstate" } }`. Référencer les sorties comme `data.terraform_remote_state.network.outputs.vpc_id`.
Pourquoi: Lecture seule — l'état de l'équipe réseau n'est ni verrouillé ni modifié.
Configuration écrite pour Terraform 0.13 ; veut utiliser 1.x.
Les fichiers d'état sont rétrocompatibles : 1.x lit l'état 0.13. HashiCorp recommande des mises à niveau incrémentielles (0.13 → 0.14 → … → 1.x) en exécutant chaque version sur l'état.
Quelqu'un a modifié un groupe de sécurité via la console ; veut que Terraform réaffirme ou accepte le nouvel état.
Réaffirmer : `terraform apply` — Terraform revient à la configuration. Accepter : mettre à jour le HCL pour qu'il corresponde à la réalité, puis appliquer (pas de diff). Détecter d'abord via `terraform plan -refresh-only`.
Fortement typer une variable.
Primitives : `string`, `number`, `bool`. Collections : `list(<type>)`, `set(<type>)`, `map(<type>)`. Structurelles : `object({...})`, `tuple([...])`. Utiliser `any` uniquement si véritablement polymorphe.
Restreindre `environment` à dev/staging/prod.
`variable "environment" { validation { condition = contains(["dev","staging","prod"], var.environment); error_message = "..." } }`. Plusieurs blocs `validation` sont autorisés ; tous doivent passer.
Sortir un mot de passe de base de données sans qu'il n'apparaisse dans `terraform output`.
`output "db_password" { value = ...; sensitive = true }`. La CLI affiche `(valeur sensible)`. Toujours lisible via `terraform output db_password` ou `-json` (intentionnellement — pour les scripts).
Calculer une valeur une fois et la réutiliser sur de nombreuses ressources.
`locals { common_tags = merge(var.tags, { Project = var.project }) }`. Référencer comme `local.common_tags`. Non surchargeable depuis l'extérieur du module.
Rechercher une AMI existante sans la gérer.
`data "aws_ami" "ubuntu" { most_recent = true; filter { ... } }`. Lecture seule. Référencer les attributs comme `data.aws_ami.ubuntu.id`.
Créer N ressources similaires — choisir `count` ou `for_each`.
`for_each` (avec map ou set) lorsque les éléments ont une identité stable (noms de régions, clés d'environnement). `count` pour "J'ai besoin de N copies, l'ordre n'a pas d'importance, l'identité est juste un index". L'ajout/suppression au milieu de `count` provoque une destruction/recréation ; `for_each` préserve l'identité.
Créer une ressource par élément dans une liste de chaînes.
`for_each = toset(["a", "b", "c"])`. `each.key` et `each.value` donnent tous deux la chaîne. Pour les maps : `for_each = var.users` — `each.key` = clé de map, `each.value` = valeur de map.
Générer un nombre variable de blocs imbriqués (par exemple, règles d'ingress).
`dynamic "ingress" { for_each = var.rules; content { from_port = ingress.value.from; ... } }`. L'argument `iterator` peut renommer l'itérateur si nécessaire.
Obtenir une liste d'attributs pour toutes les instances d'une ressource `count`.
`aws_instance.web[*].id` renvoie une liste d'ID. Fonctionne avec `count` et `for_each` (mais `for_each` produit une map non ordonnée, donc `values(aws_instance.web)[*].id`).
Définir une valeur en fonction d'une condition.
Ternaire : `var.is_prod ? 5 : 1`. Les deux branches doivent produire le même type.
Combiner deux maps ; les valeurs du second l'emportent en cas de collision de clés.
`merge(local.defaults, local.overrides)`. La map la plus à droite l'emporte. Utile pour la composition de tags.
Lire une valeur de map avec une valeur par défaut si la clé est manquante.
`lookup(var.config, "region", "us-east-1")`. Retourne la valeur par défaut si la clé n'est pas présente. Pour les structures profondément optionnelles, préférer la fonction optionnelle `try()`.
Aplatir les listes imbriquées en une liste simple.
`flatten([["a","b"], ["c"], [["d","e"]]])` → `["a","b","c","d","e"]`. Aplatit récursivement les listes ; préserve l'ordre.
Intégrer une map Terraform dans un document de politique IAM.
`jsonencode({Version = "2012-10-17", Statement = [...]})`. Produit une chaîne JSON. Inverse : `jsondecode()`.
Rendre un script user-data templatisé avec des valeurs provenant de variables.
`templatefile("init.sh.tpl", { region = var.region, env = var.env })`. Le template utilise la syntaxe `${region}`. Alternative plus récente pour le rendu statique : `file()` + `format()`.
Découper les CIDR de sous-réseaux à partir d'une plage de VPC.
`cidrsubnet("10.0.0.0/16", 8, 0)` → `10.0.0.0/24`. Premier argument = parent, deuxième = bits à étendre, troisième = numéro de sous-réseau.
Lire une valeur qui pourrait ne pas exister ; revenir à une valeur par défaut.
`try(yamldecode(file("config.yaml")), { defaults = true })`. Évalue de gauche à droite ; retourne la première expression sans erreur.
Itérer sur les fichiers correspondant à un glob.
`fileset(path.module, "configs/*.json")` retourne un ensemble de chemins. À combiner avec `for_each` pour gérer une ressource par fichier.
Même provider dans deux régions (par exemple, AWS us-east-1 + us-west-2).
Deux blocs `provider "aws" { alias = "..." }`. Les ressources optent via `provider = aws.us_west`. Les modules acceptent les alias via `configuration_aliases`.
Exécuter une commande shell sur une VM nouvellement créée.
Provisioner `remote-exec` à l'intérieur d'une ressource. Outil de dernier recours — préférer cloud-init, user data, ou la gestion de configuration. Les provisioners ne sont pas suivis dans l'état et ne se réexécutent pas en cas de dérive.
Exécuter une commande qui ne correspond pas à une ressource cloud (par exemple, invocation CLI).
`resource "null_resource" "trigger" { triggers = { sha = sha1(file(".")) }; provisioner "local-exec" { command = "..." } }`. Se réexécute lorsque les `triggers` changent.
Vérifier en continu un invariant d'exécution (par exemple, un endpoint de santé retourne 200) sans bloquer l'apply.
`check "endpoint" { data "http" "h" { url = "..." }; assert { condition = data.http.h.status_code == 200; error_message = "..." } }`. S'exécute lors du plan/apply ; l'échec est un avertissement, pas une erreur bloquante.
Pourquoi: `check` autorise des sources de données locales utilisables uniquement à l'intérieur du check. `precondition`/`postcondition` sont des erreurs bloquantes au plan/apply.
Faire échouer le plan si une AMI est trop ancienne.
`lifecycle { precondition { condition = data.aws_ami.x.creation_date > "2024-01-01"; error_message = "..." } }`. Échec bloquant, évalué avant/après selon le cas.
Variable avec une valeur positionnelle de forme fixe.
`type = tuple([string, number, bool])` exige exactement trois éléments dans cet ordre. Différent d'une liste (homogène, longueur variable).
Fortement typer une entrée structurée (par exemple `database = { instance_class = string, allocated_storage = number }`).
`type = object({ instance_class = string, allocated_storage = number, multi_az = optional(bool, false) })`. `optional(<type>, <default>)` rend les attributs optionnels.
Comment les fichiers `*.tfvars` sont-ils chargés ?
`terraform.tfvars` et `*.auto.tfvars` se chargent automatiquement (ordre lexical pour `auto`). D'autres noms nécessitent `-var-file=path.tfvars`.
Écrire des tests automatisés pour un module Terraform.
Fichiers `.tftest.hcl` avec `run "name" { command = plan|apply, assert { condition = ..., error_message = ... } }`. `command = plan` est sans effets secondaires ; `command = apply` crée réellement des ressources.
Passer des variables dans les exécutions de test.
Le bloc `variables { ... }` au niveau du fichier s'applique à toutes les exécutions. Le bloc `variables { ... }` par exécution surcharge pour cette exécution uniquement.
Choisir un mode d'exécution de workspace dans HCP Terraform.
Piloté par VCS (auto-plan sur push Git, le plus courant). Piloté par CLI (le développeur exécute `terraform plan/apply` localement, HCP détient l'état). Piloté par API (exécutions Terraform déclenchées par API, utilisées par les systèmes d'automatisation/CD).
Ordre des étapes dans une exécution HCP Terraform.
plan → estimation des coûts (si activée) → vérification des politiques (Sentinel/OPA) → apply manuel ou automatique. Les échecs de politique obligatoires ou les échecs de tâche d'exécution arrêtent le pipeline.
Appliquer que tous les buckets S3 sont chiffrés, bloquant l'apply en cas de violation.
Politique Sentinel avec application obligatoire stricte. Inspecte le plan ; l'échec bloque l'apply. Le mode soft-mandatory permet la dérogation par l'administrateur. Le mode consultatif loggue mais ne bloque jamais.
Intégrer un scanner de sécurité tiers dans le pipeline d'exécution HCP Terraform.
Exécuter la tâche à l'étape post-plan. HCP POSTe le plan à votre endpoint ; l'endpoint répond pass/fail. L'application obligatoire bloque l'apply en cas d'échec ; le mode consultatif ne fait que prévenir.
Afficher l'impact d'une pull request avant de la fusionner.
Les plans spéculatifs s'exécutent sur les PR (ou branches), renvoient les résultats à la PR sous forme de commentaires, et ne sont jamais appliqués. Déclenchés automatiquement lorsque l'intégration VCS est activée.
Éviter de stocker les clés d'accès AWS comme secrets statiques dans les variables HCP Terraform.
Identifiants de provider dynamiques. HCP Terraform demande des identifiants de courte durée via la confiance OIDC à AWS/Azure/GCP. Pas de clés statiques ; identités par exécution ; auditables.
Pourquoi: Les clés statiques fuient. La confiance OIDC lie les identifiants au workspace + exécution, expire dans l'heure.
Partager les mêmes identifiants de provider entre plusieurs workspaces.
Ensembles de variables. Définir une fois au niveau de l'organisation/du projet, attacher à plusieurs workspaces. Les mises à jour se propagent sans éditions par workspace.
Qu'est-ce que le projet par défaut dans HCP Terraform ?
Un projet intégré qui existe dans chaque organisation et ne peut pas être supprimé (le renommage est autorisé). Tous les workspaces lui appartiennent à moins d'être explicitement assignés à un autre projet.
Appliquer le workspace aval chaque fois qu'un workspace amont termine un apply réussi.
Déclencheurs d'exécution. Configurer le(s) workspace(s) source(s) sur le workspace dépendant ; HCP met en file d'attente une exécution sur le dépendant après chaque apply amont réussi.
