-target fait vraimentterraform apply -target=… ne « va plus vite ». Il coupe le graphe : seules les adresses ciblées et leurs dépendances amont nécessaires sont considérées. Le reste de la configuration est feint comme absent de ce run. HashiCorp le documente comme outil de secours, pas comme workflow.
Conséquences typiques : vous créez un security group ciblé, mais la règle qui devrait partir avec, non ciblée, reste ancienne ; vous « corrigez juste le DNS » pendant qu’un changement de listener attend dans le même root ; le state avance sur un îlot, le code décrit autre chose. Le lundi suivant, le plan complet propose un carnage que personne n’avait approuvé.
La tentation est honnête : un apply de trente minutes, un incident, « je ne touche qu’à ça ». Le mensonge : Terraform n’a pas de notion de « ça » isolé dès que les resources partagent un state. Les outputs, les interpolations, les destroy d’un refactor : tout ça est hors champ.
L’intervieweur senior écoute si vous refusez le target comme habitude. Acceptable : débloquer un objet cassé, puis immédiatement un plan sans target pour voir la dette. Inacceptable : une doc d’équipe « on target toujours pour aller plus vite ».
« Et si on découpait les states à la place ? »
Oui. C’est la vraie réponse architecturale : un apply plus petit par conception (réseau / data / app), pas un graphe entier auquel on met un bandeau -target. Le target est un scalpel d’incident ; le découpage est de la chirurgie réglée.