Cheatsheet Professional : commandes Terraform avancées

Référence centrée sur la vitesse d’exécution en lab. L’examen Professional est 100% pratique : vous écrivez du HCL, vous exécutez des commandes et vous résolvez des problèmes réels. Cette page couvre les commandes avancées organisées par objectif d’examen.

Rappel format examen

Critère	Valeur
Format	Lab pratique + QCM (objectif 6)
Durée	4 heures (pause 15 min incluse)
Version testée	Terraform 1.6
Provider	AWS
Clavier	US English QWERTY uniquement
Documentation	Terraform docs + Registry limité + doc cloud limitée + console AWS
Moteurs de recherche	Non — aucun accès externe
Prix	295 USD (free retake inclus)

Glissez pour voir

Tableau “besoin → commande”

Besoin	Commande
Importer une ressource existante	terraform import <addr> <id>
Renommer une ressource (déclaratif)	Bloc moved {}
Forcer la recréation	terraform apply -replace=<addr>
Lister les ressources du state	terraform state list
Inspecter une ressource	terraform state show <addr>
Déplacer dans le state	terraform state mv <old> <new>
Retirer du state sans détruire	terraform state rm <addr>
Exécuter les tests	terraform test
Sauvegarder un plan	terraform plan -out=tfplan
Appliquer un plan sauvegardé	terraform apply tfplan
Réconcilier le state (changements hors Terraform)	terraform plan -refresh-only
Mettre à jour les providers	terraform init -upgrade
Debug avancé	TF_LOG=TRACE terraform plan
Voir les providers requis	terraform providers
Voir les versions Terraform + providers installés	terraform version
Mettre à jour / préremplir le lock file	terraform providers lock
Lire le lock file	Ouvrir .terraform.lock.hcl
Afficher un output sensible	terraform output -raw <name>

Glissez pour voir

---

Objectif 1 — Manage resource lifecycle

Import d’une ressource existante

# Import classique (CLI)
terraform import aws_instance.web i-0abc123def456

# Import avec adresse de module
terraform import module.vpc.aws_vpc.main vpc-0abc123

Bloc import (déclaratif — Terraform 1.5+) :

import {
  to = aws_instance.web
  id = "i-0abc123def456"
}

# Générer le code HCL automatiquement
terraform plan -generate-config-out=generated_resources.tf

Import déclaratif = préféré

Le bloc import {} est préférable à la commande CLI : il est versionné dans le code, reproductible et peut générer le HCL automatiquement. Utilisez la commande CLI seulement pour les imports ponctuels.

Bloc moved (refactoring)

# Renommer une ressource
moved {
  from = aws_instance.web
  to   = aws_instance.application
}

# Déplacer dans un module
moved {
  from = aws_instance.web
  to   = module.compute.aws_instance.main
}

# Renommer un module
moved {
  from = module.old_name
  to   = module.new_name
}

Vérification :

# Le plan doit montrer "moved" sans create/destroy
terraform plan
# → aws_instance.application has moved from aws_instance.web

removed {} — hors périmètre examen (Terraform 1.7)

Le bloc removed {} est l’alternative déclarative à terraform state rm — il retire une ressource du state sans la détruire (avec lifecycle { destroy = false }). Cependant, ce bloc a été introduit en Terraform 1.7. L’examen Professional teste sur Terraform 1.6 : utilisez terraform state rm à la place.

Manipulation du state

# Lister toutes les ressources
terraform state list

# Filtrer par adresse
terraform state list module.vpc

# Inspecter une ressource en détail
terraform state show aws_instance.web

# Déplacer (opération manuelle ponctuelle)
terraform state mv aws_instance.web aws_instance.application
terraform state mv aws_instance.web module.compute.aws_instance.main

# Retirer du state (la ressource reste dans AWS)
terraform state rm aws_instance.legacy

# Télécharger le state distant en JSON
terraform state pull

# Envoyer un state local vers le backend
terraform state push terraform.tfstate

state mv = opération dangereuse

state mv modifie le state directement. En cas d’erreur, la ressource devient orpheline ou dupliquée. Préférez moved {} quand c’est possible. Si vous devez utiliser state mv, faites un state pull de sauvegarde avant.

Recréation forcée

# Forcer la destruction + recréation d'une ressource
terraform apply -replace=aws_instance.web

