TerraformAssociate on Valérian Pyckaert

Terraform Associate #9 — Certifié !

Thu, 03 Sep 2026 14:58:35 +0200

C’est fait : j’ai obtenu la certification HashiCorp Certified: Terraform Associate aujourd’hui, au terme de la série d’articles commencée avec l’objectif certification.

L’examen

Pas de mauvaise surprise sur le fond : les sujets couverts correspondaient à ce que j’avais préparé au fil des huit précédents articles, suivant l’exam guide point par point. Le seul vrai piège, ce sont certaines tournures de questions volontairement ambiguës, qui font douter même quand on connaît la réponse. Il faut prendre le temps de bien relire l’énoncé avant de répondre.

Ce qui a le plus aidé

Écrire les articles au fil de l’eau. Reformuler chaque module avec mes propres mots a forcé la clarification de ce que je pensais déjà maîtriser, et a fait ressortir les zones floues.
La mise en pratique sur un cas concret (hub & spoke sur GCP) plutôt que des exemples jetables : ça ancre les concepts (state, modules, workspaces) bien mieux que la lecture seule.
Les questions type examen, pour se confronter au format réel et repérer les points faibles avant le jour J.

La suite

Direction la certification Google Professional Cloud Architect (PCA), pour élargir cette base Terraform à une vision plus large de l’architecture cloud sur GCP.

Terraform Associate #8 — Mise en pratique : hub & spoke sur GCP

Mon, 31 Aug 2026 11:08:24 +0200

Après les sept premiers modules de ma préparation à la certification Terraform Associate (fondamentaux, IaC, workflow, configuration, modules, state,…), place à la pratique : je mets ces connaissances en application en construisant une architecture réseau hub & spoke sur GCP.

Introduction

Une architecture hub & spoke, c’est comme un aéroport de correspondance : un hub central qui concentre les ressources et services partagés, et des spokes qui y sont raccordés mais qui n’ont pas de liaison directe entre eux. Tout le trafic transite par le hub.

Appliqué à un réseau cloud, ça donne :

un hub : un VPC central qui héberge les ressources partagées (passerelle NAT, connectivité vers l’extérieur, éventuellement pare-feu et DNS centralisés) ;
des spokes : des VPC isolés par environnement, ici dev et prod, connectés au hub mais étanches l’un par rapport à l’autre.

L’intérêt : mutualiser ce qui peut l’être tout en gardant une isolation forte entre environnements, un cas d’usage classique pour tester en conditions réelles les notions vues dans les articles précédents (modules, state, workflow).

À la fin de ce tutoriel, vous saurez construire cette architecture sur GCP avec Terraform.

Prérequis

Avoir suivi les articles précédents de la série Terraform Associate, notamment sur les modules et le state.
Un compte GCP avec un projet.
Terraform installé et le CLI gcloud configuré.

Architecture

Voici l’architecture visée :

graph TB
    subgraph HUB["hub-vpc — 10.0.0.0/24"]
        HubSub["hub-subnet"]
        HubVM["hub-vm"]
        HubSub --- HubVM
    end

    subgraph DEV["spoke-dev-vpc — 10.1.0.0/24"]
        DevSub["spoke-dev-subnet"]
        DevVM["spoke-dev-vm"]
        DevNAT["Cloud Router + Cloud NAT"]
        DevSub --- DevVM
        DevSub --- DevNAT
    end

    subgraph PROD["spoke-prod-vpc — 10.2.0.0/24"]
        ProdSub["spoke-prod-subnet"]
        ProdVM["spoke-prod-vm"]
        ProdNAT["Cloud Router + Cloud NAT"]
        ProdSub --- ProdVM
        ProdSub --- ProdNAT
    end

    DEV <-->|VPC Peering| HUB
    PROD <-->|VPC Peering| HUB
    DevNAT --> Internet(("Internet"))
    ProdNAT --> Internet

VPC	Subnet	CIDR
`hub-vpc`	`hub-subnet`	`10.0.0.0/24`
`spoke-dev-vpc`	`spoke-dev-subnet`	`10.1.0.0/24`
`spoke-prod-vpc`	`spoke-prod-subnet`	`10.2.0.0/24`

Chaque spoke aura un peering bidirectionnel avec le hub (hub_to_spoke / spoke_to_hub); aucun peering entre les différent spoke, pas de NAT ni IP publique pour les VM.

Iterations

1. Mise en place de l’infrastructure de base

Ici l’idée a été de partir d’une configuration simple en laissant volontairement des pistes d’améliorations. On part d’une configuration qui fonctionne et petit à petit on vise quelque chose d’optimisé et portable entreprise.

Voici l’architecture obtenue :

.
├── .gitignore
├── .terraform.lock.hcl
├── README.md
├── compute.tf
├── firewall.tf
├── main.tf
├── peering.tf
├── routing.tf
├── subnet.tf
├── variables.tf
└── vpc.tf

Une structure plate, un fichier par type de ressource (VPC, subnet, firewall, peering, routing, compute), le tout dans un seul state local.

La totalité de la configuration est disponible ici.

2. Refactoring à l’aide de modules

Si on analyse la configuration précédente, on voit rapidement que pas mal de configuration est dupliquée :

resource "google_compute_instance" "hub_vm" {
  name         = "hub-vm"
  machine_type = "e2-micro"
  zone         = "europe-west1-b"

  boot_disk {
    initialize_params {
      image = "debian-cloud/debian-13"
    }
  }

  network_interface {
    network    = google_compute_network.hub.id
    subnetwork = google_compute_subnetwork.hub.id
    # pas de access_config => pas d'IP publique
  }
}

resource "google_compute_instance" "spoke_vm" {
  for_each     = var.spokes
  name         = "${each.key}-vm"
  machine_type = "e2-micro"
  zone         = "europe-west1-b"

  boot_disk {
    initialize_params {
      image = "debian-cloud/debian-13"
    }
  }

  network_interface {
    network    = google_compute_network.spoke[each.key].id
    subnetwork = google_compute_subnetwork.spoke[each.key].id
  }
}

Créons donc un module compute:

main.tf

resource "google_compute_instance" "this" {
  name         = "${var.name}-vm"
  machine_type = "${var.machine_type}"
  zone         = "europe-west1-b"

  boot_disk {
    initialize_params {
      image = "debian-cloud/debian-13"
    }
  }

  network_interface {
    network    = var.network_interface.network
    subnetwork = var.network_interface.subnetwork
  }
}

variables.tf

variable "name" {
  type        = string
  description = "Nom logique de la machine"
}

variable "machine_type" {
  type        = string
  description = "Type de la machine"
  default     = "e2-micro"
}

variable "network_interface"{
    type      = object({
      network = string
      subnetwork = string
    })
}

outputs.tf

output "compute_id" {
  value = google_compute_instance.this.id
}

output "network_name" {
  value = google_compute_instance.this.name
}

Dans notre module root il suffit alors d’appeler ce module via :

module "hub_vm" {
  source = "./modules/compute"
  name   = "hub"
  network_interface = {
    network    = module.hub.network_id
    subnetwork = module.hub.subnetwork_id
  }
}

module "spoke_vm" {
  source   = "./modules/compute"
  for_each = var.spokes
  name     = "spoke-${each.key}"
  network_interface = {
    network    = module.spoke[each.key].network_id
    subnetwork = module.spoke[each.key].subnetwork_id
  }
}

Version fonctionnelle ici

3. Ajout de Lifecycle

Le VPC hub est une ressource critique de notre infrastructure puisque les deux spoke passe par lui. Afin de faire échouer un plan si on tente un destroy sur cette ressource on peut s’appuyer sur le meta argument lifecycle.

resource "google_compute_network" "hub" {
  name                    = "hub-vpc"
  auto_create_subnetworks = false

  lifecycle {
    prevent_destroy = true
  }
}

4. Bloc de validation

Dans la même idée on peut mettre en place une règle de validation sur le module vpc pour empêcher le chevauchement de cidr avec le hub.

