Google PCA: DevOps, Delivery Engineering und Infrastruktur als Code — Lernleitfaden

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

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

Überblick

DevOps, Delivery Engineering und Infrastructure as Code (IaC) auf Google Cloud konzentrieren sich auf die kontinuierliche Bereitstellung zuverlässiger Änderungen mit starker Nachverfolgbarkeit, Automatisierung und Sicherheit. Architekturen sollten für kurze Feedback-Zyklen, wiederholbare Deployments, unveränderliche Infrastruktur und Leitplanken, die mit der Organisation skalieren, optimiert sein. Auf Google Cloud kombiniert dies typischerweise Best Practices der Quellcodeverwaltung, CI mit Cloud Build, Artefakt-Management mit Artifact Registry, CD mit Cloud Deploy, Kubernetes mit GKE unter Verwendung von Manifesten, Helm oder Kustomize, GitOps zur Kontrolle von Konfigurationsdrift und IaC mit Terraform oder Google Cloud Deployment-Vorlagen. Operative Exzellenz erfordert progressive Bereitstellung (Blue-Green, Canary, Traffic-Splitting und Feature-Flags), Kontrollen für die Software-Lieferkette (Scannen, Provenienz, Signieren), Test- und Deployment-Gates sowie eine Governance, die Geschwindigkeit, Sicherheit, Auditierbarkeit und Zuständigkeit in Einklang bringt.

CI/CD, Quellcodeverwaltung und Release-Orchestrierung

• CI/CD-Prinzipien

  • Halten Sie den master/main-Branch release-fähig; praktizieren Sie Trunk-based Development mit kurzlebigen Feature-Branches.
  • Automatisieren Sie Build, Test, Scan und Packaging bei jeder Änderung; fordern Sie Code-Reviews mit obligatorischen Genehmigungen und Statusprüfungen.
  • Sorgen Sie für vollständige Nachverfolgbarkeit vom Commit → Build → Artefakt-Digest → Umgebungs-Release; betten Sie Commit-SHAs und Build-Metadaten in Images und Deployment-Annotationen ein.
  • Fehlermodi: Langlebige Branches, manuelle Übergaben, unzuverlässige („flaky“) Tests, nicht reproduzierbare Builds und fehlende Unveränderlichkeit von Artefakten führen zu späten Überraschungen und Rollbacks.

• Quellcodeverwaltung, Branching, Pull-Requests, Code-Review und Nachverfolgbarkeit

  • Verwenden Sie geschützte Branches, erforderliche Reviews und Commit-Signierung. Taggen Sie Releases und pflegen Sie ein Changelog, das aus Merge-Commits generiert wird.
  • Wenden Sie CODEOWNERS und Metadaten zur Service-Ownership an, um die Fachbereichsverantwortung durchzusetzen.
  • Verknüpfen Sie Commits mit Issues und Deployments; exportieren Sie CI/CD-Protokolle und -Metadaten nach Cloud Logging und BigQuery für Audits und DORA-Metriken.

• Cloud Build

  • Trigger: Werden durch Git-Ereignisse (Branch, Tag, PR), manuelle Aufrufe oder Pub/Sub ausgelöst. Parametrisieren Sie mit Substitutionen für Version, Umgebung und Feature-Flags, um Pipelines DRY zu halten.
  • Build-Schritte: Führen Sie offizielle Builder oder von Ihnen definierte Container aus; verwenden Sie parallele Schritte, wenn diese unabhängig sind, um die Latenz zu reduzieren; nutzen Sie Caches für Sprachabhängigkeiten, um Builds zu beschleunigen.
  • Artefakte: Pushen Sie Images mit unveränderlichen Tags und Digests in die Artifact Registry; speichern Sie SBOMs und Build-Protokolle; veröffentlichen Sie Testberichte als Build-Artefakte.
  • Sichere Build-Identitäten: Führen Sie Cloud Build mit einem dedizierten Servicekonto nach dem Prinzip der geringsten Rechte (Least Privilege) und, wo möglich, mit Workload Identity Federation pro Repository aus. Für private Netzwerke oder zur Vermeidung von Egress-Traffic verwenden Sie Private Pools. Beschränken Sie Servicekonto-Schlüssel; bevorzugen Sie kurzlebige Token.
  • Beispiel (gekürzt):
    • cloudbuild.yaml:
      • steps:
        • name: gcr.io/cloud-builders/docker args: [build, -t, $REGION-docker.pkg.dev/$PROJECT/app/web:$COMMIT_SHA, .]
        • name: gcr.io/cloud-builders/docker args: [push, $REGION-docker.pkg.dev/$PROJECT/app/web:$COMMIT_SHA]
      • substitutions:
        • _ENV=staging

