67 labs pratiques pour préparer le HashiCorp Certified: Terraform Authoring and Operations Professional, soit environ 63 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.
Le niveau au-dessus, et celui-ci est pratique : écrire des modules réutilisables, gérer le state à plusieurs, et opérer Terraform dans une chaîne de livraison.
- 67labs
- 63heures de pratique
Niveaux 43 intermédiaire 24 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
É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 -
Fonctions définies par les providers
Utiliser les fonctions exposées par un provider via la syntaxe provider::. Objectifs Pro 2c et 5a.
dsoxlab start write-code-provider-defined-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 -
Lire des secrets depuis Vault
Récupérer des secrets depuis HashiCorp Vault avec le provider vault et les consommer sans les figer en clair dans le state. Objectif Pro 2f.
dsoxlab start write-code-sensitive-data-vault-secrets
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 -
Le bloc removed : léguer une infrastructure sans la détruire
Sortir des ressources du state en décidant pour chacune si l'objet réel survit, et découvrir où le bloc removed déclare forfait. Objectifs Pro 1e et 4c.
dsoxlab start state-removed-block -
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
-
Decouper une configuration monolithique, et prouver que le plan n'a pas bouge
Decouper un main.tf de quatre-vingts lignes selon le socle officiel, puis prouver en comparant deux plans que rien n'a change : un validate vert ne prouve rien ici.
dsoxlab start environments-organize-terraform-repo -
Deux racines, deux états, un seul module partagé
Brancher deux configurations racine sur un module partage avec un backend partiel, puis prouver en detruisant dev que prod n'a pas bouge.
dsoxlab start environments-separate-environments -
Workspaces ou configurations separees, et ce que coute la decoupe
Decider ce qui releve encore des workspaces, decouper le reste en deux racines, et rebrancher leur dependance par terraform_remote_state sans dupliquer une valeur.
dsoxlab start environments-when-to-use-workspaces -
Decouper un monorepo en deux stacks qui se parlent
Re-exporter a la racine la sortie d'un module imbrique, la consommer depuis une stack aval par terraform_remote_state, et garder le secret de la plateforme hors de l'etat partage.
dsoxlab start environments-monorepo-vs-repo-per-stack -
Exécuter Terraform en automation (CI/CD)
Batir une chaine Terraform non interactive jugee sur ses seuls codes de retour, puis consigner ce qu'un plan sauvegarde fige vraiment, ce que fait un verrou, et ou fuit un secret.
dsoxlab start environments-terraform-in-automation
Terraform sur AWS, via Floci
-
Composer la chaîne IAM, et nommer ses deux policies correctement
`aws_iam_policy_document` est une data source LOCALE : elle n'interroge rien, elle fabrique du JSON. Composez la chaîne policy, rôle, instance profile, instance, et prouvez dans l'état structuré que la trust policy et les permissions empruntent deux chemins distincts jusqu'au rôle.
dsoxlab start aws-iam-role-policy-instance-profile -
Un state distant, verrouillé, et lu par une autre stack
Reparer un bloc backend piege, rendre le verrou S3 reellement effectif, et faire consommer les outputs par une seconde configuration sans recopier une valeur.
dsoxlab start aws-backend-s3-remote-state -
Lire un remplacement dans le plan, avant qu'il n'arrive
Un ASG qui référence `version = "$Latest"` ne déclenche jamais d'instance refresh, et un `create_before_destroy` posé sur le launch template ne protège rien du tout. Lisez ces deux vérités dans le plan converti en JSON, sans jamais appeler AWS.
dsoxlab start aws-launch-template-autoscaling -
Import, moved et dérive : les trois pièges qu'un tutoriel ne montre jamais
Placez sous contrôle de Terraform une instance EC2 créée en dehors de lui, changez son adresse logique sans que l'objet réel soit recréé, puis réconciliez une dérive en ACCEPTANT la réalité plutôt qu'en l'écrasant.
dsoxlab start aws-import-moved-drift
HCP Terraform
-
Le workflow d'un run : joué en deux temps, puis qualifié
Un run est un plan, puis un apply de CE plan. Reproduire cette division en local avec les plans enregistrés, constater ce que refusent un plan périmé et une variable figée, puis qualifier six runs décrits et remettre les onze étapes dans l'ordre que la documentation donne.
dsoxlab start hcp-terraform-hcp-terraform-overview -
Workspaces : un mot, deux sens, deux stratégies de rattachement
Un workspace CLI est un état de plus dans le même répertoire ; un workspace HCP Terraform est une unité d'exécution, avec ses variables, ses droits et son historique. Réparer deux blocs `cloud`, rattacher l'un par nom et l'autre par étiquettes, et établir ce que `terraform validate` ne voit pas.
dsoxlab start hcp-terraform-hcp-workspaces -
Le flux qu'un run renvoie, et les trois façons de le lancer
Ce qu'une CLI reçoit d'un run distant est le flux structuré que `terraform apply -json` produit aussi en local. L'enregistrer, l'analyser en HCL, avec deux `change_summary` dont un seul dit ce qui s'est passé, et établir ce que chacun des trois workflows autorise.
dsoxlab start hcp-terraform-remote-runs -
Quinze niveaux de précédence, et une inversion
Chez les variable sets prioritaires, la portée la plus large gagne, alors que chez les sets normaux c'est la plus étroite. Construire la table complète des quinze niveaux, puis résoudre des cas que les tests génèrent et qu'aucune réponse écrite cas par cas ne traite.
dsoxlab start hcp-terraform-variable-sets -
Les identifiants ne vivent ni dans le code, ni dans le state
`sensitive` masque une valeur à l'écran, et le state la porte quand même en clair. Sortir les clés du provider de la configuration, remplacer un jeton posé en étiquette par son empreinte, et établir comment fonctionnent les identifiants dynamiques.
dsoxlab start hcp-terraform-shared-credentials -
Les permissions s'additionnent, elles ne s'écrasent pas
Une permission posée au niveau organisation peut l'emporter sur celle du workspace, et l'inverse est vrai aussi : c'est le plus permissif qui gagne, jamais le plus spécifique. Écrire la règle qui calcule l'accès effectif de six équipes, et établir deux échelles qui ne sont pas la même.
dsoxlab start hcp-terraform-projects-teams -
Policy as code : qui bloque un run, et qui peut passer outre
Un `hard-mandatory` n'est pas indépassable : c'est le réglage du policy set qui tranche, croisé avec la permission de l'utilisateur. Qualifier sept runs, établir les niveaux des trois frameworks, et écrire une règle qui refuse un plan non conforme et accepte l'autre.
dsoxlab start hcp-terraform-policy-as-code -
Le premier run distant, pour de vrai (optionnel, demande un compte)
Le seul lab du catalogue qui demande un compte HCP Terraform. Provisionner la plateforme avec le provider `tfe` (projet, workspace, réglages, une variable sensible), rattacher une configuration par un bloc `cloud`, et voir un run s'exécuter sur l'infrastructure de HashiCorp.
dsoxlab start hcp-terraform-premier-run-distant
Certification Professional
-
Pro · Objectif 1 : cycle de vie, import et réconciliation de drift
Importer dans le state une EC2 créée hors Terraform (aws cli sur Floci), puis détecter et réconcilier un drift. Objectif d'examen 1.
dsoxlab start certifications-professional-capstone1-resource-lifecycle -
Pro · Objectif 2 : configuration dynamique et troubleshooting
Data sources, fonctions HCL, meta-arguments (count/for_each/dynamic), types complexes, données sensibles et Vault. Objectif d'examen 2.
dsoxlab start certifications-professional-capstone2-dynamic-config -
Pro · Objectif 3 : workflows collaboratifs
Remote state (backend S3 sur Floci), version constraints, workflow en automation et partage de données via terraform_remote_state. Objectif d'examen 3.
dsoxlab start certifications-professional-capstone3-collaborative-workflows -
Pro · Objectif 4 : créer, maintenir et utiliser des modules
Créer un module, le consommer, le refactorer et le versionner ; refactorer une configuration plate en modules. Objectif d'examen 4.
dsoxlab start certifications-professional-capstone4-modules -
Pro · Objectif 5 : configurer et utiliser les providers
Architecture plugin, aliasing, versioning/sourcing/upgrades, authentification et troubleshooting d'erreurs provider (sur Floci). Objectif d'examen 5.
dsoxlab start certifications-professional-capstone5-providers -
Pro · Objectif 6 : HCP Terraform, là où les sous-objectifs se croisent
L'objectif 6 est évalué en QCM, et ne demande aucun compte. Six situations qui croisent chacune deux sous-objectifs, un bloc `cloud` à écrire, et un secret qui ne doit pas atteindre le state. Six situations, six issues différentes : aucune réponse constante ne passe.
dsoxlab start certifications-professional-capstone6-hcp -
Pro · Examen blanc intégratif : les six objectifs d'une traite
Une répétition générale, pas une leçon : six tâches, une par objectif, à jouer d'un trait une fois les six capstones réussis. Réconciliation d'une dérive, configuration dynamique, deux états qui communiquent, un module qui ne recrée rien, deux configurations d'un provider, et un QCM de douze questions noté par sous-objectif.
dsoxlab start certifications-professional-mock-pro