# Avec un plan sauvegardé
terraform plan -replace=aws_instance.web -out=tfplan
terraform apply tfplan

Options avancées de plan et apply

# Plan avec cible spécifique
terraform plan -target=module.vpc

# Plan de destruction
terraform plan -destroy

# Apply sans interaction (CI/CD)
terraform apply -input=false -auto-approve

# Refresh only (réconcilier le state avec l'infrastructure réelle)
terraform apply -refresh-only -auto-approve

# Parallélisme (par défaut : 10)
terraform apply -parallelism=20

Provisioners (dernier recours)

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

  # Exécution locale après création
  provisioner "local-exec" {
    command = "echo ${self.private_ip} >> hosts.txt"
  }

  # Exécution distante
  provisioner "remote-exec" {
    inline = [
      "sudo apt-get update",
      "sudo apt-get install -y nginx"
    ]

    connection {
      type        = "ssh"
      user        = "ubuntu"
      private_key = file("~/.ssh/id_rsa")
      host        = self.public_ip
    }
  }

  # Exécution à la destruction
  provisioner "local-exec" {
    when    = destroy
    command = "echo 'Instance destroyed'"
  }
}

Provisioners = dernier recours

HashiCorp recommande d’éviter les provisioners quand des alternatives existent (user_data, cloud-init, Ansible, Packer). Les provisioners rendent la configuration non déclarative et compliquent le plan. L’examen attend que vous sachiez les utiliser et que vous compreniez leurs limites.

---

Objectif 2 — Dynamic configuration

Preconditions et postconditions

resource "aws_instance" "web" {
  ami           = var.ami_id
  instance_type = var.instance_type

  lifecycle {
    # Vérification AVANT la création
    precondition {
      condition     = can(regex("^ami-", var.ami_id))
      error_message = "L'AMI doit commencer par 'ami-'."
    }

    # Vérification APRÈS la création
    postcondition {
      condition     = self.public_ip != ""
      error_message = "L'instance doit avoir une IP publique."
    }
  }
}

Check blocks

check "website_health" {
  data "http" "app" {
    url = "https://${aws_lb.main.dns_name}/health"
  }

  assert {
    condition     = data.http.app.status_code == 200
    error_message = "Le site ne répond pas correctement."
  }
}

terraform test

tests/main.tftest.hcl

variables {
  instance_type = "t3.micro"
  environment   = "test"
}

run "create_instance" {
  command = apply

  assert {
    condition     = aws_instance.web.instance_type == "t3.micro"
    error_message = "Mauvais type d'instance."
  }

  assert {
    condition     = aws_instance.web.tags["Environment"] == "test"
    error_message = "Tag Environment incorrect."
  }
}

run "verify_plan_only" {
  command = plan

  assert {
    condition     = aws_instance.web.ami != ""
    error_message = "AMI non définie."
  }
}

# Exécuter les tests
terraform test

# Tests verbeux
terraform test -verbose

# Filtre sur un fichier de test
terraform test -filter=tests/main.tftest.hcl

Dynamic blocks

variable "ingress_rules" {
  type = list(object({
    port        = number
    protocol    = string
    cidr_blocks = list(string)
  }))
  default = [
    { port = 80, protocol = "tcp", cidr_blocks = ["0.0.0.0/0"] },
    { port = 443, protocol = "tcp", cidr_blocks = ["0.0.0.0/0"] },
  ]
}

resource "aws_security_group" "web" {
  name = "web-sg"

  dynamic "ingress" {
    for_each = var.ingress_rules
    content {
      from_port   = ingress.value.port
      to_port     = ingress.value.port
      protocol    = ingress.value.protocol
      cidr_blocks = ingress.value.cidr_blocks
    }
  }
}

Fonctions avancées

# flatten : aplatir des listes imbriquées
locals {
  all_subnets = flatten([
    for env, config in var.environments : [
      for subnet in config.subnets : {
        env    = env
        cidr   = subnet
      }
    ]
  ])
}

# setproduct : produit cartésien
locals {
  az_subnet_pairs = setproduct(var.azs, var.subnet_cidrs)
}

# cidrsubnet : calcul de sous-réseaux
locals {
  subnets = [for i in range(3) : cidrsubnet("10.0.0.0/16", 8, i)]
  # → ["10.0.0.0/24", "10.0.1.0/24", "10.0.2.0/24"]
}