• Cloud Deploy

  • Releases und Targets: Modellieren Sie eine Delivery-Pipeline mit Promotion über verschiedene Targets (z. B. dev → staging → prod). Ein Release erfasst eine unveränderliche Artefaktreferenz und die Deployment-Konfiguration.
  • Genehmigungen und Promotion: Erfordern Sie manuelle oder automatisierte Genehmigungen mit rollenbasierter Steuerung. Die Promotion sollte eine schnelle, risikoarme Aktion sein, da Artefakt und Manifeste unverändert bleiben.
  • Canary-Rollout und Rollback: Definieren Sie Strategien für die progressive Bereitstellung, Health Checks und automatisches Rollback bei SLO-Fehlern. Zeichnen Sie jede Promotion, jeden Genehmigenden und jedes Verifizierungsergebnis für Audits auf.
  • Fehlermodi: Veränderliche Artefakte zwischen Umgebungen, manuelles kubectl in der Produktion oder übersprungene Verifizierung vor dem Deployment verursachen Drift und nicht nachverfolgbare Ausfälle.

Infrastruktur als Code und Konfigurationsmanagement

• Terraform
  • Module: Wiederverwendbare Muster erfassen (z. B. VPCs, GKE-Cluster, Service-Konten, IAM-Bindungen). Modul-Releases versionieren und pinnen; interne Modul-Registries veröffentlichen.
  • Remote-Zustand: In Cloud Storage mit Versionierung, Aufbewahrungsrichtlinie und CMEK speichern; Sperren (Locking) aktivieren; Zugriff über IAM und einheitlichen Zugriff auf Bucket-Ebene einschränken; Zustand sichern.
  • Pläne und Richtlinienprüfungen:

undefined

in CI ausführen; menschliche Überprüfung des Plans erfordern; Richtlinie als Code (OPA/Conftest, Sentinel oder Policy Controller) erzwingen, um Verstöße zu blockieren (z. B. öffentliche Buckets, weite IAM-Bindungen).

• Umgebungs-Promotion: Separate Workspaces oder separate Zustands-/Backends pro Umgebung verwenden; Änderungen über dieselben Modulversionen und Variablen promoten; Cloud-Ressourcen niemals manuell bearbeiten. Sensible Eingaben sollten aus dem Secret Manager oder durch Automatisierung kommen, niemals hartcodiert sein.

• Fehlermodi: Durchsickern von Secrets in den Zustand, gleichzeitige Änderungen ohne Sperren, Drift durch außerplanmäßige Bearbeitungen und implizite Abhängigkeiten, die destroy/replace unterbrechen.

• Google Cloud Deployment-Vorlagen und deklarative Konfiguration

  • Deklarative Tools (Terraform, Google Cloud Deployment Manager oder Kubernetes Configuration as Code) verwenden, um den Soll-Zustand zu definieren, anstatt Skripte mit imperativen Schritten zu verwenden.
  • Unveränderliche Infrastruktur bevorzugen: Instanzvorlagen ersetzen und MIGs ausrollen; neue GKE-Deployments ausrollen, anstatt Pods direkt zu patchen. Unveränderliche Muster vereinfachen Rollbacks und Audits.
  • Deployment Manager unterstützt Jinja/Python-Vorlagen für Google Cloud-Ressourcen, ist aber auf Google Cloud beschränkt; Terraform bietet ein breiteres Ökosystem und Richtlinien-Tools. Auswahl basierend auf unternehmensweiter Standardisierung und Fähigkeiten treffen.

• Kubernetes-Manifeste, Helm, Kustomize und GitOps

  • Manifeste: Basisvorlagen mit Umgebungs-Overlays beibehalten; nur das parametrisieren, was je nach Umgebung variieren soll (z. B. Replicas, Limits, Endpunkte).
  • Helm: Services mit Charts paketieren, als Vorlage erstellen und versionieren; Abhängigkeiten sperren; Image-Digests pinnen. Fehlermodus: Übermäßiges Templating verschleiert die Absicht und erschwert die Überprüfung.
  • Kustomize: Overlays verwalten (Basis + Umgebungs-Patches); einfacher als Helm, wenn reines Kubernetes ausreicht.
  • GitOps: Ein Controller (z. B. Config Sync, Argo CD, Flux) gleicht Cluster kontinuierlich mit dem Soll-Zustand in Git ab; jede Änderung ist ein PR mit Überprüfung und Audit-Trail. Drift automatisch erkennen und korrigieren.

Progressive Bereitstellung, Lieferkette, Tests und Verifizierung

• Feature Flags und Traffic-Management

  • Feature Flags entkoppeln das Deployment vom Release; für schrittweise Freigabe, A/B-Tests und Not-Ausschalter verwenden. Sicherstellen, dass die Zustände der Flags versioniert und auditierbar sind; veraltete Flags entfernen.
  • Traffic-Splitting: Bei Cloud Run prozentbasiertes Routing über Revisionen verwenden; bei GKE Service Mesh oder Ingress-Controller verwenden, die gewichtetes Routing unterstützen. Für APIs unter einem Hostnamen/TLS separate Backend-Services pro Pfad hinter dem HTTP(S) Load Balancer beibehalten; Pfad-basiertes Routing isoliert alte/neue Versionen sauber, während eine einzige URL und ein Zertifikat erhalten bleiben.
  • Blue-Green: Zwei produktionsreife Stacks betreiben; Traffic atomar über Load Balancer, Service-Selektoren oder Cloud Run Revisions-Traffic umschalten. Ermöglicht sofortigen Rollback, verdoppelt aber die Kosten im Dauerbetrieb.
  • Canary und progressiver Rollout: Traffic schrittweise von einem kleinen Teil erhöhen, während Golden Signals und Geschäfts-KPIs gemessen werden; Rollback bei Regressionen automatisieren.

• Kontrollen der Software-Lieferkette

  • Image-Scanning: Schwachstellen-Scanning mit Artifact Analysis aktivieren; Builds bei kritischen Schwachstellen oder bekanntermaßen fehlerhaften Basis-Images fehlschlagen lassen; eine Patch-Kadenz einhalten.
  • Herkunft und Signierung: SLSA-konforme Build-Herkunft in Cloud Build generieren; Artefakte mit Cosign signieren; Binary Authorization-Richtlinien durchsetzen, die Attestierungen vor dem Deployment erfordern.
  • Abhängigkeitsmanagement: Versionen und Digests pinnen, SBOMs pflegen, kritische Abhängigkeiten vendoren (d.h. lokal kopieren) und Prüfsummen verifizieren. Fehlermodi umfassen Drift bei transitiven Abhängigkeiten und kompromittierte Registries.

• Testpyramide, Deployment-Gates und Verifizierung nach dem Deployment

  • Pyramide: Schnelle Unit-Tests betonen; Integrations- und Vertragstests hinzufügen; gezielte End-to-End-Tests durchführen. Testdaten realistisch und deanonymisiert halten (Cloud DLP verwenden, um PII zu entfernen).
  • Deployment-Gates: Schwellenwerte für Erfolgsraten von Tests, Schwachstellenstatus, Richtlinienkonformität und Code-Review vor der Promotion durchsetzen; manuelle Genehmigung für die Produktion bei erhöhtem Risiko erfordern.
  • Verifizierung nach dem Deployment: Smoke-Tests, synthetische Prüfungen und Canary-Analysen mit Cloud Monitoring, Error Reporting und Trace durchführen. Wenn sich KPIs verschlechtern, einen automatisierten Rollback auslösen und einen Incident mit erfasstem Kontext öffnen.
  • Betriebsdiagnose: Den Cloud Logging-Agenten bei Bedarf bereitstellen und Services für Trace und Debugger instrumentieren. Runbooks für eine sichere Problembehebung bereithalten (z. B. Online-Größenänderung einer Persistent Disk und Ausführen von

undefined

mit minimaler Ausfallzeit).

Governance, Sicherheit, Auditierbarkeit und Zuständigkeit

• Geschwindigkeit mit Sicherheit

  • Trunk-basierte Entwicklung mit kurzlebigen PRs und obligatorischer Überprüfung erhält den Flow, ohne die Qualität zu beeinträchtigen.
  • Self-Service-Pipelines mit Vorlagen für gängige Stacks (GKE + Helm, Cloud Run, Dataflow) beschleunigen Teams und reduzieren das Risiko von Sonderanfertigungen.

• Zugriff, Identität und Genehmigungen

  • Verwenden Sie dedizierte Service Accounts pro Pipeline-Phase mit dem Prinzip der geringsten Rechte (Least Privilege) und Workload Identity Federation; vermeiden Sie statische Schlüssel.
  • Trennung der Aufgaben: Entwickler erstellen (build); Release Manager genehmigen die Übernahme in die Produktion; Runtime-Operatoren sind für die Laufzeitkonfiguration und Budgets zuständig.

• Auditierbarkeit und Compliance

  • Exportieren Sie Cloud Build-, Cloud Deploy- und Cloud Audit Logs nach BigQuery. Verwenden Sie Dataset-Ansichten und IAM, um bereichsbezogene Audit-Daten mit Auditoren zu teilen. Bewahren Sie Metriken langfristig auf, indem Sie sie gemäß Richtlinien nach Cloud Storage oder BigQuery exportieren.
  • Erfassen Sie Artefakt-Digests in den Metadaten der Bereitstellung. Pflegen Sie eine durchgängige SBOM und Provenienz für jedes Release.

• Zuständigkeit und SLOs

  • Jeder Service hat einen Verantwortlichen (Owner), eine Rufbereitschaft (On-Call Rotation), SLOs und Fehlerbudgets, die Releases steuern. Koppeln Sie Bereitstellungsrichtlinien an die Einhaltung der SLOs, um das Pushen von Änderungen bei erschöpftem Budget zu vermeiden.

• Häufige Kompromisse und Fallstricke

  • Blue-Green-Kosten vs. Rollback-Geschwindigkeit; Canary-Vertrauen vs. Zeit bis zum vollständigen Release.
  • GitOps-Konsistenz vs. operative Flexibilität; erlauben Sie kontrollierte Notfallzugriffe (Break-Glass) mit Protokollierung und nachfolgenden PRs.
  • Übermäßiger Einsatz von Vorlagen (Over-Templating) reduziert die Lesbarkeit; halten Sie die Konfiguration explizit und minimal.
  • Eine zentrale Richtlinie verhindert Fehlkonfigurationen, muss aber iterativ ausgerollt werden, um Teams nicht unnötig zu blockieren.

Praktisches Problemszenario

Unternehmen: Borealis Fintech

Herausforderung: Borealis führt eine neue Zahlungs-API auf GKE ein und muss dabei v1 und v2 unter demselben Hostnamen und TLS beibehalten. Sie benötigen durchgängige Nachverfolgbarkeit, progressive Bereitstellung mit Canary und Feature Flags, starke Kontrollen der Lieferkette (Supply Chain) und auditierte Beförderungen (Promotions) über Dev, Staging und Prod hinweg. Außerdem möchten sie GitOps für die Cluster-Konfiguration und Terraform für Plattform-Ressourcen verwenden.

Ansatz:

1. Quellcodeverwaltung und Branching-Strategie festlegen

   • Erstellen eines Mono-Repos mit Service-Verzeichnissen und eines separaten Infra-Repos. Erzwingen von geschütztem Main-Branch, obligatorischen PR-Reviews, CODEOWNERS und signierten Commits. Begründung: Trunk-basierter Flow mit klarer Zuständigkeit und auditierbarer Historie.

2. Artefakte mit Cloud Build und Artifact Registry erstellen

   • Definieren einer cloudbuild.yaml zum Erstellen und Pushen von Images, die mit $COMMIT_SHA getaggt und mit SBOM und Provenienz annotiert sind. Verwenden eines dedizierten Cloud Build Service Accounts mit geringsten Rechten und eines Private Pools. Begründung: reproduzierbare, isolierte Builds mit nachverfolgbaren Digests.

   • Beispiel:

undefined

3. Kontrollen für die Software-Lieferkette implementieren

   • Aktivieren des Schwachstellen-Scannings in Artifact Registry. Generieren von Provenienz und Signieren von Images mit Cosign in den Post-Build-Schritten von Cloud Build. Konfigurieren von Binary Authorization, um Signaturen und bestandene Scans vor der Bereitstellung in GKE zu verlangen. Begründung: Blockieren von nicht vertrauenswürdigen oder anfälligen Artefakten zum Zeitpunkt der Durchsetzung.

4. Bereitstellung mit Cloud Deploy modellieren

   • Definieren einer Delivery-Pipeline mit den Zielen Dev, Staging, Prod und einer Canary-Strategie für Prod. Manuelle Genehmigung für Prod mit rollenbasierten Genehmigern vorschreiben. Begründung: unveränderliche Beförderung (Promotion) und auditierbare Genehmigungen.

   • clouddeploy.yaml (Auszug):

undefined

5. v1- und v2-APIs unter demselben Hostnamen routen
   • Konfigurieren eines externen HTTP(S) Load Balancers mit separaten Backend-Services für die Pfade /v1 und /v2, die jeweils auf die entsprechende GKE NEG verweisen. Begründung: saubere pfadbasierte Isolierung, gleiches Zertifikat und DNS, unabhängige Bereitstellbarkeit.

   • Beispiel (Auszug):

undefined

6. Infrastruktur mit Terraform verwalten
   • Erstellen von Modulen für VPC, GKE, Artifact Registry, Service Accounts und IAM. Speichern des Remote-Zustands (State) in einem CMEK-geschützten Cloud Storage Bucket mit Versionierung und Aufbewahrung. Erzwingen von OPA-Richtlinien in der CI, um riskante Änderungen zu verhindern. Begründung: wiederverwendbare, überprüfbare und gesteuerte Plattform-Bereitstellung.

undefined

7. Kubernetes mit Helm/Kustomize und GitOps konfigurieren

   • Pflegen von Basis-Manifesten für die API und Overlays pro Umgebung mit Kustomize. Verwenden von Config Sync oder Argo CD, um Cluster mit dem Git-Zustand abzugleichen (reconcile). Begründung: deklarativer, auditierbarer und drift-resistenter Betrieb.

8. Progressive Bereitstellung mit Canary und Feature Flags

   • Verwenden von Cloud Deploy Canary für Prod und eines Feature-Flag-SDKs (OpenFeature), um neue Logik zu steuern. Beginnen mit 5 % des Traffics, automatische Beförderung bei gesunden SLOs; automatisches Rollback bei Verschlechterung und Verwendung des Flags als Notausschalter (Kill Switch). Begründung: Reduzierung des Explosionsradius (Blast Radius) und Entkopplung von Bereitstellung (Deploy) und Veröffentlichung (Release).

9. Qualitäts-Gates und Verifizierung

   • Pipeline-Phasen: Unit-Tests → Integrationstests gegen eine ephemere Umgebung → Container-Scan → Richtlinienprüfungen → End-to-End-Tests in Staging → Prod-Canary mit automatisierter SLO-basierter Verifizierung (Cloud Monitoring, Error Reporting, Trace). Begründung: schnelles Feedback früh im Prozess, hohe Sicherheit vor der Produktion und objektive Zustandsprüfungen nach der Bereitstellung.

10. Betrieb, Logging und Audit

    • Installieren von Cloud Logging/Monitoring-Agenten für unterstützende VMs und Aktivieren von GKE-Workload-Logs/Metriken. Exportieren von CI/CD- und Audit-Logs nach BigQuery mit bereichsbezogenen Ansichten für Auditoren. Pflegen von Runbooks (einschließlich sicherer Rollback- und Notfallprozeduren für DNS- oder LB-Umschaltungen). Begründung: Beobachtbarkeit (Observability) für schnelle Problembehebung und Compliance-konforme Nachweise.

Dieses Design bewahrt die Geschwindigkeit durch einen Trunk-basierten Flow und automatisierte Pipelines; die Sicherheit durch Canary, Feature Flags und Binary Authorization; die Auditierbarkeit durch unveränderliche Artefakte, Genehmigungen und zentralisierte Logs; und klare Zuständigkeiten durch CODEOWNERS und GitOps-gesteuerte Umgebungen.

← Betrieb · Alle Domänen · Kosten →

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

Google durchsuchen →