Terraform IAM : users, groups, roles et least privilege

À la fin de ce tutoriel, vous maîtriserez le modèle IAM (user / group / role / policy, identity-based vs resource-based), distinguerez trust policy et permissions policy, déclarerez des users + groups avec aws_iam_group_membership, attacherez des politiques de groupe, créerez un aws_iam_role (EC2 / Lambda) avec assume_role_policy, une aws_iam_policy customer managed + attachments, un instance profile EC2, et exécuterez un lab complet en ca-central-1 (IAM global) — Terraform ≥ 1.9, AWS provider ~> 5.0. Message clé : least privilege — jamais AdministratorAccess en prod, jamais d’access keys en HCL ; préférer rôles et credentials temporaires.

Niveau : Intermédiaire · Temps estimé : 55–70 min (lecture) / +15–25 min si apply · Versions testées : Terraform 1.16.2 (série ≥ 1.9), AWS provider ~> 5.0 · Dernière vérification : 2026-09-10

Slug proposé : terraform-iam · Série : Terraform · Remplace / fusionne : #1694 (IAM Terraform ancien)

Prérequis

• Avoir suivi ALB (terraform-alb) : lab, tags, destroy obligatoire
• Idéalement Providers (terraform-providers-ressources) et Variables (terraform-variables)
• Notions IAM console/CLI : série AWS IAM users / groupes / rôles (aws-iam-users-groupes-roles-politiques)
• Terraform ≥ 1.9, AWS CLI v2, profil de lab (aws sts get-caller-identity OK)

Coût estimé : 0 € pour les ressources IAM (gratuit). Un bucket S3 de test éventuel reste hors scope ou Free Tier — destroy obligatoire après le lab. Aucun secret dans le HCL / tfvars.

Auth sans secrets. AWS_PROFILE / SSO uniquement. Jamais d’access_key / secret_key dans le provider. Aucune clé longue dans le dépôt : les rôles EC2 / Lambda utilisent des credentials temporaires (IMDSv2 / STS).

Ce que nous allons construire

Lab terraform iam (ca-central-1) — IAM global, provider Region OK
  ├── versions.tf / providers.tf     → TF ≥ 1.9, aws ~> 5.0, region ca-central-1
  ├── Users + Group + membership     → aws_iam_user ×2, aws_iam_group, aws_iam_group_membership
  ├── Policy groupe (S3 read min.)   → aws_iam_policy + aws_iam_group_policy_attachment
  ├── Rôle EC2 + trust + policy      → aws_iam_role, assume_role_policy, attachment
  ├── Instance profile               → aws_iam_instance_profile (sans lancer d’EC2)
  ├── apply OPTIONNEL                → vérif CLI → destroy immédiat
  └── Checklist + erreurs (≥6) + quiz (6 QCM)

(Alt : « Terraform IAM : aws_iam_group_membership, iam role terraform, least privilege — ca-central-1 ».)

Ce guide remplace le post WordPress #1694. Focus : terraform iam déclaratif moderne (users/groups/membership + rôles + politiques customer managed), snippets provider 5.x, discipline stricte du moindre privilège — pas de AdministratorAccess dans les exemples destinés à la production, pas de secrets en clair.

Étape 1 — Rappels IAM : user, group, role, policy

Identité / objet	Rôle	Terraform typique
User	Humain ou compte de service (mot de passe / access keys)	aws_iam_user (souvent évité en prod : préférez SSO / Identity Center)
Group	Collection de users ; politiques attachées au groupe	aws_iam_group + membership + attachments
Role	Identité assumable (pas de secret long terme)	aws_iam_role
Policy	Document JSON d’autorisations	aws_iam_policy (customer) ou data AWS managed

Deux familles de politiques à ne jamais confondre :

• Identity-based : attachées à un user, un group ou un rôle (« que peut faire cette identité ? »). C’est le modèle dominant en Terraform IAM.
• Resource-based : collées sur la ressource elle-même (bucket policy S3, queue policy SQS, trust policy d’un rôle). Elles répondent à « qui peut appeler / assumer / accéder à cette ressource ? ».

Types d’identity-based policies :

Type	Qui la gère	Quand l’utiliser
AWS managed	AWS	Démarrer vite (AmazonS3ReadOnlyAccess) — souvent trop large pour un lab précis
Customer managed	Vous	Lab et prod : réutilisable, versionnable, least privilege
Inline	Collée à une seule identité	À éviter (difficile à auditer / réutiliser) — aws_iam_group_policy, aws_iam_role_policy

