Je viens de réussir Terraform Associate (004) — ce que j'aurais aimé savoir

J'ai passé le Terraform Associate 004 hier et l'ai réussi du premier coup. Ce n'est pas un article du type "voici ce qu'il faut étudier" — il y en a beaucoup, y compris le nôtre. C'est l'article que j'aurais aimé lire la veille au soir, tant que tout est encore frais.

Pour le contexte : j'écris du Terraform sur AWS depuis environ trois ans, principalement pour des infrastructures applicatives — VPC, ECS, RDS, ALB, l'habituel — parfois avec HCP Terraform mais plus souvent avec S3 + DynamoDB. J'ai passé le 003 il y a longtemps, de manière peu attentive, et j'ai pensé que le 004 serait une révision rapide. Ce fut le cas pour l'essentiel, mais avec quelques notes.

Ce que j'ai bachoté inutilement

Les deux jours précédant l'examen, je me suis plongé dans quelques sujets qui se sont avérés quasi absents du test :

• Syntaxe Sentinel et OPA. Je m'étais convaincu qu'il fallait que je reconnaisse une règle Sentinel à vue. Il y a eu exactement une question qui abordait la politique en tant que code, et elle était conceptuelle — "quelle fonctionnalité applique les politiques organisationnelles ?" — à laquelle on pouvait répondre simplement en sachant que le mot "Sentinel" existe.
• Versions du protocole des plugins de fournisseur. Aucune pertinence.
• Mémoriser chaque sous-commande terraform state. L'examen pose des questions sur state list, state mv et state rm dans des scénarios. Si vous comprenez ce que chacun fait en langage simple, vous n'avez pas besoin de mémoriser les options.
• Niveaux tarifaires de HCP Terraform. Pas à l'examen. L'examen traite HCP de manière conceptuelle.

Si j'avais pu récupérer le temps de préparation, je l'aurais consacré à plus d'exercices sur for_each vs. count.

Ce qui m'a surpris

Quelques points auxquels je ne m'attendais pas :

Les nouveautés du 004 sont posées précisément. Je m'attendais à des questions floues du type "à quoi sert le bloc moved ?" ; au lieu de cela, j'ai eu des scénarios spécifiques comme "vous avez renommé une ressource et souhaitez préserver son état sans interruption — quel est le changement valide minimal ?" avec des choix de réponses incluant à la fois une invocation state mv et un bloc moved. Il faut choisir l'approche qui correspond au workflow, et pas seulement reconnaître que les deux existent.

Plusieurs questions sur les blocs import vs. terraform import. J'avais paresseusement supposé qu'ils étaient équivalents. L'examen m'a rappelé qu'ils ne le sont pas — le bloc est déclaratif et s'intègre au plan ; la commande CLI est impérative et modifie l'état immédiatement. Deux questions ont spécifiquement testé si je savais lequel convient à un workflow CI/CD révisable.

Les questions HCL sont plus denses que ne le suggèrent les tests pratiques. De nombreux examens pratiques vous donnent un extrait soigné de quatre lignes. Le véritable examen m'a au moins une fois présenté un bloc de quinze lignes avec un dynamic imbriqué dans une resource dont le for_each propre pilotait le compte externe, et m'a demandé de prédire le nombre de ressources créées. J'ai dû le lire deux fois. Ne sous-estimez pas la charge cognitive de lire attentivement le HCL sous la contrainte d'une minute par question.

Deux questions sur terraform test. J'avais failli sauter cette section car les tests pratiques la mentionnaient à peine. Les questions étaient conceptuelles — que .tftest.hcl existe, que les blocs run contiennent des assertions, que l'on peut simuler des fournisseurs pour les tests unitaires. Parcourez la page de documentation ; c'est suffisant.

La gestion du temps a failli me jouer des tours

