Google PCD: Continuous Delivery, Konfiguration und Infrastrukturautomatisierung — Lernleitfaden

By Laurynas Brazys · 3 September 2026 · #google #PCD #certification #exam-prep #study-guide

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

Überblick

Continuous Delivery in der Google Cloud integriert Build-Automatisierung, Artefakt-Management, Deployment-Orchestrierung, Infrastructure as Code und starke Governance, um Änderungen wiederholt und sicher bereitzustellen. Robuste Pipelines kombinieren unveränderliche Artefakte und deklarative Konfigurationen mit Richtlinien und Auditierbarkeit. Dieser Abschnitt erläutert Designentscheidungen, Betriebspraktiken und häufige Fehlermodi bei der End-to-End-Implementierung von Cloud Build, Cloud Deploy, Artifact Registry, Terraform, Kubernetes, Feature-Flags und Governance-Kontrollen.

Build- und Deployment-Orchestrierung

Cloud Build

Trigger: Verbinden Sie Builds mit Quell-Ereignissen (Branch-Pushes, Tags, PRs) oder Zeitplänen. Bevorzugen Sie Branch- oder Tag-Regex, um sicherzustellen, dass nur beabsichtigte Refs ausgelöst werden. Trigger können mit einem spezifischen Servicekonto ausgeführt werden, um das Prinzip der geringsten Rechte (Least Privilege) durchzusetzen; verlassen Sie sich nicht auf das Standardkonto, wenn Builds weitreichenden API-Zugriff benötigen.
Build-Schritte: Jeder Schritt wird in einem Container ausgeführt. Verwenden Sie zweckgebundene Builder (docker, gcloud) oder benutzerdefinierte Builder, wenn die Standard-Toolchain nicht ausreicht. Trennen Sie die Schritte für Kompilierung, Unit-Tests, Integrationstests, Linting, Sicherheitsscans und Artefakt-Paketierung, damit Fehler zuordenbar sind und effektiv zwischengespeichert werden.
Substitutionen: Verwenden Sie integrierte Variablen (PROJECT_ID, SHORT_SHA) und benutzerdefinierte Substitutionen (mit dem Präfix $_) für parametrisierte Builds. Halten Sie umgebungsspezifische Werte aus der Build-Logik heraus; übergeben Sie sie als Substitutionen oder lösen Sie sie später während des Deployments auf.
Servicekonten: Das Cloud Build-Dienstkonto (PROJECT_NUMBER@cloudbuild.gserviceaccount.com) erfordert explizite Rollen (z. B. Artifact Registry-Schreibzugriff, Cloud Deploy-Release-Admin). Weisen Sie minimale Rollen zu und beschränken Sie den Geltungsbereich pro Projekt. Für private Ressourcen verwenden Sie Private Pools mit VPC-Konnektivität.
Artefakte: Veröffentlichen Sie unveränderliche Images in Artifact Registry und laden Sie optional Nicht-Container-Artefakte über den artifacts-Abschnitt in Cloud Storage hoch. Taggen Sie Images sowohl mit einer semantischen Version als auch mit dem Commit-Digest; verwenden Sie Image-Digests in Deployments, um Tag-Drift zu vermeiden.

Beispiel für eine Cloud Build-Konfiguration:

cloudbuild.yaml: steps:
- name: gcr.io/cloud-builders/docker args: [“build”,"-t","$REGION-docker.pkg.dev/$PROJECT_ID/app/app:${SHORT_SHA}","."]
- name: gcr.io/cloud-builders/docker args: [“push”,"$REGION-docker.pkg.dev/$PROJECT_ID/app/app:${SHORT_SHA}"]
- name: gcr.io/cloud-builders/gcloud args: [“deploy”,“releases”,“create”,“app-${SHORT_SHA}”,"–delivery-pipeline=app-pipeline","–images=app=$REGION-docker.pkg.dev/$PROJECT_ID/app/app@sha256:${COMMIT_SHA}"] substitutions: _REGION: us-central1 serviceAccount: projects/$PROJECT_ID/serviceAccounts/cb-deployer@$PROJECT_ID.iam.gserviceaccount.com
Trigger-Beispiel: gcloud builds triggers create cloud-source-repositories –repo=my-repo –branch-pattern=^main$ –build-config=cloudbuild.yaml –service-account=cb-deployer@$PROJECT_ID.iam.gserviceaccount.com

