Google ACE: Bereitstellung, Konfiguration und Automatisierung — Lernleitfaden

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

Teil des Google Associate Cloud Engineer — Lernleitfaden. Üben Sie mit verifizierten Antworten im Google-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Überblick

Bereitstellung, Konfiguration und Automatisierung in Google Cloud konzentrieren sich auf die wiederholbare, prüfbare und sichere Bereitstellung von Änderungen. Bewährte Praktiken basieren auf Infrastructure as Code (IaC), deklarativen Vorlagen, unveränderlichen Artefakten und standardisierten Pipelines. Operative Exzellenz wird durch das Design für Idempotenz, die Vorschau von Änderungen, die Durchsetzung von Richtlinien und die Planung kontrollierter Rollouts mit klaren Rollback-Pfaden erreicht. Die folgenden Abschnitte bieten praktische Muster, Befehlsbeispiele und die Begründung für Designentscheidungen, einschließlich häufiger Fallstricke und Kompromisse.

Grundlagen von Infrastructure as Code und Konfiguration

Prinzipien:

Deklarative Vorlagen beschreiben den gewünschten Endzustand; Werkzeuge gleichen den tatsächlichen Zustand an. Dies verbessert die Idempotenz, Wiederholbarkeit und Prüfbarkeit.
Unveränderliche Infrastruktur stellt neue Instanzen oder Revisionen bereit, anstatt bestehende zu modifizieren, was das Rollback vereinfacht und Drift reduziert.
Trennung der Belange (Separation of Concerns): Parametrisieren Sie umgebungsspezifische Werte und verwenden Sie gemeinsam genutzte Module oder Vorlagen wieder.

Terraform in Google Cloud:

Konfiguration: HCL-Dateien definieren Ressourcen, Variablen und Ausgaben. Verwenden Sie Module, um VPCs, Service Accounts oder GKE-Cluster zu kapseln; veröffentlichen Sie gemeinsam genutzte Module intern, um Muster zu standardisieren.
Zustand (State): Halten Sie den Zustand remote und versioniert. Verwenden Sie ein Cloud Storage-Backend mit Objektversionierung und gegebenenfalls Bucket-Aufbewahrungsrichtlinien.
- Beispiel für einen Backend-Block:

undefined

Fehlermodi: Lokaler Zustand oder nicht versionierte Buckets bergen das Risiko von Datenverlust und konkurrierenden Schreibvorgängen. Erzwingen Sie den Zugriff auf den State-Bucket nach dem Prinzip der geringsten Rechte (Least Privilege); bevorzugen Sie kurzlebige Anmeldedaten und Service Account Impersonation gegenüber Schlüsseln.
Pläne und Anwendung (Plans and Applies): terraform plan bietet eine Vorschau; sichern Sie apply-Vorgänge in CI/CD durch eine menschliche Genehmigung für die Produktion ab. Verwenden Sie -target sparsam; häufiges Targeting erhöht das Risiko von Drift.
Module: Versionieren Sie Module semantisch; pinnen Sie Versionen, um ungeplante Änderungen zu vermeiden. Validieren Sie vor der Anwendung mit terraform validate und Richtlinienprüfungen.
Importe und Drift: terraform import übernimmt bestehende Ressourcen in die Verwaltung; führen Sie danach eine sorgfältige Überprüfung des Zustands durch. Erkennen Sie Drift, indem Sie terraform plan regelmäßig ausführen.
Remote-Ausführung: Führen Sie Terraform in Cloud Build- oder Cloud Run-Jobs mit Workload Identity Federation aus, um Service-Account-Schlüssel zu vermeiden. Cachen Sie Provider, um die Build-Zeit zu reduzieren.

Deployment Manager:

Obwohl viele Teams auf Terraform standardisieren, könnten Sie auf den Deployment Manager stoßen. Aktualisieren Sie eine Bereitstellung ohne Ausfallzeit, indem Sie die Konfiguration aktualisieren:

undefined

Konfigurationsstandards:

Namensgebung: Verwenden Sie konsistente, maschinenlesbare Namen mit Umgebung, Region, Zweck und Sequenz, z. B. vpc-prod-usw1-core.
Labels: Fügen Sie allen Ressourcen Labels wie env, cost_center, owner und app hinzu; erzwingen Sie dies durch Richtlinien oder Validierung.
Tags: Verwenden Sie Netzwerk-Tags, um den Geltungsbereich von Firewall-Regeln festzulegen; vermeiden Sie die Überladung von Tags für Identität oder Besitz (Labels sind besser geeignet).
Metadaten: Nutzen Sie Instanz-Metadaten für Startskripte und Konfiguration; bevorzugen Sie Metadaten mit Prüfsummen- oder Versions-Flags, um wiederholte Ausführungen zu steuern. Platzieren Sie keine Secrets in Metadaten; verwenden Sie den Secret Manager.

