Google ACE: Container, App-Hosting und Serverless-Plattformen — 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.

Serverless-Anwendungsplattformen

Cloud Run bietet container-native, anfragegesteuerte Rechenleistung mit automatischer Skalierung auf null und Identitätsdurchsetzung pro Anfrage.

• Cloud Run-Dienste und -Jobs

  • Dienste verarbeiten HTTP; die Gleichzeitigkeit (Concurrency) steuert die Anzahl simultaner Anfragen pro Instanz (Abstimmung zwischen Latenz und Effizienz). Jobs verarbeiten Nicht-HTTP-Batch/Cron-Aufgaben und können parallelisiert werden.
  • Revisionen sind unveränderliche Snapshots. Traffic-Splitting ermöglicht Canary-Deployments nach Prozentsatz. Legen Sie Mindestinstanzen (min instances) fest, um Kaltstarts zu reduzieren; nutzen Sie die CPU-Zuweisung im Leerlauf (CPU allocation during idle), wenn Hintergrundarbeiten erforderlich sind.
  • Identität: Weisen Sie pro Dienst/Revision ein dediziertes Servicekonto mit den geringsten Rechten (Least Privilege) zu. Beschränken Sie den Aufruf über IAM (Rolle: Cloud Run Invoker) oder machen Sie den Dienst bei Bedarf öffentlich. Für die Endbenutzer-Authentifizierung verwenden Sie signierte IAP-Tokens oder die integrierte Authentifizierung von Cloud Run mit der Identity Platform.

• Networking

  • Verwenden Sie Serverless VPC Connectors, um auf private VPC-Ressourcen zuzugreifen. Wählen Sie den Egress-Typ: gesamter Traffic über den Connector oder nur private RFC1918-Bereiche. Beachten Sie die Durchsatzquoten des Connectors; skalieren Sie die Größe des Connectors und richten Sie ihn regional am Dienst aus. Für ausgehenden Internetverkehr mit reinen privaten IP-Ressourcen kombinieren Sie dies mit Cloud NAT.
  • Private Service Connect kann Producer-Dienste privat konsumieren oder interne Endpunkte bereitstellen. Für den Ingest über externes HTTP(S) verwenden Sie Cloud Load Balancing mit Serverless NEGs.

App Engine bietet zwei Umgebungen:

• Standard
  • In einer Sandbox ausgeführt, skaliert schnell, unterstützt automatische, grundlegende oder manuelle Skalierung. Automatische Skalierung mit min_idle_instances stellt vorgewärmte Kapazität bereit. Schneller Kaltstart und einfaches Bereitstellungsmodell; begrenzte Anpassungen auf Betriebssystemebene und ein festes Set an Laufzeitumgebungen.
• Flexible
  • Führt Docker auf Compute Engine VMs aus und bietet mehr Kontrolle über Systembibliotheken und Networking. Langsamerer Instanzlebenszyklus und höhere Basiskosten; geeignet, wenn benutzerdefinierte Laufzeitumgebungen oder native Bibliotheken benötigt werden.
• Dienste und Versionen
  • Teilen Sie den Traffic nach Version auf (zufällig, per Cookie oder IP). Jeder Dienst kann unabhängig skalieren. Verwenden Sie schrittweise Rollouts (gradual rollouts) und behalten Sie eine frühere Version für ein sofortiges Rollback bei.

Cloud Functions stellt ereignisgesteuerte, auf einen einzigen Zweck ausgerichtete Funktionen bereit.

• Trigger: Pub/Sub, Cloud Storage, HTTP, Eventarc für viele Quellen. Gestalten Sie Handler idempotent; einige Trigger führen bei Fehlern Wiederholungsversuche durch, was zu doppelter Verarbeitung führen kann.
• Laufzeitkonfiguration: Umgebungsvariablen, Secret Manager-Anbindungen, maximale Instanzen (max instances), Speicher/CPU. Steuern Sie die Gleichzeitigkeit (Concurrency) für HTTP-Funktionen, um Latenz und Kosten auszubalancieren.
• Häufige Fallstricke: Unbegrenzte Gleichzeitigkeit (unbounded concurrency) oder nicht-idempotente Nebeneffekte verursachen Datenduplizierung; stellen Sie DLQs für Pub/Sub sicher; legen Sie angemessene Timeouts fest.

Plattformauswahl, Networking und operative Zuständigkeit

Wählen Sie eine Plattform basierend auf der erforderlichen Kontrolle, den Skalierungseigenschaften, den Portabilitätsanforderungen und dem Betriebsbudget.

• Kontrolle vs. Verwaltungsaufwand

  • Höchste Kontrolle: GKE Standard (Knoten-Betriebssystem, Networking, Sicherheits-Add-ons) mit entsprechendem Betriebsaufwand.
  • Ausgewogen: GKE Autopilot (keine Knotenverwaltung, festgelegte Sicherheitskonfiguration).
  • Geringster Aufwand: Cloud Run, App Engine, Cloud Functions (keine Knoten, verwaltete Skalierung), aber durch Laufzeitumgebung und Anfragemodelle eingeschränkt.

• Skalierung und Eignung für Workloads

  • Workloads mit Lastspitzen: Cloud Run/App Engine Standard eignen sich hervorragend; Functions für ereignisgesteuerte Handler.
  • Zustandsbehaftete oder benutzerdefinierte Netzwerkkonfigurationen: GKE mit StatefulSets und CNI-Funktionen.
  • Portabilität: Container auf GKE/Cloud Run; Functions sind aufgrund des FaaS-Modells weniger portabel.

• Serverless Networking, Egress und private Dienste

  • Verwenden Sie VPC-Konnektoren für den privaten Zugriff; überwachen Sie die Auslastung der Konnektoren, um Drosselung zu vermeiden. Setzen Sie den Egress nur bei Bedarf auf „all“; andernfalls beschränken Sie ihn auf private Bereiche, um Kosten und Risiken zu reduzieren.
  • Für privaten Ingress ziehen Sie internes HTTP(S)-Load-Balancing mit Serverless NEGs oder Private Service Connect in Betracht.
  • Zur Kontrolle der Datenexfiltration kombinieren Sie dies mit VPC Service Controls, wo unterstützt, und beschränken Sie Egress-Routen über Firewalls und Cloud NAT.

• Diagnose und operative Zuständigkeit

  • Standardisieren Sie auf Cloud Logging mit strukturierten Logs (JSON) und Trace/Span-IDs über alle Dienste hinweg zur Korrelation. Verwenden Sie Cloud Monitoring-Dashboards, Verfügbarkeitsprüfungen, SLOs und Benachrichtigungsrichtlinien.
  • Für GKE: Aktivieren Sie Cloud Ops for GKE, erfassen Sie Anwendungsmetriken über Prometheus oder Cloud Monitoring und verwenden Sie DaemonSets für Telemetrie auf Knotenebene.
  • Für Serverless: Nutzen Sie die integrierten Anfrage-Logs, Error Reporting, Trace und Profiler. Legen Sie dienstspezifische SLOs und Benachrichtigungen für Latenz, Fehlerrate und Auslastung (Gleichzeitigkeit, Instanz-CPU) fest.
  • Zuständigkeitsmodell: Definieren Sie, wer für Laufzeitparameter (Skalierung, Gleichzeitigkeit), IAM und Release-Pipelines verantwortlich ist. Testen Sie regelmäßig Rollbacks und Notfallszenarien.

Praktisches Problemszenario

Acme Retail plant, eine neue Checkout-API bereitzustellen und gleichzeitig interne Dienste zu modernisieren. Anforderungen: eine öffentliche API mit niedriger Latenz und Canary-Rollouts, privater Zugriff auf eine interne Inventardatenbank in einer VPC, Durchsetzung der Lieferkettensicherheit und klare Rollback-Möglichkeiten bei minimalem Betriebsaufwand.

1. Wählen Sie Cloud Run für die öffentliche API und GKE Autopilot für den internen Inventardienst.

• Begründung: Cloud Run minimiert den Betriebsaufwand für zustandsloses HTTP, unterstützt Revisionen und Traffic-Splitting; GKE Autopilot bietet Kubernetes-Funktionen für zustandsbehaftete/interne Dienste ohne Knotenverwaltung.

2. Erstellen, scannen und speichern Sie Images in Artifact Registry mit Provenienz.

• Begründung: Cloud Build produziert Container-Images; Artifact Analysis scannt nach CVEs. Das Speichern von Digests und Provenienz ermöglicht es Binary Authorization, zu erzwingen, dass nur gescannte, signierte Images ausgeführt werden.

3. Erzwingen Sie Zulassungsrichtlinien.

• Begründung: Aktivieren Sie Binary Authorization auf dem GKE-Cluster, um Signaturen und Richtlinienbestätigungen zu verlangen. Konfigurieren Sie für Cloud Run die Deployment-Automatisierung so, dass die Beförderung (Promotion) vom Bestehen der Schwachstellenrichtlinie abhängig gemacht wird.

4. Konfigurieren Sie das Networking mit einem Serverless VPC Connector und Cloud NAT.

• Begründung: Die Cloud Run API muss den Inventardienst und Cloud SQL privat erreichen. Ein VPC-Konnektor ermöglicht privaten RFC1918-Egress; Cloud NAT bietet ausgehenden Internetzugriff für das Herunterladen von Abhängigkeiten, ohne dass externe IPs auf privaten Ressourcen erforderlich sind. Halten Sie Konnektor und Dienste in derselben Region und dimensionieren Sie den Durchsatz passend.

5. Sichern Sie Identitäten und Berechtigungen.

• Begründung: Weisen Sie dem Cloud Run-Dienst ein dediziertes Servicekonto mit den geringsten Berechtigungen zu (z. B. Cloud SQL Client, Aufrufsberechtigungen für interne Endpunkte, falls erforderlich). Verwenden Sie für GKE Workload Identity, damit Pods Servicekonten ohne Anmeldeinformationen auf Knotenebene annehmen können.

6. Implementieren Sie sichere Releases und Rollbacks.

• Begründung: Stellen Sie die API in einer neuen Cloud Run-Revision bereit und teilen Sie 5 % des Traffics für ein Canary-Deployment auf. Überwachen Sie Latenz, Fehlerrate und Auslastung; fahren Sie dann auf 100 % hoch oder führen Sie sofort ein Rollback durch, indem Sie den Traffic auf die vorherige Revision zurücksetzen. Verwenden Sie in GKE rollierende Updates mit Readiness Probes und ein kleines Canary-Deployment hinter demselben Service, um vor dem vollständigen Rollout zu validieren.

7. Konfigurieren Sie Beobachtbarkeit und SLOs.

• Begründung: Geben Sie strukturierte JSON-Logs mit Trace-IDs von beiden Plattformen an Cloud Logging aus. Erstellen Sie SLOs für die p95-Latenz und die 5xx-Fehlerrate; hängen Sie Benachrichtigungsrichtlinien an. Verwenden Sie Error Reporting und Trace für die Ursachenanalyse. Stellen Sie für GKE ein DaemonSet für Knotenmetriken bereit und aktivieren Sie Cloud Ops for GKE.

8. Validieren Sie Fehlermodi und Kapazität.

• Begründung: Führen Sie Lasttests durch, um den Durchsatz des VPC-Konnektors, die Gleichzeitigkeit von Cloud Run und das HPA-Verhalten von GKE zu überprüfen. Bestätigen Sie die Genauigkeit der Readiness Probes, um Blackholing zu verhindern. Testen Sie die Ablehnungspfade von Binary Authorization und das Image-Rollback anhand des Digests, um die Wiederherstellbarkeit unter der Durchsetzung der Lieferkettensicherheit zu gewährleisten.

Dieser Ansatz liefert eine betriebsarme, sichere öffentliche API, kontrollierte interne Dienste, privates Networking, durchsetzbare Lieferkettensicherheit und schnelle Rollbacks, im Einklang mit den operativen Best Practices von Google Cloud.

← Compute Engine und Betrieb virtueller Maschinen · Alle Domänen · VPC-Netzwerke →

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

Google durchsuchen →