Cloud Deploy

Delivery-Pipelines definieren geordnete Stufen und Ziele (Targets). Ziele verweisen auf GKE-Cluster, Cloud Run-Dienste oder andere unterstützte Runtimes. Markieren Sie Produktionsstufen mit requireApproval, um die Beförderung (Promotion) zu steuern.
Rollouts ordnen ein Release einem Ziel zu; eine Promotion befördert ein Release durch die Ziele. Verwenden Sie progressive Bereitstellung (Canary, Blue/Green) und Hooks für Pre-Deploy- und Post-Deploy-Prüfungen.
Fehlermodi: Die Verwendung veränderlicher Tags verursacht unbeabsichtigte Upgrades; pinnen Sie immer Digests. Fehlende IAM-Berechtigungen für das Deployer-Konto blockieren Rollouts. Nicht renderbare Manifeste oder Konfigurationsabweichungen zwischen Umgebungen führen zu Fehlern bei der Promotion; validieren Sie Manifeste während des Builds.

Beispiele für Cloud Deploy-Definitionen:

delivery-pipeline.yaml: apiVersion: deploy.cloud.google.com/v1 kind: DeliveryPipeline metadata: name: app-pipeline serialPipeline: stages:
- targetId: dev
- targetId: prod strategy: standard: verify: true requireApproval: true
targets.yaml: apiVersion: deploy.cloud.google.com/v1 kind: Target metadata: name: dev gke: cluster: projects/PROJECT/locations/REGION/clusters/DEV_CLUSTER
Definition des Produktionsziels
apiVersion: deploy.cloud.google.com/v1 kind: Target metadata: name: prod gke: cluster: projects/PROJECT/locations/REGION/clusters/PROD_CLUSTER
Release und Promotion: gcloud deploy releases create app-20260903-1 –delivery-pipeline=app-pipeline –region=us-central1 –images=app=us-central1-docker.pkg.dev/PROJECT/app/app@sha256:IMAGE_DIGEST gcloud deploy releases promote –delivery-pipeline=app-pipeline –release=app-20260903-1 –region=us-central1

Artefakte und Integrität der Lieferkette

Artifact Registry

Repositories: Erstellen Sie separate Repositories pro Team oder Umgebung, um IAM und Bereinigungen zu begrenzen. Verwenden Sie regionale Repositories in der Nähe von Buildern und Runtimes, um Egress-Kosten und Latenz zu reduzieren. Paketformate umfassen Docker-Images und Sprachpakete (Maven, npm, PyPI).
Aufbewahrung (Retention): Definieren Sie Bereinigungsrichtlinien, um nicht referenzierte oder alte Tags zu entfernen, wobei ein Sicherheitsfenster für Rollbacks beibehalten wird. Vermeiden Sie eine aggressive Aufbewahrung, die die letzte als funktionierend bekannte Version entfernt.
Provenienz und SBOM: Aktivieren Sie die Build-Provenienz, damit Images SLSA-konforme Attestierungen enthalten. Generieren Sie SBOMs während des Builds und speichern Sie sie als Attestierungen, um die Triage von Schwachstellen zu verbessern.
Schwachstellenscans: Aktivieren Sie die Container-Analyse und brechen Sie den Build ab oder blockieren Sie die Promotion, wenn CVEs mit hohem Schweregrad ohne verfügbare Fixes oder Richtlinienausnahmen erkannt werden.
Kompromisse: Die Zentralisierung aller Artefakte in einem einzigen Projekt vereinfacht die Governance, kann aber einen großen Auswirkungsradius (Blast Radius) schaffen; Repositories pro Umgebung oder pro Anwendung reduzieren das Risiko, erhöhen aber den Verwaltungsaufwand.

