Zuletzt überprüft: Mai 2026
Erstellen Sie die AWS-Dienste der ACE-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 einfachem Terraform die kleinste realistische, ACE-konforme GCP-Admin-Infrastruktur bereitgestellt – eine VPC im benutzerdefinierten Modus mit einem regionalen Subnetz, zwei Firewall-Regeln (intern zulassen + IAP SSH), eine Compute Engine VM, die mit einem Service-Konto mit Least-Privilege IAM läuft, und eine Cloud Logging-Benachrichtigungsrichtlinie, die bei Kontingentfehlern alarmiert. Dies ist die Grundausstattung eines IaaS-Admins für den ersten Tag.
Fügen Sie die Snippets in eine einzelne main.tf ein, führen Sie terraform init aus und anschließend terraform apply Schritt für Schritt.
>= 1.5 oder OpenTofu >= 1.6.gcloud auth application-default login.your-project-id im folgenden Snippet durch Ihre tatsächliche Projekt-ID.gcloud compute ssh certlabpro-ace-vm --tunnel-through-iap.e2-micro: ca. 6,50 $/Monat in us-central1 (1 immer kostenlose Stufe pro Konto, falls berechtigt).Ca. 6,50 $/Monat, solange die VM läuft. Beenden oder zerstören Sie die VM, wenn Sie sie nicht aktiv nutzen – laufende VMs sind die größte Kostenüberraschung bei GCP-Labs.
Aktivieren Sie die APIs für Compute Engine, IAM und Cloud Logging. Die ACE-Prüfung testet dieses Muster des API-Aktivierens pro Ressource wiederholt.
terraform {
required_version = ">= 1.5"
required_providers {
google = { source = "hashicorp/google", version = "~> 6.0" }
}
}
provider "google" {
project = "your-project-id" # REPLACE
region = "us-central1"
zone = "us-central1-a"
}
locals {
labels = {
project = "certlabpro-ace"
managed_by = "terraform"
}
}
resource "google_project_service" "compute" {
service = "compute.googleapis.com"
disable_on_destroy = false
}
resource "google_project_service" "iam" {
service = "iam.googleapis.com"
disable_on_destroy = false
}
resource "google_project_service" "logging" {
service = "logging.googleapis.com"
disable_on_destroy = false
}
resource "google_project_service" "monitoring" {
service = "monitoring.googleapis.com"
disable_on_destroy = false
}GCP-Netzwerke sind global – eine einzelne VPC erstreckt sich über alle Regionen, und Subnetze sind regionale Primitive, die daraus geschnitzt werden. Dies ist eine wiederkehrende Frageform in der ACE-Prüfung: AWS hat regionale VPCs; Azure hat regionale VNets; GCP hat eine globale VPC mit regionalen Subnetzen.
Wir deaktivieren auto_create_subnetworks (VPC im benutzerdefinierten Modus, die von ACE empfohlene Standardeinstellung) und richten ein einzelnes /24-Subnetz in us-central1 mit aktiviertem Private Google Access ein, damit VMs ohne externe IPs weiterhin GCP APIs erreichen können.
resource "google_compute_network" "main" {
name = "certlabpro-ace-vpc"
auto_create_subnetworks = false
routing_mode = "REGIONAL"
depends_on = [google_project_service.compute]
}
resource "google_compute_subnetwork" "main" {
name = "certlabpro-ace-subnet"
ip_cidr_range = "10.10.1.0/24"
region = "us-central1"
network = google_compute_network.main.id
private_ip_google_access = true
}GCP-Firewall-Regeln sind VPC-gebunden (nicht pro Subnetz) und haben eine explizite Richtung: Ingress (Standard) oder Egress. Der Standard-Ingress ist alles verweigern; der Standard-Egress ist alles erlauben. Die ACE-Prüfung testet diese Richtung + Standard-Verweigerung-Invariante unerbittlich.
Wir fügen hinzu:
10.10.1.0/24.35.235.240.0/20), damit Sie SSH nutzen können, ohne die VM dem Internet auszusetzen.Die IAP-SSH-Regel ist das von ACE empfohlene Muster – sie erfordert roles/iap.tunnelResourceAccessor auf der VM (Bindung wird in Schritt 4 behandelt).
resource "google_compute_firewall" "allow_internal" {
name = "certlabpro-ace-allow-internal"
network = google_compute_network.main.name
direction = "INGRESS"
source_ranges = ["10.10.1.0/24"]
allow {
protocol = "tcp"
}
allow {
protocol = "udp"
}
allow {
protocol = "icmp"
}
}
resource "google_compute_firewall" "allow_iap_ssh" {
name = "certlabpro-ace-allow-iap-ssh"
network = google_compute_network.main.name
direction = "INGRESS"
source_ranges = ["35.235.240.0/20"] # IAP gateway range
allow {
protocol = "tcp"
ports = ["22"]
}
}Compute Engine VMs laufen mit einem angehängten Service-Konto – dem GCP-Äquivalent eines AWS EC2-Instanzprofils oder einer verwalteten Azure VM-Identität. ACE-empfohlenes Muster: Verwenden Sie niemals das standardmäßige Compute-Service-Konto (überprivilegiert); erstellen Sie immer ein Service-Konto pro Workload mit nur den IAM-Rollen, die die Workload benötigt.
Wir erstellen ein Service-Konto, gewähren ihm roles/logging.logWriter + roles/monitoring.metricWriter (das Minimum für den Ops Agent zum Senden von Logs / Metriken) und hängen es an eine e2-micro Debian VM ohne externe IP an. Die IAP-SSH-Firewall-Regel aus Schritt 3 ermöglicht den Zugriff über einen Tunnel.
resource "google_service_account" "vm" {
account_id = "certlabpro-ace-vm-sa"
display_name = "ACE lab VM service account"
}
resource "google_project_iam_member" "vm_log_writer" {
project = data.google_project.current.project_id
role = "roles/logging.logWriter"
member = "serviceAccount:${google_service_account.vm.email}"
}
resource "google_project_iam_member" "vm_metric_writer" {
project = data.google_project.current.project_id
role = "roles/monitoring.metricWriter"
member = "serviceAccount:${google_service_account.vm.email}"
}
data "google_project" "current" {}
resource "google_compute_instance" "vm" {
name = "certlabpro-ace-vm"
machine_type = "e2-micro"
zone = "us-central1-a"
boot_disk {
initialize_params {
image = "debian-cloud/debian-12"
}
}
network_interface {
subnetwork = google_compute_subnetwork.main.id
# No access_config block = no external IP. SSH via IAP only.
}
service_account {
email = google_service_account.vm.email
scopes = ["cloud-platform"] # API scope; IAM does the real gating
}
labels = local.labels
}ACE-empfohlenes Beobachtbarkeitsmuster: Eine logbasierte Metrik zählt Übereinstimmungen eines Cloud Logging-Filters, dann löst eine Cloud Monitoring-Benachrichtigungsrichtlinie einen Alarm aus, wenn die Metrik einen Schwellenwert überschreitet. Wir überwachen Logzeilen mit severity >= ERROR von jeder GCE VM in diesem Projekt, zählen sie pro Minute und alarmieren, wenn mehr als 5 in einem 5-Minuten-Fenster auftreten.
Der Benachrichtigungskanal ist implizit – Benachrichtigungsrichtlinien benötigen ein notification_channels-Array, aber der Kanal selbst (E-Mail, Slack, PagerDuty) wird typischerweise einmal pro Projekt in der Konsole konfiguriert. Die ACE-Prüfung testet dieses Log-Metrik → Benachrichtigungsrichtlinie → Benachrichtigungskanal-Dreieck als das standardmäßige Beobachtbarkeits-Primitiv.
resource "google_logging_metric" "vm_errors" {
name = "certlabpro_ace_vm_errors"
filter = "resource.type=\"gce_instance\" AND severity >= ERROR"
metric_descriptor {
metric_kind = "DELTA"
value_type = "INT64"
}
depends_on = [google_project_service.logging]
}
resource "google_monitoring_alert_policy" "vm_error_burst" {
display_name = "ACE lab — VM error burst"
combiner = "OR"
conditions {
display_name = "More than 5 ERROR lines per 5 minutes"
condition_threshold {
filter = "metric.type=\"logging.googleapis.com/user/${google_logging_metric.vm_errors.name}\" AND resource.type=\"gce_instance\""
duration = "300s"
comparison = "COMPARISON_GT"
threshold_value = 5
aggregations {
alignment_period = "60s"
per_series_aligner = "ALIGN_DELTA"
}
}
}
# notification_channels = [] # add channels via the console or as a separate TF resource
depends_on = [google_project_service.monitoring]
}terraform destroy reißt alles ab. Die VM stoppt die Abrechnung sofort bei Zerstörung (die Festplatte geht mit ihr). Das Service-Konto wird zerstört; IAM-Bindungen werden gelöst. Die VPC + Subnetz + Firewalls werden sauber zerstört. Logbasierte Metrik + Benachrichtigungsrichtlinie werden sauber getrennt. Projektdienste bleiben aktiviert (kann kostenlos anbleiben).
ACE deckt viele GCP-Admin-Oberflächen ab, die in diesem Lab nicht behandelt werden können – Cloud Load Balancing (globales HTTP(S) LB, regionales internes LB, Netzwerk-LB), Managed Instance Groups + Autoscaling, Cloud Run, GKE-Cluster, Cloud Storage (behandelt in [[gcp-cdl]]), Cloud SQL, Cloud Spanner, Cloud Bigtable, Pub/Sub, Cloud Functions, Cloud Scheduler, Cloud Tasks, Cloud KMS, VPC Peering / Shared VPC ([[gcp-pcne]]), Cloud NAT, Cloud VPN / Interconnect, Cloud DNS, Cloud Armor, IAM-Benutzerrollen, Resource Manager-Hierarchie (Ordner + Organisationen), Cloud Asset Inventory, Cloud Deployment Manager (zugunsten von Terraform veraltet).
Wir beschränken uns auf die Primitiven VPC + GCE + IAM + Logging, da sie die Grundlage für jedes fortgeschrittenere GCP-Admin-Muster bilden. MIGs skalieren GCE-Instanzen; LBs stehen vor MIGs; GKE / Cloud Run laufen auf Compute; alles schreibt in Cloud Logging.
Für eine konzeptionelle Abdeckung Dienst für Dienst siehe die Bereiche Durchsuchen, Handbuch und Editorial dieser Zertifizierungsseite.