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.