# templatefile : template avec variables
resource "aws_instance" "web" {
  user_data = templatefile("${path.module}/user-data.tpl", {
    hostname = var.hostname
    packages = join(" ", var.packages)
  })
}

# try et can : gestion d'erreurs
locals {
  name = try(var.config.name, "default")
  is_valid = can(regex("^[a-z]+$", var.input))
}

Types complexes et optional

variable "server_config" {
  type = object({
    name          = string
    instance_type = optional(string, "t3.micro")
    tags          = optional(map(string), {})
    monitoring    = optional(object({
      enabled  = bool
      interval = optional(number, 60)
    }), { enabled = false })
  })
}

---

Objectif 3 — Collaborative workflows

Backend S3 avec locking DynamoDB

terraform {
  backend "s3" {
    bucket         = "my-terraform-state"
    key            = "production/terraform.tfstate"
    region         = "eu-west-1"
    dynamodb_table = "terraform-locks"
    encrypt        = true
  }
}

Remote state (lecture)

# Lire le state d'une autre configuration
data "terraform_remote_state" "vpc" {
  backend = "s3"
  config = {
    bucket = "my-terraform-state"
    key    = "network/terraform.tfstate"
    region = "eu-west-1"
  }
}

# Utiliser les outputs
resource "aws_instance" "web" {
  subnet_id = data.terraform_remote_state.vpc.outputs.private_subnet_ids[0]
}

tfe_outputs (alternative HCP Terraform)

# Lire les outputs d'un workspace HCP Terraform
data "tfe_outputs" "network" {
  config = {
    organization = "my-org"
    workspaces = {
      name = "network-prod"
    }
  }
}

resource "aws_instance" "web" {
  subnet_id = data.tfe_outputs.network.outputs.subnet_id
}

tfe_outputs vs terraform_remote_state

tfe_outputs est l’alternative recommandée à terraform_remote_state quand vous utilisez HCP Terraform. Il accède directement aux outputs du workspace distant via le bloc config (organisation + workspace). L’accès se fait via .outputs.<nom>, pas .values.

Version constraints