modules/vpc/variables.tf

variable "cidr" {
  type        = string
  description = "Subnet CIDR range (e.g. 10.0.0.0/24)"

  validation {
    condition = var.cidr != "10.0.0.0/24"
    error_message = "The cidr range shouldn't overlap with hub's one."
  }
}

Un plan qui tente ce chevauchement aura ce message d’erreur :

╷
│ Error: Invalid value for variable
│ 
│   on main.tf line 29, in module "spoke":
│   29:   cidr     = each.value.cidr
│     ├────────────────
│     │ var.cidr is "10.0.0.0/24"
│ 
│ The cidr range shouldn't overlap with hub's one.
│ 
│ This was checked by the validation rule at
│ modules/vpc/variables.tf:15,3-13.

5. Data sources

Autre ajout mineur mais qui permet de mettre en exergue l’instruction data, l’image Debian est codée en dur (ex: debian-cloud/debian-13). Si dans 6 mois Google dépréciée cette image, l’apply échoue. Avec data "google_compute_image" { family = "debian-13", project = "debian-cloud" }, Terraform récupère toujours la dernière image au moment de l’apply, sans maintenance manuelle.

data "google_compute_image" "debian" {
  family  = "debian-13"
  project = "debian-cloud"
}

resource "google_compute_instance" "this" {
  name         = "${var.name}-vm"
  machine_type = "${var.machine_type}"
  zone         = "europe-west1-b"

  boot_disk {
    initialize_params {
      #Utilisation de la data créée plus haut
      image = data.google_compute_image.debian.self_link
    }
  }

6. Séparation des states

Enfin, un changement un peu plus costaud mais qui peut réellement être pertinent en entreprise : séparé la partie réseau dans un state dédié.

A ce stade, modifier une VM oblige à revoir un plan qui inclut tout le réseau (VPC, firewall, routes), ce qui est risqué. En séparant en deux stacks (network/ et compute/), l’équipe réseau pourrait appliquer ses changements indépendamment de l’équipe applicative. La partie compute lit ensuite les infos du VPC via un bloc data qui pointe vers le state network au lieu de dupliquer les valeurs en dur : si le réseau change, le compute suit automatiquement au prochain apply.

Le découpage final peut être retrouvé ici.

Avant :

.
├── main.tf
├── providers.tf
├── variables.tf
└── modules/
    ├── compute/
    ├── firewall/
    ├── peering/
    ├── routing/
    └── vpc/

Après :

.
├── modules/
│   ├── compute/
│   ├── firewall/
│   ├── peering/
│   ├── routing/
│   └── vpc/
├── network/
│   ├── main.tf
│   ├── outputs.tf
│   ├── providers.tf
│   └── variables.tf
└── compute/
    ├── main.tf
    └── providers.tf

Le dossier modules/ reste commun aux deux stacks. Ce qui était à la racine (main.tf, providers.tf, variables.tf, donc un seul state) est éclaté en deux : network/ (VPC, subnets, firewall, peering, routing) et compute/ (VMs), chacun avec son propre backend et donc son propre state.

compute/ n’a plus de variables.tf : il récupère les infos réseau via un bloc data "terraform_remote_state" qui pointe vers le state de network/, plutôt que de dupliquer des valeurs en dur.

HCP Terraform

Comme nous l’avons vu dans l’article précédent, HCP Terraform est la plateforme cloud d’Hashicorp. J’ai voulu l’essayer pour découvrir plus en détail ses capacités.

Configuration

Tout démarre via la création d’un compte Terraform/HCP, vous avez ensuite la possibilité de lier ce compte à un VCS. Pour ma part j’ai choisi de le faire pour bénéficier de l’intégration VCS avec Github.

Enfin il faut créer une organisation, bernedotcom pour ma part.

Dernière étape : créer un workspace pour cela vous avez deux possibilités :

Lancer terraform login depuis votre poste local + terraform init
Le créer manuellement

Migration du backend

Il faut désormais indiquer à notre configuration que le backend est HCP désormais via l’instruction cloud. Suite à la séparation des states j’ai deux workspaces à gérer : gcp-hub-and-spoke-network et gcp-hub-and-spoke-compute.

Voici un exemple de configuration dans network/providers.tf

terraform {
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = "7.45.0"
    }
  }
  required_version = ">= 1.15"

  cloud {
    organization = "bernedotcom"
    workspaces {
      name = "gcp-hub-and-spoke-network"
    }
  }
}

Un coup de terraform init pour valider tout ça et c’est terminé pour cette partie.

Service account

Auparavant terraform était lancé depuis mon poste local et utilisait mon compte personnel GCP pour appliquer la configuration (ce n’est évidemment pas une bonne pratique). Maintenant c’est HCP qui va lancer les plan & apply depuis une machine distante, il faut alors l’autoriser à faire ce type d’opérations sur mon projet GCP.

Pour cela deux possibilités :

Un token d’authorization (peu secure)
Workload identity (plus complexe à mettre en place mais beaucoup plus robuste).

J’ai opté pour la workload identity ici :

# 1. Activer les APIs nécessaires
gcloud services enable iam.googleapis.com iamcredentials.googleapis.com sts.googleapis.com --project=hubandspoke-demo

# 2. Créer le Workload Identity Pool
gcloud iam workload-identity-pools create "hcp-terraform-pool" \
  --project="hubandspoke-demo" \
  --location="global" \
  --display-name="HCP Terraform"

# 3. Créer le provider OIDC dans ce pool, restreint à org=bernedotcom / workspaces=gcp-hub-and-spoke-network,gcp-hub-and-spoke-compute
gcloud iam workload-identity-pools providers create-oidc "hcp-terraform-provider" \
  --project="hubandspoke-demo" \
  --location="global" \
  --workload-identity-pool="hcp-terraform-pool" \
  --display-name="HCP Terraform Provider" \
  --attribute-mapping="google.subject=assertion.sub,attribute.terraform_organization_name=assertion.terraform_organization_name,attribute.terraform_workspace_name=assertion.terraform_workspace_name,attribute.terraform_run_phase=assertion.terraform_run_phase" \
  --attribute-condition="assertion.terraform_organization_name==\"bernedotcom\" && assertion.terraform_workspace_name in [\"gcp-hub-and-spoke-network\", \"gcp-hub-and-spoke-compute\"]" \
  --issuer-uri="https://app.terraform.io"

# 4. Créer le service account que Terraform utilisera
gcloud iam service-accounts create "hcp-terraform-runner" \
  --project="hubandspoke-demo" \
  --display-name="HCP Terraform runner"

# 5. Lui donner les droits nécessaires sur le projet (couvre VPC, subnets, firewall, routeur/NAT, peering, VM)
gcloud projects add-iam-policy-binding hubandspoke-demo \
  --member="serviceAccount:hcp-terraform-runner@hubandspoke-demo.iam.gserviceaccount.com" \
  --role="roles/compute.networkAdmin"

gcloud projects add-iam-policy-binding hubandspoke-demo \
  --member="serviceAccount:hcp-terraform-runner@hubandspoke-demo.iam.gserviceaccount.com" \
  --role="roles/compute.instanceAdmin.v1"

# roles/compute.networkAdmin exclut explicitement les firewalls, il faut ce rôle en plus
gcloud projects add-iam-policy-binding hubandspoke-demo \
  --member="serviceAccount:hcp-terraform-runner@hubandspoke-demo.iam.gserviceaccount.com" \
  --role="roles/compute.securityAdmin"

# 6. Autoriser le pool WIF à impersonate ce service account (uniquement depuis le workspace gcp-hub-and-spoke-network & compute)
gcloud iam service-accounts add-iam-policy-binding "hcp-terraform-runner@hubandspoke-demo.iam.gserviceaccount.com" \
  --project="hubandspoke-demo" \
  --role="roles/iam.workloadIdentityUser" \
  --member="principalSet://iam.googleapis.com/projects/123456789012/locations/global/workloadIdentityPools/hcp-terraform-pool/attribute.terraform_workspace_name/gcp-hub-and-spoke-network"