57 questions en 60 minutes, c'est un peu plus d'une minute par question. Je suis lent aux examens techniques car je lis le code attentivement. J'ai terminé ma première passe à la 52ème minute avec cinq questions signalées pour révision. Pour deux de ces questions signalées, j'avais trop réfléchi à la formulation ; en les relisant à nouveau, j'ai changé les deux réponses — l'une s'est avérée correcte, l'autre, je pense, que je l'ai changée vers la mauvaise réponse (il n'y a aucun moyen de le savoir après coup).

Ce qui a fonctionné : toute question où je me surprenais à relire l'énoncé plus de deux fois, je faisais ma meilleure supposition, la signalais et passais à la suivante. Ne restez pas bloqué sur une seule question pendant quatre minutes. Si vous ne la connaissez pas après une minute, vous ne la connaîtrez probablement pas après trois de plus.

Les questions lentes

Une catégorie spécifique qui a consommé du temps : "étant donné cette sortie de fichier d'état, que montrera terraform plan ?" Celles-ci sont lentes car vous parcourez mentalement un diff d'état. Pour deux d'entre elles, j'ai abandonné l'idée d'essayer de simuler, j'ai regardé les options de réponse et j'ai choisi la chose la plus susceptible d'être cassée (une balise manquante dans un cas, un attribut modifié dans l'autre). Les deux se sont avérées correctes. La reconnaissance de formes plutôt qu'une simulation approfondie, quand le temps est court.

Ce que je recommanderais vraiment, si je refaisais ma préparation

Compte tenu de ce que je sais maintenant, voici le budget rééquilibré :

• 40% de questions pratiques. Passez-les réellement sous la contrainte du temps, engagez-vous réellement avec les mauvaises réponses.
• 25% de lecture lente d'exemples HCL. Écrivez-en aussi, mais la fluidité dont vous avez besoin le jour de l'examen est la fluidité de lecture, pas la fluidité d'écriture.
• 15% de sémantique d'état. Ce qu'il y a dans le fichier d'état, pourquoi le verrouillage est important, ce que résolvent les blocs moved / removed / import.
• 10% des nouvelles fonctionnalités du 004 isolément — validation des variables, préconditions, valeurs éphémères, arguments en écriture seule, projets HCP, terraform test.
• 10% tout le reste — Concepts IaC, le but de Terraform, aperçu de HCP.

Un budget déséquilibré par conception. La catégorie "tout le reste" regroupe principalement des choses que vous connaissez déjà si vous avez utilisé Terraform pendant plus de quelques mois.

Ce que je ne pensais pas important et qui l'a été

• Savoir que terraform fmt existe et ce qu'il fait. Est apparu deux fois. L'une des mauvaises réponses était que fmt modifie l'état.
• Syntaxe des contraintes de version du fournisseur. La différence entre ~> 1.2 et ~> 1.2.0 (le second est pessimiste au niveau du patch — plus restrictif). J'ai eu cette bonne réponse mais je m'étais convaincu que cela ne serait pas testé.
• Ce que fait terraform init -upgrade par rapport à terraform init -reconfigure. On m'a demandé lequel utiliser après avoir modifié un bloc backend. La réponse est -reconfigure.
• terraform output avec -json. Un scénario de script demandait quelle commande produit des valeurs de sortie lisibles par machine. Trivial si vous l'avez utilisé ; facile à ignorer si ce n'est pas le cas.

Après l'examen

PSI affiche un écran de réussite/échec à la fin (j'ai eu le coche vert ; soulagement). La ventilation complète des scores par domaine arrive par e-mail quelques jours plus tard. Le badge apparaît dans votre compte Credly une fois que vous l'avez accepté. Les certifications HashiCorp sont valides pendant deux ans, alors mettez un rappel dans votre agenda.

Ce que j'ai sous-estimé concernant un examen de fournisseur, c'est à quel point 60 minutes de concentration intense sont épuisantes. Ne planifiez pas de réunion après. Je suis rentré chez moi et j'ai fixé un mur pendant une heure.

Si votre date d'examen est proche, exécutez un bloc d'exercices "à froid" de la banque CertLabPro 004. N'optimisez pas pour un score élevé à la pratique — optimisez pour identifier les catégories où vous êtes faible tant qu'il est encore temps de les corriger.