Dernière révision : mai 2026
Configurez les services AWS figurant à l'examen CDL avec Terraform simple — un bloc à la fois, chacun étant lié à un domaine de l'examen. Le même code fonctionne sur OpenTofu.
À la fin de ce laboratoire, vous aurez provisionné, avec du Terraform simple, l'empreinte GCP réaliste la plus petite — deux services de projet activés, un bucket Cloud Storage avec accès uniforme au niveau du bucket + cycle de vie, et un budget Cloud Billing qui envoie des e-mails lorsque les dépenses dépassent un seuil. Quatre blocs, l'équivalent GCP de créer un compte AWS et s'y déposer un seul bucket S3.
Déposez les extraits dans un unique main.tf, exécutez terraform init, puis terraform apply étape par étape.
>= 1.5 ou OpenTofu >= 1.6.provider.gcloud auth application-default login.gcloud beta billing accounts list.your-project-id et your-billing-account-id dans les extraits ci-dessous avant d'exécuter terraform apply.Tout est gratuit à ce niveau :
us-* ; le bucket du laboratoire ne contient rien.Le laboratoire est inactif à environ 0 $/mois. Le but est de prouver que le dispositif de déclenchement de la facturation fonctionne — l'examen CDL entier tourne autour de la compétence opérer-GCP-en-toute-sécurité, dont "savoir ce que l'on dépense" est la règle n°1.
GCP exige que les services de projet (API) soient explicitement activés avant que les ressources puissent être provisionnées. Nous activons storage.googleapis.com (pour l'étape 2) et billingbudgets.googleapis.com (pour l'étape 4). Comparez à AWS où les surfaces d'API sont toujours activées — GCP vous oblige à les activer par projet.
Remplacez your-project-id par l'ID réel de votre projet.
terraform {
required_version = ">= 1.5"
required_providers {
google = { source = "hashicorp/google", version = "~> 6.0" }
}
}
provider "google" {
project = "your-project-id" # REPLACE with your GCP project ID
region = "us-central1"
}
locals {
labels = {
project = "certlabpro-cdl"
managed_by = "terraform"
}
}
resource "google_project_service" "storage" {
service = "storage.googleapis.com"
disable_on_destroy = false
}
resource "google_project_service" "budgets" {
service = "billingbudgets.googleapis.com"
disable_on_destroy = false
}Cloud Storage est l'équivalent S3 de GCP — un stockage d'objets avec des options de réplication régionale, multi-régionale et bi-régionale. L'examen CDL teste à plusieurs reprises la question quelle classe de stockage : Standard (chaud), Nearline (>30 jours), Coldline (>90 jours), Archive (>365 jours).
Nous activons l'accès uniforme au niveau du bucket (la sécurité par défaut recommandée par le CDL — désactive les ACL par objet granulaires en faveur d'un accès uniquement via IAM) et une transition de cycle de vie de 30 jours → Nearline. Les noms doivent être globalement uniques sur l'ensemble de GCP — nous ajoutons un suffixe hexadécimal aléatoire.
resource "random_id" "suffix" {
byte_length = 4
}
resource "google_storage_bucket" "main" {
name = "certlabpro-cdl-${random_id.suffix.hex}"
location = "US"
uniform_bucket_level_access = true
force_destroy = true # lab-only — never in production
lifecycle_rule {
condition {
age = 30
}
action {
type = "SetStorageClass"
storage_class = "NEARLINE"
}
}
labels = local.labels
depends_on = [google_project_service.storage]
}Cloud Logging de GCP est activé par défaut pour la plupart des services — mais l'examen CDL teste la distinction des journaux d'audit Obligatoires vs Par défaut vs Accès aux données. Les journaux d'audit Obligatoires (activité d'administrateur) sont toujours activés, gratuits et ne peuvent pas être désactivés. Les journaux Par défaut (écritures de données pour certains services) sont activés mais peuvent être désactivés. Les journaux d'Accès aux données (lectures de données) sont désactivés par défaut — ils doivent être explicitement activés et sont facturés normalement.
Nous activons la journalisation d'Accès aux données pour Cloud Storage afin que chaque lecture de chaque objet dans le bucket de l'étape 2 se retrouve dans Cloud Logging. Le laboratoire est une démonstration de la primitive iam-audit-config ; les déploiements en production utilisent ce modèle au niveau de l'organisation via les modèles [[gcp-pcse]].
resource "google_project_iam_audit_config" "storage_data_access" {
service = "storage.googleapis.com"
audit_log_config {
log_type = "DATA_READ"
}
audit_log_config {
log_type = "DATA_WRITE"
}
}L'examen CDL adore ce modèle — les budgets + alertes Cloud Billing sont la forme récurrente des questions d'examen CDL pour le contrôle des coûts. Nous définissons un budget de 10 $/mois et configurons des alertes à 50 % / 90 % / 100 % des dépenses prévues. L'alerte est envoyée par e-mail aux administrateurs du compte de facturation (aucune configuration supplémentaire n'est nécessaire pour l'e-mail ; pour Slack / PagerDuty, vous ajouteriez un sujet Pub/Sub + un fanout Cloud Function).
Remplacez your-billing-account-id par votre ID réel. Le budget est limité au projet actuel uniquement via le filtre projects — l'examen CDL teste cette distinction budget par projet vs budget à l'échelle de l'organisation.
data "google_project" "current" {}
resource "google_billing_budget" "monthly_10" {
billing_account = "your-billing-account-id" # REPLACE — find via `gcloud beta billing accounts list`
display_name = "certlabpro-cdl-$10-monthly"
budget_filter {
projects = ["projects/${data.google_project.current.number}"]
}
amount {
specified_amount {
currency_code = "USD"
units = "10"
}
}
threshold_rules {
threshold_percent = 0.5
spend_basis = "FORECASTED_SPEND"
}
threshold_rules {
threshold_percent = 0.9
spend_basis = "FORECASTED_SPEND"
}
threshold_rules {
threshold_percent = 1.0
spend_basis = "CURRENT_SPEND"
}
depends_on = [google_project_service.budgets]
}terraform destroy supprime tout proprement. Le bucket est détruit (le force_destroy = true spécifique au laboratoire permet à Terraform de le supprimer même s'il n'est pas vide — ne jamais utiliser cela en production). Le budget est détaché ; les e-mails s'arrêtent. La configuration d'audit IAM revient à la valeur par défaut. Les services de projet restent activés (nous avons défini disable_on_destroy = false — ils sont gratuits à laisser activés, et les désactiver peut interrompre des charges de travail non liées sur le même projet).
Le CDL couvre de nombreuses surfaces GCP que ce laboratoire ne peut pas aborder — VM Compute Engine, clusters GKE, Cloud Run, Cloud Functions, App Engine, BigQuery, Cloud SQL, Spanner, Bigtable, Firestore, Cloud Pub/Sub, Dataflow, Dataproc, Vertex AI, Cloud Build, Cloud Deploy, Anthos / Multi-Cloud, Cloud CDN / Cloud Armor, VPC + Cloud NAT, Cloud Interconnect, Cloud IAM / Identity, Cloud KMS, Security Command Center, la marketplace GCP complète.
Nous nous en tenons aux primitives Stockage + Journalisation + Facturation car elles représentent l'empreinte la plus petite commune que chaque scénario d'examen CDL suppose être en place. Tout autre service GCP écrit vers Cloud Storage / lit depuis Cloud Storage / dépose des journaux dans Cloud Logging / apparaît sur un tableau de bord Cloud Billing. Maîtrisez les fondations ; superposez les services spécialisés plus tard.
Pour une couverture conceptuelle service par service, consultez les sections Parcourir, Guide et Editorial de cette page de certification.