Lernen

Die Prüfung auf einen Blick

Google Cloud Certified — Associate Cloud Engineer prüft die tägliche Arbeit: Projekte und Abrechnung einrichten, Rechenleistung, Speicher und Netz bereitstellen, den Betrieb überwachen und Zugriffe sauber vergeben. Erwartet wird, dass man den Weg in der Konsole und den passenden gcloud-Befehl kennt.

Stand September 2026. Die Prüfung wird nicht auf Deutsch angeboten — abgelegt wird sie auf Englisch. Deshalb steht hier jede Frage in beiden Sprachen. Gebühr rund 125 USD zuzüglich Steuern. Google empfiehlt mindestens sechs Monate Praxis mit Google Cloud; Voraussetzungen gibt es keine.

Keine veröffentlichte Bestehensgrenze: Google nennt weder Punktzahl noch Prozentwert. Die Simulation hier rechnet mit 70 % als Richtwert, nicht als offizielle Angabe.

Die vier Bereiche und ihr Gewicht

Bereiche 2 und 3 machen zusammen rund 60 % aus und behandeln dieselben Dienste einmal beim Anlegen und einmal im Betrieb. Wer eine Ressource anlegen kann, sollte deshalb immer gleich mitlernen, wie man sie später ändert, vergrößert, sichert und wieder abbaut.

Besonderheiten der Prüfung

• Befehle werden abgefragt. Unterbefehl und Flag müssen stimmen; die falschen Optionen unterscheiden sich oft nur in einem Wort (create statt update, --zone statt --region).
• Die Ebene entscheidet. Viele Fragen lassen sich allein daran lösen, ob etwas global, regional oder zonal ist: Subnetz regional, VM zonal, Bucket je nach Standorttyp, Image global.
• Geringste Rechte ist der häufigste Zusatz. Gefragt ist fast nie Owner oder Editor, sondern die engste vordefinierte Rolle auf der kleinsten passenden Ebene.
• Ein Weg, nicht mehrere: Lösungen, die „erst exportieren, dann neu anlegen, dann migrieren“ lauten, sind fast immer falsch, wenn es einen eingebauten Schalter gibt.
• Kein Abzug fürs Raten. Keine Frage unbeantwortet lassen.

Denkraster

1. Auf welcher Ebene? Organisation, Ordner, Projekt, Ressource — und global, regional oder zonal. Das schließt meist zwei Optionen sofort aus.
2. Braucht es einen Stopp? Maschinentyp, Dienstkonto und Zugriffsbereiche ändern sich nur an der beendeten Instanz; Laufwerk vergrößern, Tags und Labels gehen im Betrieb.
3. Verwalteter Dienst oder Eigenbau? Cloud NAT statt eigener NAT-Instanz, verwaltete Instanzgruppe statt Skript, Infrastructure Manager statt eigener Terraform-Pipeline.
4. Welche Rolle reicht? Immer die engste vordefinierte Rolle; Rechte über Gruppen, nicht über Einzelpersonen; Dienstkonto statt Schlüsseldatei.

Lernquellen

• Google Cloud Skills Boost: der Lernpfad zum Associate Cloud Engineer mit Übungslabs in echten Projekten — für diese Prüfung der wichtigste Teil.
• Offizieller Prüfungsleitfaden („Exam guide“) mit der verbindlichen Themenliste je Abschnitt.
• Kostenloser Beispieltest von Google als Formatprobe.
• Eigenes Projekt mit Gratisguthaben: Eine VM anlegen, ein Subnetz erweitern, eine Firewallregel testen und wieder aufräumen bringt mehr als drei Kapitel lesen. Danach unbedingt alles löschen und die Abrechnung prüfen.
• Generalprobe: Die Simulation hier zieht 50 Fragen nach Gewicht, mit 120-Minuten-Countdown.

Die Ressourcenhierarchie

Google Cloud ordnet alles in einem Baum an. Von oben nach unten: Organisation → Ordner → Projekt → Ressource. Diese Reihenfolge ist Prüfungsstoff und wird gern in vertauschter Form angeboten — ein Projekt steht nie über einem Ordner.

Vererbung läuft immer nach unten und ist additiv: Eine auf einem Ordner vergebene Rolle gilt in allen Projekten darunter — auch in solchen, die erst später in diesem Ordner entstehen. Eine Nachpflege je Projekt ist deshalb nicht nötig; Rechte lassen sich weiter unten auch nicht wieder wegnehmen.

Eine Organisationsressource entsteht nicht von Hand. Sie wird automatisch angelegt, sobald für die Domain Cloud Identity oder Google Workspace eingerichtet ist. Wer bisher nur Projekte unter privaten Google-Konten betreibt, braucht also zuerst eine verwaltete Domain; bestehende Projekte lassen sich danach in die Hierarchie migrieren.

Projekte

Jedes Projekt trägt drei Bezeichner, die auseinandergehalten werden müssen:

Ein Projekt wird mit gcloud projects delete nicht sofort entfernt, sondern geht in den Zustand „gelöscht“ über. Innerhalb von 30 Tagen holt gcloud projects undelete es mitsamt Ressourcen zurück; danach löscht Google Cloud endgültig. Projekt-ID und Projektnummer bleiben dauerhaft belegt und werden nie an ein anderes Projekt vergeben. Das verknüpfte Abrechnungskonto ist eine eigenständige Ressource und bleibt bestehen; IAM-Bindungen wandern nicht nach oben.

Verschieben in einen Ordner erledigt gcloud beta projects move PROJECT_ID --folder=FOLDER_ID. Dafür braucht es die Rolle Project Mover auf Quelle und Ziel. gcloud projects update ändert dagegen nur den Anzeigenamen.

Rollen der Hierarchie nach dem Prinzip der geringsten Rechte: Project Creator erlaubt genau das Anlegen neuer Projekte unterhalb der Ressource, auf der die Rolle vergeben wurde — für ein Team mit eigenem Sandbox-Ordner also die richtige Wahl. Folder Admin ginge deutlich weiter, da sie den Ordner selbst und dessen IAM-Richtlinie einschließt. Gebunden werden Rollen an Google-Gruppen, nicht an Einzelpersonen: Die Bindung fällt einmal je Projekt an, alles Weitere regelt die Gruppenmitgliedschaft. Dienstkonten mit verteilten Schlüsseldateien sind für Personen nie die Antwort.

APIs und Kontingente

In einem frischen Projekt ist fast nichts freigeschaltet. Bevor eine Ressource entsteht, muss die zugehörige API aktiv sein: gcloud services enable compute.googleapis.com. gcloud services list zeigt nur an, was verfügbar oder aktiv ist, und ändert nichts. Damit in einem leeren Projekt eine Compute Engine-Instanz entstehen kann, sind genau zwei Schritte Pflicht: Abrechnungskonto verknüpfen und API aktivieren. Budgets, Ordnerzuordnung und Organisationsrichtlinien sind organisatorisch sinnvoll, aber keine technische Voraussetzung.