IAM est un service global : les ARN n’ont pas de Region dans le path classique (arn:aws:iam::ACCOUNT:role/...). Vous configurez quand même le provider en ca-central-1 pour les tags, la cohérence de la série P2 et les data sources régionales éventuelles.

Le pattern 2026 : groupes pour les humains, rôles pour les services — pas de clés statiques sur une instance.

Étape 2 — Trust policy vs permissions policy

Sur un rôle, deux documents JSON distincts :

1. Trust policy (assume_role_policy sur aws_iam_role) : qui peut appeler sts:AssumeRole (service EC2, Lambda, un compte AWS, un user SSO). C’est une resource-based policy collée au rôle.
2. Permissions policy : ce que le rôle peut faire une fois assumé (S3, CloudWatch Logs, etc.). Identity-based : attachée via aws_iam_role_policy_attachment ou inline.

Anti-patterns fréquents :

• Mettre les actions S3 dans la trust policy → invalide ou inutile.
• Principal = "*" sans condition → n’importe qui peut tenter d’assumer le rôle.
• Confondre « permissions du rôle » et « permissions de l’instance profile » : l’instance profile n’ajoute aucune permission ; il enveloppe uniquement le rôle pour EC2.

Pour les users / groups, il n’y a pas de trust policy : uniquement des permissions identity-based (attachées au groupe de préférence).

Étape 3 — Provider Terraform IAM (versions, ca-central-1)