Durchsetzung der Lieferkette

Binary Authorization in GKE kann Attestierungen erfordern (z. B. „erstellt von Cloud Build im Projekt X“, „keine kritischen CVEs“). Integrieren Sie dies mit Cloud Deploy-Gates, um nicht konforme Releases zu stoppen.
Fehlermodi: Das Verlassen auf veränderliche Tags, deaktivierte Scans oder nicht authentifizierte Pulls kann dazu führen, dass ungeprüfte Software in die Produktion gelangt. Pinnen Sie Digests und fordern Sie Attestierungen an.

Infrastructure as Code und GitOps

Terraform

Konfiguration und Module: Erstellen Sie wiederverwendbare Module mit klaren Ein- und Ausgaben sowie semantischen Versionen. Veröffentlichen Sie Module in einem geteilten Repo oder einer Registry; pinnen Sie Versionen, um unerwartete Änderungen zu vermeiden.
State: Verwenden Sie das GCS-Backend für den Remote State mit IAM auf Bucket-Ebene, Objektversionierung und CMEK. Schützen Sie den State vor manuellen Bearbeitungen und stellen Sie die Verschlüsselung des States sicher. Vermeiden Sie Secrets im State, indem Sie diese zur Apply-Zeit aus dem Secret Manager lesen und Data Sources sparsam einsetzen. terraform { backend “gcs” { bucket = “tf-state-prod” prefix = “networking” } }
Plans und Applies: Führen Sie terraform plan mit -out aus und lassen Sie den Diff von einem Menschen oder einem automatisierten Gate prüfen; wenden Sie nur den zuvor genehmigten Plan an. Verwenden Sie -refresh-only oder -detailed-exitcode in Drift-Detection-Jobs.
Umgebungstrennung: Verwenden Sie separate Projekte, State-Buckets und Service Accounts pro Umgebung. Bevorzugen Sie für komplexe Organisationen Verzeichnisse pro Umgebung mit Variablendateien gegenüber Workspaces. Teilen Sie niemals den State zwischen Umgebungen.
Fehlermodi: Gleichzeitige Applies beschädigen den State; erzwingen Sie die Serialisierung mit CI/CD und Locking (GCS verwendet Object Preconditions). Manuelle Änderungen in der Konsole verursachen Drift; schränken Sie direkte Mutationen ein und führen Sie periodische Plan-Jobs aus.

Deklarative Kubernetes-Konfiguration

Manifeste: Halten Sie Kubernetes-Objekte deklarativ; vermeiden Sie imperative kubectl-Befehle in Produktions-Flows. Pinnen Sie Image-Digests und Ressourcen-Requests/-Limits.
Kustomize: Verwenden Sie Base + Overlays, um umgebungsspezifische Patches zu handhaben, ohne Charts zu forken. kustomization.yaml (Overlay): resources:
- ../../base patches:
- target: kind: Deployment name: api patch: |
  - op: replace path: /spec/replicas value: 3
Helm: Verwenden Sie Values-Dateien pro Umgebung; dokumentieren Sie die Vorrangregeln (Kommandozeilen-Werte überschreiben Values-Dateien, welche wiederum die Chart-Standardwerte überschreiben). Templaten und rendern Sie in der CI (skaffold render oder helm template), sodass die Konfigurationen zur Deploy-Zeit unveränderlich sind.
GitOps: Speichern Sie den Soll-Zustand in Git. Verwenden Sie Cloud Deploy oder Config Sync, um Cluster mit Git abzugleichen. PRs werden zur Oberfläche für die Änderungssteuerung mit Audit-Trails und Richtlinienprüfungen. Vermeiden Sie Modifikationen durch kubectl exec, die nicht in Git erfasst werden.