Kontingente (Quotas) werden je Projekt, Dienst und Region geführt — etwa CPUs in europe‑west3. Ist ein Kontingent ausgeschöpft, hilft weder ein höheres Budget noch eine andere Organisationsrichtlinie: Die Erhöhung wird in der Konsole unter IAM und Verwaltung → Kontingente eingesehen und beantragt. Ein zusätzliches Projekt anzulegen, um das Kontingent zu umgehen, ist in Prüfungsfragen die falsche Antwort.

Das Google Cloud CLI und Cloud Shell

gcloud init führt auf einem neuen Rechner durch Anmeldung, Standardprojekt und Standardregion und legt dabei eine Konfiguration an. Benannte Konfigurationen halten mehrere Sätze aus Konto, Projekt und Region nebeneinander — für Beratung mit mehreren Kundenorganisationen der vorgesehene Weg. Umgeschaltet wird mit gcloud config configurations activate, nicht durch wiederholtes Ab- und Anmelden oder eine zweite CLI-Installation.

Soll ein einzelner Befehl gegen ein anderes Projekt laufen, ohne die aktive Konfiguration zu verändern, genügt das Flag --project=PROJECT_ID. gcloud config set project würde den Standardwert dauerhaft ändern.

Anmeldung: gcloud auth login meldet ein Nutzerkonto an und verlangt eine Bestätigung im Browser. Auf einem Build-Server ohne Browser wird stattdessen ein Dienstkonto nicht interaktiv aktiviert: gcloud auth activate-service-account --key-file=key.json.

Cloud Shell ist ein Terminal im Browser mit vorinstalliertem CLI und einem dauerhaften Home-Verzeichnis. Dateien dort überstehen das Beenden der Sitzung und Neustarts der zugrunde liegenden VM; nur was außerhalb des Home-Verzeichnisses liegt, geht verloren.

Abrechnung einrichten

Zwei Begriffe werden regelmäßig verwechselt:

• Zahlungsprofil — enthält Zahlungsmittel, Steuer- und Rechnungsdaten. Es wird mit einem oder mehreren Abrechnungskonten verknüpft.
• Abrechnungskonto (Cloud Billing Account) — bündelt die Kosten vieler Projekte. Ein Projekt gehört zu genau einem Abrechnungskonto, ein Abrechnungskonto zu beliebig vielen Projekten.

Trennen statt löschen: Soll ein Testprojekt keine Kosten mehr verursachen, seine Konfiguration und IAM-Richtlinie aber erhalten bleiben, löst gcloud billing projects unlink die Verknüpfung. Die Abrechnung ist damit deaktiviert und kostenpflichtige Dienste werden gestoppt, das Projekt selbst bleibt bestehen. Ein Budget wäre der falsche Hebel — es warnt nur.

Unterkonten (Abrechnungsunterkonten) trennen die Kosten je Endkunde, während die Rechnung weiterhin an den Wiederverkäufer geht. Sie sind die Antwort für Partner mit mehreren Endkunden — ein zusätzliches Zahlungsprofil je Kunde würde die Abrechnung dagegen vollständig trennen.

Kosten steuern und auswerten

Budgets warnen, sie bremsen nicht. Ein Cloud Billing-Budget verschickt Benachrichtigungen an den gesetzten Schwellen (etwa 50, 90 und 100 %), sperrt aber keine Ressourcen und beendet keine Nutzung. Der Umfang lässt sich auf Projekte, Dienste und Labels einschränken. Eine harte Obergrenze, ab der Google Cloud selbst abschaltet, gibt es nicht.

Wer trotzdem automatisch reagieren will, leitet die Budgetmeldungen an ein Pub/Sub-Thema und wertet sie mit einer Cloud Run function als Abonnent aus — diese kann dann etwa VMs stoppen oder die Abrechnung trennen. Das ist der vorgesehene Weg zur programmatischen Reaktion.

Der Export beginnt erst ab dem Zeitpunkt der Aktivierung und liefert keine Daten aus der Vergangenheit — für eine einmalige Rückschau ist deshalb der Konsolenbericht richtig, für dauerhafte Auswertung der Export.

Labels gegen Netzwerk-Tags — eine beliebte Verwechslung:

• Labels sind Schlüssel-Wert-Paare an nahezu jeder Ressource und erscheinen in Abrechnungsberichten und im BigQuery-Export. Sie sind das Mittel zur Kostenzuordnung je Kostenstelle, ohne die Ressourcen auf eigene Projekte aufzuteilen.
• Netzwerk-Tags gelten nur für VM-Instanzen, steuern Firewallregeln und Routen und tauchen in der Abrechnung nicht auf.

Organisationsrichtlinien

Organisationsrichtlinien (Organization Policies) begrenzen, was in der Hierarchie überhaupt konfiguriert werden darf. Sie werden auf Organisation, Ordner oder Projekt gesetzt, nach unten vererbt — auch an später angelegte Projekte — und wirken unabhängig von den IAM-Rollen der handelnden Personen. Sie ersetzen die IAM-Richtlinie nicht, sondern treten neben sie, und sie hängen nicht an Labels.

Abzugrenzen davon: VPC Service Controls ziehen einen Perimeter gegen Datenabfluss, begrenzen aber keine Regionen. Eine logbasierte Messung in Cloud Logging meldet neue Schlüssel erst nachträglich und verhindert sie nicht. Eine benutzerdefinierte IAM-Rolle je Person wäre Verwaltungsaufwand ohne durchsetzbare Wirkung.

Stand September 2026: Der Dienst heißt Cloud Run functions (früher Cloud Functions) — in Budget-Szenarien ist er der Abonnent des Pub/Sub-Themas. Beim Verschieben von Projekten ist gcloud beta projects move weiterhin der geprüfte Befehl; das beta im Pfad gehört zur richtigen Antwort.

Compute Engine: Maschine, Standort, Rabatt

Eine VM ist immer zonal. Die Zone bestimmt Ausfallgrenze und Latenz, die Region bestimmt Datenresidenz und Preis. Der Maschinentyp entscheidet über Leistungsprofil und Kosten:

Passt keine vordefinierte Kombination, ist der benutzerdefinierte Maschinentyp (custom machine type) die Antwort: vCPU-Zahl und Speichermenge werden innerhalb der Grenzen einer Familie frei gewählt, bezahlt wird nur das Angeforderte. Den nächstgrößeren vordefinierten Typ zu nehmen ist in Prüfungsfragen die teure Falschantwort. Sole-Tenant-Knoten sind kein Sparmodell, sondern dienen der physischen Isolation aus Lizenz- oder Compliance-Gründen.