# versions.tf
terraform {
  required_version = ">= 1.9.0"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

# providers.tf
provider "aws" {
  region = "ca-central-1"
  # Auth : AWS_PROFILE / SSO — jamais de clés ici
}

# variables.tf
variable "project" {
  type        = string
  description = "Préfixe lab unique (sans secret)."
}

variable "lab_bucket_name" {
  type        = string
  description = "Nom du bucket S3 autorisé en lecture (existe déjà ou lab)."
}

Points durs : pinnez required_version et le provider ; Region ca-central-1 même si IAM est global ; zéro credential dans le HCL. Le préfixe project évite les collisions de noms (EntityAlreadyExists) dans un compte partagé.

Étape 4 — Users, groups et aws_iam_group_membership

Le cœur de terraform iam pour les humains de lab : créer des users, un groupe, puis une membership explicite. Utilisez exactement ce pattern (adapté lab, noms préfixés par variables, pas de secrets) :

resource "aws_iam_group_membership" "team" {
  name = "${var.project}-tf-testing-group-membership"

  users = [
    aws_iam_user.user_one.name,
    aws_iam_user.user_two.name,
  ]

  group = aws_iam_group.group.name
}

resource "aws_iam_group" "group" {
  name = "${var.project}-test-group"
}

resource "aws_iam_user" "user_one" {
  name = "${var.project}-test-user"

  tags = {
    Lab       = "terraform-iam"
    ManagedBy = "terraform"
  }
}

resource "aws_iam_user" "user_two" {
  name = "${var.project}-test-user-two"

  tags = {
    Lab       = "terraform-iam"
    ManagedBy = "terraform"
  }
}

Pourquoi une membership séparée ?

aws_iam_group_membership est une ressource dédiée qui gère la liste des membres du groupe comme un ensemble unique. Terraform crée / met à jour / détruit cette association indépendamment des users et du groupe. Avantages :

• Le graphe de dépendances est clair : users + group avant membership (références .name).
• Vous pouvez destroy la membership sans supprimer les users (utile en lab).
• L’état Terraform reflète explicitement « ces N users appartiennent à ce groupe ».

Ordre des dépendances

Terraform déduit l’ordre via les références : aws_iam_user.* et aws_iam_group.group doivent exister avant aws_iam_group_membership.team. Vous n’avez pas besoin de depends_on si vous référencez .name comme ci-dessus. Évitez les depends_on croisés inutiles qui créent des cycles.

Alternative : aws_iam_user_group_membership

Ressource	Portée	Quand
aws_iam_group_membership	Tous les membres d’un groupe (liste autoritative)	Lab / équipes : un groupe, N users — pattern recommandé ici
aws_iam_user_group_membership	Les groupes d’un user	User multi-groupes ; moins pratique pour « vider » un groupe

Attention : aws_iam_group_membership est autoritaire. Si un user a été ajouté manuellement au groupe hors Terraform, un apply peut le retirer s’il n’est pas dans users. Piège inverse : si le user est déjà membre et que vous créez une autre membership concurrente (console + Terraform), vous obtiendrez des drifts / conflits.

Pièges concrets

1. User déjà dans le groupe (console) → Terraform peut « corriger » en retirant les membres hors liste.
2. Deux ressources membership sur le même groupe → état incohérent ; une seule membership par groupe.
3. Access keys créées hors Terraform sur ces users → hors scope de ce lab ; ne les mettez jamais dans le HCL.
4. Noms sans préfixe (test-user) → collision dans un compte partagé ; toujours ${var.project}-….

Étape 5 — Attacher une politique au groupe (S3 read minimale)

Attachez au groupe une politique customer managed limitée à la lecture d’un bucket — pas s3: sur , et surtout pas AdministratorAccess.

data "aws_iam_policy_document" "s3_read_lab" {
  statement {
    sid    = "ListLabBucket"
    effect = "Allow"
    actions = [
      "s3:ListBucket",
    ]
    resources = [
      "arn:aws:s3:::${var.lab_bucket_name}",
    ]
  }

  statement {
    sid    = "GetLabObjects"
    effect = "Allow"
    actions = [
      "s3:GetObject",
    ]
    resources = [
      "arn:aws:s3:::${var.lab_bucket_name}/*",
    ]
  }
}

resource "aws_iam_policy" "s3_read_lab" {
  name        = "${var.project}-s3-read-lab"
  description = "Lecture seule sur un bucket lab — pas Admin"
  policy      = data.aws_iam_policy_document.s3_read_lab.json

  tags = {
    Lab       = "terraform-iam"
    ManagedBy = "terraform"
  }
}

resource "aws_iam_group_policy_attachment" "team_s3_read" {
  group      = aws_iam_group.group.name
  policy_arn = aws_iam_policy.s3_read_lab.arn
}

Approche	Ressource	Quand
Managed + attachment	aws_iam_policy + aws_iam_group_policy_attachment	Réutilisable, auditable — préférez
Inline groupe	aws_iam_group_policy	Une seule identité ; plus dur à versionner — à éviter
AWS managed large	data + attachment AmazonS3ReadOnlyAccess	Démarrage rapide ; trop large pour un bucket précis

Deux statements sont obligatoires pour une lecture S3 correcte : ListBucket sur l’ARN du bucket, GetObject sur bucket/*. Oublier l’un des deux produit un AccessDenied trompeur.

Variante inline (déconseillée, montrée pour contraste) :

# À éviter en prod — inline non réutilisable
# resource "aws_iam_group_policy" "team_s3_inline" {
#   name   = "${var.project}-s3-inline"
#   group  = aws_iam_group.group.name
#   policy = data.aws_iam_policy_document.s3_read_lab.json
# }

Étape 6 — IAM role Terraform : aws_iam_role + assume_role_policy

Pour les services (EC2, Lambda), créez un rôle avec une trust policy explicite via data.aws_iam_policy_document — plus sûr qu’un JSON brut.

Trust EC2

data "aws_iam_policy_document" "ec2_assume" {
  statement {
    sid     = "EC2AssumeRole"
    effect  = "Allow"
    actions = ["sts:AssumeRole"]

    principals {
      type        = "Service"
      identifiers = ["ec2.amazonaws.com"]
    }
  }
}

resource "aws_iam_role" "ec2_s3_reader" {
  name               = "${var.project}-ec2-s3-reader"
  assume_role_policy = data.aws_iam_policy_document.ec2_assume.json
  description        = "Lab P2 : EC2 lit un bucket S3 (least privilege)"

  tags = {
    Name      = "${var.project}-ec2-s3-reader"
    ManagedBy = "terraform"
    Lab       = "terraform-iam"
    Region    = "ca-central-1"
  }
}

Trust Lambda (variante)

data "aws_iam_policy_document" "lambda_assume" {
  statement {
    sid     = "LambdaAssumeRole"
    effect  = "Allow"
    actions = ["sts:AssumeRole"]

    principals {
      type        = "Service"
      identifiers = ["lambda.amazonaws.com"]
    }
  }
}

resource "aws_iam_role" "lambda_s3_reader" {
  name               = "${var.project}-lambda-s3-reader"
  assume_role_policy = data.aws_iam_policy_document.lambda_assume.json
  description        = "Lab : Lambda lit un bucket S3 (least privilege)"

  tags = {
    Lab       = "terraform-iam"
    ManagedBy = "terraform"
  }
}

Points durs :

1. assume_role_policy est un JSON string — préférez data.aws_iam_policy_document.
2. Le principal doit correspondre au service réel (ec2.amazonaws.com, lambda.amazonaws.com).
3. Ne mettez pas les permissions S3 dans la trust policy.
4. Noms de rôle uniques dans le compte ; préfixe project court.

Étape 7 — aws_iam_policy customer + attachments + data AWS managed

Réutilisez la même politique S3 read sur le rôle EC2 (pattern customer managed + attachment) :

resource "aws_iam_role_policy_attachment" "ec2_s3_read" {
  role       = aws_iam_role.ec2_s3_reader.name
  policy_arn = aws_iam_policy.s3_read_lab.arn
}

# Optionnel : attacher aussi une AWS managed (ex. logs) via data source
data "aws_iam_policy" "lambda_basic" {
  name = "AWSLambdaBasicExecutionRole"
}

resource "aws_iam_role_policy_attachment" "lambda_basic" {
  role       = aws_iam_role.lambda_s3_reader.name
  policy_arn = data.aws_iam_policy.lambda_basic.arn
}

resource "aws_iam_role_policy_attachment" "lambda_s3_read" {
  role       = aws_iam_role.lambda_s3_reader.name
  policy_arn = aws_iam_policy.s3_read_lab.arn
}

Approche	Quand
aws_iam_policy + aws_iam_role_policy_attachment	Réutilisable (groupe et rôle) — préférez
aws_iam_role_policy (inline)	Une seule identité ; à éviter
Data aws_iam_policy (AWS managed)	Logs de base Lambda, SSM core — complément, pas remplacant d’un least privilege S3

L’attachment référence un ARN managé réutilisable (plusieurs rôles / un groupe) sans dupliquer le JSON. C’est le cœur de iam role terraform propre.

Étape 8 — Instance profile EC2

EC2 n’attache pas un rôle directement : elle utilise un instance profile qui enveloppe le rôle.

resource "aws_iam_instance_profile" "ec2_s3_reader" {
  name = "${var.project}-ec2-s3-reader"
  role = aws_iam_role.ec2_s3_reader.name

  tags = {
    Lab = "terraform-iam"
  }
}

# CONCEPTUEL — nécessite une EC2 (hors lab minimal IAM)
# resource "aws_instance" "app" {
#   ami                  = data.aws_ami.al2023.id
#   instance_type        = "t3.micro"
#   iam_instance_profile = aws_iam_instance_profile.ec2_s3_reader.name
#   # ...
# }

output "role_arn" {
  description = "ARN du rôle EC2 lab (si apply)."
  value       = aws_iam_role.ec2_s3_reader.arn
}

output "instance_profile_name" {
  description = "Nom du profil à coller sur une EC2."
  value       = aws_iam_instance_profile.ec2_s3_reader.name
}

output "group_name" {
  description = "Nom du groupe lab."
  value       = aws_iam_group.group.name
}

En résumé : rôle (trust + permissions) → instance profile → attribut iam_instance_profile de l’instance. Les métadonnées d’instance fournissent alors des credentials temporaires (IMDSv2 recommandé). Pour Lambda, vous attachez directement role = aws_iam_role....arn sans instance profile.

Ce lab P2 s’arrête avant le launch EC2 : maîtriser terraform iam, pas facturer une instance.

Étape 9 — Least privilege : règles non négociables

1. Pas AdministratorAccess (ni PowerUserAccess) dans les exemples / modules destinés à la production.
2. Pas d’access keys (aws_iam_access_key) en HCL versionné — SSO, rôles, OIDC CI.
3. Scopez les ARN : un bucket, un préfixe, des actions précises (ListBucket, GetObject) — pas s3: sur .
4. Préférez customer managed + attachment aux inline et aux AWS managed trop larges.
5. Humains → groupes ; services → rôles + credentials temporaires.
6. Tags Lab / ManagedBy pour retrouver et détruire facilement.
7. terraform destroy après chaque lab — les rôles orphelins s’accumulent et polluent les audits.

Le moindre privilège n’est pas « moins de confort » : c’est la seule posture compatible avec un state Terraform partagé et des pipelines CI.

Étape 10 — Lab complet ca-central-1 : users + group + membership + policy + rôle

Mode A — Recommandé : validate / plan

mkdir -p ~/terraform-iam-lab && cd ~/terraform-iam-lab
# Collez versions.tf, providers.tf, variables.tf, main.tf (étapes 3–8)

export AWS_PROFILE=lab
export AWS_REGION=ca-central-1
PROJECT="votreprenom20260910"
# Remplacez par un bucket lab existant (pas de secret dans le nom)
BUCKET="votreprenom-lab-assets-ca"

terraform init && terraform fmt && terraform validate
terraform plan 
  -var="project=${PROJECT}" 
  -var="lab_bucket_name=${BUCKET}"
# STOP ici si vous ne voulez pas créer les ressources

Observez le plan : users ×2, group, aws_iam_group_membership, policy S3, attachments groupe + rôle, rôle EC2 (+ Lambda optionnel), instance profile. Aucune access key.

Mode B — Apply minimal puis destroy

IAM est gratuit ; appliquez uniquement si vous voulez vérifier en console / CLI :

terraform apply -auto-approve 
  -var="project=${PROJECT}" 
  -var="lab_bucket_name=${BUCKET}"
terraform output

aws iam get-group --group-name "${PROJECT}-test-group" --profile lab
aws iam get-role --role-name "${PROJECT}-ec2-s3-reader" --profile lab
aws iam list-attached-role-policies --role-name "${PROJECT}-ec2-s3-reader" --profile lab
aws iam list-attached-group-policies --group-name "${PROJECT}-test-group" --profile lab

# Destroy — ne laissez pas de rôles / users / politiques orphelins
terraform destroy -auto-approve 
  -var="project=${PROJECT}" 
  -var="lab_bucket_name=${BUCKET}"
cd ~ && rm -rf ~/terraform-iam-lab

Post-destroy : aws iam get-role / get-group → NoSuchEntity. Aucune access key créée — voulu.

Étape 11 — Checklist

1. Distinguer user / group / role / policy et identity-based vs resource-based.
2. Séparer trust policy et permissions policy.
3. Déclarer users + group + aws_iam_group_membership (pattern autoritaire).
4. Attacher une politique customer au groupe (aws_iam_group_policy_attachment).
5. Déclarer aws_iam_role + assume_role_policy (EC2 / Lambda).
6. Créer aws_iam_policy + aws_iam_role_policy_attachment (+ data AWS managed si besoin).
7. Aperçu instance profile pour EC2 ; pas de clés longues.
8. Least privilege : un bucket, ListBucket + GetObject — pas AdministratorAccess.
9. Provider Region ca-central-1, TF ≥ 1.9, provider ~> 5.0.
10. Aucun secret / access key en clair ; destroy après le lab.

Nettoyage

cd ~/terraform-iam-lab
terraform destroy -auto-approve 
  -var="project=${PROJECT}" 
  -var="lab_bucket_name=${BUCKET}"
cd ~ && rm -rf ~/terraform-iam-lab
# Filet CLI :
# aws iam list-roles --query "Roles[?contains(RoleName, '${PROJECT}')]" --profile lab
# aws iam list-groups --query "Groups[?contains(GroupName, '${PROJECT}')]" --profile lab
# + politiques customer taguées Lab=terraform-iam

Confirmez l’absence des users / groupe / rôle / instance profile. Si un user a des access keys créées hors Terraform, désactivez-les avant le destroy du user.

Erreurs fréquentes

Symptôme	Cause	Correction
MalformedPolicyDocument	JSON invalide, guillemets, Principal mal formé	Utiliser aws_iam_policy_document ; valider le JSON
Circular dependency	Rôle ↔ politique / attachment qui se référencent en boucle	Séparer data documents ; éviter depends_on croisés inutiles
EntityAlreadyExists	Nom de rôle / user / groupe / politique déjà pris	Préfixe project unique ou name_prefix
AccessDenied sur S3	ARN bucket / objet incorrect ; oubli ListBucket	Deux statements : bucket ARN et bucket/*
EC2 sans permissions S3	Rôle attaché sans instance profile	Créer aws_iam_instance_profile + l’assigner
Trust trop large	Principal = "*" ou compte entier sans condition	Restreindre au service (ec2.amazonaws.com / lambda.amazonaws.com)
Drift membership	User ajouté en console hors liste Terraform	Une seule aws_iam_group_membership autoritaire ; ré-appliquer ou importer
Tentation Admin	Copier AdministratorAccess « pour aller vite »	Interdit en exemples prod — customer least privilege
Secrets dans le state	Access keys user Terraform	Préférez rôles / SSO ; marquez outputs sensibles ; jamais de clés en HCL
DeleteConflict au destroy	Politiques encore attachées / membership active	Destroy via Terraform (ordre géré) ; détacher avant delete manuel

Circular typique : inline qui référence l’ARN du rôle déjà lié à cette policy. Avec policy managée + attachment, le graphe reste acyclique. Membership : si Terraform et la console se battent sur les membres, le prochain apply gagne — documentez la règle « IAM via Terraform uniquement » dans l’équipe.

Quiz (6 questions)

1. Que contient assume_role_policy sur un aws_iam_role ?

• A. Les permissions S3 du rôle
• B. La trust policy (qui peut assumer le rôle)
• C. L’instance profile EC2 obligatoire
• D. La liste des users du groupe

2. Pour une lecture seule sur un bucket en prod Terraform, quelle approche ?

• A. Attacher AdministratorAccess
• B. aws_iam_policy customer (ListBucket/GetObject) + attachment
• C. Access keys hardcodées dans user_data
• D. Inline s3: sur « temporaire »

3. Pourquoi utiliser aws_iam_group_membership plutôt que d’ignorer la membership ?

• A. Elle crée automatiquement des access keys
• B. Elle gère de façon autoritaire la liste des membres d’un groupe dans le state
• C. Elle remplace la trust policy du rôle
• D. Elle est obligatoire pour Lambda uniquement

4. Quelle est la différence trust vs permissions policy ?

• A. Aucune : synonymes AWS
• B. Trust = qui assume ; permissions = ce que le rôle peut faire
• C. Trust = S3 ; permissions = EC2
• D. Trust uniquement pour les users humains

5. EC2 consomme un rôle via…

• A. Un aws_iam_access_key collé dans le user_data
• B. Un aws_iam_instance_profile référencé par iam_instance_profile
• C. Uniquement une bucket policy
• D. aws_iam_group_membership sur l’instance

6. Après un lab terraform iam, action critique ?

• A. Laisser le rôle jusqu’au prochain trimestre
• B. terraform destroy + vérif CLI (get-role / get-group = absent)
• C. Créer des access keys long terme « au cas où »
• D. Attacher AdministratorAccess « pour la suite »

Réponses : 1‑B · 2‑B · 3‑B · 4‑B · 5‑B · 6‑B

FAQ rapide (issues du quiz élargi)

• Puis-je mettre des access keys dans le provider ? Non — AWS_PROFILE / SSO uniquement.
• aws_iam_user_group_membership vs aws_iam_group_membership ? User→groupes vs groupe→users (autoritaire) ; ce lab utilise la seconde.
• IAM est-il régional ? Non (global) ; le provider reste en ca-central-1 pour la cohérence série.
• Faut-il un instance profile pour Lambda ? Non — ARN du rôle directement sur la fonction.

Pour aller plus loin

• Doc : aws_iam_role, aws_iam_group_membership, aws_iam_policy, aws_iam_instance_profile, aws_iam_policy_document
• Sur ce site : série AWS IAM users / groupes / rôles (aws-iam-users-groupes-roles-politiques) ; suite immédiate Terraform RDS (terraform-rds)

Maillage série Terraform (P2)

← Précédent	ALB (terraform-alb)
→ Suivant	RDS (terraform-rds)
Aussi	Providers (terraform-providers-ressources) · Variables (terraform-variables) · IAM AWS (aws-iam-users-groupes-roles-politiques)
Carte	Overview · … · EBS · ALB · IAM · RDS · …

← Retour parcours Terraform

Ressources liées sur le site

• Parcours Terraform
• Certification Terraform Associate
• Vue d’ensemble Terraform
• Modules Terraform
• Parcours AWS
• Socle Linux

Retour parcours Terraform — hub de la série et leçons sœurs.