Zuletzt überprüft: Mai 2026
Erstellen Sie die AWS-Dienste der CDL-Prüfung mit reinem Terraform — ein Block nach dem anderen, jeweils abgestimmt auf eine Prüfungsdomäne. Derselbe Code funktioniert auch mit OpenTofu.
Am Ende dieses Labs haben Sie mit reinem Terraform den kleinsten realistischen GCP-Footprint bereitgestellt – zwei aktivierte Projektdienste, einen Cloud Storage-Bucket mit einheitlichem Bucket-Level-Zugriff + Lebenszyklus und ein Cloud Billing-Budget, das E-Mails versendet, wenn Ausgaben einen Schwellenwert überschreiten. Vier Blöcke, das GCP-Äquivalent zum Erstellen eines AWS-Kontos und Ablegen eines einzelnen S3-Buckets darin.
Fügen Sie die Snippets in eine einzelne main.tf ein, führen Sie terraform init und dann terraform apply Schritt für Schritt aus.
>= 1.5 oder OpenTofu >= 1.6.provider-Block einfügen.gcloud auth application-default login.gcloud beta billing accounts list.your-project-id und your-billing-account-id in den Snippets unten, bevor Sie terraform apply ausführen.In diesem Umfang alles kostenlos:
us-*-Regionen; der Lab-Bucket enthält nichts.Das Lab verursacht im Leerlauf ca. 0 $/Monat. Es geht darum, zu beweisen, dass die Abrechnungs-Stolperfalle funktioniert – die gesamte CDL-Prüfung dreht sich um die Fähigkeit, GCP sicher zu betreiben (operate-GCP-safely), wobei "wissen, was Sie ausgeben" Regel Nr. 1 ist.
GCP erfordert die explizite Aktivierung von Projektdiensten (APIs), bevor Ressourcen bereitgestellt werden können. Wir aktivieren storage.googleapis.com (für Schritt 2) und billingbudgets.googleapis.com (für Schritt 4). Im Vergleich zu AWS, wo API-Oberflächen immer aktiviert sind, müssen Sie sich bei GCP pro Projekt anmelden.
Ersetzen Sie your-project-id durch Ihre tatsächliche Projekt-ID.
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 ist GCPs Äquivalent zu S3 – ein Objektspeicher mit regionalen, multiregionalen und Dual-Region-Replikationsoptionen. Die CDL-Prüfung testet wiederholt die Frage welche-Speicherklasse: Standard (hot), Nearline (>30 Tage), Coldline (>90 Tage), Archive (>365 Tage).
Wir aktivieren den einheitlichen Bucket-Level-Zugriff (die von CDL empfohlene Sicherheitseinstellung – deaktiviert fein granulierte ACLs pro Objekt zugunsten von IAM-only) und einen 30-Tage → Nearline-Lebenszyklusübergang. Namen müssen global eindeutig über alle GCP hinweg sein – wir fügen ein zufälliges Hex-Suffix an.
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]
}GCPs Cloud Logging ist standardmäßig für die meisten Dienste aktiviert – die CDL-Prüfung testet jedoch die Unterscheidung der Audit-Logs zwischen Erforderlich (Required) vs. Standard (Default) vs. Datenzugriff (Data Access). Erforderliche Audit-Logs (Administratoraktivität) sind immer aktiviert, kostenlos und können nicht deaktiviert werden. Standard-Logs (Datenschreibvorgänge für einige Dienste) sind aktiviert, können aber deaktiviert werden. Datenzugriffs-Logs (Datenlesevorgänge) sind standardmäßig deaktiviert – sie müssen explizit aktiviert werden und werden normal abgerechnet.
Wir aktivieren die Datenzugriffs-Protokollierung für Cloud Storage, sodass jeder Lesevorgang jedes Objekts im Bucket aus Schritt 2 in Cloud Logging landet. Das Lab ist eine Demonstration des iam-audit-config-Primitivs; Produktionsbereitstellungen verwenden dieses Muster auf Organisationsebene über [[gcp-pcse]]-Muster.
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"
}
}Die CDL-Prüfung liebt dieses Muster – Cloud Billing-Budgets + Warnungen ist die wiederkehrende CDL-Prüfungsfrageform für die Kostenkontrolle. Wir legen ein Budget von 10 $/Monat fest und konfigurieren Warnungen bei 50 % / 90 % / 100 % der prognostizierten Ausgaben. Die Warnung wird per E-Mail an die Billing-Konto-Administratoren gesendet (keine zusätzliche Konfiguration für E-Mails erforderlich; für Slack / PagerDuty würden Sie ein Pub/Sub-Thema + Cloud Function-Fanout hinzufügen).
Ersetzen Sie your-billing-account-id durch Ihre tatsächliche ID. Das Budget ist über den projects-Filter nur auf das aktuelle Projekt beschränkt – die CDL-Prüfung testet diese Unterscheidung zwischen Budget pro Projekt und organisationsweitem Budget.
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 reißt alles sauber ab. Der Bucket wird gelöscht (das nur für Labs vorgesehene force_destroy = true ermöglicht Terraform, ihn auch im nicht leeren Zustand zu löschen – niemals in der Produktion verwenden). Das Budget wird getrennt; E-Mails hören auf. Die IAM-Audit-Konfiguration wird auf den Standard zurückgesetzt. Die Projektdienste bleiben aktiviert (wir haben disable_on_destroy = false gesetzt – sie können kostenlos aktiviert bleiben, und ihre Deaktivierung kann andere, nicht zusammenhängende Workloads im selben Projekt stören).
CDL deckt viele GCP-Oberflächen ab, die dieses Lab nicht behandeln kann – Compute Engine VMs, GKE-Cluster, 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, der gesamte GCP-Marktplatz.
Wir beschränken uns auf die Storage + Logging + Billing-Grundlagen, da sie der kleinste gemeinsame Nenner sind, den jedes CDL-Prüfungsszenario voraussetzt. Jeder andere GCP-Dienst schreibt in Cloud Storage / liest aus Cloud Storage / speichert Logs in Cloud Logging / erscheint auf einem Cloud Billing-Dashboard. Beherrschen Sie die Grundlagen; spezialisierte Dienste kommen später hinzu.
Für die konzeptionelle Abdeckung Dienst für Dienst siehe die Bereiche Durchsuchen, Handbuch und Editorial dieser Zertifizierungsseite.