Die drei Preishebel unterscheiden sich in der Lastform, nicht im Dienst:

• Sustained Use Discounts — werden automatisch gewährt, wenn eine VM einen großen Teil des Monats läuft. Kein Vertrag, aber auch nur ein kleiner Nachlass.
• Committed Use Discounts — ein oder drei Jahre Bindung auf eine Nutzungsmenge, der höchste Rabatt. Richtige Wahl bei planbarer Grundlast, die rund um die Uhr läuft.
• Spot-VMs — deutlich günstiger, ohne Verfügbarkeitsgarantie, jederzeit vorzeitig beendbar. Nur für unterbrechbare Arbeit mit Zwischenständen, etwa Batch-, Render- oder Analysejobs.

Vorlagen, Instanzgruppen, Images und Laufwerke

Eine Instanzvorlage (instance template) beschreibt Maschinentyp, Bootimage, Laufwerke, Netzwerk-Tags, Dienstkonto und Metadaten. Sie ist unveränderlich: Änderungen bedeuten eine neue Vorlage, nicht eine Bearbeitung. Aus der Vorlage entsteht die verwaltete Instanzgruppe (MIG) — die einzige Gruppenart mit Autoskalierung, automatischer Reparatur und rollierender Aktualisierung. Nicht verwaltete Gruppen sind bloße Sammlungen bestehender VMs und können nichts davon.

• Autoskalierung nach CPU-Auslastung, Load-Balancer-Kapazität oder Cloud-Monitoring-Messwert, mit Mindest- und Höchstzahl an Instanzen.
• Automatische Reparatur (autohealing) braucht zwingend eine Integritätsprüfung. Ohne sie wird nur eine gelöschte oder abgestürzte VM ersetzt, nicht ein hängender Anwendungsprozess.
• Regionale gegen zonale Gruppe: Die regionale MIG verteilt Instanzen über mehrere Zonen einer Region und übersteht damit einen Zonenausfall. Die zonale Gruppe tut das nicht. Bei der Frage nach Hochverfügbarkeit ist „regional“ fast immer Teil der Antwort.
• Startskripte kommen über Metadaten: Schlüssel startup-script in der Vorlage oder an der VM. Das Skript läuft bei jedem Start als Root — der Weg, Agenten zu installieren, ohne sich per SSH anzumelden. Projektweit geht das über gcloud compute project-info add-metadata.

Drei Abbilder, die gern verwechselt werden:

Wiederkehrende Sicherungen erledigt ein Snapshot-Zeitplan — eine Ressourcenrichtlinie, die an ein persistentes Laufwerk gebunden wird, Snapshots nach Plan erzeugt und sie nach der eingestellten Aufbewahrungsdauer selbst löscht. Skripte auf den VMs sind hier nie die gesuchte Lösung. Bei den Laufwerken gilt: persistente Laufwerke (Balanced, SSD, Standard, Extreme) überleben Stopp und Löschung der VM und lassen sich im Betrieb vergrößern — aber nie verkleinern. Die lokale SSD sitzt physisch am Host, liefert die höchsten IOPS bei niedrigster Latenz und verliert ihren Inhalt beim Stoppen der VM: ausschließlich für temporäre Daten und Scratch-Bereiche.

Container und serverlos

GKE Autopilot gegen GKE Standard ist eine Frage der Verantwortung: Im Autopilot-Modus verwaltet Google Knoten, Dimensionierung, Aktualisierung und Knotensicherheit, abgerechnet werden die von den Pods angeforderten Ressourcen. Im Standard-Modus gehören Knotenpools dem Team. Ein Knotenpool bündelt Knoten gleicher Konfiguration; der Maschinentyp eines bestehenden Pools lässt sich nicht nachträglich ändern. Braucht eine Arbeitslast andere Knoten, wird ein zusätzlicher Pool angelegt (gcloud container node-pools create) und die Pods per nodeSelector oder Taints dorthin gelenkt — ohne Ausfallzeit, ohne Neuanlage des Clusters.

Cloud Run führt Container vollständig verwaltet aus, skaliert bei ausbleibenden Anfragen auf null Instanzen und verursacht dann keine Rechenkosten. Cloud Run functions sind dieselbe Plattform für einzelne Funktionen mit Auslösern — HTTP oder Ereignisse aus Cloud Storage, Pub/Sub und Eventarc. Eine Miniaturansicht beim Objekt-Upload ist der Musterfall; abfragende Schleifen auf VMs oder CronJobs sind die teure Falschantwort.

Stand September 2026: Der Dienst heißt Cloud Run functions, nicht mehr „Cloud Functions“; Container-Images liegen in der Artifact Registry, nicht mehr in der Container Registry.

Anforderung → Compute-Dienst:

Cloud Storage: Standort, Klasse, Schutz

Der Standorttyp wird beim Anlegen festgelegt und bestimmt Residenz, Verfügbarkeit und Preis: Region (eine Region, günstigste Variante, erfüllt Residenzvorgaben), Dual-Region (zwei benannte Regionen mit Georedundanz) und Multi-Region (mehrere Regionen eines Kontinents, für weltweite Leser). Darf ein Bestand seine Region nicht verlassen, scheiden Dual- und Multi-Region aus.

Alle vier Klassen liefern Objekte sofort aus — es gibt keine Wartezeit auf das Auftauen. Der Unterschied liegt in Speicherpreis gegen Abrufpreis und in der Gebühr bei vorzeitigem Löschen.

• Autoclass — verschiebt einzelne Objekte automatisch zwischen den Klassen, je nach letztem Zugriff. Die Antwort, wenn das Zugriffsmuster unbekannt ist oder schwankt.
• Lebenszyklusregeln — arbeiten nach Alter und weiteren Bedingungen: Klasse wechseln oder Objekt löschen. Die Bedingung für nicht aktuelle Versionen räumt alte Fassungen auf.
• Objektversionierung — bewahrt überschriebene und gelöschte Objekte als nicht aktuelle Versionen auf. Nur sie stellt etwas wieder her.
• Aufbewahrungsrichtlinie (retention policy) — verhindert Löschen vor Ablauf der Frist. Erst die Sperre (Bucket Lock) macht sie unwiderruflich, sodass auch Administratoren nichts mehr löschen oder die Frist verkürzen können. Für regulatorische Unveränderlichkeit ist genau das gefragt.

Datenbanken und Dateispeicher