Release-Sicherheit, Konfiguration und Governance

Feature-Flags und Laufzeitkonfiguration

Feature-Flags entkoppeln die Bereitstellung (Deploy) von der Veröffentlichung (Release); liefern Sie ruhenden Code aus und aktivieren Sie ihn pro Kohorte, Prozentsatz oder Region. Speichern Sie Flag-Definitionen in einem System mit niedriger Latenz und hoher Verfügbarkeit (HA) (Firestore, Memorystore) und cachen Sie diese mit kurzen TTLs. Protokollieren Sie Auswertungen zur Nachverfolgbarkeit.
Schrittweiser Rollout: Kombinieren Sie Traffic-Splitting (Cloud Run) oder Canary-Subsets (GKE) mit Flags, um den „Blast Radius“ (Schadensradius) zu minimieren. Verwenden Sie Zustandsmetriken und SLO-basierte, automatisierte Rollback-Trigger.
Sicherer Rollback: Bevorzugen Sie schnelle Deaktivierungen über Feature-Flags. Für einen binären Rollback stufen Sie das letzte als funktionierend bekannte Release hoch oder wenden Sie den Digest des vorherigen Manifests erneut an.

Umgebungsvariablen, Rangfolge, Secrets

Die Rangfolge ist üblicherweise: Laufzeit-Flags > Umgebungsvariablen > Konfigurationsdateien > Standardwerte im Code. Dokumentieren und standardisieren Sie dies über alle Services hinweg.
Injizieren Sie Konfigurationen mit ConfigMaps und Umgebungsvariablen; verwenden Sie Secret Manager oder Kubernetes Secrets für sensible Werte. Rotieren Sie diese regelmäßig und vermeiden Sie das Einbacken von Secrets in Images.
Beispiele für die Injektion von Secrets:
- Cloud Run Umgebungsvariable:

undefined

GKE Secret Manager CSI:

undefined

Qualitäts-Gates in CI/CD

Unit-Tests werden bei jedem Commit ausgeführt; schnelles Feedback ist entscheidend.
Integrationstests laufen gegen kurzlebige Umgebungen oder Sandboxes mit vorbereiteten Daten.
Sicherheitsprüfungen: SAST, Scannen von Abhängigkeiten, Scannen von Container-Schwachstellen, IaC-Richtlinienprüfungen (Conftest, Policy Controller). Blockieren Sie Merges oder Hochstufungen bei kritischen Befunden.
Deployment-Prüfungen: Predeploy- und Postdeploy-Aktionen von Cloud Deploy validieren die Bereitschaft, die Sicherheit von Datenbankmigrationen und Smoke-Tests.

Branching, Code-Review, Versionierung, Nachverfolgbarkeit

Bevorzugen Sie Trunk-based Development mit kurzlebigen Feature-Branches und obligatorischen PR-Reviews. Erzwingen Sie erforderliche Prüfungen und eine lineare Historie zur Auditierbarkeit.
Versionierung: Semantische Versionierungs-Tags für Releases; Image-Digests und Commit-SHAs für Unveränderlichkeit (Immutability). Vermeiden Sie bewegliche Tags wie latest in Produktions-Deployments.
Nachverfolgbarkeit: Annotieren Sie Builds und Releases mit Commit-, PR- und Ticket-IDs. Senden Sie Deployment-Ereignisse an Logging; versehen Sie Ressourcen mit Labels für Kosten und Zuständigkeit.

Infrastruktur-Drift, Richtlinien, Audit, Änderungssteuerung

Drift-Erkennung: Geplanter

undefined

; Alarmierung bei Exit-Codes ungleich null. Bei Clustern stellt Config Sync die schlussendliche Konvergenz mit Git sicher.

