61 labs pratiques pour préparer le HashiCorp Certified: Terraform Associate (003/004), soit environ 41 heures de travail, chacun noté sur l'état réel de votre machine et non sur les commandes tapées. Ils se jouent chez vous avec la ligne de commande `dsoxlab`, et ne coûtent rien.
Un examen à questions, pas un examen pratique : il porte sur le vocabulaire, le cycle de vie des ressources, le state et les modules. Les labs servent à comprendre ce que les questions décrivent.
- 61labs
- 41heures de pratique
Niveaux 15 débutant 42 intermédiaire 4 avancé
Objectifs officiels de l'examen publiés par HashiCorp
Ce ne sont pas des questions d'examen. Ce sont des exercices pratiques sur les compétences que l'examen mesure, notés sur l'état de votre machine.
Terraform, Associate et Professional
Ajouter ce catalogue dsoxlab catalog add https://github.com/stephrobert/terraform-dsoxlab-training
Découvrir Terraform
-
Prouver que Terraform a une mémoire
Un débutant croit que Terraform relit ses fichiers `.tf` et interroge l'infrastructure à chaque commande, le state n'étant qu'un cache accessoire. Démontez cette idée sur une configuration purement locale : prouvez qu'une seconde application ne change rien, qu'une dérive provoquée hors de Terraform est détectée sans perdre l'identité des ressources intactes, qu'une donnée seulement lue n'est pas une ressource gérée, et qu'un objet que personne n'a déclaré reste invisible.
dsoxlab start getting-started-terraform-overview -
Prouver l'idempotence là où le script impératif diverge
Un script de provisionnement est fourni, et il diverge dès qu'on le rejoue : un identifiant différent à chaque appel, un rapport qui s'empile au lieu d'être remplacé. Obtenez le même résultat en Terraform, puis établissez par le plan qu'un second passage est un non-événement, et corrigez une dérive externe sans toucher à votre code.
dsoxlab start getting-started-declarative-vs-imperative -
Prouver la compatibilité Terraform / OpenTofu, et où elle s'arrête
« Les deux outils sont compatibles » se répète partout et personne ne le vérifie. Rendez une configuration portable en déclarant la source et la contrainte de version de chaque provider, puis établissez par l'état structuré que les deux binaires lisent le même state, résolvent les mêmes versions sur deux registres différents, et que le fichier de verrouillage est exactement l'endroit où la portabilité s'arrête.
dsoxlab start getting-started-terraform-vs-opentofu -
Contraindre la version de la CLI et verrouiller les providers
Installer le binaire ne prouve presque rien. Contraignez la version de la CLI depuis la configuration elle-même, épinglez les trois providers, faites refuser une contrainte impossible, et prouvez que le verrou fait autorité : effacez `.terraform/`, relancez `init`, les versions retenues ne doivent pas bouger.
dsoxlab start getting-started-install-terraform -
Mettre d'accord fmt, validate et les outputs
Trois défauts sont posés : un fichier hors format canonique, une référence orpheline qui fait échouer `validate`, et des outputs absents. Corrigez les trois sans changer ce que la configuration produit, puis prouvez qu'une expression se recalcule hors du state.
dsoxlab start getting-started-cli-terraform -
Lire un plan avant de l'appliquer
Une configuration déjà appliquée doit évoluer. Avant de toucher quoi que ce soit, dites lesquelles de ses ressources seront modifiées en place et lesquelles seront détruites puis recréées. La sortie humaine du plan annonce les deux cas dans le même bloc de texte : la seule lecture fiable est le champ des actions du plan converti en JSON. Appliquez ensuite exactement le plan que vous avez relu, depuis un plan enregistré.
dsoxlab start getting-started-terraform-workflow -
Ce que Terraform gère, ce qu'il se contente de lire
Un mot sépare les deux natures de blocs : `resource` crée et gère, `data` lit. Le prouver dans le champ `mode` du state, puis constater les deux conséquences : un `destroy` ne touche pas ce qu'il n'a pas créé, et une data source est relue à chaque plan.
dsoxlab start getting-started-providers-resources-data-sources -
Découper un monolithe sans bouger le plan
Le nom des fichiers n'a aucun effet fonctionnel : Terraform lit tous les `.tf` comme un seul document. Découper un monolithe en six fichiers thématiques et prouver, en comparant deux plans JSON, que rien n'a changé. Puis constater quelle source de valeur l'emporte.
dsoxlab start getting-started-terraform-project-structure
Premières infrastructures
-
Première infrastructure : le cycle complet, prouvé
Déroulez le cycle Terraform sur une ressource RÉELLE plutôt que de le réciter, et découvrez au passage que `~> 0.8` n'interdit pas `0.9.x` : l'opérateur pessimiste incrémente le composant le plus à droite, et la branche 0.9 a réécrit le schéma des ressources.
dsoxlab start first-infra-first-infrastructure -
Variables, locals et l'ordre de précédence réel
Quatre marches, vérifiées dans l'ordre : `default`, `TF_VAR_`, `terraform.tfvars`, `*.auto.tfvars`, `-var`. La décisive est la deuxième : un fichier de valeurs BAT la variable d'environnement, rang que presque tout le monde place trop haut.
dsoxlab start first-infra-variables-outputs -
La dépendance que Terraform ne peut pas deviner
Terraform construit son graphe à partir des RÉFÉRENCES qu'il trouve dans les expressions. Neuf fois sur dix, un `depends_on` écrit à la main signale une référence manquante. Ce lab porte sur la dixième : un bloc qui consomme une variable et ne référence rien, où Terraform est libre d'agir dans le mauvais ordre.
dsoxlab start first-infra-virtual-network -
Mise à jour en place ou remplacement : le lire dans le plan
Sur une machine virtuelle, certains attributs se modifient en place et d'autres détruisent puis recréent la machine. Le plan dit lequel, avant l'apply, à condition de savoir où regarder. Vérifiez ensuite que le plan disait vrai, en l'appliquant.
dsoxlab start first-infra-vm-libvirt -
Produire un inventaire Ansible depuis le state
Terraform sait ce qu'il a créé ; Ansible doit le savoir aussi. Construisez le pont, et rendez-le FIABLE plutôt que seulement fonctionnel : une variable typée, des adresses calculées par une fonction HCL, un fichier sérialisé, et un inventaire qui disparaît avec le parc qu'il décrit.
dsoxlab start first-infra-ansible -
Reprendre après un apply qui a échoué, sans refaire le travail
Un apply qui échoue en cours de route laisse un state PARTIEL. Ce n'est pas un accident à effacer : c'est le point de départ de la réparation. Corrigez la cause dans la configuration, et prouvez que les ressources déjà créées ont gardé leurs identifiants.
dsoxlab start first-infra-debug-apply -
Détruire proprement, et les quatre choses que cela recouvre
Détruire n'est pas une seule opération. Constatez-en quatre qui ne se ressemblent pas : le destroy global qu'un garde-fou peut REFUSER, le destroy ciblé, le retrait d'une ressource DU CODE, et le destroy complet qui vide le state sans supprimer son fichier.
dsoxlab start first-infra-clean-destroy
Écrire du code Terraform
-
Source explicite et alias de provider
Déclarer les providers correctement : une adresse source explicite qui se résout en registry.terraform.io/hashicorp/random, une seconde configuration du même provider distinguée par un alias, et une ressource rattachée avec provider =. Prouvé par version -json et le provider_config du plan JSON. Associate 5b.
dsoxlab start write-code-providers -
Lire le cycle de vie d'une ressource dans le plan
Construire quatre ressources ordonnées par les seules références, puis prouver dans le plan JSON les quatre opérations du cycle de vie : mise à jour en place, remplacement, création avant destruction, et destruction. Sous-objectif Pro 1c.
dsoxlab start write-code-declare-resources -
Variables, typage, validation et précédence
Typer correctement les variables et maîtriser leurs pièges : une map d'objets avec des defauts optional(), une validation qui rejette avant tout provider, un null explicite qui retombe sur le defaut avec nullable=false, la vraie précédence des sources (auto.tfvars au-dessus de TF_VAR_, -var au-dessus de tout), et sensitive comme masque d'affichage, pas comme protection du state. Associate 2e et 2f.
dsoxlab start write-code-variables -
Le secret que l'output ne cache pas
Maîtriser le vrai bloc output : une contrainte de type (object), la propagation de la sensibilité (un output qui référence un secret doit être sensible, et sensitive n'est qu'un masque d'affichage, le clair reste dans le state, -json et -raw), nonsensitive() pour exposer un hash volontairement, et un precondition qui bloque le plan. Associate 2e et 2f.
dsoxlab start write-code-outputs -
Le local qui ne se calcule pas au plan
Centraliser les expressions dans des blocs locals : normaliser par des fonctions HCL, garder un ternaire typé, générer une liste par expression for, dériver d'un attribut de ressource (inconnu au plan), et hériter de la sensibilité d'une variable. Sous-objectif Pro 2c.
dsoxlab start write-code-locals -
À quel moment Terraform lit-il une data source ?
Construire trois data sources dont le moment de lecture est délibéré : l'une lue pendant le plan, l'autre reportée à l'apply parce que la ressource dont elle dépend change, la troisième portant un depends_on explicite qui ne la reporte PAS. Prouver chaque cas dans le plan JSON. Sous-objectif Pro 2b.
dsoxlab start write-code-data-sources -
Ce que les expressions calculent vraiment
Écrire des expressions Terraform correctes : référencer une ressource gérée sans préfixe, savoir que == ne convertit pas les types (3 n'est pas "3") alors que l'arithmétique convertit, respecter la précédence des opérateurs, et utiliser null pour omettre un argument plutôt qu'une chaîne vide. Associate 2e.
dsoxlab start write-code-expressions -
Composer des valeurs avec les fonctions HCL
Dedupliquer une collection pour for_each, maitriser element() hors bornes, le repli de lookup(), l'arrondi de ceil(), l'echappement des templates et une fonction de provider. Objectif Pro 2c.
dsoxlab start write-code-functions -
La configuration qui refuse les valeurs absurdes
Calculer des valeurs par expression conditionnelle, puis placer chaque garde au bon niveau : validation, precondition, postcondition et bloc check. Objectif Pro 2a.
dsoxlab start write-code-conditionals -
Conditions personnalisées : precondition, postcondition et blocs check
Valider une configuration avec les fonctionnalités du langage prévues pour cela. Objectif Pro 2a.
dsoxlab start write-code-validation-check-preconditions -
count indexé par position, et la position ment
Choisir count ou for_each pour chaque ressource et le prouver : indexer un ensemble par nom avec for_each, migrer une ressource count vers for_each sans rien detruire grace aux blocs moved, garder count pour des copies interchangeables, et exposer une ressource conditionnelle avec one(). Objectif Associate 4b et la migration moved du niveau Professional.
dsoxlab start write-code-count -
Ajouter une instance sans détruire les autres
Migrer count vers for_each avec des blocs moved sur une configuration deja appliquee, puis ajouter un service en prouvant zero destruction. Objectif Pro 2d.
dsoxlab start write-code-for-each -
Transformer un catalogue avec les expressions for
Dériver quatre collections depuis une seule map de serveurs avec des expressions for : un tuple filtré, un objet groupé par rôle via l'ellipsis, un croisement à deux niveaux aplati, et un for_each filtré. Éviter le piège du splat sur une map. Sous-objectif Pro 2c.
dsoxlab start write-code-for-loops -
Générer des blocs, et savoir ne pas le faire
Générer des parties cloudinit avec un bloc dynamic filtré dans le for_each et nommé depuis la clé, garder la partie fixe littérale, et buter sur le mur : un bloc de méta-arguments lifecycle ne se génère pas par dynamic. Sous-objectif Pro 2d.
dsoxlab start write-code-dynamic-blocks -
depends_on ne se pose que là où une référence ne peut aller
Supprimer un depends_on redondant qu'une référence couvre déjà, remplacer un chemin en dur par une référence, garder le seul depends_on qu'aucune référence ne peut exprimer, et prouver le graphe dans le plan JSON. Sous-objectif Pro 2d.
dsoxlab start write-code-depends-on -
Le bloc lifecycle décide de l'ordre, pas vous
Poser create_before_destroy et constater que sa propagation descend vers les dépendances, buter sur la limite documentée de prevent_destroy, limiter ignore_changes à un seul attribut, déclencher un remplacement depuis une valeur nue via terraform_data, et refuser une entrée invalide au plan. Sous-objectif Pro 2d.
dsoxlab start write-code-lifecycle -
La faute de frappe qui ne casse rien
Deux pièges des tfvars : une variable non déclarée dans un .tfvars n'est qu'un avertissement, la vraie variable reste donc silencieusement à son défaut (corriger la faute de frappe), et terraform.tfvars.json l'emporte sur terraform.tfvars (un niveau de précédence distinct). Associate 3c.
dsoxlab start write-code-tfvars-files -
Contraintes de version et lock file
Écrire des contraintes de version correctes : un required_version littéral (le bloc terraform n'accepte aucune variable), un pin exact de provider qui se résout à cette version, et le pessimiste ~> qui autorise la 3.x mais pas la 4.0. Prouvé par version -json et les empreintes h1 du lock file. Associate 3a.
dsoxlab start write-code-version-constraints -
La configuration qui marche mais qu'aucune CI n'accepte
Reprendre une configuration fonctionnelle mais non conforme et la rendre acceptable en CI : passer terraform fmt, corriger la référence orpheline qui fait échouer validate, renommer les ressources en snake_case, typer et décrire variables et outputs, marquer le jeton sensible, typer l'output nombre (1.15), et écrire un .gitignore qui exclut le state mais garde le lock file. Associate 2a et 2e.
dsoxlab start write-code-style-guide -
Quand la sensibilité casse for_each
Un effet de bord de sensitive rarement enseigné : une valeur sensible ne peut pas être une clé for_each (Invalid for_each argument), il faut donc itérer sur un ensemble non sensible. L'attribut de ressource contaminé est marqué dans sensitive_values, et un hash s'expose avec nonsensitive(). Professional 2f.
dsoxlab start write-code-sensitive-data-sensitive-values -
La valeur qui ne touche jamais le state
Déclarer une valeur éphémère, générée pendant l'opération mais jamais écrite dans le state ni le plan : le bloc ephemeral (random 3.7+), le contraste avec un random_password persisté, l'exposer sans risque au root avec ephemeralasnull(), et les deux erreurs qu'elle lève si on la laisse fuiter. Professional 2f.
dsoxlab start write-code-sensitive-data-ephemeral-values -
Arguments write-only : un secret qui n'atterrit jamais dans le state
Transmettre un secret au provider sans jamais le persister dans le state Terraform, grâce aux arguments write-only, contre un émulateur AWS local.
dsoxlab start write-code-sensitive-data-write-only-arguments
Le state Terraform
-
Reprendre un secret déjà en service, sans le régénérer
Un `apply` ordinaire tirerait un mot de passe neuf. Rattacher l'existant par un bloc `import`, puis constater que le secret est en clair dans le state tout en étant marqué `sensitive_attributes` : le masquage est un affichage, pas un chiffrement.
dsoxlab start state-understand-state -
Migrer le state sans casser sa lignée
Un bloc backend n'accepte aucune valeur nommée. Passer d'un backend local implicite à un backend paramétré par configuration partielle et `-backend-config`, et prouver que le state a migré plutôt que d'être recréé : même `lineage`, deux ressources toujours gérées.
dsoxlab start state-backends -
Verrouillage du state, ce qu'il bloque vraiment
Mesurer le périmètre exact du verrou sur un backend local, et énoncer ce qui l'active sur S3.
dsoxlab start state-state-locking -
terraform state list, l'adresse est l'identité
Retrouver l'adresse d'une instance dont on ne connaît que l'identifiant réel, et compter les ressources gérées sans se faire piéger par un module.
dsoxlab start state-terraform-state-list -
terraform state show, ce que la fiche cache
Extraire du state une valeur sensible et des attributs nuls, que la sortie humaine de state show caviarde ou omet.
dsoxlab start state-terraform-state-show -
terraform state mv et le bloc moved, refactorer sans détruire
Rattacher trois objets existants à leurs nouvelles adresses, en impératif puis en déclaratif, et prouver que rien n'a été recréé.
dsoxlab start state-terraform-state-mv -
terraform state rm et le bloc removed, cesser de gérer sans détruire
Sortir deux ressources du state sans supprimer les fichiers, et comprendre pourquoi un bloc removed détruit tant qu'on n'écrit pas destroy = false.
dsoxlab start state-terraform-state-rm -
Restaurer un state amputé : choisir la bonne sauvegarde, prouver que rien n'a été recréé
Un state rm a mal tourné et le backup est écrasé. Trois sauvegardes candidates, une seule restaurable, départagées par lineage et serial, puis poussée sans toucher aux fichiers réels.
dsoxlab start state-backup-restore-state -
Diagnostiquer une dérive et adopter une orpheline, sans perdre sa valeur
Prouver une dérive par un plan refresh-only enregistré, la réconcilier, puis adopter un jeton préexistant avec un bloc import, sans que Terraform le regénère.
dsoxlab start state-diagnose-state
Modules Terraform
-
Un module réutilisable ne configure aucun provider
Vider un module enfant de sa configuration de provider, lui faire déclarer la configuration aliasée qu'il attend, la lui passer depuis la racine, et l'instancier trois fois avec un seul for_each.
dsoxlab start modules-create-modules -
Refactorer un monolithe vers la structure standard
Éclater un fichier .tf unique selon la structure officielle, ajouter un module imbriqué appelé par chemin relatif, un exemple autonome, et prouver que override.tf est le seul nom de fichier à avoir un effet.
dsoxlab start modules-module-structure -
L'interface d'un module est un contrat, pas seulement des types
Rendre un attribut d'objet facultatif, refuser un null explicite, rejeter une valeur hors bornes, garder une sortie sous precondition, et ré-exporter un secret sans casser le plan.
dsoxlab start modules-module-variables-outputs -
Un module local se lit sur place, il ne s'installe pas
Brancher deux projets racine sur un seul module local partagé, et prouver depuis modules.json quel dossier chaque appel lit vraiment : chemin relatif contre chemin absolu.
dsoxlab start modules-module-local -
Un module de registre est téléchargé, versionné, et jamais verrouillé
Épingler un module de registre, résoudre une contrainte souple, et prouver depuis modules.json et le JSON du plan quelle version a été installée : le fichier de verrouillage ne couvre jamais un module.
dsoxlab start modules-module-registry -
Publier et consommer des versions de module avec des tags Git
Publier trois versions d'un module partagé, puis les consommer depuis trois projets : une référence immuable, un tag mineur et un tag majeur, sans jamais employer l'argument version.
dsoxlab start modules-version-modules -
Prouver un module avec terraform test, mutations comprises
Écrire la suite .tftest.hcl d'un module, couvrant son défaut, ses options et son refus d'une entrée invalide : chaque comportement est contrôlé en mutant le module.
dsoxlab start modules-test-module -
Rendre un module composable, et le prouver depuis le JSON du plan
Debarrasser un module legacy de sa configuration de provider, inverser sa dependance et le documenter, puis lire la preuve dans provider_config et module_calls.
dsoxlab start modules-module-best-practices -
Refactorer un projet copié-collé sans rien détruire
Extraire deux ressources copiees-collees dans un module type appele une seule fois, et prouver depuis les identifiants du state que rien n'a ete detruit en chemin.
dsoxlab start modules-module-anti-patterns
Environnements
-
Quelle valeur gagne, et comment le prouver
Servir trois environnements depuis une seule configuration, retablir le garde-fou qu'un terraform.tfvars avait neutralise, et prouver quelle source gagne par le JSON du plan.
dsoxlab start environments-per-environment-variables -
Un seul répertoire, trois états qui ne se voient pas
Piloter trois instances d'etat depuis une seule configuration grace a terraform.workspace, puis retirer un workspace herite sans laisser d'objet orphelin.
dsoxlab start environments-workspace
Terraform sur AWS, via Floci
-
Provider AWS : authentification, endpoints et tags par defaut
Configurer un provider AWS epingle pour qu'il dialogue avec une API locale, puis prouver que l'instance tourne reellement.
dsoxlab start aws-provider-aws-first-ec2 -
Security group : règles dédiées, for_each et subnet déterministe
Construire un security group dont toutes les regles sont des ressources dediees, factoriser les regles d'entree par for_each, et poser une instance dans un subnet designe par son tag.
dsoxlab start aws-sg-subnet-instance
Certification Associate (004)
-
Les commandes que l'examen attend, faites plutôt que récitées
Huit gestes qu'un candidat doit savoir FAIRE : `validate`, `fmt`, la cascade de précédence, `moved`, `import`, `removed` sans détruire, `-replace`, et ce que `sensitive` protège vraiment. Les codes de retour se consignent au moment où ils sont observés : ils ne se reconstituent pas après coup.
dsoxlab start certifications-associate-essential-commands -
Associate 004 : examen blanc
Examen blanc de l'Associate 004, validé par pytest.
dsoxlab start certifications-associate-mock-004