Cloud SQL ist verwaltetes MySQL, PostgreSQL und SQL Server. Drei Funktionen, drei verschiedene Probleme: die Hochverfügbarkeitskonfiguration hält eine Standby-Instanz in einer zweiten Zone und schaltet bei Zonenausfall automatisch um; ein Lesereplikat nimmt lesende Berichtsabfragen auf und entlastet die Primärinstanz, schützt aber nicht vor Ausfällen; Point-in-Time-Recovery setzt auf fortlaufende Transaktionslogs auf und stellt einen beliebigen Zeitpunkt innerhalb des Aufbewahrungszeitraums wieder her — vorher aktiviert, sonst bleibt nur der Stand der letzten Sicherung.

Ein persistentes Laufwerk lässt sich nur an eine VM schreibend anhängen — sobald mehrere VMs gleichzeitig in dasselbe Dateisystem schreiben sollen, ist Filestore die Antwort, nicht ein weiteres Laufwerk und nicht ein Bucket.

VPC, Firewall, Adressen und DNS

Ein VPC-Netzwerk ist global, Subnetze sind regional und decken alle Zonen ihrer Region ab — VMs in verschiedenen Zonen teilen sich also denselben Bereich. Im automatischen Modus legt Google je Region ein Subnetz aus einem festen Bereich an; im benutzerdefinierten Modus (custom mode) werden Netz und Bereiche selbst bestimmt, was bei Überschneidungsfreiheit zum lokalen Rechenzentrum die einzig brauchbare Wahl ist. Ein Subnetzbereich lässt sich mit gcloud compute networks subnets expand-ip-range im laufenden Betrieb vergrößern, aber niemals verkleinern. Für VPC-native GKE-Cluster erhält das Subnetz zwei sekundäre Bereiche, einen für Pods und einen für Services.

• Shared VPC — ein Hostprojekt stellt Subnetze mehreren Dienstprojekten derselben Organisation bereit; Netz und Firewall bleiben zentral. Die Antwort bei „zentrale Netzwerkabteilung“.
• VPC-Netzwerk-Peering — verbindet zwei eigenständig verwaltete Netzwerke, auch über Projekte und Organisationen hinweg. Bedingungen: keine überlappenden Subnetzbereiche, beide Seiten legen ihre Hälfte an, und es ist nicht transitiv. Jedes Netzwerk behält seine eigenen Firewallregeln.

Firewallregeln sind zustandsbehaftet und werden nach Priorität (0 bis 65535, niedriger gewinnt) ausgewertet. Jedes Netzwerk trägt zwei implizite Regeln mit der niedrigsten Priorität: implied deny ingress und implied allow egress. Ohne eigene Regel kommt also nichts herein, aber alles hinaus. Ziele werden über Netzwerk-Tags oder Ziel-Dienstkonten gesetzt; das Dienstkonto ist die sicherere Wahl, weil seine Zuweisung an eine IAM-Berechtigung gebunden ist, während ein Tag jeder setzen kann, der VMs erstellen darf. Drei Bereiche muss man auswendig können:

Regeln für viele Projekte auf einmal — auch für künftige — gehören in eine hierarchische Firewallrichtlinie an Organisation oder Ordner; sie wirkt vor den VPC-Regeln. Organisationsrichtlinien steuern dagegen Konfiguration, nicht Verkehr.

Adressen und Ausgang: Eine kurzlebige (ephemere) externe Adresse wird beim Stoppen der VM freigegeben — steht sie in einem DNS-Eintrag, ist der Dienst danach nicht mehr erreichbar. Gefragt ist dann eine reservierte statische Adresse. Cloud NAT verschafft VMs ohne externe Adresse ausgehenden Internetzugang, ohne eingehende Verbindungen zu öffnen. Private Google Access lässt dieselben VMs Google-APIs erreichen, ohne dass der Verkehr das Google-Netzwerk verlässt, und hat dabei Vorrang vor Cloud NAT. Beides wird oft zusammen gebraucht und schließt sich nicht aus. Cloud DNS verwaltet öffentliche Zonen für Namen im Internet und private Zonen, die an ein oder mehrere VPC-Netzwerke gebunden und nur aus diesen auflösbar sind.

Lastverteilung, Anbindung, Bereitstellung

Merkmal des Passthrough-Typs: Er verteilt Pakete unverändert, kennt keine URL-Pfade und behält die Quelladresse. Proxy-basierte Verteiler terminieren die Verbindung, ersetzen die Quelladresse und unterstützen kein UDP. Cloud CDN wird am Back-End-Dienst eines externen Application Load Balancers eingeschaltet und speichert Inhalte an Google-Edge-Standorten zwischen — der Weg, Latenz und Back-End-Last bei häufig abgerufenen statischen Inhalten zugleich zu senken.

Stand September 2026: Die Lastverteiler tragen die Namen „Application Load Balancer“ und „Network Load Balancer“ mit den Zusätzen extern/intern und Passthrough/Proxy. Ältere Bezeichnungen wie „HTTP(S) Load Balancing“ oder „TCP/UDP Network Load Balancing“ meinen dieselben Dienste.

Hybride Anbindung: HA VPN baut IPsec-Tunnel über das Internet auf, ist in Tagen eingerichtet und tauscht Routen über Cloud Router per BGP aus — die Wahl bei geringem Volumen und kurzer Frist. Dedicated Interconnect braucht eine physische Kreuzverbindung an einem Colocation-Standort, Partner Interconnect läuft über einen Anbieter; beide bieten hohe Bandbreite ohne Internet, aber mit deutlich mehr Vorlauf.

Bereitstellungswerkzeuge: die Konsole zum Ausprobieren und Nachsehen, gcloud für einzelne, wiederholbare Schritte und Skripte, Terraform für deklarative Infrastruktur als Code. Im Team gehört die Terraform-Zustandsdatei in ein Remote-Backend in einem Cloud Storage Bucket — dort ist sie für alle zugänglich und wird während eines Laufs gesperrt —, und vor jedem Apply zeigt terraform plan, was entstehen, sich ändern oder verschwinden würde. Handgriffe in der Konsole zwischendurch erzeugen Abweichungen (drift). Infrastructure Manager führt dieselben Terraform-Konfigurationen als verwalteter Dienst aus, verwahrt den Zustand selbst und arbeitet unter einem Dienstkonto. Cloud Marketplace liefert fertige Lösungen samt VMs, Netzwerk und Lizenz in einem geführten Ablauf, wenn nichts Eigenes beschrieben werden soll.

Instanzen im Betrieb: Zustände, Kosten, Änderungen