Richtliniendurchsetzung: Verwenden Sie Organisationsrichtlinien (Organization Policy) für Leitplanken (z. B. Einschränkung externer IPs), Policy Controller für KRM-Constraints und Binary Authorization für Image-Richtlinien.
Audit-Logs: Aktivieren Sie Admin Activity- und Data Access-Logs; leiten Sie sie an zentralisierte Projekte mit Sinks und einer Aufbewahrungsdauer weiter, die den Compliance-Anforderungen entspricht. Cloud Asset Inventory liefert Änderungshistorie und Zugriffsanalysen.
Änderungssteuerung: Manuelle Freigaben bei Hochstufungen in die Produktion, mit Begründungen, die als Annotationen erfasst werden. Freeze-Windows können als Richtlinienprüfungen in CI/CD kodiert werden. Stellen Sie sicher, dass Notfall-Rollback-Pfade dokumentiert und geübt werden.

Praktisches Problemszenario

Acme Retail muss einen neuen order-service in GKE für die Entwicklungs- (Dev) und Produktionsumgebung (Prod) bereitstellen, und zwar mit sicheren Canary-Rollouts, strikter Richtliniendurchsetzung und vollständiger Nachverfolgbarkeit der Releases. Das Team muss die mit Terraform verwaltete Infrastruktur, die deklarative Kubernetes-Konfiguration mit Kustomize und eine auditierbare CI/CD-Pipeline mit Cloud Build und Cloud Deploy standardisieren.

Ansatz:

Artefakt-Repositories und Identitäten einrichten

Erstellen Sie die regionalen Artifact Registry-Repositories order-docker-dev und order-docker-prod. Weisen Sie dem Cloud Build Service Account im App-Projekt die Rollen roles/artifactregistry.writer und den GKE-Laufzeitknoten die Rolle roles/artifactregistry.reader für das entsprechende Repo zu.
Begründung: Getrennte Repositories reduzieren den „Blast Radius“ und vereinfachen Lifecycle-Richtlinien. Explizites IAM vermeidet standardmäßig zu weitreichende Berechtigungen.

Terraform für die Infrastruktur mit Umgebungstrennung definieren

Erstellen Sie die Verzeichnisse terraform/envs/dev und terraform/envs/prod. Jede Konfiguration enthält ein GCS-Backend mit separaten State-Buckets, ein GKE-Cluster-Modul und IAM-Bindungen für den Cloud Deploy Service Account. Führen Sie terraform init, plan -out=plan.bin und apply plan.bin in einem abgesicherten CI-Job pro Umgebung aus.
Begründung: Pro-Umgebungs-State und -Projekte verhindern versehentliche Auswirkungen auf andere Umgebungen; Plan-Dateien unterstützen die Überprüfung und eine auditierbare Änderungssteuerung.

Deklarative Kubernetes-Basis und Kustomize-Overlays erstellen

Platzieren Sie Kubernetes-Manifeste in k8s/base für Deployment, Service und HPAs mit Images, die per Digest festgeschrieben sind. Erstellen Sie k8s/overlays/dev und k8s/overlays/prod mit Patches für Replicas, Ressourcenanforderungen und Konfigurationen. Verwenden Sie eine Secret Manager CSI-Klasse für Datenbank-Anmeldeinformationen.
Begründung: Eine „Single Source of Truth“ mit Overlays eliminiert Drift und hält Konfigurationen DRY (Don’t Repeat Yourself), während sie gleichzeitig sichere, umgebungsspezifische Unterschiede ermöglicht.

Cloud Build mit getrennten Test- und Paketierungsschritten implementieren