APIs, Dienstaktivierung, Kontingente und Service Accounts:

Aktivieren Sie benötigte Dienste frühzeitig in der Automatisierung:

undefined

Validieren Sie den Kontingent-Spielraum während der Planung; Skalierungstests sollten Kontingent-Prüfungen beinhalten, um Drosselung (Throttling) zu vermeiden.
Verwenden Sie dedizierte Service Accounts pro Workload und Umgebung; vergeben Sie IAM-Rollen nach dem Prinzip der geringsten Rechte (Least Privilege) im engsten Geltungsbereich. Bevorzugen Sie Gruppenmitgliedschaften für den menschlichen Zugriff und Service Account Impersonation für die Automatisierung.

Delivery Pipelines und Artefakt-Promotion

Cloud Build:

Definieren Sie Cloud Build-Schritte zum Erstellen, Testen und Verpacken von Artefakten. Verwenden Sie Substitutionen für dynamische Werte und den Secret Manager für Anmeldedaten.
Lösen Sie Builds durch Quellcode-Änderungen aus; isolieren Sie Build-Service-Accounts nach Repository oder Umgebung und vergeben Sie nur die benötigten Berechtigungen.
Cachen Sie Docker-Layer und Sprachabhängigkeiten, um die Build-Zeiten zu reduzieren. Achten Sie auf Limits für gleichzeitige Builds und Quotas für ephemere Worker.

Artefakt-Promotion:

Speichern Sie Container-Images oder Sprachpakete in der Artifact Registry. Die Beförderung (Promotion) erfolgt durch:
- Erneutes Taggen von unveränderlichen Digests für die Umgebung (z. B., :qa, :prod) oder
- Kopieren von Artefakten in ein umgebungsspezifisches Repository.
Kompromisse: Ein einziges Repository mit Tags vereinfacht die Auffindbarkeit, erfordert aber eine strikte Governance; Repositories pro Umgebung stärken die Isolation und die Durchsetzung von Richtlinien.

Cloud Deploy:

Modellieren Sie eine Delivery-Pipeline mit geordneten Zielen (z. B. dev → qa → prod). Releases referenzieren einen spezifischen Artefakt-Digest und ein Deployment-Manifest.
Für GKE und Cloud Run verwendet Cloud Deploy Skaffold-Konfigurationen, um Manifeste zu rendern und anzuwenden. Konfigurieren Sie Genehmigungen, Verifizierungen und Gates.
Rollout und Rollback:
- Canary-Deployments mit schrittweiser Traffic-Verschiebung reduzieren den Explosionsradius (Blast Radius).
- Blue/Green ermöglicht eine schnelle Umschaltung und ein schnelles Rollback auf Kosten zusätzlicher Kapazität.
- Führen Sie ein Rollback durch, indem Sie auf das letzte funktionierende Release pinnen; vermeiden Sie direkte Korrekturen (In-Place Fixes), die zu Drift führen.
Fehlermodi: Nicht übereinstimmende Cluster-Berechtigungen, fehlende APIs und Fehler im Manifest-Schema. Erkennen Sie diese frühzeitig, indem Sie Manifeste während des Builds rendern und gegen Cluster-Richtlinien validieren.

Planung sicherer Änderungen:

Fordern Sie für die Produktion eine Vorschau (Plan oder Render), automatisierte Tests, eine Richtlinienvalidierung und eine menschliche Genehmigung an.
Passen Sie bei verwalteten Instanzgruppen von Compute Engine die Update-Richtlinien maxSurge/maxUnavailable und die Health-Check-Einstellungen an, um eine Überprovisionierung zu vermeiden, wenn die Anwendungsbereitschaft langsam ist.

Befehlszeilenoperationen und Umgebungsverwaltung

Cloud Shell- und gcloud-Konfigurationen:

Cloud Shell bietet eine verwaltete Admin-Umgebung mit vorauthentifiziertem gcloud und einem persistenten Home-Verzeichnis.
Verwenden Sie benannte Konfigurationen, um schnell zwischen Konten, Projekten und Regionen zu wechseln: gcloud config configurations create prod gcloud config set project my-prod gcloud config set compute/region us-central1 gcloud config set compute/zone us-central1-a gcloud config configurations activate prod
Überprüfen Sie die aktive Konfiguration mit gcloud config list. Für GKE rufen Sie die Anmeldeinformationen ab: gcloud container clusters get-credentials my-cluster –region us-central1

Compute-Befehlsmuster:

VM mit einer reservierten internen IP-Adresse erstellen: gcloud compute addresses create license-ip –region=us-central1 –subnet=default –addresses=10.0.3.21 gcloud compute instances create license-server –zone=us-central1-a –subnet=default –private-network-ip=10.0.3.21 –tags=license
Eine benutzerdefinierte VPC, ein Subnetz und eine Firewall-Regel erstellen: gcloud compute networks create core –subnet-mode=custom gcloud compute networks subnets create core-us –network=core –range=10.0.0.0/20 –region=us-central1 gcloud compute firewall-rules create allow-https –network=core –allow=tcp:443 –target-tags=web

IAM-Muster:

Eine Rolle auf Projektebene zuweisen: gcloud projects add-iam-policy-binding my-project –member=group:ops@example.com –role=roles/logging.viewer
Benutzerdefinierte Rollen zwischen Projekten kopieren: gcloud iam roles copy myCustomRole –source=my-dev –destination=my-prod

Storage-Muster:

Einen Bucket erstellen und Objekte hochladen: gcloud storage buckets create gs://backups-prod –location=us-central1 –class=coldline –uniform-bucket-level-access gcloud storage cp ./backup.tar.gz gs://backups-prod/
Lebenszyklus über eine Datei konfigurieren und mit gcloud storage buckets update –lifecycle-file=policy.json anwenden

API-Aktivierung und -Überprüfung:

Pub/Sub für eine App aktivieren: gcloud services enable pubsub.googleapis.com
Aktivierte Dienste auflisten: gcloud services list –enabled

Governance, Drift und Automatisierung

Konfigurationsdrift und Richtliniendurchsetzung:

Drift durch regelmäßiges Ausführen von terraform plan erkennen; Builds bei unerwarteten Änderungen fehlschlagen lassen.
Richtlinien der Organisation durchsetzen (z. B. externe IPs einschränken) und Ressourcenkonfigurationen vor dem Anwenden mit Policy-as-Code validieren.
Für Kubernetes Config Sync und Policy Controller verwenden, um nicht konforme Änderungen kontinuierlich abzugleichen und zu blockieren.
Auditierbarkeit: Auf Admin Activity- und Data Access-Logs verlassen; zur Analyse an BigQuery weiterleiten. Cloud Asset Inventory für Point-in-Time- und Zeitreise-Zustandsabfragen verwenden.

Kontingente und Limits:

Kontingente pro Region und Projekt prüfen; Puffer für Autoscaling und Rollouts einplanen: gcloud compute regions describe us-central1 –format=“yaml(quotas)”
Erhöhungen vor geplantem Wachstum oder großen Rollouts beantragen.

Automatisierte Betriebsaufgaben:

Cloud Scheduler löst HTTP-Endpunkte, Pub/Sub-Themen oder Workflows nach einem Cron-Zeitplan aus. Idempotente Handler sicherstellen; Wiederholungsversuche und Dead-Letter-Themen konfigurieren.
Workflows orchestrieren mehrstufige Automatisierungen über Google-APIs hinweg mit Wiederholungsversuchen, parallelen Schritten und Kompensationslogik.
Cloud Run-Jobs führen containerisierte Batch- oder Verwaltungsaufgaben bei Bedarf oder über den Scheduler aus. Jobs für einmalige oder iterative Workloads bevorzugen; minimale Berechtigungen für das Service-Konto des Jobs verwenden.

Sicherheit und Beobachtbarkeit von Rollouts:

Health Checks und Readiness Probes in Dienste integrieren. Bei MIGs mit langsamem Start die anfängliche Verzögerung (initial delay) erhöhen, um vorzeitige Skalierungsaktionen zu verhindern.
Deployment-Metriken und Fehlerbudgets erfassen; Rollouts anhalten oder automatisch abbrechen, wenn sich SLOs verschlechtern.

Praktisches Problemszenario

Altostrat Media muss Deployments für einen GKE-basierten Dienst über mehrere Umgebungen hinweg standardisieren, dabei Konfigurationsdrift eliminieren und schnelle Rollbacks sicherstellen. Außerdem müssen sie eine feste interne IP für einen alten Lizenzserver reservieren, ohne die Anwendung neu zu konfigurieren.

Grundlegende Terraform-Module und Remote State erstellen

Module für VPC, Subnetze, GKE, Service-Konten und Firewall-Regeln implementieren. Ein Cloud Storage-Backend mit Versionierung und einer Aufbewahrungsrichtlinie für den State-Bucket konfigurieren.
Begründung: Modularisierung fördert Wiederverwendung und Konsistenz; ein entfernter, versionierter State ermöglicht Zusammenarbeit, Wiederherstellbarkeit und Sperren (Locking).