Eine Compute Engine-Instanz kennt die Zustände RUNNING, TERMINATED und — kurzzeitig — STOPPING. gcloud compute instances stop führt nach TERMINATED, start wieder zurück, delete entfernt die Instanz endgültig. Entscheidend für Kostenfragen: Im Zustand TERMINATED werden vCPU und Arbeitsspeicher nicht mehr berechnet, angehängte Persistent Disks, reservierte statische IP-Adressen und vorhandene Snapshots schon. Erst das Löschen der Instanz samt Laufwerken und das Freigeben der reservierten Adresse beendet alle Kosten. Eine gestoppte Instanz behält ihre Boot-Disk und ihre interne IP-Adresse; eine kurzlebige externe Adresse verliert sie.

Die zweithäufigste Frage dieses Bereichs lautet: Muss die Instanz dafür gestoppt werden? Die Trennlinie verläuft zwischen Eigenschaften der virtuellen Hardware und Identität einerseits und Metadaten und Anhängseln andererseits.

Livemigration verschiebt eine laufende Instanz bei Wartungsarbeiten auf andere Hardware — sie ändert nichts an der Größe und ist nie die Antwort auf „mehr CPU“. Startskripte liegen als Instanz- oder Projektmetadaten unter dem Schlüssel startup-script und werden vom Gast-Agent bei jedem Boot ausgeführt; /etc/rc.local verwaltet Compute Engine nicht.

Laufwerke, Snapshots, Images und Zugang

• Laufwerk vergrößern ohne Ausfall: gcloud compute disks resize DISK --size=… vergrößert das Persistent Disk online, danach erweitert man das Dateisystem auf der laufenden Instanz. Verkleinern ist nicht möglich.
• Snapshot — inkrementelle Sicherung eines Persistent Disk, auch im laufenden Betrieb. Snapshots sind globale Ressourcen und lassen sich in jeder Zone jeder Region als neues Laufwerk wiederherstellen: gcloud compute disks create --source-snapshot=…. Ein Snapshot-Zeitplan (snapshot-schedules) automatisiert die Sicherung.
• VM in eine andere Zone bringen: Snapshot der Boot-Disk erstellen, in der Zielzone ein Laufwerk daraus anlegen, Instanz darauf starten. Ein zonales Laufwerk lässt sich nicht an eine VM in einer anderen Zone anhängen; ein regionales Persistent Disk repliziert nur zwischen zwei Zonen derselben Region.
• Benutzerdefiniertes Image — friert den fertig eingerichteten Softwarestand einer Boot-Disk ein (gcloud compute images create --source-disk=…). Eine Instanzvorlage verweist darauf, und neue VMs starten sofort einsatzbereit. Ein Startskript, das bei jedem Start alles neu installiert, verlängert dagegen jede Startzeit. Images sind global, Instanzvorlagen global, Instanzen zonal.

Verbinden: gcloud compute ssh INSTANZ --zone=… erzeugt bei Bedarf ein Schlüsselpaar und hinterlegt es. Zentral verwaltet wird der Zugang über OS Login: Das Metadatenflag enable-oslogin=TRUE auf Projekt- oder Instanzebene verknüpft Linux-Konten mit Google-Identitäten, der Zugriff wird dann über roles/compute.osLogin beziehungsweise roles/compute.osAdminLogin vergeben. In Metadaten abgelegte SSH-Schlüssel umgehen IAM und müssen von Hand gepflegt werden.

Für VMs ohne externe IP-Adresse übernimmt die IAP-TCP-Weiterleitung den Tunnel: gcloud compute ssh INSTANZ --tunnel-through-iap. Zwei Voraussetzungen werden geprüft: eine Ingress-Firewallregel, die TCP 22 aus 35.235.240.0/20 erlaubt, und die Rolle roles/iap.tunnelResourceAccessor für die Nutzer. Cloud NAT ist kein Ersatz — es öffnet nur den Weg nach außen, nicht hinein.

Gruppen, Cluster und Container im Betrieb

Verwaltete Instanzgruppen (MIG) sind das Werkzeug für gleichartige VMs. Vier Eingriffe sind prüfungsrelevant und werden gern verwechselt:

1. Größe ändern: gcloud compute instance-groups managed resize --size=N setzt die Zielgröße von Hand.
2. Autoskalierung: set-autoscaling mit einer Richtlinie, etwa --target-cpu-utilization oder Auslastung des Load Balancers, dazu --min-num-replicas und --max-num-replicas. Nur das skaliert automatisch hoch und nachts wieder herunter.
3. Automatische Reparatur (Autohealing): eine Reparaturrichtlinie mit Systemdiagnose ersetzt fehlerhafte Instanzen — sie ändert die Gruppengröße nicht.
4. Rollierendes Update: rolling-action start-update --version=… tauscht die Instanzvorlage schrittweise aus; mit --canary-version samt eigener target-size erhält nur ein Teil der Instanzen die neue Vorlage, der Rest bleibt auf der alten. Eine zweite Gruppe danebenzustellen wäre Blue/Green mit deutlich mehr Aufwand.

• GKE: gcloud container clusters get-credentials NAME --location=… schreibt Endpunkt und Anmeldedaten in die kubeconfig und richtet das Auth-Plugin ein — das ist immer der erste Schritt auf einer neuen Workstation, nie das Kopieren einer fremden kubeconfig. Mehr Knoten liefert gcloud container clusters resize --node-pool=… oder das Cluster Autoscaling; mehr Pods liefert kubectl scale. Bleiben Pods im Status Pending, fehlt Kapazität — dann hilft nur der Knotenpool, nicht mehr Replikate.
• Cloud Run: Jede Bereitstellung erzeugt eine Revision. Der Verkehr wird revisionsweise verteilt: gcloud run services update-traffic --to-revisions REV=10 schickt zehn Prozent auf die neue Revision, ein Zurückrollen ist jederzeit möglich. --no-traffic stellt nur bereit, ohne Anfragen zuzulassen, und teilt nichts auf. Geheimnisse kommen mit --set-secrets aus dem Secret Manager als Umgebungsvariable oder gemountete Datei; das Dienstkonto braucht dafür roles/secretmanager.secretAccessor. --set-env-vars würde den Wert im Klartext in der Revisionskonfiguration ablegen.
• Artifact Registry: Vor dem ersten docker push wird gcloud als Credential Helper eingetragen: gcloud auth configure-docker europe-west3-docker.pkg.dev. Danach gelten die eigenen Anmeldedaten und die IAM-Rollen des Repositorys — ein exportierter Dienstkontoschlüssel in der Docker-Konfiguration wäre ein unnötiges Langzeit-Geheimnis.

Stand September 2026: Container Registry ist abgelöst, Artifact Registry ist die Antwort auf alle Fragen nach einem Image-Repository. Ebenso heißt es Cloud Run functions statt Cloud Functions.

Speicher und Daten im Betrieb

Cloud Storage wird mit dem aktuellen Befehlssatz gcloud storage bedient — ls, cp, rsync, sign-url. Er löst gsutil ab und überträgt parallel; in Prüfungsfragen ist ein Skript, das auf gsutil umgestellt werden soll, immer auf gcloud storage umzustellen. Für wiederkehrende Übertragungen aus anderen Clouds, von HTTP-Quellen oder zwischen Buckets gibt es den Storage Transfer Service mit Zeitplan; für große Mengen ohne Leitung das Transfer Appliance.

• Lebenszyklusregeln arbeiten mit den Aktionen SetStorageClass und Delete und lassen sich kombinieren — etwa nach 30 Tagen nach Coldline, nach 365 Tagen löschen. Die Mindestspeicherdauern entscheiden die Frage: Standard keine, Nearline 30 Tage, Coldline 90 Tage, Archive 365 Tage. Wer nach 90 Tagen löschen will, darf nicht nach Archive verschieben.
• Frühere Stände sichert die Objektversionierung; sie allein lässt die Kosten wachsen, deshalb gehört eine Lebenszyklusregel auf nichtaktuelle Versionen (daysSinceNoncurrentTime) dazu. Eine Aufbewahrungsrichtlinie verhindert nur das Löschen und stellt nichts wieder her.
• Signierte URL — zeitlich begrenzter Zugriff auf genau ein Objekt, ohne Google-Konto auf der Gegenseite: gcloud storage sign-url --duration=24h, ausgestellt mit einem berechtigten Dienstkonto. Die Rolle roles/storage.objectViewer für allUsers macht das Objekt dagegen dauerhaft öffentlich.

Cloud SQL: Automatische Sicherungen und Point-in-Time-Recovery werden je Instanz eingeschaltet; gcloud sql backups restore spielt eine Sicherung zurück. Ein Hochverfügbarkeits-Failover wirkt nur innerhalb derselben Region. Fällt die ganze Region aus, wird ein regionsübergreifendes Lesereplikat hochgestuft: gcloud sql instances promote-replica macht es zur eigenständigen, beschreibbaren Instanz — die Replikation endet damit endgültig.

BigQuery: Abfragekosten richten sich nach der gelesenen Datenmenge. Partitionierung nach einem Datums- oder Zeitstempelfeld beschränkt den Scan auf die betroffenen Tage, Clustering ordnet innerhalb der Partitionen nach häufig gefilterten Spalten, und maximum_bytes_billed bricht eine Abfrage ab, bevor mehr als erlaubt berechnet wird. SELECT * liest alle Spalten und ist das Gegenteil davon. Zugriff wird auf Datensatzebene vergeben: roles/bigquery.dataViewer auf dem Dataset plus roles/bigquery.jobUser im Abfrageprojekt — dieselbe Rolle auf Projektebene würde alle Datensätze öffnen. Speicherklassen wie Coldline gibt es nur in Cloud Storage, nie in BigQuery.

Netz im Betrieb

• Subnetz erweitern: gcloud compute networks subnets expand-ip-range vergrößert den primären Bereich im laufenden Betrieb, solange der neue Präfix den alten enthält; laufende Instanzen behalten ihre Adressen. Löschen und neu anlegen geht nicht, solange Instanzen im Subnetz sind. Verkleinern ist ausgeschlossen.
• Adresse festnageln: Eine bereits zugewiesene kurzlebige externe Adresse wird in derselben Region zur statischen hochgestuft (gcloud compute addresses create --addresses=…), wodurch genau diese Adresse erhalten bleibt. Eine neue Adresse zu reservieren würde die beim Partner freigegebene Adresse wechseln.
• Firewallregeln werden nach Priorität ausgewertet: Die kleinere Zahl greift zuerst, unabhängig von der Anzeigereihenfolge. Blockiert eine Deny-Regel mit Priorität 100, muss die Allow-Regel darunter liegen. Ziele werden über Netzwerk-Tags oder Dienstkonten bestimmt — Labels wertet die Firewall nicht aus. Ohne eigene Regeln gilt: Ingress standardmäßig verworfen, Egress standardmäßig erlaubt.
• Statische Route statt Firewallregel, wenn Verkehr umgeleitet werden soll: eine Route 0.0.0.0/0 mit einer Appliance-Instanz als Next Hop und einem Instanz-Tag betrifft nur die getaggten VMs; alle anderen behalten die Standardroute. Firewallregeln erlauben und verwerfen, sie leiten nicht um.
• Cloud NAT gibt VMs ohne externe Adresse ausgehenden Internetzugang. Es setzt einen Cloud Router in derselben Region voraus und wird als NAT-Konfiguration an diesem Router für das Subnetz eingerichtet. Private Google Access ist etwas anderes: Es öffnet nur den Weg zu Google-APIs, nicht zu beliebigen Paketquellen im Internet.
• Lastverteiler: Eine weitere Region wird beim globalen externen Application Load Balancer einfach als zusätzliches Back-End ergänzt (gcloud compute backend-services add-backend) — ein zweiter Load Balancer mit DNS-Verteilung verlöre das globale Anycast-Verhalten. Melden alle Back-Ends „unhealthy“, obwohl die Anwendung lokal antwortet, fehlt fast immer die Ingress-Regel für die Prüfbereiche 35.191.0.0/16 und 130.211.0.0/22. Externe Adressen auf den Instanzen sind dafür nicht nötig.
• Zertifikate und Namen: Ein Google-verwaltetes SSL-Zertifikat am HTTPS-Zielproxy wird automatisch ausgestellt und erneuert, sobald der DNS-Eintrag auf die Adresse des Load Balancers zeigt — dauerhaft ohne Verwaltungsaufwand. In Cloud DNS wird ein Eintragssatz ersetzt, nicht ergänzt: gcloud dns record-sets update oder eine Transaktion aus Entfernen und Hinzufügen. Ein zweiter A-Eintrag für denselben Namen führt zu wechselnden Antworten.

Überwachen, protokollieren, Fehler finden

Cloud Monitoring sammelt Messwerte, zeigt sie in Dashboards und alarmiert über Benachrichtigungsrichtlinien, die auf einen Benachrichtigungskanal zeigen — E-Mail, SMS, Pub/Sub oder ein Webhook. Eine Uptime-Prüfung testet einen öffentlichen Endpunkt aus mehreren Regionen; erst die Richtlinie darauf verschickt die Meldung. Eine Integritätsprüfung des Load Balancers nimmt dagegen nur Back-Ends aus der Rotation und benachrichtigt niemanden.

Compute Engine liefert ohne Agent CPU-Auslastung, Netzwerkbytes und Laufwerks-E/A auf Hypervisor-Ebene. Arbeitsspeicherauslastung und Dateisystembelegung sind nur im Gastsystem sichtbar und kommen erst mit dem Ops Agent — dem einen Agent, der Messwerte und Protokolle sendet und die früheren getrennten Agents ablöst.

Cloud Logging: Der Log-Explorer filtert die Einträge, Protokollbuckets haben eine einstellbare Aufbewahrungsdauer, und Senken leiten Einträge weiter — nach Cloud Storage für die günstige Langzeitablage, nach BigQuery für SQL-Auswertung über Monate und die Verknüpfung mit Geschäftsdaten, nach Pub/Sub für die Weitergabe an ein anderes System in nahezu Echtzeit. Ein Ausschlussfilter an einer Senke verwirft passende Einträge vor der Aufnahme und senkt damit die Aufnahmegebühr, ohne die weiterhin benötigten Einträge zu verlieren; die Protokollierung ganz abzuschalten wäre zu grob. Ein logbasierter Messwert zählt Einträge, die einem Filter entsprechen, und macht sie als Grundlage einer Alarmrichtlinie in Cloud Monitoring messbar — das Gegenteil eines Ausschlussfilters.

Cloud Audit Logs: Protokolle zur Administratoraktivität und zu Systemereignissen laufen immer und lassen sich nicht abschalten. Datenzugriffsprotokolle (ADMIN_READ, DATA_READ, DATA_WRITE) sind mit Ausnahme von BigQuery standardmäßig aus und werden in der IAM-Konfiguration je Dienst und Typ eingeschaltet. Dazu kommen Protokolle zu abgelehnten Richtlinien (Policy Denied).

Die vier Bausteine von IAM

Die Arten von Hauptkonten: Google-Konto einer Person (user:), Google-Gruppe (group:), Dienstkonto (serviceAccount:), eine ganze Workspace- oder Cloud-Identity-Domäne (domain:) sowie föderierte Identitäten aus Workforce- und Workload-Identitätspools. Dazu zwei Sonderfälle, die in Prüfungsfragen fast immer die gesuchte Schwachstelle sind: allUsers meint jede Anfrage aus dem Internet, auch völlig ohne Anmeldung — und allAuthenticatedUsers jedes angemeldete Google-Konto, also auch jedes fremde Privatkonto. Beide machen Objekte für Personen außerhalb der Organisation zugänglich; allAuthenticatedUsers bedeutet nicht „nur meine Organisation“.

Die drei Rollenarten

• Einfache Rollen (basic roles) — Viewer, Editor, Owner. Sie gelten für nahezu alle Dienste eines Projekts und sind deshalb viel zu weit; sie sind die Altlast aus der Zeit vor IAM. Wichtig für die Prüfung: Editor darf Ressourcen ändern, aber die Zulassungsrichtlinie nicht anfassen — Rollen vergeben darf nur Owner oder, gezielter, Project IAM Admin.
• Vordefinierte Rollen — von Google je Dienst geschnitten und gepflegt, etwa Storage Object Viewer, Pub/Sub Subscriber, Compute Instance Admin. Sie sind in der Prüfung fast immer die richtige Antwort und lassen sich nicht löschen oder ändern.
• Benutzerdefinierte Rollen — eine eigene Liste von Berechtigungen, wenn keine vordefinierte Rolle passt. Sie lassen sich nur auf Organisations- oder Projektebene anlegen, nie auf einem Ordner und nie an einer einzelnen Ressource. Eine Rolle der Organisation ist in allen darunter liegenden Projekten bindbar. Jede eigene Rolle trägt eine Lebenszyklusphase (ALPHA, BETA, GA), die nur den Reifegrad dokumentiert und an der Wirkung nichts ändert; deaktivieren entzieht dagegen jeden Zugriff.

Vererbung, Verweigerung, Bedingungen

Vererbung ist additiv. Eine Rolle, die auf Organisation, Ordner oder Projekt gebunden ist, wirkt auf alles darunter. Eine Richtlinie weiter unten kann nur hinzufügen — eine geerbte Rolle entfernt sie niemals. Wer Rechte wegnehmen will, löst die Bindung dort, wo sie gesetzt wurde, oder setzt eine Verweigerungsrichtlinie.

Verweigerungsrichtlinien (deny policies) hängen an Organisation, Ordner oder Projekt und benennen Hauptkonten und einzelne Berechtigungen. Sie werden vor den Zulassungsrichtlinien ausgewertet und haben Vorrang: Die genannte Berechtigung greift nicht, egal welche Rollen das Hauptkonto geerbt hat — der Weg, eine Berechtigung organisationsweit zu blockieren, ohne bestehende Rollenbindungen anzufassen.

Bedingungen (IAM Conditions) hängen an einer einzelnen Bindung und machen sie nur unter Umständen wirksam:

• request.time < timestamp("2026-12-31T00:00:00Z") — befristeter Zugriff, etwa für externe Prüfer. Die Bindung läuft von selbst aus, ohne Kalendereintrag und ohne Nacharbeit.
• resource.name.startsWith("projects/_/buckets/logs-") — die Rolle wirkt nur auf Ressourcen mit passendem Namen, obwohl sie auf dem Projekt gebunden ist. Für Cloud Storage funktioniert das nur, wenn am Bucket der einheitliche Zugriff auf Bucket-Ebene (uniform bucket-level access) eingeschaltet ist.
• Weitere Ausdrücke prüfen resource.type oder die Zugriffsebene des Aufrufers.

Geringste Rechte in der Praxis

Rechte gehören an Google-Gruppen, nicht an einzelne Personen: Die Bindung bleibt stehen, Ein- und Austritte ändern nur noch die Gruppenmitgliedschaft. Einzelbindungen müssten sonst bei jedem Wechsel in jeder Richtlinie nachgezogen werden. Drei Werkzeuge beantworten die typischen Fragen:

Aufgabe → passende Rolle:

Richtlinien mit gcloud ändern

Der entscheidende Unterschied: add-iam-policy-binding und remove-iam-policy-binding ändern genau eine Bindung und lassen alle anderen unberührt. set-iam-policy ersetzt die gesamte Richtlinie durch den Dateiinhalt — was dort fehlt, ist danach weg; sinnvoll nur beim geplanten Zurückspielen einer vollständigen Richtlinie, nie für eine einzelne Änderung.

Dieselben Unterbefehle gibt es auf jeder Ebene — gcloud organizations, gcloud resource-manager folders, gcloud projects — und je Dienst auf der Ressource selbst.

Dienstkonten

Ein Dienstkonto ist gleichzeitig Identität (es bekommt Rollen) und Ressource (auf ihm selbst liegt eine Richtlinie, die regelt, wer es benutzen darf). Es ist projektübergreifend verwendbar: Damit ein Dienstkonto aus Projekt A einen Bucket in Projekt B liest, wird es schlicht als Hauptkonto in der Richtlinie dieses Buckets gebunden — ein gleichnamiges Konto in Projekt B wäre eine andere Identität mit eigener E-Mail-Adresse.

• Standard-Dienstkonten von Compute Engine und App Engine entstehen automatisch und trugen historisch die Rolle Editor — viel zu weit. Für Arbeitslasten gilt: eigenes Dienstkonto anlegen, nur die nötige Rolle binden und es beim Erstellen der Instanz beziehungsweise beim Deployment eines Cloud-Run-Dienstes angeben. Wechseln lässt es sich nur an der beendeten Instanz: Dienstkonto und Zugriffsbereiche einer VM ändern sich nur im Zustand TERMINATED, ein neuer Schlüssel ist dafür nie nötig.
• Zugriffsbereiche (access scopes) sind der ältere Mechanismus auf VM-Ebene und begrenzen zusätzlich zur IAM-Rolle, welche APIs das angehängte Dienstkonto ansprechen darf. Wirksam ist die Schnittmenge aus Bereich und Rolle — die häufigste Ursache dafür, dass ein Aufruf trotz korrekt gebundener Rolle an fehlender Berechtigung scheitert. Heute: Bereich cloud-platform setzen und allein über enge IAM-Rollen steuern.
• Dienstkontoschlüssel (JSON-Dateien) sind langlebige Geheimnisse, werden kopiert, landen in Repositories und rotieren nicht von selbst — praktisch immer die falsche Antwort.
• Workload Identity Federation ersetzt sie für Arbeitslasten außerhalb von Google Cloud: Ein Identitätspool vertraut dem externen Anbieter, dessen Token wird gegen kurzlebige Google-Cloud-Anmeldedaten getauscht — der Weg für CI-Pipelines, die etwa Images nach Artifact Registry schieben. Workload Identity Federation for GKE tut dasselbe für einen Pod, indem es ein Kubernetes-Dienstkonto mit einer Google-Cloud-Identität verknüpft; das ist genauer als Zugriffsbereiche auf Knotenebene, die grob für alle Pods gelten.
• Identitätsübernahme (impersonation): Wer kurzzeitig unter der Identität eines Dienstkontos handeln soll, bekommt die Rolle Service Account Token Creator auf diesem Dienstkonto und erzeugt damit kurzlebige Anmeldedaten. Service Account Key Admin wäre das Gegenteil — es erlaubt gerade das Anlegen dauerhafter Schlüssel.
• Anwendungsstandardanmeldedaten (ADC): Clientbibliotheken ohne Anmeldedaten im Code suchen eine angehängte Dienstkonto-Identität und holen das Token vom Metadatenserver der Instanz. Deshalb funktioniert Code auf einer VM, in Cloud Run oder in GKE ohne jede Schlüsseldatei; lokal tritt gcloud auth application-default login an diese Stelle.

Geheimnisse, Zugang, Protokolle

• Secret Manager speichert Passwörter, Tokens und Zertifikate versioniert und verschlüsselt. Die Laufzeit-Identität des Dienstes braucht dafür genau die Rolle Secret Manager Secret Accessor auf diesem Secret — nicht auf dem Projekt und keinesfalls eine Admin-Rolle.
• Identity-Aware Proxy (IAP) prüft die Identität, bevor eine Anfrage die Anwendung erreicht. Für eine interne Webanwendung hinter einem externen Application Load Balancer sind zwei Schritte nötig: IAP für das Backend aktivieren und den Berechtigten die Rolle IAP-secured Web App User geben. Ergebnis: Zugang ohne VPN und ohne eigene Anmeldelogik.
• OS Login bindet Linux-Konten an Google-Identitäten und steuert SSH über die Rollen Compute OS Login und OS Admin Login statt über SSH-Schlüssel in den Projektmetadaten, die pauschal für alle Instanzen gelten. Aktiviert per Metadatum enable-oslogin=TRUE auf Projekt oder Instanz; Vorteil ist der zentrale Entzug beim Austritt. Hängt an der Instanz ein Dienstkonto, braucht der Anmeldende zusätzlich Service Account User.
• Organisationsrichtlinien setzen technische Leitplanken, die keine Rolle aushebeln kann: iam.disableServiceAccountKeyCreation verbietet neue Schlüssel organisationsweit, iam.allowedPolicyMemberDomains verhindert Bindungen an Konten fremder Domänen, und storage.publicAccessPrevention schließt öffentliche Buckets aus. Sie vergeben selbst keinen Zugriff — sie schränken ein.
• Cloud Audit Logs beantworten „wer hat wann was getan“. Admin Activity, System Event und Policy Denied laufen standardmäßig und lassen sich nicht abschalten, erfassen aber nur ändernde Verwaltungsaufrufe, Systemereignisse und abgelehnte Anfragen. Data Access — also lesende und schreibende Zugriffe auf Daten, etwa Objekte in Cloud Storage — ist außer bei BigQuery standardmäßig ausgeschaltet und muss je Dienst in der Audit-Log-Konfiguration eingeschaltet werden. Gelesen werden diese Einträge mit der Rolle Private Logs Viewer.

Stand September 2026: Die frühere „IAM-Richtlinie“ heißt jetzt Zulassungsrichtlinie, weil ihr die Verweigerungsrichtlinie gegenübersteht; „Mitglied“ (member) heißt Hauptkonto (principal). Das GKE-Verfahren heißt heute Workload Identity Federation for GKE (früher schlicht Workload Identity). In neu angelegten Organisationen erhalten Standard-Dienstkonten die Rolle Editor nicht mehr automatisch.

Was ist global, regional, zonal?

Verwechslungspaare

Stopp nötig oder nicht?

Zahlen, die sitzen müssen

• Speicherklassen und Mindesthaltedauer: Standard keine, Nearline 30 Tage, Coldline 90 Tage, Archive 365 Tage. Früher gelöscht heißt trotzdem bezahlt.
• Integritätsprüfungen von Google kommen aus 35.191.0.0/16 und 130.211.0.0/22 — beide müssen die Firewall passieren dürfen, sonst gilt jedes Back-End als ungesund.
• IAP-TCP-Weiterleitung kommt aus 35.235.240.0/20. Damit gibt es SSH ohne externe Adresse und ohne Bastionshost.
• Gelöschtes Projekt: rund 30 Tage wiederherstellbar mit gcloud projects undelete; die Projekt-ID bleibt danach für immer verbraucht.
• Implizite Firewallregeln: eingehend alles verboten, ausgehend alles erlaubt. Die kleinere Prioritätszahl gewinnt, und nach dem ersten Treffer wird nicht weitergesucht.

Befehle, die immer wieder vorkommen