gcloud iam service-accounts add-iam-policy-binding "hcp-terraform-runner@hubandspoke-demo.iam.gserviceaccount.com" \
  --project="hubandspoke-demo" \
  --role="roles/iam.workloadIdentityUser" \
  --member="principalSet://iam.googleapis.com/projects/123456789012/locations/global/workloadIdentityPools/hcp-terraform-pool/attribute.terraform_workspace_name/gcp-hub-and-spoke-compute"

Ensuite, dans les workspaces HCP Terraform (bernedotcom/gcp-hub-and-spoke-network(compute) → Settings → Variables), ajouter en variables d’environnement :

TFC_GCP_PROVIDER_AUTH = true
TFC_GCP_RUN_SERVICE_ACCOUNT_EMAIL = hcp-terraform-runner@hubandspoke-demo.iam.gserviceaccount.com
TFC_GCP_WORKLOAD_PROVIDER_NAME = projects/123456789012/locations/global/workloadIdentityPools/hcp-terraform-pool/providers/hcp-terraform-provider

Tour d’horizon de l’UI

Grâce à l’intégration VCS le plan est ensuite automatiquement déclenché lors d’un nouveau commit sur la branche cible (main dans mon cas).

Voici le résultat obtenu :

Il est également possible d’obtenir la liste des derniers runs :

Une fois un plan valide, il est alors possible de l’approuver manuellement pour application. Voici le résultat une fois l’apply lancé :

Vérification

Une fois la totalité des ressources créées il s’agit de vérifier le bon fonctionnement de l’architecture; pour cela rien de compliqué :

gcloud compute ssh spoke-dev-vm --zone=europe-west1-b --tunnel-through-iap

# from spoke-dev-vm
ping 10.0.0.2   # hub — should succeed
ping 10.2.0.2   # spoke-prod — should time out

Conclusion

Cette mise en place d’une architecture hub & spoke aura permis de mettre en application concrètement les notions vues tout au long de ma préparation à la certification Terraform Associate. Je suis également satisfait de cet essai d’HCP Terraform : la plateforme est agréable à utiliser et tout s’est déroulé sans difficulté, de la configuration du workspace jusqu’à la workload identity. On obtient une solution GitOps friendly clé en main, sans avoir à gérer soi-même un backend distant ni un pipeline CI/CD pour Terraform.

La version finale de l’implémentation est disponible ici.

Terraform Associate #7 — HCP Terraform

Tue, 18 Aug 2026 17:30:00 +0200

Suite de ma série sur la certification Terraform Associate, après le module sur le state. Dernier objectif de l’exam guide, “Understand HCP Terraform capabilities” : cet article couvre les workspaces, l’intégration VCS, le registre privé, Sentinel/OPA et l’exécution en automation.

Qu’est-ce que HCP Terraform

HCP Terraform (anciennement Terraform Cloud) est le service managé de HashiCorp : state distant, locking, runs plan/apply centralisés, et couche de gouvernance en plus du CLI open source.

Workspaces : CLI vs HCP Terraform

Le mot “workspace” désigne deux choses différentes selon le contexte :

	Workspace CLI (OSS)	Workspace HCP Terraform
Portée	Plusieurs états pour une même configuration locale (`terraform workspace new`)	Unité complète : configuration + variables + state + historique des runs
State	Un fichier par workspace, même backend	State propre à chaque workspace
Isolation	Faible, même répertoire de code	Forte, généralement un repo/dossier ↔ un workspace

Un workspace HCP Terraform correspond en général à un environnement (dev/staging/prod) ou un composant d’infrastructure, chacun avec ses propres variables et son propre historique.

Les workspaces peuvent partager des informations entre eux via des outputs racine.
Un workspace utilisant l’exécution distante peut accéder aux outputs d’un autre workspace via une source de données terraform_remote_state, sous réserve des contrôles d’accès par workspace.
Des run triggers workspace-à-workspace permettent de faire réagir automatiquement un workspace en aval quand ses dépendances changent.

Intégration VCS

Un workspace peut être connecté à un dépôt Git (GitHub, GitLab, Bitbucket…). Chaque push ou pull request déclenche automatiquement un run.

Génère un plan en preview sur les pull requests, avant merge.
Déclenche un apply sur push vers la branche configurée (selon le mode d’apply du workspace).
Évite d’exécuter Terraform depuis un poste local : le run s’exécute sur l’infrastructure HCP Terraform.

Registre privé

En plus du Terraform Registry public, HCP Terraform propose un registre privé pour publier des modules et des providers internes, avec la même syntaxe source = "app.terraform.io/<org>/<nom>/<provider>" que le registre public.

Estimation des coûts

HCP Terraform peut estimer le coût mensuel des ressources créées, modifiées ou détruites par un plan, pour les providers supportés (AWS, Azure, GCP).

L’estimation apparaît directement dans le run, avant l’apply.
Elle peut être utilisée dans une policy Sentinel (ex. bloquer un plan si le delta de coût dépasse un seuil).
Elle reste une estimation basée sur le pricing public du provider, pas une facture réelle (remises, réservations… non prises en compte).

Sentinel et OPA

Sentinel (propriétaire HashiCorp) et Open Policy Agent (OPA) permettent d’appliquer du policy as code : des règles évaluées automatiquement entre le plan et l’apply, pour bloquer un changement qui ne respecte pas une politique organisationnelle.

# exemple de règle Sentinel
main = rule {
  all tfplan.resources.aws_instance as _, instances {
    all instances as _, r {
      r.applied.instance_type in ["t3.micro", "t3.small"]
    }
  }
}

Advisory : avertit sans bloquer.
Soft mandatory : bloque, mais un utilisateur autorisé peut passer outre.
Hard mandatory : bloque sans possibilité de contournement.

Cas d’usage typiques : imposer des tags obligatoires, restreindre les types d’instance autorisés, interdire l’ouverture de ports sensibles.

Run tasks

Les run tasks intègrent un service tiers (scan de sécurité, coût, conformité…) dans le cycle de vie d’un run, à un stade précis (post-plan, pre-apply, post-apply).

HCP Terraform envoie les détails du run à l’endpoint du service tiers via une API webhook.
Le service répond avec un statut passed ou failed.
Comme Sentinel/OPA, la sévérité peut être advisory (informatif) ou mandatory (bloque l’apply si le check échoue).

Contrairement à Sentinel/OPA qui évalue localement le plan avec des règles écrites en Sentinel ou Rego, un run task délègue la vérification à un outil externe (ex. Snyk, Bridgecrew, Infracost).

RBAC

HCP Terraform gère les permissions à deux niveaux :

Niveau organisation : rôles Owner, ou permissions personnalisées (gestion des membres, des teams, des paramètres).
Niveau workspace : accès par team, avec des permissions fixes (Read, Plan, Write, Admin) ou personnalisées (ex. autoriser l’apply sans donner accès aux variables sensibles).

Les teams regroupent des utilisateurs et se voient assigner des permissions par workspace, ce qui permet par exemple de restreindre l’apply en prod à une team dédiée.

Run triggers et notifications

Les run triggers permettent de chaîner des workspaces : un apply réussi sur un workspace peut déclencher automatiquement un run sur un autre (ex. réseau → applicatif).
Les notifications (Slack, email, webhook générique) informent des événements d’un workspace (run créé, en attente, terminé, erreur).
Les run triggers sont destinés aux workspaces qui dépendent d’informations ou d’infrastructure produites par d’autres workspaces.
Un run déclenché par un run trigger n’est pas auto-appliqué, sauf si l’option “Auto-apply run triggers” est activée.

Workspaces vs Stacks

HCP Terraform Stacks est une fonctionnalité pour orchestrer plusieurs composants d’infrastructure liés comme une seule unité :

Workspace : une configuration, un state, un cycle de vie indépendant. Pour chaîner plusieurs workspaces (ex. réseau → applicatif), il faut des run triggers ou de l’orchestration externe.
Stack : regroupe plusieurs composants (chacun avec son propre state) déployés ensemble sur plusieurs environnements ou régions, avec un ordonnancement natif des dépendances entre composants et une configuration écrite en langage Terraform Stacks (basé sur HCL, fichiers .tfcomponent.hcl).

En résumé, un Stack remplace le pattern “plusieurs workspaces + run triggers” par une orchestration native quand les composants sont fortement couplés.

graph TD
    Org[Organisation] --> Proj[Projet]
    Proj --> WS1[Workspace: réseau]
    Proj --> WS2[Workspace: applicatif]
    Proj --> Stack[Stack]
    Stack --> C1[Composant: state 1]
    Stack --> C2[Composant: state 2]

Health checks

HCP Terraform peut vérifier périodiquement l’état d’un workspace en dehors des runs déclenchés manuellement :

Drift detection : lance un plan régulier pour détecter si l’infrastructure réelle a divergé du state (changement fait hors Terraform).
Continuous validation : réévalue en continu les blocs check de la configuration (ex. certificat encore valide, endpoint toujours joignable) même sans nouveau run.

Ces contrôles remontent des alertes sans forcément déclencher d’apply, ce qui aide à repérer une dérive avant qu’elle ne cause un incident.

Exécution en automation

HCP Terraform peut lancer des runs via trois mécanismes :

VCS-driven : déclenché par un push/PR sur le dépôt connecté (voir ci-dessus).
API-driven : déclenché par un appel à l’API HCP Terraform, utile pour l’intégrer à un pipeline CI/CD externe.
CLI-driven : terraform plan/apply lancés localement, mais exécutés à distance sur HCP Terraform grâce au bloc cloud (voir l’article sur le state).

Dans les trois cas, l’exécution du run (et l’accès aux credentials associés) a lieu sur l’infrastructure HCP Terraform, pas sur le poste ou l’agent qui déclenche l’opération.

Migrer son state vers HCP Terraform

Pour basculer un state existant (local ou backend distant type S3) vers HCP Terraform :

Ajouter un bloc cloud dans la configuration, avec l’organisation et le nom du workspace cible :

terraform {
  cloud {
    organization = "mon-org"
    workspaces {
      name = "mon-workspace"
    }
  }
}

Lancer terraform login pour s’authentifier auprès de HCP Terraform.
Lancer terraform init : Terraform détecte l’ancien backend et propose de migrer le state existant vers le workspace HCP Terraform.
Confirmer la migration : le state est copié, le workspace HCP Terraform en devient la nouvelle source de vérité.

Une fois migré, le mode d’exécution du workspace (remote par défaut, ou local) détermine si les plan/apply s’exécutent sur l’infrastructure HCP Terraform ou toujours en local avec state distant.

Ce que je retiens

Workspace CLI ≠ workspace HCP Terraform : le premier isole un state, le second isole un environnement complet (config, variables, historique).
Sentinel/OPA s’évaluent entre plan et apply : c’est le point de contrôle pour bloquer un changement non conforme avant qu’il ne soit appliqué.
Trois façons de déclencher un run : VCS, API ou CLI, mais l’exécution reste toujours centralisée côté HCP Terraform.

Fin de cette série sur le “learning path” Terraform Associate. La suite consistera à développer un projet pour mettre en application toutes les connaissances acquises avec le learning path.

Terraform Associate #6 — Le state

Tue, 18 Aug 2026 16:05:00 +0200

Suite de ma série sur la certification Terraform Associate, après les modules. Sixième objectif de l’exam guide, “Implement and maintain state” : cet article couvre le backend local, le locking, le remote state, l’authentification et la gestion des secrets dans le state.

Qu’est-ce que le state

Le state est un fichier (terraform.tfstate, au format JSON) dans lequel Terraform stocke le mapping entre les ressources déclarées dans la configuration et les objets réels de l’infrastructure. C’est ce fichier qui permet à Terraform de savoir quoi créer, modifier ou détruire à chaque plan/apply, sans avoir à interroger l’ensemble du provider à chaque fois.

Backend local

Par défaut, Terraform utilise le backend local : le state est stocké dans un fichier terraform.tfstate à la racine du répertoire de travail.

Simple à utiliser, aucune configuration requise.
Ne convient pas au travail en équipe : pas de lock partagé, pas de state partagé entre collaborateurs, secret stocké en clair sur le poste local.

State locking

Avant toute opération qui écrit dans le state (apply, parfois plan), Terraform tente de le verrouiller pour empêcher deux opérations concurrentes de le corrompre.

Le locking est supporté par la plupart des backends distants (S3, Azure Blob Storage, HCP Terraform…)
Si le lock ne peut pas être acquis, Terraform bloque l’opération et indique qui détient le lock.
L’option -lock=false permet de désactiver ce comportement, à éviter en usage normal.

Backend distant

Un backend distant stocke le state en dehors du poste local (bucket S3, Azure Blob Storage, GCS, HCP Terraform…). Il se déclare dans un bloc backend, imbriqué dans le bloc terraform.

terraform {
  backend "s3" {
    bucket         = "mon-bucket-tfstate"
    key            = "prod/network/terraform.tfstate"
    region         = "eu-west-1"
    dynamodb_table = "terraform-locks"
    encrypt        = true
  }
}

Avantages par rapport au backend local :

State partagé entre plusieurs collaborateurs ou pipelines CI/CD.
Locking natif.
Chiffrement.
Historique/versionning du state selon le backend.

Changer de backend nécessite de relancer terraform init, qui propose alors de migrer le state existant vers le nouveau backend.

HCP Terraform

HCP Terraform (anciennement Terraform Cloud) peut aussi servir de backend, via un bloc cloud plutôt que backend :

terraform {
  cloud {
    organization = "mon-org"

    workspaces {
      name = "prod-network"
    }
  }
}

En plus du stockage du state, HCP Terraform ajoute le locking, un historique des runs, et l’exécution du plan/apply à distance.

Authentification aux backends

Chaque backend a son propre mécanisme d’authentification, indépendant de celui des providers :

S3 : credentials AWS (variables d’environnement, profil CLI, rôle IAM).
Azure Blob Storage : Azure CLI, service principal, managed identity.
HCP Terraform : token d’API, généralement stocké dans ~/.terraform.d/credentials.tfrc.json via terraform login.

Ces credentials ne doivent jamais être codés en dur dans la configuration.

Effet de terraform refresh

terraform refresh (ou l’étape de refresh implicite lors d’un plan/apply) interroge les providers pour comparer l’état réel de l’infrastructure au state enregistré, et met à jour le state en conséquence.

Ne modifie jamais l’infrastructure réelle, uniquement le fichier de state.
Permet de détecter un drift (modification manuelle en dehors de Terraform).
Peut être désactivé avec -refresh=false pour accélérer un plan quand on est sûr qu’il n’y a pas eu de changement externe.

Secrets dans le state

Le state contient les valeurs de toutes les ressources qu’il suit, y compris les attributs sensibles (mots de passe générés, clés, tokens), même si la variable ou l’output correspondant est marqué sensitive. Comme évoqué dans l’article sur la configuration, sensitive masque seulement l’affichage dans les logs et l’UI, il ne retire rien du state.

Bonnes pratiques :

Toujours utiliser un backend distant chiffré at rest plutôt que le backend local.
Restreindre l’accès au state via des contrôles d’accès (IAM, permissions du backend).
Activer les logs d’audit du backend pour tracer les accès au state.
Préférer ephemeral/write-only quand c’est possible, pour éviter que la valeur n’atterrisse dans le state.

Commandes terraform state

Terraform fournit un sous-ensemble de commandes dédiées à l’inspection et la manipulation du state, sans passer par un apply :

terraform state list                    # liste les ressources trackées
terraform state show aws_instance.web   # détail d'une ressource dans le state
terraform state mv aws_instance.web aws_instance.app   # renomme/déplace une ressource dans le state
terraform state rm aws_instance.web     # retire une ressource du state (sans la détruire)
terraform state pull                    # affiche le state distant au format JSON
terraform state push                    # écrase le state distant (usage avancé, à risque)

terraform state list est généralement la première commande à lancer pour retrouver l’adresse exacte d’une ressource avant d’utiliser show, mv ou rm.

Importer une ressource existante

terraform import rattache une ressource déjà existante (créée manuellement ou par un autre outil) à un bloc resource du state, sans la recréer.

terraform import aws_instance.web i-0abcd1234

Le bloc resource "aws_instance" "web" { ... } doit déjà exister dans la configuration : la commande ne fait qu’ajouter l’entrée au state, elle ne génère aucun HCL.
Il faut ensuite compléter le bloc à la main pour que la configuration corresponde à la ressource réelle, sinon le prochain plan proposera des changements pour aligner l’un sur l’autre.
Fonctionne ressource par ressource : pas d’import groupé avec la commande CLI.

Logs

Terraform expose des logs de debug via la variable d’environnement TF_LOG, utile pour diagnostiquer un comportement inattendu (au niveau du core ou d’un provider).

export TF_LOG=DEBUG
terraform plan

Niveaux disponibles, du plus verbeux au moins verbeux : TRACE, DEBUG, INFO, WARN, ERROR.
TF_LOG_CORE et TF_LOG_PROVIDER permettent de cibler respectivement le cœur de Terraform ou les providers, indépendamment l’un de l’autre.
TF_LOG_PATH redirige les logs vers un fichier plutôt que stdout/stderr :

export TF_LOG=TRACE
export TF_LOG_PATH=./terraform.log

Penser à unset TF_LOG (et TF_LOG_PATH) une fois le diagnostic terminé, sinon chaque commande reste verbeuse.
Ces logs tracent l’exécution du CLI (appels aux providers, résolution de la configuration…), sans lien avec le contenu du state.

Ce que je retiens

Le backend local ne convient pas au travail en équipe : pas de locking partagé, secrets en clair sur le poste.
sensitive ≠ absent du state : seul ephemeral garantit qu’une valeur n’y est jamais écrite.
terraform refresh ne touche jamais l’infrastructure réelle, seulement le fichier de state, pour détecter un drift.
terraform import rattache une ressource existante au state sans la recréer, mais ne génère pas la configuration correspondante : à compléter à la main.
TF_LOG cible le core ou les providers séparément (TF_LOG_CORE/TF_LOG_PROVIDER), et n’a aucun effet sur le contenu du state.

Prochaine (et dernière) étape de la série : HCP Terraform.

Terraform Associate #5 — Les modules

Mon, 17 Aug 2026 16:44:02 +0200

Nous en sommes à un peu plus de la moitié du learning path pour l’obtention de la certification Terraform Associate, après le module sur la configuration. Cinquième objectif de l’exam guide, “Interact with Terraform modules” : cet article couvre les sources de module, les inputs/outputs, la portée des variables et le versionning.

Qu’est-ce qu’un module

Un module est un ensemble de fichiers .tf regroupés dans un même répertoire. Chaque configuration Terraform a au moins un module : le module racine, celui dans lequel on lance terraform apply. Les modules qu’il appelle sont des modules enfants, et peuvent eux-mêmes en appeler d’autres.

Regrouper des ressources dans un module permet de les réutiliser, de les partager entre équipes et de simplifier la configuration racine.

Utilisation

module "consul" {
  source  = "hashicorp/consul/aws"
  version = "0.1.0"

  servers = 3
}

source est le seul argument obligatoire : il indique où trouver le code du module.
terraform init télécharge et met en cache tout module référencé par la configuration.
Les autres arguments du bloc (servers ici) correspondent aux variables d’input déclarées par le module.

Sources de module

L’argument source détermine où et comment Terraform va chercher le module :

Chemin local (./modules/consul) : pas de téléchargement, le module suit le cycle de vie du code parent. Ne supporte pas le versionning.
Terraform Registry (hashicorp/consul/aws, format <namespace>/<nom>/<provider>) : source la plus courante pour les modules publics ou privés.
GitHub / Git / HTTP (git::https://example.com/vpc.git) : utile pour des modules non publiés sur un registre.
Buckets S3 / GCS : pour des modules stockés en interne sans registre dédié.

Seules les sources de registre (public ou privé) supportent l’argument version.

Inputs et outputs

Un module communique avec l’extérieur via des variables d’input et des outputs, comme évoqué dans l’article précédent sur les variables & outputs.

# modules/vpc/variables.tf
variable "cidr_block" {
  type = string
}

# modules/vpc/outputs.tf
output "vpc_id" {
  value = aws_vpc.this.id
}

# racine
module "network" {
  source     = "./modules/vpc"
  cidr_block = "10.0.0.0/16"
}

resource "aws_subnet" "web" {
  vpc_id = module.network.vpc_id
}

Les inputs se passent comme des arguments du bloc module.
Les outputs se référencent avec module.<nom>.<output>.

Portée des variables

Une variable ou un local défini dans un module n’est pas automatiquement visible dans les autres modules, parent ou enfant : chaque module a sa propre portée. Pour faire transiter une valeur :

Du parent vers l’enfant : passer un input au bloc module.
De l’enfant vers le parent : déclarer un output dans l’enfant, puis le référencer via module.<nom>.<output>.
Entre deux modules enfants : faire remonter la valeur au parent via un output, puis la repasser en input à l’autre module.

Il n’existe pas de variable globale partagée implicitement entre modules.

Registre public de modules

Le Terraform Registry héberge des modules publics, identifiés par <NAMESPACE>/<NOM>/<PROVIDER> (ex. terraform-aws-modules/vpc/aws). Chaque module y expose sa documentation, ses inputs/outputs et l’historique de ses versions. Les modules verified sont validés par HashiCorp ou un partenaire.

Versionning des modules

Pour les sources de registre, l’argument version accepte des contraintes :

Opérateur	Effet
`=` (ou rien)	Version exacte
`!=`	Exclut une version
`>`, `>=`, `<`, `<=`	Comparaison
`~>`	Autorise seulement le dernier composant à incrémenter (ex. `~> 2.1` autorise `2.1.x` mais pas `2.2`)

module "consul" {
  source  = "hashicorp/consul/aws"
  version = "~> 0.1"
}

Fixer une version évite qu’une mise à jour du module casse la configuration lors d’un prochain terraform init. Sans contrainte, Terraform utilise la dernière version disponible.

Ce que je retiens

Un module = un répertoire de fichiers .tf : la configuration racine est elle-même un module.
Seules les sources de registre supportent le versionning : un chemin local ou une source git suit le cycle de vie du code parent.
Pas de portée globale : toute communication entre modules passe explicitement par des inputs et des outputs.

Prochaine étape de la série : le state management.

Terraform Associate #4 — Terraform Configuration

Mon, 17 Aug 2026 12:56:18 +0200

Suite de ma série sur la certification Terraform Associate, après le module sur le workflow. Le quatrième objectif de l’exam guide, “Read and write configuration”, est le plus dense. Celui-ci couvre les resources, les data sources, le système de types et les expressions conditionnelles, ainsi que la gestion des sensitive data.

Resources

Le bloc resource est l’unité de base de la configuration : c’est lui qui déclare une ressource gérée par Terraform (créée, modifiée et détruite selon le state).

resource "aws_instance" "web" {
  ami           = "ami-0abcd1234"
  instance_type = "t3.micro"
}

Les types de ressources disponibles dépendent des providers installés.
aws_instance est le type de ressource, web est le nom local : ensemble ils forment l’adresse aws_instance.web, utilisée pour y référer ailleurs dans la configuration ou en CLI (terraform state show aws_instance.web).
Les méta-arguments s’appliquent à n’importe quel type de resource, indépendamment du provider.
Ils déterminent comment Terraform crée et gère la ressource, par exemple :
- count : crée N instances de la ressource, indexées (aws_instance.web[0]).
- for_each : crée une instance par élément d’une map ou d’un set, indexées par clé (aws_instance.web["a"]) — plus robuste que count quand la liste peut changer, car ça évite de décaler les index existants.
- depends_on : force une dépendance explicite quand Terraform ne peut pas la déduire des références entre arguments.
- lifecycle : bloc imbriqué pour affiner le comportement (create_before_destroy, prevent_destroy, ignore_changes).

Data sources

Terraform peut aller chercher des données auprès d’un large éventail de data sources : API, autres workspaces Terraform, outputs de fonctions… Ce fetch dynamique rend la configuration plus flexible, mais ne crée ni ne modifie aucune ressource.

data "aws_ami" "web" {
  most_recent = true
  owners      = ["amazon"]

  filter {
    name   = "name"
    values = ["amzn2-ami-hvm-*-x86_64-gp2"]
  }
}

resource "aws_instance" "web" {
  ami           = data.aws_ami.web.id
  instance_type = "t3.micro"
}

Terraform tente d’interroger les data sources dès la phase de plan, mais peut différer la lecture à la phase d’apply selon la configuration.
Ajouter un argument depends_on à un bloc data force Terraform à différer la lecture jusqu’à l’apply.
On peut ajouter des blocs precondition et postcondition.
On peut ajouter les méta-arguments count et for_each aux blocs data pour créer plusieurs instances de la data source.
La syntaxe data.<TYPE>.<LABEL>.<ATTRIBUTE> permet de référencer les attributs d’une data resource ailleurs dans la configuration.

Types

Terraform a son propre système de types, utilisé notamment pour contraindre les variables (variable "x" { type = ... }) et pour typer les valeurs manipulées dans la configuration.

Primitifs : string, number, bool.
Collections (éléments d’un seul type) : list(type), set(type), map(type).
Structurels (éléments de types différents, structure fixe) : object({ ... }), tuple([...]).

variable "instance_type" {
  type    = string
  default = "t3.micro"
}

variable "tags" {
  type    = map(string)
  default = {}
}

variable "network" {
  type = object({
    cidr_block = string
    az_count   = number
  })
}

Terraform effectue des conversions implicites quand c’est possible (une list sans type déclaré est inférée, un number peut être converti en string dans une interpolation), mais déclarer le type explicitement sur les variables reste la meilleure protection contre une valeur mal formée passée en entrée d’un module.

Références

On peut référencer les ressources dans notre configuration de plusieurs façons.

Références de ressources

Une adresse de ressource :

[chemin de module][spec de ressource]

Chemin de module

module.nom_module[index de module]

Chemin de module complexe

module.foo[0].module.bar[“a”]

Chemin de spec de ressource

type_de_ressource.nom_ressource[index d’instance]

Valeurs pas encore connues

Quand Terraform planifie des changements pour appliquer la configuration, certaines valeurs ne peuvent pas être renseignées immédiatement car elles sont décidées dynamiquement par le système distant.

Ces valeurs inconnues apparaissent dans la sortie de terraform plan sous la forme (known after apply).

Variables & outputs

Les modules Terraform communiquent entre eux via des inputs et des outputs. Les variables permettent de paramétrer un module pour que d’autres utilisateurs puissent fournir des valeurs personnalisées au runtime.

Outputs

Ils exposent des données d’un module, permettant d’exporter des informations sur l’infrastructure. La valeur d’un bloc output s’apparente à une valeur de retour dans d’autres langages de programmation.

output "instance_public_ip" {
  description = "IP publique de l'instance web"
  value       = aws_instance.web.public_ip
}

Locals

Les locals permettent de définir et réutiliser des expressions au sein d’un module.

locals {
  name_prefix = "${var.project}-${var.environment}"
  common_tags = {
    project = var.project
    env     = var.environment
  }
}

resource "aws_instance" "web" {
  ami           = "ami-0abcd1234"
  instance_type = "t3.micro"
  tags          = local.common_tags
}

Types complexes

Un type complexe regroupe plusieurs valeurs en une seule.

Collection

list(...) : une séquence de valeurs identifiées par des entiers consécutifs à partir de zéro.
map(...) : une collection de valeurs où chacune est identifiée par un label de type string.
set(...) : une collection de valeurs uniques, sans identifiant secondaire ni ordre.

variable "azs" {
  type    = list(string)
  default = ["eu-west-1a", "eu-west-1b"]
}

variable "tags" {
  type    = map(string)
  default = { env = "prod", team = "infra" }
}

variable "allowed_ports" {
  type    = set(number)
  default = [80, 443]
}

Types structurels

object(...) : un ensemble d’attributs nommés ayant chacun leur propre type (ex : object({ name=string, age=number })).
tuple(...) : une séquence d’éléments identifiés par des entiers consécutifs à partir de zéro, chaque élément ayant son propre type (ex : tuple([string, number, bool])).

variable "network" {
  type = object({
    cidr_block = string
    az_count   = number
  })
  default = {
    cidr_block = "10.0.0.0/16"
    az_count   = 2
  }
}

Any

any est rarement le bon type à utiliser. Toujours spécifier le type exact, sauf en cas de données réellement dynamiques.

Validation de la configuration

terraform validate

La validation permet de vérifier que la configuration Terraform fonctionne comme prévu.

Moyens de validation

Terraform propose plusieurs moyens de valider la configuration :

Les validations de variables d’input vérifient les paramètres de la configuration au moment du plan.
Les preconditions s’assurent qu’une resource, data source ou output individuel respecte les exigences avant que Terraform ne tente de la créer.
Les postconditions vérifient que Terraform a produit les resources et data sources avec les propriétés attendues.
Les checks permettent de valider que l’infrastructure se comporte comme prévu sans bloquer les opérations Terraform selon leur résultat.

resource "aws_instance" "web" {
  ami           = "ami-0abcd1234"
  instance_type = "t3.micro"

  lifecycle {
    precondition {
      condition     = data.aws_ami.web.architecture == "x86_64"
      error_message = "L'AMI doit être en x86_64."
    }

    postcondition {
      condition     = self.public_ip != ""
      error_message = "L'instance doit avoir une IP publique."
    }
  }
}

check "site_up" {
  data "http" "homepage" {
    url = "https://${aws_instance.web.public_ip}"
  }

  assert {
    condition     = data.http.homepage.status_code == 200
    error_message = "Le site ne répond pas en HTTP 200."
  }
}

Checks

Le bloc check sert à valider l’infrastructure en dehors du cycle de vie habituel des ressources. Il s’exécute en dernière étape d’un plan ou d’un apply, une fois que Terraform a planifié ou provisionné l’infrastructure. Quand l’assertion d’un bloc check échoue, Terraform émet un warning et poursuit l’opération en cours.

Il permet de :

Valider des resources, data sources, variables ou outputs de la configuration.
Valider le comportement de l’infrastructure dans son ensemble.
Vérifier la configuration de l’infrastructure sans bloquer les opérations.
Effectuer une validation continue dans HCP Terraform.

Workflow de validation

Terraform valide les différents aspects de la configuration le plus tôt possible. En général, l’ordre d’exécution est le suivant :

flowchart TD
    A[Validations de variables d'entrée] --> B[Génération du plan]
    B --> C[Preconditions]
    C --> D[Création / modification de la resource, data source ou output]
    D --> E[Postconditions]
    E --> F[Apply terminé]
    F --> G[Checks]
    G -.->|HCP Terraform| H[Health assessments périodiques]

Gérer les données sensibles

Terraform peut avoir besoin d’accéder à des données sensibles (credentials cloud, tokens API, autres secrets) pour provisionner l’infrastructure. Terraform stocke le state dans un fichier en clair, qui inclut toute valeur secrète définie dans la configuration.

Argument sensitive

L’argument sensitive sur un bloc variable ou output permet de masquer ces valeurs dans les logs du CLI Terraform et dans l’UI HCP Terraform.

Argument ephemeral

Les valeurs ephemeral sont disponibles au runtime d’une opération, mais Terraform les omet des fichiers de state et de plan.

Quand les utiliser ?

	`sensitive`	`ephemeral`
Où l’utiliser	Bloc `variable` ou `output`	Bloc `variable`, output d’un module enfant, bloc `ephemeral`, argument write-only, `provider`, `provisioner`/`connection`
Effet sur le state/plan	Reste dans le state, mais masqué dans les logs CLI et l’UI HCP Terraform	Jamais persisté dans le state ni le plan
Effet sur l’affichage	Valeur remplacée par `(sensitive value)` dans le plan/apply	Valeur disponible uniquement au runtime de l’opération
Portée d’usage	Utilisable partout où la variable/output est référencé	Restreint aux contextes ephemeral listés ci-dessus
Cas d’usage typique	Mot de passe affiché dans un output	Token temporaire passé à un provider ou une resource

Arguments write-only

Les arguments write-only permettent de passer de façon sécurisée des valeurs temporaires aux managed resources de Terraform pendant une opération, sans les persister dans le state ou les fichiers de plan.

resource "aws_db_instance" "db" {
  identifier             = "app-db"
  password_wo            = var.db_password
  password_wo_version    = 1
}

variable "db_password" {
  type      = string
  ephemeral = true
}

Bonnes pratiques de sécurité

Si des valeurs sensibles sont stockées dans un fichier de state, il est recommandé de mettre en place des mesures de sécurité supplémentaires :

Stocker le state à distance.
Chiffrer le state au repos.
Utiliser des contrôles d’accès pour limiter qui peut accéder au state.
Utiliser des logs d’audit pour tracer les accès au state dans le temps.

Ce que je retiens

count vs for_each : for_each évite le décalage d’index quand la liste change, à privilégier dès que les éléments sont identifiables par une clé stable.
Preconditions, postconditions et checks ne servent pas la même chose : les deux premières bloquent le plan/apply sur une resource précise, les checks valident l’infrastructure globalement sans bloquer.
sensitive masque l’affichage, ephemeral évite la persistance : seul ephemeral garantit qu’une valeur n’atterrit jamais dans le state ou le plan.

Prochaine étape de la série : les modules.

Terraform Associate #3 — Core Terraform Workflow

Sun, 16 Aug 2026 16:53:36 +0200

Suite de ma série sur la certification Terraform Associate, après le module sur les providers et le state. Le troisième objectif de l’exam guide s’intitule “Core Terraform workflow”.

Le cycle Write, Plan, Apply

Le workflow Terraform “de base” (un seul développeur, sans HCP Terraform ni CI) tient en trois étapes qui se répètent :

Write : j’écris ou je modifie la configuration HCL.
Plan : Terraform compare la configuration au state et à l’infrastructure réelle, puis affiche le diff des actions qu’il compte effectuer.
Apply : Terraform exécute ce plan et met à jour le state en conséquence.

terraform init

Première commande à lancer dans un nouveau répertoire de configuration, ou après avoir ajouté un nouveau provider/module :

Télécharge les providers déclarés dans required_providers et les modules référencés, puis met à jour le fichier de lock (vu dans le module précédent).
Configure le backend (local par défaut, ou distant s’il est défini).
Idempotente : la relancer sur un répertoire déjà initialisé ne casse rien, c’est même le réflexe à avoir après un git pull qui touche aux versions de providers.

terraform init

terraform fmt et terraform validate

Deux commandes rapides à passer avant de committer, qui ne touchent ni au state ni à l’infrastructure :

terraform fmt reformate les fichiers .tf selon la convention de style canonique (indentation, alignement des =).
terraform validate vérifie que la configuration est syntaxiquement correcte et cohérente en interne (types, arguments requis, références). Elle ne contacte pas le provider et ne sait donc pas si une ressource existe déjà ou si les credentials sont valides.

terraform fmt -recursive
terraform validate

terraform plan

C’est l’étape qui rend Terraform prévisible : avant de toucher à quoi que ce soit, il annonce ce qu’il va faire.

Compare la configuration, le state, et l’état réel de l’infrastructure via des appels en lecture au provider.
Affiche un diff coloré : + création, - destruction, ~ mise à jour, et parfois -/+ (destroy puis recreate, quand un attribut ne peut pas être modifié en place).
Peut être sauvegardé dans un fichier avec -out, pour garantir que l’apply qui suit exécute exactement ce plan et rien d’autre (important en CI, où le code peut changer entre les deux étapes).

terraform plan -out=tfplan

terraform apply

Exécute les actions du plan et persiste le résultat dans le state.

Sans fichier de plan en argument, apply recalcule un plan et demande une confirmation interactive (yes) avant d’exécuter.
Avec un fichier de plan (terraform apply tfplan), aucune confirmation n’est demandée : c’est le mode utilisé en CI/CD, après une revue humaine du plan affiché en amont.
Terraform ordonne les créations/modifications/destructions selon le graphe de dépendances qu’il construit à partir de la configuration, pas selon l’ordre d’écriture des blocs.

terraform apply tfplan

terraform destroy

Détruit toutes les ressources gérées par le state courant.

Fonctionne comme un apply dont le plan ne contient que des destructions.
-target permet de limiter la portée à une ressource précise, mais c’est un outil de dépannage ponctuel, pas une pratique à généraliser : il casse la vision globale du plan et peut laisser des ressources dans un état incohérent avec la configuration.

terraform destroy

Ce qu’il faut retenir

plan avant apply n’est pas optionnel : c’est la seule étape qui donne une visibilité sur ce qui va changer avant que ça ne change réellement.
-out transforme un plan en contrat : ce qui a été revu est exactement ce qui sera appliqué, ce qui est indispensable dès qu’un pipeline CI s’intercale entre la revue humaine et l’exécution.
fmt et validate sont des commandes de formattage et validation syntaxique, l’infrastructure sous jacente n’est pas analysée.

Prochaine étape de la série : la configuration Terraform.

Terraform Associate #2 — Terraform fundamentals

Sun, 16 Aug 2026 13:48:17 +0200

Suite de ma série sur la certification Terraform Associate, après le premier module sur l’Infrastructure as Code. Le deuxième module de l’exam guide s’intitule “Terraform Fundamentals” : il s’agit de comprendre ce que sont les providers et comment le state fonctionne.

Les providers

Terraform ne parle nativement à aucun cloud. Tout se fait via des providers : des plugins qui traduisent le langage déclaratif HCL en appels API vers AWS, GCP, Azure, mais aussi Kubernetes, Cloudflare, Datadog, GitHub… Le cœur de Terraform (le CLI, le state, le langage) reste identique quel que soit le provider utilisé.

Chaque provider ajoute un ensemble de types de ressources et/ou de data sources que Terraform peut gérer.
Chaque type de ressource est implémenté par un provider ; sans providers, Terraform ne peut gérer aucun type d’infrastructure.
Terraform exige un nom local unique pour chaque provider au sein d’un module.
N’importe qui peut développer et distribuer ses propres providers Terraform
Quand un provider est défini dans le module racine, Terraform transmet implicitement cette configuration à tous les modules enfants, afin que tous les modules utilisent la même configuration.

Ne pas confondre required_providerset provider:

required_providers

Sert uniquement à terraform init : source (adresse dans le registry) + contrainte de version, pour savoir quel plugin télécharger.
Pas de credentials, pas de région, aucune logique d’exécution.
Un seul bloc par module.

provider

Configure une instance réelle du provider : région, credentials, endpoints custom, etc.
Peut apparaître plusieurs fois pour le même provider via alias (ex. déployer sur plusieurs régions AWS dans le même module).
Sans lui, init fonctionne mais plan/apply échouera (ou retombera sur des credentials par défaut via variables d’env/CLI).

Dependency lock

Le fichier lock ne suit que les dépendances des providers.
Terraform crée ou met à jour automatiquement ce fichier à chaque exécution de terraform init.
Ce fichier appartient à la configuration dans son ensemble, et non à chaque module pris séparément.

Comportement d’installation des dépendances

Quand terraform init installe les providers nécessaires à une configuration, Terraform prend en compte à la fois les contraintes de version de la configuration et celles déjà enregistrées dans le fichier de lock.
Si un provider n’a pas encore de version enregistrée, Terraform choisit la version la plus récente qui respecte la contrainte, puis met à jour le fichier de lock avec ce choix.
On peut forcer ce comportement avec l’option -upgrade sur terraform init.

Le state : la mémoire de Terraform

Le fichier terraform.tfstate est ce qui permet à Terraform d’être déclaratif : c’est lui qui fait le lien entre la configuration HCL (ce que je veux) et les ressources réellement créées chez le fournisseur (ce qui existe). Sans state, Terraform ne pourrait pas savoir qu’un aws_instance.web dans le code correspond à l’instance i-0abc123 déjà en place.

Ses rôles concrets :

Mapping vers le monde réel. Le state associe chaque ressource déclarée à un identifiant réel côté fournisseur, indispensable pour savoir quoi modifier ou détruire.
Metadata. Il stocke aussi des informations que l’API du fournisseur n’expose pas toujours (dépendances entre ressources, par exemple), utiles pour calculer un plan correct.
Performance. Pour de grosses infrastructures, relire l’état de centaines de ressources via l’API à chaque commande serait lent. Le state fait office de cache.
Collaboration. En le stockant à distance (S3, GCS, Terraform Cloud…) avec un mécanisme de lock, plusieurs personnes peuvent exécuter des apply sans risquer d’écraser le travail des autres. C’est un point que j’avais déjà creusé en pratique dans mes articles sur the-forge-infra.

State distant (remote state)

Terraform écrit les données de state dans un espace de stockage distant, qui peut ensuite être partagé entre tous les membres d’une équipe. Terraform prend en charge le stockage du state dans HCP Terraform, HashiCorp Consul, Amazon S3, Azure Blob Storage, Google Cloud Storage, Alibaba Cloud OSS, et d’autres.
Le state distant est implémenté par un backend, ou par HCP Terraform, tous deux configurables dans le module racine de la configuration.
La data source terraform_remote_state utilise le dernier snapshot de state d’un backend donné pour récupérer les valeurs de sortie (outputs) du module racine d’une autre configuration Terraform.
Pour les backends distants les plus complets, Terraform peut aussi verrouiller le state afin d’empêcher des exécutions concurrentes sur le même state.

Ce que je retiens

required_providers vs provider : le premier dit à terraform init quoi télécharger (source, version), le second configure une instance réelle (région, credentials) et peut se dupliquer via des alias.
Le state n’est pas un détail d’implémentation : c’est lui qui fait le lien entre le code HCL et les ressources réelles, sert de cache de métadonnées pour construire les plans, et permet le travail en équipe une fois stocké à distance avec un lock.
Le fichier de lock ne concerne que les providers : il garantit des versions reproductibles à init, indépendamment des modules.

Prochaine étape de la série : le workflow Terraform.

Terraform Associate #1 — Infrastructure as Code

Sun, 16 Aug 2026 13:44:02 +0200

Comme annoncé précédemment, je prépare la certification Terraform Associate. Premier objectif de l’exam guide : “Understand Infrastructure as Code (IaC) concepts”. Avant de parler syntaxe HCL ou providers, il s’agit de poser les bases : qu’est-ce que l’IaC, et pourquoi ça a remplacé la gestion manuelle d’infrastructure.

Qu’est-ce que l’Infrastructure as Code

L’Infrastructure as Code, c’est décrire son infrastructure (serveurs, réseau, bases de données, permissions IAM…) sous forme de fichiers texte versionnables, plutôt que de la construire à la main via une console web ou des commandes ad hoc.

Ces fichiers deviennent la source de vérité : un outil (Terraform, mais aussi Pulumi, CloudFormation, Ansible…) les lit et se charge de créer, modifier ou supprimer les ressources correspondantes chez le fournisseur cloud.

Deux façons d’écrire cette description :

Impératif : on décrit la suite d’étapes pour arriver au résultat (“crée un VPC, puis crée un subnet dedans, puis attache une route table…”). C’est l’approche d’un script bash ou d’un playbook Ansible classique.
Déclaratif : on décrit l’état final voulu (“je veux un VPC avec ce CIDR et ces subnets”), et l’outil calcule lui-même les actions nécessaires pour y parvenir. C’est l’approche de Terraform.

L’approche déclarative est centrale pour comprendre Terraform : on ne lui dit jamais “crée ceci”, on lui dit “voici l’état que je veux”, et c’est le moteur (via le state et le plan) qui détermine le diff à appliquer.

Idempotence

Une propriété qui découle directement du déclaratif : réappliquer la même configuration plusieurs fois de suite ne doit rien changer si l’infrastructure correspond déjà à l’état décrit. terraform apply sur une configuration inchangée doit annoncer “No changes.” C’est ce qui rend l’IaC fiable en CI/CD : on peut la rejouer sans craindre de dupliquer des ressources ou de casser l’existant.

Pourquoi l’IaC plutôt que le clic dans une console

C’est la deuxième partie de l’objectif de l’exam guide : “Describe advantages of IaC patterns”. Ce qui m’a personnellement convaincu, avant même de penser à une certification :

Versioning et historique. Chaque changement d’infra passe par un commit Git, avec un auteur, une date et (idéalement) une revue de code. Impossible d’obtenir ça avec des clics dans une console.
Collaboration. Plusieurs personnes peuvent travailler sur la même infrastructure via des pull requests, sans se marcher dessus ni se demander “qui a changé ce security group hier soir”.
Reproductibilité. Recréer un environnement identique (staging, nouvelle région, nouveau client) devient une question de minutes, pas de jours de configuration manuelle.
Documentation vivante. Le code Terraform décrit l’infrastructure telle qu’elle est réellement, contrairement à un wiki qui devient obsolète dès qu’on oublie de le mettre à jour.
Réduction de l’erreur humaine. Un plan Terraform montre le diff avant application ; un clic malheureux dans une console, lui, ne prévient pas.

Ce que je retiens

Ce premier module reste conceptuel, mais il pose un vocabulaire que je retrouverai tout au long de la certification : déclaratif, idempotence, state. Le module suivant s’attaque aux providers et au state.

Objectif certification Terraform Associate

Sat, 15 Aug 2026 18:25:02 +0200

Terraform, je l’utilise quasiment au quotidien : que ce soit sur TheForge ou en entreprise, c’est l’outil que je manipule le plus après Kubernetes. Mais jusqu’ici, mes connaissances se sont construites au fil des besoins, projet après projet, sans jamais couvrir l’ensemble des concepts de façon structurée.

Je me lance donc dans la préparation de la certification HashiCorp Certified: Terraform Associate. L’objectif n’est pas tant le badge en lui-même que de combler les angles morts : provider versioning, state management avancé, modules, workspaces, sont autant de sujets que j’utilise sans toujours en maîtriser toutes les subtilités.

Pourquoi cette certification

Trois raisons principales m’ont poussé à me lancer :

Structurer des connaissances acquises en pratique. Apprendre “sur le tas” laisse forcément des trous : on maîtrise ce dont on a eu besoin, pas nécessairement ce qui est important.
Valider mes acquis avec un référentiel externe. Un examen impose un niveau d’exigence que l’auto-formation seule n’impose pas toujours.
Une certification reconnue dans l’écosystème DevOps/Cloud, utile aussi bien pour mes projets personnels que pour mon activité professionnelle.

Comment je vais m’organiser

Mon plan de préparation :

Reprendre la documentation officielle Terraform et l’exam guide point par point.
Manipuler chaque concept dans un contexte concret, en m’appuyant sur mes projets existants (notamment the-forge-infra) plutôt que sur des exemples jetables.
M’entraîner sur des questions type examen pour identifier mes points faibles avant de passer le test.

La suite

Je partagerai mon parcours d’apprentissage dans de prochains articles : les notions qui m’ont surpris, les pièges classiques de l’examen, et ce que je retiens une fois la certification passée. Rendez-vous dans les prochains articles pour la suite de cette préparation.