terraform {
  required_version = ">= 1.6.0, < 2.0.0"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

Syntaxe des contraintes :

Opérateur	Signification	Exemple
=	Exactement	= "5.0.0"
!=	Pas cette version	!= "5.1.0"
>, >=, <, <=	Comparaison	>= 5.0
~>	Pessimistic (incrémente le dernier chiffre)	~> 5.0 → >= 5.0, < 6.0

Glissez pour voir

Automatisation CI/CD

# Pipeline type : plan séparé de l'apply
# Étape 1 : Plan
terraform init -input=false
terraform plan -input=false -out=tfplan

# Étape 2 : Apply (après approbation)
terraform apply -input=false tfplan

---

Objectif 4 — Modules

Structure standard d’un module

modules/
└── compute/
    ├── main.tf          # Ressources
    ├── variables.tf     # Inputs
    ├── outputs.tf       # Outputs
    ├── versions.tf      # Required providers
    ├── README.md        # Documentation
    └── tests/
        └── main.tftest.hcl  # Tests

Passer des providers à un module

# Root module
provider "aws" {
  alias  = "us"
  region = "us-east-1"
}

provider "aws" {
  alias  = "eu"
  region = "eu-west-1"
}

module "us_infra" {
  source = "./modules/compute"

  providers = {
    aws = aws.us
  }
}

module "eu_infra" {
  source = "./modules/compute"

  providers = {
    aws = aws.eu
  }
}

Refactoring : extraire en module

# Étape 1 : Déplacer le code dans le module

# Étape 2 : Ajouter le bloc moved
moved {
  from = aws_instance.web
  to   = module.compute.aws_instance.main
}

moved {
  from = aws_security_group.web
  to   = module.compute.aws_security_group.main
}

# Étape 3 : Vérifier
# terraform plan ne doit montrer AUCUN destroy

---

Objectif 5 — Providers

Provider aliasing multi-région

provider "aws" {
  region = "eu-west-1"  # Provider par défaut
}

provider "aws" {
  alias  = "us_east"
  region = "us-east-1"
}

# Utilisation dans une ressource
resource "aws_s3_bucket" "backup" {
  provider = aws.us_east
  bucket   = "backup-us-east"
}

Authentication AWS

# Méthode 1 : Environment variables (recommandé en CI/CD)
# export AWS_ACCESS_KEY_ID="..."
# export AWS_SECRET_ACCESS_KEY="..."
# export AWS_REGION="eu-west-1"

# Méthode 2 : Shared credentials file
provider "aws" {
  shared_credentials_files = ["~/.aws/credentials"]
  profile                  = "production"
}

# Méthode 3 : Assume role
provider "aws" {
  assume_role {
    role_arn     = "arn:aws:iam::123456789:role/terraform"
    session_name = "terraform-session"
  }
}

Dynamic provider credentials (HCP Terraform)

HCP Terraform supporte les dynamic provider credentials via OIDC workload identity. Au lieu de stocker des clés d’accès statiques, HCP Terraform obtient des credentials temporaires auprès d’AWS à chaque run. C’est la méthode la plus sécurisée pour l’objectif 6 (collaboration et gouvernance).

Diagnostic des erreurs de provider

# Version incompatible
terraform init -upgrade
terraform providers

# Credentials invalides
export TF_LOG=DEBUG
terraform plan 2>&1 | grep -i "auth\|credential\|access"

# Rate limiting
terraform apply -parallelism=5  # Réduire le parallélisme

# Provider lock corrompu
rm .terraform.lock.hcl
terraform init

---

Debugging et diagnostic

Variables d’environnement de debug

# Niveaux : TRACE > DEBUG > INFO > WARN > ERROR
export TF_LOG=TRACE
export TF_LOG_PATH=/tmp/terraform-debug.log

# Debug uniquement le provider
export TF_LOG_PROVIDER=TRACE

# Debug uniquement le core
export TF_LOG_CORE=DEBUG

# Désactiver
unset TF_LOG TF_LOG_PATH TF_LOG_PROVIDER TF_LOG_CORE

Diagnostic rapide en examen

# Le plan échoue ? Vérifiez dans cet ordre :
# 1. Syntaxe
terraform validate

# 2. State
terraform state list
terraform state show <resource>

# 3. Provider
terraform providers
cat .terraform.lock.hcl

# 4. Logs détaillés
TF_LOG=DEBUG terraform plan 2>&1 | tail -50

# 5. Refresh
terraform plan -refresh-only

---

Naviguer dans la documentation (stratégie examen)

La documentation est autorisée pendant le lab. Voici les pages les plus utiles :

Besoin	Où chercher
Syntaxe d’une ressource AWS	registry.terraform.io/providers/hashicorp/aws → recherche
Fonctions HCL	developer.hashicorp.com/terraform/language/functions
Bloc lifecycle	developer.hashicorp.com/terraform/language/meta-arguments/lifecycle
terraform test	developer.hashicorp.com/terraform/language/tests
Check blocks	developer.hashicorp.com/terraform/language/checks
Bloc moved	developer.hashicorp.com/terraform/language/modules/develop/refactoring
Backend S3	developer.hashicorp.com/terraform/language/backend/s3
Provider configuration	developer.hashicorp.com/terraform/language/providers/configuration

Glissez pour voir

Pratiquez la navigation avant l'examen

Pendant l’examen, chaque seconde compte. Familiarisez-vous avec la structure de la documentation Terraform et AWS avant le jour J. Savoir que les fonctions sont listées alphabétiquement dans language/functions/ vous fait gagner du temps.

À retenir

• L’examen lab utilise Terraform 1.6 + AWS — entraînez-vous avec cette version
• La documentation est votre alliée — apprenez à y naviguer vite
• moved {} est préféré à state mv — apprenez les deux
• terraform test (.tftest.hcl) est un sujet clé de l’objectif 2
• Les preconditions/postconditions dans lifecycle sont un pattern récurrent
• Le provider aliasing multi-région est un sujet incontournable
• Les provisioners existent mais sont déconseillés — sachez quand les utiliser
• L’objectif 6 (HCP Terraform) est en QCM — pas besoin de commandes lab

Prochaines étapes

Exercices Professional Entraînement lab chronométré sur AWS

Guide de préparation Professional Plan de révision complet sur 6 semaines

Blocs dynamiques Dynamic blocks en profondeur

Tester un module terraform test et validation

×

📖 Voir la documentation →