Erforderliche Dienste aktivieren und Automatisierungsidentitäten nach dem Prinzip der geringsten Rechte einrichten

compute.googleapis.com, container.googleapis.com, clouddeploy.googleapis.com, artifactregistry.googleapis.com aktivieren.
Pro Umgebung Service-Konten für Terraform, Cloud Build und Cloud Deploy erstellen; minimale Rollen zuweisen (z. B. roles/container.admin an Deployer, nicht an Builder).
Begründung: Vorab-Aktivierung und die Beschränkung von Rollen reduzieren Deployment-Fehler und begrenzen den Schadensradius (Blast Radius).

Netzwerk bereitstellen und die Legacy-IP reservieren

Mit Terraform eine benutzerdefinierte VPC, regionale Subnetze und Firewall-Regeln basierend auf Netzwerk-Tags erstellen.
Die interne IP reservieren: gcloud compute addresses create license-ip –region=us-central1 –subnet=core-us –addresses=10.0.3.21
Begründung: Deklaratives Networking stellt Wiederholbarkeit sicher; die Reservierung der IP erhält die Annahmen der Anwendung aufrecht.

Artefakte mit Cloud Build erstellen und in Artifact Registry veröffentlichen

Eine cloudbuild.yaml definieren, um Tests auszuführen, den Container zu erstellen, zu scannen und einen unveränderlichen Digest in Artifact Registry zu pushen.
Begründung: Unveränderliche, gescannte Artefakte sind die Grundlage für sichere Promotions und Nachverfolgbarkeit (Provenance).

Cloud Deploy-Pipeline mit dev → qa → prod-Zielen konfigurieren

Eine Delivery-Pipeline und Ziele definieren; auf die Skaffold-Konfiguration verweisen, um Manifeste zu rendern. Manuelle Genehmigung für die Prod-Umgebung erfordern und Verifizierungen konfigurieren.
Begründung: Strukturierte Promotion erzwingt Kontrollen; richtlinien pro Zielumgebung verhindern versehentliche Deployments in die Produktion.

GKE-Updates mit Canary-Strategie und Health Gates ausrollen

Eine Canary-Rollout-Richtlinie verwenden, um den Traffic schrittweise auf 10 %, dann 50 %, dann 100 % umzuleiten, abhängig von SLO- und Fehlerratenprüfungen.
Begründung: Progressive Delivery reduziert das Risiko und bietet natürliche Rollback-Punkte.

Drift durch geplante plan-Ausführungen und Richtlinienprüfungen eliminieren

Ein nächtlicher Job führt terraform plan und einen Policy-as-Code-Validator aus; alarmiert bei unerwarteten Diffs oder Verstößen.
Begründung: Früherkennung verhindert, dass sich Drift ansammelt und zukünftige apply-Vorgänge fehlschlagen.

Die Lizenzserver-VM mit der reservierten IP in Betrieb nehmen

Die VM an die reservierte Adresse und die passenden Tags gebunden erstellen: gcloud compute instances create license-server –zone=us-central1-a –subnet=core-us –private-network-ip=10.0.3.21 –tags=license
Begründung: Stellt die Erreichbarkeit sicher, ohne die Anwendung zu ändern; Tags halten den Geltungsbereich von Firewall-Regeln eng begrenzt.

Wiederkehrende Aufgaben mit Scheduler, Workflows und Jobs automatisieren

Cloud Scheduler löst einen Workflow aus, um Service-Konto-Schlüssel zu rotieren, wo dies unvermeidbar ist, und um einen Cloud Run-Job für wöchentliche Datenbank-Vacuum-Aufgaben zu starten.
Begründung: Zentralisierte Zeitplanung plus Orchestrierung führt zu Zuverlässigkeit und Beobachtbarkeit mit Wiederholungsversuchen und Kompensation.

Rollbacks planen und Readiness-Schwellenwerte validieren

Rollback-Playbooks definieren, um das letzte funktionierende Release erneut zu promoten. Readiness Probes anpassen und bei MIG-basierten Workloads die anfänglichen Verzögerungen der Health Checks erhöhen, um sie an die Aufwärmphase der App anzupassen.
Begründung: Vorgeplante Rollbacks und angepasste Health Checks verhindern kaskadierende Ausfälle und Überprovisionierung bei Störungen.

Dieser Ansatz kombiniert unveränderliche Artefakte, deklarative Infrastruktur, kontrollierte Promotions und Automatisierung nach dem Prinzip der geringsten Rechte, um einen sicheren, auditierbaren und wiederholbaren Betrieb auf Google Cloud zu gewährleisten.

← Speicher · Alle Domänen · Überwachung →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →