Google Cloud Associate Cloud Engineer
Zuletzt überprüft: Mai 2026
Eine übersichtliche Referenz der Architekturmuster, die in der ACE-Prüfung getestet werden. Von oben nach unten lesen oder zu einem Abschnitt springen.
Die Abrechnung und die Richtliniendurchsetzung zentralisieren und gleichzeitig Geschäftseinheiten administrative Autonomie gewähren.
Verwenden Sie einen Organisationsknoten mit Ordnern für jede Geschäftseinheit. Erstellen Sie Projekte innerhalb von Ordnern. Verknüpfen Sie alle Projekte mit einem einzigen Billing Account.
Warum: Ordner bieten administrative Grenzen und Richtlinienvererbung. Ein einziges Billing Account zentralisiert das Kostenmanagement und ermöglicht organisationsweite Rabatte.
Die Finanzabteilung benachrichtigen, wenn die Projektausgaben bestimmte Prozentsätze eines Budgets erreichen.
Erstellen Sie in Cloud Billing ein Budget für das Projekt. Legen Sie mehrere Schwellenwertregeln für Benachrichtigungen fest (z. B. 50 %, 90 %, 100 %), die Benachrichtigungen an ein Pub/Sub-Thema oder per E-Mail senden.
Warum: Budgets dienen der Benachrichtigung, nicht der Ausgabenbegrenzung. Um Ausgaben automatisch zu begrenzen, muss eine Pub/Sub-Benachrichtigung eine Cloud Function auslösen, um die Abrechnung zu deaktivieren oder Ressourcen herunterzufahren.
Granulare Cloud-Kosten auf Ressourcenebene analysieren und Ausgaben nach Kostenstelle verfolgen.
Aktivieren Sie den detaillierten Billing Export in ein BigQuery-Dataset. Wenden Sie Labels (z. B. `cost-center: "finance"`) auf Ressourcen an. Fragen Sie die BigQuery-Tabelle ab und gruppieren Sie nach Labels zur Analyse.
Warum: Der Billing Export nach BigQuery liefert die detailliertesten Kostendaten, einschließlich Labels, was für benutzerdefinierte Chargeback- und Showback-Modelle unerlässlich ist.
Sicherheits- und Konfigurationsstandards für alle Projekte in einer Organisation durchsetzen (z. B. Ressourcenspeicherorte einschränken, einheitlichen Bucket-Zugriff verlangen, öffentliche IPs deaktivieren).
Wenden Sie Organization Policy-Constraints auf Organisations- oder Ordnerebene an. Beispiele: `gcp.resourceLocations` für Datenresidenz, `storage.uniformBucketLevelAccess` für GCS-Sicherheit, `compute.vmExternalIpAccess` um öffentliche IPs zu verhindern.
Warum: Organization Policies werden vererbt und bieten präventive Kontrolle, indem nicht konforme Aktionen blockiert werden, bevor sie auftreten. Dies ist effektiver als reaktive Überwachung.
Das versehentliche Löschen eines kritischen Produktionsprojekts verhindern.
Platzieren Sie einen Lien auf das Projekt mithilfe von `gcloud alpha resource-manager liens create`.
Warum: Ein Lien ist eine Eigenschaft, die das Löschen eines Projekts blockiert. Er muss von einem Benutzer mit der Rolle `resourcemanager.lienModifier` explizit entfernt werden, bevor das Projekt gelöscht werden kann.
Effizientes Wechseln zwischen verschiedenen Projekten und Benutzerkonten bei Verwendung der gcloud CLI.
Verwenden Sie `gcloud config configurations create`, um benannte Konfigurationen für jedes Projekt/Konto zu erstellen. Wechseln Sie zwischen diesen mit `gcloud config configurations activate [CONFIG_NAME]`.
Warum: Konfigurationen speichern Einstellungen wie Projekt, Konto, Region und Zone, wodurch vermieden wird, diese bei jedem Befehl angeben zu müssen.
Einen zustandslosen, containerisierten HTTP-Mikroservice mit variablem Datenverkehr betreiben, um den Betriebsaufwand und die Kosten zu minimieren.
Stellen Sie den Container in Cloud Run bereit.
Warum: Cloud Run ist vollständig verwaltet, skaliert auf null (eliminiert Kosten für Leerlaufzeiten) und skaliert automatisch basierend auf eingehenden Anfragen. Es ist ideal für zustandslose Webdienste.
Einen fehlertoleranten, zeitlich flexiblen Batch-Verarbeitungsjob zu den niedrigst-möglichen Kosten ausführen.
Verwenden Sie Spot VMs (ehemals Preemptible VMs) in einer Managed Instance Group.
Warum: Spot VMs bieten einen Rabatt von bis zu 91 % im Vergleich zu On-Demand-Preisen. Sie eignen sich für Workloads, die gestoppt und neu gestartet werden können, wie viele Batch-Verarbeitungsjobs.
Eine Webanwendung bereitstellen, die Hochverfügbarkeit (z. B. 99,9 %) und Autoscaling erfordert.
Verwenden Sie eine regionale Managed Instance Group (MIG) mit einer Autoscaling-Richtlinie, die hinter einem Global External HTTP(S) Load Balancer bereitgestellt wird.
Warum: Eine regionale MIG verteilt Instanzen automatisch über mehrere Zonen für Fehlertoleranz. Autoscaling passt die Kapazität an die Nachfrage an, und der Load Balancer bietet einen einzigen Einstiegspunkt.
Daten speichern, die 30 Tage lang häufig, dann ein Jahr lang selten und anschließend archiviert werden.
In einem Cloud Storage Standard-Class-Bucket speichern. Erstellen Sie eine Lifecycle-Regel, um Objekte nach 30 Tagen in Nearline/Coldline und nach 365 Tagen in Archive zu überführen.
Warum: Lifecycle-Regeln automatisieren die Kostenoptimierung, indem Daten ohne manuelles Eingreifen basierend auf Alter oder anderen Bedingungen in günstigere Speicherklassen verschoben werden.
Eine global verteilte Anwendung erfordert eine relationale Datenbank mit horizontaler Skalierbarkeit und starker Konsistenz.
Verwenden Sie Cloud Spanner.
Warum: Cloud Spanner ist der einzige Dienst, der eine global verteilte, stark konsistente, relationale Datenbank mit SQL-Unterstützung bietet. Cloud SQL ist regional.
Eine Anwendung erfordert eine verwaltete PostgreSQL- oder MySQL-Datenbank mit einem 99,95 % Verfügbarkeits-SLA und automatischem Failover.
Verwenden Sie Cloud SQL mit aktivierter Hochverfügbarkeits-(HA)-Konfiguration.
Warum: Die HA-Konfiguration erstellt eine primäre Instanz und eine Standby-Instanz in einer anderen Zone. Daten werden synchron repliziert, und das Failover erfolgt automatisch.
Eine VPC für eine 3-Schichten-Anwendung (Web, App, DB) entwerfen, bei der die Datenbank-Schicht nicht aus dem Internet zugänglich sein darf.
Erstellen Sie eine VPC im benutzerdefinierten Modus mit einem separaten Subnetz für jede Schicht. Stellen Sie die Datenbankinstanzen nur mit privaten IP-Adressen in ihrem dedizierten Subnetz bereit.
Warum: Die Isolierung von Schichten in separaten Subnetzen ermöglicht granulare Firewall-Regeln. Das Weglassen externer IPs auf Datenbankinstanzen ist der direkteste Weg, den Internetzugriff zu verhindern.
Eine zustandsbehaftete Anwendung (z. B. eine Datenbank) auf GKE bereitstellen, die stabile Netzwerk-Identifikatoren und persistenten Speicher erfordert.
Verwenden Sie ein StatefulSet mit einem PersistentVolumeClaim-Template.
Warum: StatefulSets sind für zustandsbehaftete Workloads konzipiert und bieten stabile Hostnamen (z. B. `pod-0`, `pod-1`) und die automatische Bereitstellung eines einzigartigen PersistentVolume für jede Replik.
Ein latenzempfindlicher Cloud Run-Dienst muss Kaltstarts bei Verkehrsspitzen vermeiden.
Stellen Sie den Dienst mit dem Flag `--min-instances` auf 1 oder höher bereit.
Warum: Das Festlegen von Mindestinstanzen hält eine bestimmte Anzahl von Containern "warm" und bereit, Anfragen zu bedienen, wodurch die Latenz beim Starten eines neuen Containers entfällt.
Eine serverlose Funktion automatisch ausführen, wenn eine neue Datei in einen Cloud Storage-Bucket hochgeladen wird.
Stellen Sie eine Cloud Function (2nd Gen) mit einem Eventarc-Trigger für das Ereignis `google.cloud.storage.object.v1.finalized` im angegebenen Bucket bereit.
Warum: Eventarc bietet eine einheitliche, ereignisgesteuerte Architektur. Der GCS-Trigger ist die standardmäßige, verwaltete Methode, um Speicherereignisse ohne Polling mit serverlosem Compute zu verbinden.
Eine neue Version einer App Engine-Anwendung zum Testen bereitstellen, ohne sofort Produktionsdatenverkehr darauf zu leiten.
Stellen Sie die neue Version mit `gcloud app deploy --no-promote` bereit.
Warum: Das Flag `--no-promote` erstellt die neue Version, leitet aber keinen Datenverkehr darauf. Sie können sie dann über ihre versionsspezifische URL testen und den Datenverkehr manuell migrieren, wenn Sie bereit sind.
Einen globalen HTTP(S)-Load Balancer für eine Webanwendung erstellen, die auf Compute Engine-Instanzen ausgeführt wird.
Erstellen Sie diese Komponenten in der Reihenfolge: Instanzgruppe (mit VMs), Health Check, Backend Service (der auf IG und HC verweist), URL Map, Target HTTP(S) Proxy und eine Global Forwarding Rule (mit einer öffentlichen IP).
Warum: Diese Reihenfolge erstellt den Load Balancer korrekt vom Backend (Instanzen) zum Frontend (Forwarding Rule). Jede Komponente dient einem spezifischen Zweck bei der Weiterleitung und der Gesundheitsprüfung.
Ein Team muss den Terraform-State gemeinsam verwalten, Sicherheit gewährleisten und gleichzeitige Änderungen verhindern.
Verwenden Sie einen Cloud Storage-Bucket als Terraform-Backend. Aktivieren Sie die Objektversionierung für Verlauf und Wiederherstellung. Die State-Sperrung wird automatisch vom GCS-Backend gehandhabt.
Warum: Ein Remote-GCS-Backend ist der Standard für die Teamzusammenarbeit auf GCP. Es bietet Sperren zur Verhinderung von State-Beschädigungen und Versionierung für Rollback-Fähigkeiten.
Eine Benachrichtigung erhalten, wenn die CPU-Auslastung auf einer beliebigen VM in einer Gruppe über einen längeren Zeitraum (z. B. 5 Minuten) 80 % überschreitet.
Erstellen Sie in Cloud Monitoring eine Alerting Policy. Stellen Sie die Bedingung auf `Metric: CPU utilization > 80%` für `Duration: 5 minutes` ein. Konfigurieren Sie einen Benachrichtigungskanal (z. B. E-Mail, PagerDuty).
Warum: Cloud Monitoring ist der native Dienst zum Erstellen metrikbasierter Warnungen. Die Dauerbedingung ist entscheidend, um "flatternde" Warnungen durch kurze, normale Spitzen in der Auslastung zu vermeiden.
Spezifische Audit-Logs 7 Jahre lang zur Compliance aufbewahren, während andere Logs 30 Tage lang aufbewahrt werden.
Erstellen Sie einen Log-Sink mit einem Filter für die Audit-Logs. Konfigurieren Sie den Sink, um in einen Cloud Storage-Bucket zu exportieren. Wenden Sie eine 7-jährige Aufbewahrungsrichtlinie auf den Bucket an.
Warum: Cloud Logging hat eine begrenzte Aufbewahrungsdauer (max. 400 Tage für Admin Activity). Sinks sind der Mechanismus zum Routen von Logs zu langfristigem, günstigerem Speicher wie GCS oder zur Analyse in BigQuery.
Ein GKE-Pod befindet sich im Zustand `CrashLoopBackOff`. Sie müssen die Logs des Containers kurz vor dem Absturz anzeigen.
Verwenden Sie den Befehl `kubectl logs [POD_NAME] --previous`.
Warum: Wenn ein Container abstürzt und neu startet, zeigt `kubectl logs` die Logs des *neuen* Containers an. Das Flag `--previous` ist unerlässlich, um die Logs der beendeten Instanz zur Diagnose des Absturzes anzuzeigen.
Eine Managed Instance Group muss Instanzen, die nicht mehr reagieren, automatisch ersetzen.
Konfigurieren Sie einen Health Check (z. B. HTTP, TCP) und wenden Sie ihn auf die Autohealing-Richtlinie der Managed Instance Group an.
Warum: Die MIG prüft Instanzen regelmäßig basierend auf dem Health Check. Wenn eine Instanz aufeinanderfolgende Prüfungen fehlschlägt, löscht und erstellt die MIG sie automatisch aus dem Template neu, um die Anwendungsverfügbarkeit sicherzustellen.
Ein Datenkorruptionsereignis ist in einer Cloud SQL-Datenbank aufgetreten. Sie müssen die Datenbank auf den Zustand wiederherstellen, den sie 5 Minuten vor dem Ereignis hatte.
Stellen Sie sicher, dass Point-in-Time Recovery (PITR) zuvor auf der Instanz aktiviert ist. Führen Sie einen Wiederherstellungsvorgang durch und geben Sie den genauen Zeitstempel an, auf den wiederhergestellt werden soll.
Warum: PITR basiert auf der Aktivierung der Binärprotokollierung. Es ermöglicht eine granulare Wiederherstellung zu jedem Zeitpunkt innerhalb des Aufbewahrungsfensters, was für die Minimierung des Datenverlusts (niedriges RPO) entscheidend ist.
Tägliche Backups eines Compute Engine Persistent Disk automatisieren und diese 14 Tage lang aufbewahren.
Erstellen Sie eine Ressourcenrichtlinie für Disk-Snapshots. Konfigurieren Sie einen täglichen Zeitplan und eine 14-tägige Aufbewahrungsrichtlinie. Wenden Sie diese Richtlinie auf den Ziel-Persistent Disk an.
Warum: Snapshot-Zeitpläne sind die verwaltete "Fire-and-forget"-Methode zur Automatisierung von GCE-Backups. Dies ist zuverlässiger und wartbarer als die Verwendung von Cron-Jobs oder benutzerdefinierten Skripten.
Eine Compute Engine-Instanz muss aus einem Cloud Storage-Bucket lesen und in eine BigQuery-Tabelle schreiben. Erteilen Sie die minimal erforderlichen Berechtigungen.
Erstellen Sie ein benutzerdefiniertes Service Account. Weisen Sie ihm die Rollen `roles/storage.objectViewer` und `roles/bigquery.dataEditor` zu. Verknüpfen Sie dieses Service Account mit der Instanz.
Warum: Die Verwendung eines benutzerdefinierten Service Accounts mit spezifischen, vordefinierten Rollen vermeidet die übermäßig permissive Natur des Standard-Compute Engine Service Accounts und hält sich an das Prinzip der geringsten Rechte.
Einem Benutzer Berechtigungen zur Verwaltung von GCE-Instanzen erteilen, aber nicht zum Löschen.
Erstellen Sie eine benutzerdefinierte IAM-Rolle. Beginnen Sie mit den Berechtigungen aus der Rolle `roles/compute.instanceAdmin.v1` und entfernen Sie die Berechtigung `compute.instances.delete`.
Warum: Benutzerdefinierte Rollen bieten die Flexibilität, einen präzisen Satz von Berechtigungen zu vergeben, wenn vordefinierte Rollen für eine spezifische Arbeitsfunktion zu breit oder zu restriktiv sind.
Ein Entwickler muss sich gemäß der Sicherheitsrichtlinie per SSH mit einer Compute Engine-Instanz verbinden, die keine externe IP-Adresse hat.
Weisen Sie dem Entwickler die Rolle `roles/iap.tunnelResourceAccessor` zu. Er kann sich dann mit `gcloud compute ssh [INSTANCE_NAME] --tunnel-through-iap` verbinden.
Warum: Identity-Aware Proxy (IAP) TCP-Forwarding bietet eine sichere, identitätsbasierte Methode zum Zugriff auf interne Instanzen ohne Bastion-Hosts, VPNs oder öffentliche IPs.
Eingehenden SSH-Verkehr (Port 22) zu bestimmten VMs nur aus dem IP-Bereich des Unternehmensbüros zulassen.
Erstellen Sie eine VPC-Firewall-Regel mit `direction: INGRESS`, `action: ALLOW`, `protocol/ports: tcp:22`, `source ranges: [CORPORATE_IP_CIDR]` und `target tags: [z. B. "allow-ssh"]`. Wenden Sie das Tag auf die vorgesehenen VMs an.
Warum: Die Kombination von Source Ranges und Target Tags bietet eine präzise und skalierbare Methode zur Steuerung des Verkehrs. Sie schränkt sowohl ein, *wer* sich verbinden kann, als auch *womit* er sich verbinden kann.
Verhindern, dass Daten aus einem sensiblen BigQuery-Projekt außerhalb einer vertrauenswürdigen Netzwerkbegrenzung kopiert oder darauf zugegriffen werden können, selbst mit gültigen Anmeldeinformationen.
Konfigurieren Sie VPC Service Controls. Erstellen Sie einen Dienstperimeter, der das sensible Projekt einschließt und die BigQuery API einschränkt.
Warum: VPC Service Controls erstellen einen virtuellen "Datenperimeter", der den API-Level-Zugriff steuert und eine starke Verteidigung gegen Datenexfiltration bietet, die Firewall-Regeln nicht leisten können.
Einer Drittanbieteranwendung temporären, zeitlich begrenzten Lesezugriff auf ein bestimmtes privates Objekt in einem Cloud Storage-Bucket gewähren.
Generieren Sie eine signierte URL für das Objekt mit einer kurzen Ablaufzeit (z. B. 15 Minuten) unter Verwendung eines Service Accounts mit Leseberechtigungen.
Warum: Signierte URLs gewähren temporären, objektbezogenen Zugriff, ohne dass die Drittpartei ein Google-Konto oder IAM-Berechtigungen benötigt. Dies ist die sicherste Methode für diesen Anwendungsfall.
Ein GKE-Pod muss sicher auf Google Cloud APIs (z. B. Pub/Sub) zugreifen, ohne Service-Account-Schlüssel als Kubernetes-Secrets zu speichern.
Aktivieren Sie Workload Identity im GKE-Cluster. Erstellen Sie ein Google Service Account (GSA) und ein Kubernetes Service Account (KSA). Binden Sie das KSA mit einer IAM-Richtlinie an das GSA. Konfigurieren Sie den Pod so, dass er das KSA verwendet.
Warum: Workload Identity ist der empfohlene, schlüssellose Weg für GKE-Anwendungen, sich bei Google Cloud-Diensten zu authentifizieren. Es ordnet KSA-Identitäten GSA-Identitäten zu, was sicherer ist als das Verwalten und Rotieren von Schlüsseldateien.
Eine Organisationsrichtlinie verlangt, dass alle Daten in einem Cloud Storage-Bucket mit einem Verschlüsselungsschlüssel verschlüsselt werden, den die Organisation kontrolliert.
Erstellen Sie einen kryptografischen Schlüssel in Cloud KMS. Geben Sie beim Erstellen des Cloud Storage-Buckets diesen Schlüssel als Customer-Managed Encryption Key (CMEK) an.
Warum: CMEK gibt Ihnen die Kontrolle über den für die Verschlüsselung verwendeten Schlüssel, einschließlich Rotation und Widerruf, während Sie weiterhin Googles verwaltete Verschlüsselungsinfrastruktur nutzen.
Mitarbeitern ermöglichen, ihre vorhandenen lokalen Active Directory-Anmeldeinformationen für den Zugriff auf Google Cloud-Ressourcen zu verwenden.
Konfigurieren Sie Cloud Identity zur Föderation mit Active Directory unter Verwendung von SAML 2.0. Benutzer authentifizieren sich bei AD, das dann ihre Identität an Google Cloud für den Zugriff bestätigt.
Warum: Föderation ermöglicht Single Sign-On (SSO) und zentralisiert die Identitätsverwaltung im vorhandenen IdP (Active Directory), wodurch die Notwendigkeit entfällt, einen separaten Satz von Passwörtern in Google Cloud zu verwalten.
Einem externen Auftragnehmer temporären Zugriff auf ein Projekt gewähren, der nach 30 Tagen automatisch abläuft.
Fügen Sie den Auftragnehmer als IAM-Mitglied mit der erforderlichen Rolle hinzu. Fügen Sie eine Bedingung zur Rollenbindung mit einem Ablaufzeitstempel hinzu (`request.time < timestamp("YYYY-MM-DDTHH:MM:SSZ")`).
Warum: IAM-Bedingungen bieten eine attributbasierte Zugriffssteuerung. Zeitbasierte Bedingungen sind perfekt für temporären Zugriff, da sie Berechtigungen automatisch ohne manuelle Bereinigung widerrufen.