Die cloudbuild.yaml enthält Schritte: Linting und Unit-Tests, Integrationstests gegen einen temporären Dev-Namespace, Container-Build und Push in das Umgebungs-Repo, SBOM- und Schwachstellen-Scans sowie die Generierung von Provenance-Daten. Der Trigger wird bei PRs zu main für Tests und bei Merges für die Paketierung ausgeführt. Builds laufen als cb-deployer Service Account mit den geringsten Rechten (Least Privilege).
Begründung: Frühe Fehlschläge sind kostengünstig; die Trennung der Belange (Separation of Concerns) verbessert die Beobachtbarkeit und ermöglicht gezielte Wiederholungsversuche. Das Prinzip der geringsten Rechte reduziert das Risiko in der Lieferkette (Supply Chain).

Cloud Deploy Delivery-Pipeline mit manueller Prod-Freigabe und Canary-Strategie konfigurieren

Definieren Sie eine DeliveryPipeline mit dev- und prod-Zielen. Die prod-Stufe erfordert eine Freigabe und verwendet eine Canary-Strategie (z. B. 10 Prozent, dann 100 Prozent). Verwenden Sie Predeploy-Hooks für Schema-Kompatibilitätsprüfungen und Smoke-Tests; Postdeploy verifiziert die SLOs.
Begründung: Progressive Delivery begrenzt den „Blast Radius“ und führt automatisierte Qualitäts-Gates ein, während die manuelle Freigabe eine menschliche Überprüfung (Human-in-the-Loop) für die Produktion erzwingt.

GitOps und Richtliniendurchsetzung verknüpfen

Schützen Sie den main-Branch mit erforderlichen Reviews und bestandenen Prüfungen. Verwenden Sie Policy Controller-Constraints, um privilegierte Pods zu blockieren und veränderliche Tags zu verbieten. Aktivieren Sie Binary Authorization, um vor der Zulassung (Admission) eine Cloud Build-Provenance und Attestierungen wie „keine hohen CVEs“ zu fordern.
Begründung: Policy-as-Code verhindert, dass riskante Konfigurationen den Cluster erreichen, und sorgt für eine konsistente Durchsetzung.

Konfiguration und Feature-Flags für ein sicheres Release verwalten

Speichern Sie nicht-sensible Laufzeitkonfigurationen in ConfigMaps; Secrets werden über Secret Manager CSI bereitgestellt. Führen Sie ein Feature-Flag order_new_flow ein, das aus Firestore gelesen wird, mit einem anfänglichen Rollout von 1 Prozent in der Produktion; Flags werden mit kurzer TTL zwischengespeichert und protokolliert.
Begründung: Flags entkoppeln das Release vom Deployment und ermöglichen eine sofortige Deaktivierung, falls Probleme auftreten, ohne das Binary zurückzurollen.

Beobachtbarkeit, Drift-Erkennung und Nachverfolgbarkeit sicherstellen

Annotieren Sie Builds und Releases mit Commit-SHA, PR-Nummer und Change-Ticket. Leiten Sie Cloud Deploy-Ereignisse und GKE-Audit-Logs an ein zentrales Logging-Projekt weiter. Nächtliche terraform plan-Jobs alarmieren bei Drift; Config Sync überwacht KRM-Abweichungen und gleicht sie mit Git ab.
Begründung: Vollständige Herkunfts- (Provenance) und Audit-Protokolle beschleunigen die Reaktion auf Vorfälle; kontinuierliche Drift-Erkennung erhält die Integrität der Infrastruktur aufrecht.

Rollbacks und Änderungssteuerung durchführen

Bei Vorfällen deaktivieren Sie zuerst order_new_flow über das Flag. Falls erforderlich, stufen Sie das vorherige erfolgreiche Release in Cloud Deploy für Dev und Prod hoch. Alle Hochstufungen in die Produktion erfordern eine Ticket-Referenz in den Release-Annotationen und eine Freigabe durch den diensthabenden SRE.
Begründung: Flags bieten eine sofortige Schadensbegrenzung; unveränderliche (immutable) Releases ermöglichen einen vorhersagbaren Rollback. Freigaben und Annotationen erfüllen die Anforderungen an operative Governance und Compliance.

← Identität · Alle Domänen · Observability →

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