Lernen

Die Prüfung auf einen Blick

Google Cloud Certified — Cloud Digital Leader ist die Einstiegszertifizierung von Google Cloud. Sie prüft Verständnis und Einordnung, nicht Konfiguration: Wozu dient ein Dienst, welches Geschäftsproblem löst er, und welcher Weg passt zu welcher Anforderung. Es wird kein einziger Befehl verlangt.

Stand September 2026. Die Prüfung wird nicht auf Deutsch angeboten — abgelegt wird sie auf Englisch. Deshalb gibt es hier jede Frage in beiden Sprachen: den Stoff auf Deutsch lernen, die Formulierungen auf Englisch üben. Die Gebühr steht auf der Google-Cloud-Zertifizierungsseite; für die Verlängerung gibt es eine kürzere Prüfung.

Keine veröffentlichte Bestehensgrenze: Google nennt weder Punktzahl noch Prozentwert. Die Simulation hier rechnet mit 70 %, wie es bei vergleichbaren Prüfungen üblich ist — als Richtwert, nicht als offizielle Angabe.

Die sechs Bereiche und ihr Gewicht

Fünf Bereiche sind fast gleich schwer gewichtet. Wer einen davon auslässt, verschenkt rund ein Fünftel der Prüfung — anders als bei Prüfungen mit einem dominanten Bereich gibt es hier keinen Schwerpunkt, auf den man sich zurückziehen kann.

Besonderheiten der Prüfung

• Geschäftssprache statt Technik: Die Fragen kommen aus der Sicht einer Organisation — Kosten, Geschwindigkeit, Risiko, Regulierung. Die richtige Antwort ist der Dienst, der das genannte Geschäftsproblem löst, nicht der technisch mächtigste.
• Dienstwahl statt Konfiguration: Gefragt wird „welcher Dienst“, nicht „welche Einstellung“. Ein Satz je Dienst reicht, wenn er die Abgrenzung zu den Nachbarn enthält.
• Mehrfachauswahl ist angekündigt („Choose two“). Ohne Ankündigung ist genau eine Antwort richtig.
• Kein Abzug fürs Raten. Keine Frage unbeantwortet lassen.
• Viele Namen, wenig Tiefe: Der Stoff ist breit. Die Prüfung belohnt, wer dreißig Dienste grob einordnen kann, mehr als den, der drei davon im Detail beherrscht.

Denkraster

1. Wer fragt? Fachbereich, Finanzen, Sicherheit oder Betrieb — das Stichwort im Szenario verrät, aus welchem Bereich die Antwort kommt.
2. Was ist die Anforderung? „Ohne eigene Server“, „ohne Programmierkenntnisse“, „Daten bleiben in Europa“, „in Echtzeit“ — jedes dieser Stichwörter schließt die Hälfte der Optionen aus.
3. Fertig oder selbst gebaut? Google Cloud hat für fast jede Aufgabe einen verwalteten Dienst. Eigenbau auf virtuellen Maschinen ist in dieser Prüfung fast nie die Antwort.
4. Passt der Dienst zur Datenform? Tabellen, Dokumente, Objekte, Ereignisse — die Datenform entscheidet zwischen Cloud SQL, Firestore, Cloud Storage und Pub/Sub.

Lernquellen

• Google Cloud Skills Boost: der kostenlose Lernpfad „Cloud Digital Leader“ mit kurzen Videos und Wissensprüfungen.
• Offizieller Prüfungsleitfaden („Exam guide“) mit der verbindlichen Themenliste je Abschnitt — die einzige Quelle, die zählt, wenn Lernmaterialien sich widersprechen.
• Kostenloser Beispieltest von Google, gut als Formatprobe.
• Produktseiten von Google Cloud: Für diese Prüfung genügt jeweils der erste Absatz — er beschreibt genau das Geschäftsproblem, nach dem gefragt wird.
• Generalprobe: Die Simulation hier zieht 50 Fragen nach Gewicht, mit 90-Minuten-Countdown.

Warum Organisationen in die Cloud gehen

Digitale Transformation ist keine Technikfrage. Sie liegt erst vor, wenn sich die Arbeitsweise ändert: aus monatlicher Auswertung wird fortlaufende Auswertung, aus Bauchgefühl werden datengestützte Entscheidungen, aus Projekten von Monaten werden Versuche von Tagen. Werden vorhandene Systeme unverändert in die Cloud kopiert (das reine Verschieben, oft „Lift and Shift“ genannt), ist das eine Migration, aber noch keine Transformation.

Typische Auslöser, die in Prüfungsszenarien als Stichwort auftauchen:

• Markteinführungszeit — Rechenleistung steht in Minuten bereit, statt über Beschaffung, Lieferzeit und Einbau zu laufen. Das ist der ausschlaggebende Vorteil, wenn im Szenario „in Tagen statt Monaten erproben“ steht.
• Auslaufender Rechenzentrumsvertrag oder Hardware am Lebensende — die Alternative wäre eine große Vorabinvestition in neue Server.
• Schwankende Last — Kapazität muss für Spitzen vorgehalten werden und liegt sonst brach.
• Neue Geschäftsmodelle, die ohne weltweite Reichweite, Datenauswertung oder künstliche Intelligenz nicht möglich wären.

Hindernisse, die dabei regelmäßig bremsen: fehlende Cloud-Kompetenz in den vorhandenen IT-Teams, eng verflochtene Altsysteme ohne saubere Schnittstellen, gewachsene Prozesse und Widerstand gegen Veränderung, unklare Vorgaben aus Regulierung und Datenschutz. Kurze Bereitstellungszeiten und eine genaue Kostenzuordnung sind dagegen Ergebnisse einer gelungenen Transformation und niemals das Hindernis — in Fragen mit dieser Formulierung sind sie die Ablenkung.

Die Kostenseite gehört zu den Auslösern und wird in eigenen Fragen geprüft:

• Investitionsausgaben (CapEx) — Hardware wird vorab gekauft und über Jahre abgeschrieben. Das ist das Modell des eigenen Rechenzentrums.
• Betriebsausgaben (OpEx) — laufender, nutzungsabhängiger Aufwand. Der Wechsel in die Cloud verschiebt Kosten von CapEx zu OpEx; die umgekehrte Richtung ist in Fragen stets die falsche Antwort.
• Verbrauchsabrechnung (Pay-as-you-go) — bezahlt wird, was tatsächlich genutzt wird, sekunden- oder minutengenau. Nicht genutzte Kapazität verursacht keine Kosten.
• Gesamtbetriebskosten (Total Cost of Ownership, TCO) — der ehrliche Vergleich umfasst neben dem Kaufpreis der Server auch Strom, Kühlung, Stellfläche, Netzanbindung, Wartung, Lizenzen und Betriebspersonal über die gesamte Nutzungsdauer. Wer nur den Anschaffungspreis betrachtet, rechnet das eigene Rechenzentrum künstlich günstig.

Betriebsmodelle: public, private, hybrid, multi

Die häufigste Verwechslung ist hybrid gegen multi: Sobald das eigene Rechenzentrum beteiligt ist, ist es hybrid; sind es mehrere fremde Clouds, ist es Multicloud. Für Multicloud sprechen vor allem zwei Gründe: geringere Abhängigkeit von einem einzelnen Anbieter und die Möglichkeit, je Aufgabe den passendsten Dienst zu wählen. Der Verwaltungsaufwand sinkt dabei nicht — er steigt, weil mehrere Plattformen betrieben und gesteuert werden müssen.

Servicemodelle und geteilte Verantwortung

Das Modell der geteilten Verantwortung verschiebt sich mit dem Servicemodell: Je mehr der Anbieter übernimmt, desto weniger bleibt beim Kunden — aber nie nichts. Physische Sicherheit der Rechenzentren liegt in jedem Modell bei Google. Daten, Identitäten und Zugriffsrechte liegen in jedem Modell beim Kunden. Dazwischen entscheidet die Ebene: Sicherheitsupdates im Gastbetriebssystem einer Compute-Engine-Instanz sind Kundensache, bei App Engine oder Workspace nicht.

Wer nur Code schreiben, aber keine Server patchen will, sucht PaaS. Wer das Betriebssystem selbst kontrollieren will, sucht IaaS. Wer eine fertige Anwendung im Browser nutzt, ist bei SaaS.

Ressourcenhierarchie und Vererbung

1. Organisation — der Wurzelknoten des Unternehmens; hier gesetzte Richtlinien gelten für alles darunter.
2. Ordner — gruppiert Projekte, etwa je Tochtergesellschaft, Abteilung oder Umgebung. Die richtige Ebene, wenn Richtlinien einmal gesetzt und an alle Projekte darunter vererbt werden sollen.
3. Projekt — die eigentliche Arbeitsgrenze: trägt Abrechnung, Kontingente, Zugriffsrechte und aktivierte Programmierschnittstellen.
4. Ressource — die virtuelle Maschine, der Storage-Bucket, die Datenbank. Jede Ressource gehört zu genau einem Projekt.

Richtlinien werden von oben nach unten vererbt; eine tiefere Ebene kann zusätzlich einschränken, aber eine von oben gesetzte Vorgabe nicht aufheben. Das Rechnungskonto ist keine Hierarchieebene: Es verknüpft Projekte mit der Zahlung und vererbt keine Zugriffsrichtlinien. Ordner und Organisation nehmen selbst keine einzelnen Ressourcen auf — dafür ist ausschließlich das Projekt zuständig.

Regionen, Zonen und der Ort der Daten

• Region — ein geografisches Gebiet mit mehreren Zonen. Sie bestimmt die Entfernung zu den Nutzern (Latenz) und das Land, in dem die Daten physisch liegen.
• Zone — eine isolierte Ausfalldomäne innerhalb einer Region. Mehrere Zonen überstehen den Ausfall einer einzelnen.
• Latenzproblem → zusätzliche Region nahe den Nutzern. Mehr Zonen in Europa verkürzen den Weg nach Asien nicht, größere Maschinen ebenso wenig.
• Ausfallsicherheit innerhalb einer Region → Verteilung über mehrere Zonen. Zusätzliche Server in derselben Zone fallen mit dieser Zone gemeinsam aus.
• Datenresidenz → Wahl der Region. Speicherklasse, Maschinentyp und Rechnungskonto haben keinen Einfluss auf den geografischen Standort.

Datenresidenz gegen Datenhoheit: Datenresidenz beschreibt nur, wo Daten physisch gespeichert sind. Datenhoheit (Data Sovereignty) geht weiter: Die Daten unterliegen dem Recht des Landes, in dem sie liegen, einschließlich möglicher behördlicher Zugriffsrechte. Eine Frage nach dem Speicherort zielt auf Residenz, eine Frage nach der geltenden Rechtsordnung auf Hoheit.

Nachhaltigkeit, offene Standards, hybride Betriebsmodelle

Nachhaltigkeit: Googles Rechenzentren sind auf hohe Energieeffizienz ausgelegt, und der Stromverbrauch wird durch den Einkauf erneuerbarer Energie gedeckt. Die Emissionen je Arbeitslast fallen dadurch deutlich niedriger aus als in typischen firmeneigenen Serverräumen. Aussagen wie „ohne Strom aus dem öffentlichen Netz“ oder „ganz ohne Kühlung“ sind Übertreibungen und in Fragen stets falsch.

Offene Standards: Googles erklärte Position ist Portabilität. Wer Anwendungen auf offene Standards und Open-Source-Software wie Kubernetes, TensorFlow oder Apache Beam stützt, kann sie später in einer anderen Umgebung betreiben und verringert damit die Anbieterbindung (Vendor Lock-in) am stärksten. Eine Verteilung auf mehrere Projekte desselben Anbieters oder größere Maschinentypen ändert an der Bindung nichts.

Stand September 2026: Die frühere Sammelmarke „Anthos“ wird nicht mehr verwendet. Ältere Lernmaterialien nennen für dieselben Aufgaben noch Anthos — gemeint sind heute GKE Enterprise und Google Distributed Cloud.

Elastizität, Skalierbarkeit und die Rollen im Vorhaben

Skalierbarkeit ist die Fähigkeit, Kapazität überhaupt zu verändern — vertikal durch größere Maschinen, horizontal durch mehr Maschinen. Elastizität ist das automatische Hoch- und Herunterskalieren nach tatsächlichem Bedarf; sie erklärt, warum ein Nachrichtenportal Großereignisse abfängt und danach wieder auf Normallast zurückfällt, ohne dauerhaft für die Spitze zu bezahlen. Infrastruktur als Code ergänzt beides: Umgebungen entstehen aus versionierten Vorlagen statt aus Klicks in der Konsole, wodurch Test und Produktion nicht mehr auseinanderlaufen. Manuelle Checklisten leisten das nicht.

Wert, Hindernisse, Datenformen

Daten sind für sich genommen wertlos. Wert entsteht erst, wenn sie zusammengeführt, ausgewertet und in Entscheidungen überführt werden. Die Prüfung beschreibt dazu regelmäßig eine Organisation, die Daten zwar besitzt, aber nicht nutzt — und fragt, woran das liegt. Drei Hindernisse tauchen immer wieder auf:

• Datensilos — jede Abteilung pflegt eigene Systeme, die nicht miteinander verbunden sind. Die Daten sind vollständig vorhanden, eine abteilungsübergreifende Auswertung ist trotzdem unmöglich. Stichwort im Szenario: „getrennte Anwendungen“, „kein Gesamtbild“.
• Mangelnde Datenqualität — Felder fehlen, Schreibweisen weichen ab, Datensätze sind doppelt. Hier sind die Daten verbunden, aber inhaltlich unbrauchbar. Stichwort: „unvollständig“, „uneinheitlich“.
• Ungenutzte Daten (dark data) — alles ist da und in Ordnung, wird aber nie ausgewertet, etwa Archivdateien, die seit Jahren nur liegen. Die Antwort ist dann nicht billigerer Speicher, sondern Zusammenführen und Analysieren.

Strukturierte Daten folgen einem festen Schema aus Zeilen und Spalten — Bestellungen, Konten, Stammdaten. Sie gehören in relationale Datenbanken oder ein Data Warehouse. Unstrukturierte Daten haben kein Schema — Video, Audio, Bilder, gescannte Akten, Freitext. Sie gehören als Objekte in Cloud Storage. Dazwischen liegen halbstrukturierte Daten wie JSON-Dokumente oder Ereignisse, die zwar Felder haben, deren Aufbau sich aber je Datensatz unterscheiden darf.

Der Datenlebenszyklus läuft in fünf Schritten. Prüfungsfragen beschreiben einen Zustand und fragen, welcher Schritt noch aussteht:

1. Erfassen (ingest) — Daten aufnehmen, aus Anwendungen, Sensoren, Dateien oder Fremdsystemen.
2. Speichern (store) — dauerhaft und in der passenden Form ablegen.
3. Verarbeiten (process) — bereinigen, vereinheitlichen, zusammenführen, für die Auswertung aufbereiten.
4. Analysieren (analyze) — Muster und Kennzahlen gewinnen, Modelle rechnen, Berichte erstellen.
5. Aktivieren (activate) — die Erkenntnis in Produkten, Prozessen und Entscheidungen wirksam machen. Ein Bericht, der nur in der Analyseabteilung liegt, hat diesen Schritt noch nicht erreicht.

Cloud Storage und die Speicherklassen

Cloud Storage ist der Objektspeicher: Dateien beliebiger Art liegen als Objekte in Buckets. Die Speicherklasse entscheidet über den Preis, und der Hebel ist immer die Zugriffshäufigkeit, nicht die Dateigröße. Je kälter die Klasse, desto günstiger der Speicher, desto teurer jeder Abruf — und desto länger die Mindestspeicherdauer, die auch bei früherem Löschen berechnet wird.

Die Zuordnung gelingt über einen einzigen Satz im Szenario: monatlich → Nearline, vierteljährlich → Coldline, Archivierung ohne erwarteten Zugriff → Archive. Daten, die schon nach zwei Wochen gelöscht werden, gehören trotz des niedrigen Speicherpreises in Standard: Coldline berechnet die vollen 90 Tage. Verschlüsselung im Ruhezustand erfolgt in allen Klassen automatisch und ist nie das Unterscheidungsmerkmal.

Objektlebenszyklusregeln (Object Lifecycle Management) wechseln die Klasse oder löschen Objekte automatisch nach Alter — die richtige Antwort immer dann, wenn im Szenario „geringster Verwaltungsaufwand“ steht. Ein geplantes Skript, das Objekte umkopiert, erreicht dasselbe mit mehr Aufwand und mehr Fehlern.

Die Datenbanken im Vergleich

Auswerten: BigQuery und die Berichte

BigQuery ist das serverlose Data Warehouse: keine Infrastruktur bereitzustellen, keine Datenbankadministration, Abfragen in vertrautem SQL über sehr große Datenmengen. Es ist die Antwort, wenn verstreute oder bislang ungenutzte Bestände gemeinsam ausgewertet werden sollen — und ausdrücklich nicht die Antwort für Transaktionen eines Kassen- oder Buchungssystems.

• BigQuery ML — Modelle mit SQL-Anweisungen dort trainieren und anwenden, wo die Daten bereits liegen. Für Fachleute, die SQL beherrschen, aber kein Python, und wenn die Daten das Warehouse nicht verlassen sollen. Das Gegenstück wäre ein Training auf der Agent Platform (früher Vertex AI), das Datenbewegung und mehr Kenntnisse verlangt.
• BI Engine — In-Memory-Beschleunigung für wiederkehrende Abfragen aus Dashboards. Richtige Antwort, wenn viele Personen dieselben Aggregationen abrufen und Berichte ohne Umbau schneller werden sollen.

Looker gegen Looker Studio ist eine Standardabgrenzung: Looker modelliert Kennzahlen zentral in einer Semantikschicht (LookML), sodass alle Berichte im Unternehmen dieselbe Definition von „Umsatz je Kunde“ verwenden — die Antwort bei widersprüchlichen Zahlen aus verschiedenen Abteilungen. Looker Studio ist das leichte Selbstbedienungswerkzeug: rasch ein Diagramm auf eine Datenquelle legen und den Link teilen, ohne verbindliches Modell und ohne Beteiligung der IT.

Daten bewegen: Ereignisse, Pipelines, Replikation

Streaming verarbeitet jedes Ereignis fortlaufend und liefert Ergebnisse in Sekunden — verlangt im Szenario durch „in Echtzeit“, „sofort melden“, „nahezu aktuell“. Batch verarbeitet gesammelte Mengen in Läufen und liefert Ergebnisse erst nach Ablauf des Intervalls; ein nächtlicher Stapellauf bleibt Batch, auch wenn er häufiger angestoßen wird.

Abzugrenzen sind zwei Dienste, die nur planen und steuern: Cloud Composer orchestriert Abläufe, verlangt aber in Python beschriebene Workflows; Cloud Scheduler stößt Aufgaben zeitgesteuert an. Beide verarbeiten selbst keine Daten. Das Standardmuster für Echtzeit lautet: Pub/Sub nimmt entgegen, Dataflow verarbeitet, BigQuery wertet aus.

Ordnung halten: Data Lake, Warehouse, Governance

• Dataplex — Katalog, Metadaten, Qualitäts- und Zugriffsregeln über verteilte Bestände hinweg. Die Antwort, wenn der Überblick fehlt: welche Daten existieren, wer verantwortet sie, welche Regeln gelten. Dataplex beschreibt und steuert, bewegt aber selbst keine Daten.
• BigLake — macht Dateien in offenen Formaten wie Parquet in Cloud Storage über BigQuery abfragbar, mit einheitlicher Zugriffssteuerung und ohne vorheriges Laden. Lake und Warehouse werden so mit denselben Abfragen und denselben Rechten genutzt.
• Datenqualität geht man an der Wurzel an: Datensätze bereinigen und vereinheitlichen, dann Qualitätsregeln festlegen und laufend überwachen, etwa mit Dataplex. Mehr Rechenleistung, eine andere Speicherklasse oder ein schöneres Dashboard ändern an fehlenden Werten nichts.
• Data Governance beantwortet, wer welche Daten sehen darf, wie lange sie aufbewahrt werden und wo sie liegen dürfen (Datenresidenz) — eine Frage der Regeln, nicht der Technik.

Welche Anforderung führt zu welchem Dienst

Stand September 2026: Die Agent Platform (früher Vertex AI) ist der Ort für eigenes Modelltraining; BigQuery ML behält seinen Namen und bleibt die Antwort, wenn Modelle im Data Warehouse und in SQL entstehen sollen. Looker und Looker Studio sind zwei getrennte Produkte und werden es bleiben — der ähnliche Name ist die häufigste Falle dieses Bereichs.

Vier Begriffe, vier Ebenen

Die Prüfung verlangt die saubere Einordnung der Begriffe ineinander — sie liegen wie Schalen umeinander, nicht nebeneinander.

Typische Prüfungsszene: handgeschriebene Regeln, die ständig veralten. Der Übergang zum maschinellen Lernen heißt, dass das Modell die Muster aus den historischen Daten lernt — weitere Schwellenwerte zu ergänzen bleibt regelbasierte Programmierung, ein Dashboard oder eine Datenbank ist Darstellung beziehungsweise Ablage, aber keine KI.

Wie ein Modell lernt

• Überwachtes Lernen — es gibt gelabelte Beispiele: bereits eingestufte Vorgänge, E-Mails mit Kategorie, Fotos mit Bezeichnung. Daraus lernt das Modell den Zusammenhang zwischen Eingabe und Antwort. Teilaufgaben: Klassifikation (in vorgegebene Kategorien einsortieren) und Regression (eine Zahl vorhersagen, etwa den Umsatz des nächsten Quartals).
• Unüberwachtes Lernen — es gibt keine Labels, nur Rohdaten. Das Modell findet Strukturen: Clustering (Kunden nach Kaufverhalten gruppieren) und Anomalieerkennung (ungewöhnliche Transaktionsmuster ohne Vorgabe aufspüren).
• Bestärkendes Lernen — ein System lernt durch Belohnung für gute Handlungsfolgen; in dieser Prüfung eher Abgrenzungsoption als Lösungsweg.

Training, Inferenz und die Daten dahinter

1. Datenaufbereitung — Rohdaten zusammenführen, bereinigen, Dubletten entfernen, fehlende Pflichtfelder klären.
2. Merkmalsbildung (Feature Engineering) — aus den Rohdaten die Eingangsgrößen berechnen, mit denen das Modell arbeitet.
3. Training — das Modell passt anhand der Beispiele seine Parameter an; rechenintensiv, einmalig oder in festen Abständen wiederholt.
4. Auswertung — die Güte wird auf zurückgehaltenen Daten gemessen, nicht auf den Trainingsdaten.
5. Inferenz (Vorhersage) — das fertige Modell wird auf neue Daten angewendet, etwa auf jedes neue Kamerabild in der Fertigung. Läuft dauerhaft im Betrieb.

Die Trainingsdaten entscheiden über das Ergebnis, nicht die Rechenleistung. Vier Stichwörter der Prüfung:

Mehr Rechenleistung oder mehr Trainingsdurchläufe verlängern nur den Lauf und gleichen eine schiefe Datengrundlage nicht aus. Latenz ist die Antwortzeit und sagt nichts über die Vorhersagegüte.

Verantwortungsvolle KI, Datenschutz und Datenhoheit

Von Googles Grundsätzen für verantwortungsvolle KI (Responsible AI) zählen für die Prüfung die Leitgedanken, nicht der Wortlaut: gesellschaftlicher Nutzen, Vermeidung unfairer Verzerrung, Sicherheit im Betrieb, Rechenschaftspflicht gegenüber Menschen, Datenschutz im Entwurf, wissenschaftliche Sorgfalt und Beschränkung auf zulässige Einsatzzwecke.

• Menschliche Aufsicht (human in the loop) — bei folgenreichen Entscheidungen wie Kreditablehnungen, Schadensregulierung oder Personalauswahl prüft ein Mensch, bevor die Entscheidung wirksam wird. Ein Modell allein entscheiden zu lassen, widerspricht den Grundsätzen.
• Transparenz — Grenzen und Fehlerquote eines Modells werden offengelegt, nicht verschwiegen.
• Fairness — Trainingsdaten werden regelmäßig auf Verzerrungen geprüft, Merkmale werden bewusst ausgewählt statt ungeprüft übernommen.
• Datenhoheit — Region und Speicherort der Daten lassen sich festlegen; Vorgaben zu Datenresidenz und Verschlüsselung gelten für KI-Dienste wie für jede andere Last.

Die Gemini Enterprise Agent Platform

Die gemeinsame Plattform für KI in Google Cloud heißt Gemini Enterprise Agent Platform (früher Vertex AI), kurz Agent Platform. Sie deckt den gesamten Weg von der Idee bis zum laufenden Modell ab.

Stand September 2026: Vertex AI wurde am 22. April 2026 in Gemini Enterprise Agent Platform umbenannt; aus Vertex AI Studio wurde Agent Studio, aus Vertex AI Search wurde Agent Search, aus Vertex AI Training wurde Managed Training. Ältere Lernmaterialien und Prüfungsfragen nennen vielfach noch die alten Namen — gemeint ist derselbe Dienst. BigQuery ML, Gemini Code Assist und die vortrainierten APIs behalten ihre Bezeichnungen.

Fertige API, AutoML oder eigenes Training

Die häufigste Entscheidungsfrage des Bereichs. Die Reihenfolge ist immer dieselbe: so fertig wie möglich, so eigen wie nötig.

Die vortrainierten APIs im Einzelnen — sie sind sofort aufrufbar, ohne Trainingsdaten und ohne Modellpflege:

Gemini, Grounding und agentische KI

• Gemini ist Googles Familie multimodaler Basismodelle in verschiedenen Größen, nutzbar über die Agent Platform und Grundlage der fertigen Gemini-Angebote.
• Gemini für Google Workspace — generative Unterstützung direkt in Gmail, Docs und den übrigen Büroanwendungen: lange Verläufe zusammenfassen, Entwürfe schreiben. Zielgruppe: Fachbereiche.
• Gemini Code Assist (Teil von Gemini für Google Cloud) — Code und Cloud-Konfigurationen schreiben, erklären und verstehen. Zielgruppe: technische Rollen; nicht mit Workspace verwechseln.
• Gemini Enterprise for Customer Experience (früher Contact Center AI) — virtuelle Agenten lösen einfache Anliegen selbst, Agent Assist blendet Mitarbeitern im laufenden Gespräch Vorschläge ein.

Grounding bedeutet, die Antwort eines generativen Modells auf überprüfbare Quellen zu stützen, statt sie frei erzeugen zu lassen. Der übliche Weg dorthin ist Retrieval-Augmented Generation (RAG) und läuft in zwei Schritten:

1. Die eigenen Dokumente werden als Vektor-Embeddings abgelegt — Zahlenfolgen, die die Bedeutung eines Textstücks abbilden, sodass inhaltlich ähnliche Stellen nah beieinander liegen und durchsuchbar werden.
2. Zu einer Frage werden nur die passenden Textstellen gesucht und dem Prompt als Kontext beigegeben. Das Modell antwortet daraufhin auf Grundlage dieser Stellen.

Weder wird dabei ein Basismodell neu trainiert, noch werden sämtliche Dokumente bei jeder Anfrage übergeben, noch braucht es je Dokument ein eigenes Modell — das sind die typischen Falschoptionen.

Agentische KI geht einen Schritt weiter als ein antwortender Assistent: Das System zerlegt ein Ziel in Schritte, ruft dafür Werkzeuge und Fachanwendungen auf — Daten im CRM anlegen, Termine prüfen, Rückrufe auslösen — und bringt den Vorgang eigenständig zu Ende. Abzugrenzen von Business Intelligence, die vorhandene Kennzahlen aufbereitet, aber keine Vorgänge ausführt.

BigQuery ML schließlich bringt maschinelles Lernen dorthin, wo die Daten schon liegen: Modelle für Prognose, Klassifikation oder Clustering entstehen mit gewohnten SQL-Anweisungen im Data Warehouse, ohne Datenbewegung und ohne Programmierkenntnisse jenseits von SQL.

Warum überhaupt modernisiert wird

Die Prüfung fragt nach dem geschäftlichen Grund, nicht nach dem technischen. Eine Anwendung, die seit fünfzehn Jahren läuft, ist kein Argument gegen Modernisierung — teuer ist sie trotzdem:

• Pflegeaufwand bindet Budget und Leute. Wer Hardware, Betriebssysteme und Patches selbst verantwortet, hat diese Stunden nicht für neue Funktionen.
• Starre Kapazität. Im eigenen Rechenzentrum wird Hardware für die Spitzenlast gekauft und läuft den Rest des Jahres halb leer; nach oben ist bei der gekauften Größe Schluss.
• Langsame Markteinführung. Jede Änderung am Monolithen erzwingt einen kompletten Rollout, also lange Testzyklen und seltene Releases.
• Auslaufende Verträge und Hardware. Ein endender Rechenzentrumsmietvertrag oder abgekündigte Server setzen den Termin, nicht die Technik.

Falsch sind dagegen zwei beliebte Behauptungen: Betriebskosten entfallen nach einer Migration nicht, sie ändern nur ihre Form — aus Abschreibung wird laufende Nutzungsabrechnung. Und Modernisierung ist kein Personalabbauprogramm; sie verschiebt Aufwand von der Wartung zur Entwicklung.

Die drei Migrationspfade und ihre Werkzeuge

Der Aufwand steigt von oben nach unten, der Nutzen ebenfalls. Unter Termindruck ist die Antwort fast immer der obere Pfad; ist im Szenario von unabhängiger Auslieferung oder getrennter Skalierung einzelner Teile die Rede, der untere. Ein vierter, oft übersehener Pfad ist das Abschalten (Retirement) von Anwendungen, die niemand mehr braucht.

Für den Umzug selbst stehen drei Dienste bereit, die in der Prüfung regelmäßig gegeneinander ausgespielt werden:

Die Compute-Optionen und ihr Trennsatz

Stand September 2026: Cloud Run functions heißt so seit der Zusammenführung mit Cloud Run; ältere Lernmaterialien nennen den Dienst noch „Cloud Functions“. Container-Images liegen in der Artifact Registry, nicht mehr in der abgelösten Container Registry.

Als Entscheidungshilfe, gelesen vom Stichwort im Szenario zur Antwort:

Container, Microservices, serverlos

Container gegen virtuelle Maschine: Eine virtuelle Maschine bringt ein eigenes vollständiges Betriebssystem mit. Container teilen sich den Kernel des Hostsystems und enthalten nur die Anwendung samt ihren Abhängigkeiten. Daraus folgt alles Weitere: Container sind schlanker, starten in Sekunden statt Minuten und lassen sich dichter auf dieselbe Hardware packen. Eigene physische Server brauchen sie nicht, und gegen doppelte Arbeit im Team helfen sie auch nicht — sie lösen ein Verpackungsproblem, kein Organisationsproblem.

Monolith gegen Microservices: Im Monolithen hängt alles an einer Auslieferung — jede Änderung am kleinsten Modul erzwingt den kompletten Rollout, und skaliert wird nur das Ganze. Microservices sind unabhängig ausrollbar und einzeln skalierbar: Das Zahlungsmodul kann zur Spitzenzeit wachsen, während der Rest unverändert bleibt. Größere Maschinen lösen dieses Problem nicht; sie erhöhen nur die Gesamtleistung. Der Preis sind mehr bewegliche Teile und aufwendigere Beobachtung des Gesamtsystems.

Serverlos als Modell: Server verschwinden nicht — sie werden nur nicht mehr vom Kunden bereitgestellt, skaliert und gepflegt. Google übernimmt Bereitstellung, Skalierung und Wartung der darunterliegenden Infrastruktur, das Team verantwortet den Code. Abgerechnet wird nach tatsächlicher Nutzung, nicht nach vorgehaltener Kapazität. Serverlos in Google Cloud heißt in dieser Prüfung vor allem Cloud Run, Cloud Run functions und App Engine.

Hybrid und Multicloud

Von hybrid spricht man, wenn Arbeitslasten im eigenen Rechenzentrum und in der Cloud laufen, von Multicloud, wenn mehrere Cloud-Anbieter beteiligt sind. Die geschäftlichen Gründe, die in der Prüfung zählen:

• Geringere Bindung an einen einzigen Anbieter (Vendor Lock-in) und verteiltes Risiko.
• Vorhandene Investitionen bleiben nutzbar — bereits bezahlte Hardware läuft weiter.
• Rechtliche Auflagen und Datenhoheit — bestimmte Daten dürfen den Standort nicht verlassen.
• Latenz am Ort des Geschehens — Verarbeitung in der Fabrik oder Filiale statt in der Region.

Was dieses Modell ausdrücklich nicht bringt: einfacheren Betrieb. Mehrere Umgebungen müssen weiterhin verwaltet werden, und Lizenzkosten entfallen dabei nicht.

Stand September 2026: Beide Angebote hießen früher Anthos. Ältere Fragen und Lernmaterialien verwenden noch diesen Namen.

Kostenhebel in der Infrastruktur

Die Hebel schließen sich nicht aus: Grundlast über Committed Use Discounts absichern, Spitzen über bedarfsgesteuerte Skalierung abfangen, unterbrechbare Lasten auf Spot-VMs legen und die Größen regelmäßig nach den Empfehlungen korrigieren.

Schnittstellen als Produkt und Apigee

Eine Schnittstelle (API) ist zunächst der Weg, auf dem Systeme miteinander sprechen. Sie wird zum Produkt, sobald ein Unternehmen sie nach außen anbietet: mit Entwicklerportal, Zugangsschlüsseln und Abrechnung nach Nutzung. Wer seine Sendungsverfolgung so bereitstellt, eröffnet eine neue Einnahmequelle — die Schnittstelle selbst ist das Verkaufte, nicht ein Nebenprodukt der Anwendung. Die rein interne Nutzung zwischen Abteilungen ist das Gegenmodell.

Apigee ist die API-Management-Plattform von Google Cloud und deckt den gesamten Lebenszyklus ab:

• Entwicklerportal — Dokumentation, Selbstregistrierung und Zugangsschlüssel für externe Entwickler.
• Versionierung — mehrere Fassungen einer Schnittstelle parallel betreiben und alte geordnet auslaufen lassen.
• Zugangskontrolle und Nutzungsgrenzen — wer darf zugreifen, mit welchen Kontingenten (Quotas) und Ratenbegrenzungen.
• Nutzungsauswertung — Berichte und Kennzahlen darüber, wer welche Schnittstelle wie oft aufruft; Grundlage für Abrechnung und Produktentscheidungen.

Abgrenzung: Cloud Armor wehrt Angriffe auf Webanwendungen ab, verwaltet aber keine Schnittstellen. Cloud CDN speichert Inhalte am Rand des Netzes zwischen. Cloud Run ist die Laufzeit, auf der die Schnittstelle ausgeführt wird — Apigee liegt davor und steuert den Zugang.

Bedrohungen und Schutzziele

Die Fragen dieses Bereichs beginnen fast immer mit einem geschilderten Vorfall. Der erste Schritt ist das Benennen der Bedrohungsart — daraus folgt die passende Gegenmaßnahme.

Darüber liegen die drei klassischen Schutzziele. Jede Maßnahme zahlt auf genau eines davon ein, und Prüfungsfragen fragen oft, auf welches:

• Vertraulichkeit — nur Berechtigte sehen die Daten. Beispiele: IAM, Verschlüsselung, kundenverwaltete Schlüssel, Maskierung sensibler Felder.
• Integrität — Daten bleiben unverändert und nachweislich korrekt. Beispiele: Prüfsummen, sicherer Startvorgang der Hardware, Schutz vor unbemerkter Änderung.
• Verfügbarkeit — die Daten und der Dienst sind erreichbar, wenn sie gebraucht werden. Beispiele: Verteilung über mehrere Zonen, Abwehr von Überlastungsangriffen, Sicherungen.

Die Nachvollziehbarkeit — wer hat wann was getan — gehört nicht zu den drei Zielen, wird in Antwortoptionen aber gern danebengestellt. Sie beschreibt Protokollierung, nicht Schutz.

Geteilte Verantwortung und geteiltes Schicksal

Sicherheit in der Cloud ist nie vollständig Sache eines der beiden Beteiligten. Die Grenze verschiebt sich mit dem Betriebsmodell: Je mehr Google übernimmt, desto weniger bleibt beim Kunden.

Zwei Punkte bleiben in jedem Modell beim Kunden: die Daten und die Vergabe der Zugriffsrechte. Ein Szenario mit virtuellen Maschinen, in dem nach Sicherheitsupdates des Gastbetriebssystems gefragt wird, hat deshalb immer dieselbe Antwort — das Kundenteam.

Geteiltes Schicksal (shared fate) ist Googles Erweiterung dieses Modells: Statt die Grenze nur zu benennen, unterstützt Google aktiv mit abgesicherten Standardkonfigurationen, Blueprints und Vorlagen, Empfehlungen in der Konsole sowie Absicherungs- und Risikoschutzprogrammen — und trägt das Risiko mit. Wenn eine Frage Vorlagen, Empfehlungen und Absicherung nennt, ist geteiltes Schicksal gemeint, nicht Zero Trust und nicht Defense in Depth.

Zero Trust, IAM und Dienstkonten

Zero Trust gibt die Vorstellung auf, das Firmennetz sei vertrauenswürdig. Der Standort im Netz entscheidet nicht mehr über den Zugriff; jede einzelne Anfrage wird anhand von Identität, Gerätezustand und Kontext neu bewertet. Das Gegenmodell heißt Perimetersicherheit — Schutz allein an der Netzgrenze, innen alles offen. Ergänzend gilt das Prinzip der geringsten Rechte (least privilege): genau so viele Berechtigungen wie für die Aufgabe nötig, nicht mehr.

Identity-Aware Proxy (IAP) ist die praktische Umsetzung für Anwendungszugang. Er sitzt vor einer internen Anwendung — etwa in Cloud Run, App Engine oder hinter einem Load Balancer — und prüft jede Anfrage gegen Identität und IAM-Richtlinie. Beschäftigte kommen so ohne VPN an interne Anwendungen — die Abgrenzung zu Cloud VPN, dem netzbasierten und damit gerade nicht gemeinten Weg. Für einen öffentlichen Shop ohne Anmeldung ist IAP ungeeignet.

Cloud IAM beantwortet „wer darf was auf welcher Ressource“ mit drei Begriffen:

1. Hauptkonto (principal) — die Identität: eine Person, eine Google-Gruppe, ein Dienstkonto oder eine ganze Domain.
2. Rolle — eine Sammlung von Berechtigungen für eine Aufgabe. Berechtigungen werden nie einzeln vergeben, sondern immer über eine Rolle.
3. Zulassungsrichtlinie (allow policy) — die Bindung, die eine Rolle einem Hauptkonto auf einer Ressource zuweist.

Es gibt drei Rollenarten: einfache Rollen (Betrachter, Bearbeiter, Inhaber) sind sehr weit und stammen aus der Frühzeit — in Prüfungsfragen praktisch nie die richtige Antwort. Vordefinierte Rollen sind pro Dienst zugeschnitten (etwa eine reine Leserolle für Protokolle) und der Normalfall. Benutzerdefinierte Rollen baut man selbst, wenn keine vordefinierte passt.

Richtlinien werden entlang der Ressourcenhierarchie nach unten vererbt: Organisation → Ordner → Projekt → Ressource. Eine Rolle, die einer Gruppe auf Ordnerebene zugewiesen wird, wirkt damit in allen Projekten und Ressourcen unterhalb dieses Ordners; eine erneute Bindung je Projekt ist nicht nötig. Weitreichende Rollen gehören deshalb nicht nach oben. Zwei Empfehlungen tauchen regelmäßig als richtige Antwort auf: Rollen an Google-Gruppen binden statt an einzelne Konten, weil Wechsel und Neuzugänge dann über die Mitgliedschaft laufen, und vordefinierte statt einfache Rollen verwenden.

Dienstkonten sind Identitäten für Anwendungen und Arbeitslasten, nicht für Menschen. Eine Anwendung auf einer Compute Engine-Instanz, die Objekte in Cloud Storage lesen soll, bekommt ein an die Instanz gebundenes Dienstkonto mit passender Leserolle und erhält darüber kurzlebige Anmeldedaten. Falsch sind stets: Nutzerzugangsdaten in der Anwendung hinterlegen, einen Dienstkontoschlüssel im Quellcode ablegen, den Bucket öffentlich lesbar machen — oder ein Dienstkonto je Person statt eines persönlichen Kontos.

Organisationsrichtlinien (Organization Policies) sind die zweite, davon unabhängige Ebene: Sie setzen Leitplanken für die Ressourcen selbst, auf Organisations-, Ordner- oder Projektebene. Die Einschränkung zulässiger Ressourcenstandorte verhindert, dass überhaupt Ressourcen außerhalb erlaubter Regionen entstehen — verbindlich für alle Projekte darunter. IAM regelt, wer etwas darf; eine Organisationsrichtlinie, was überhaupt erlaubt ist.

Mehrstufige Authentifizierung (MFA) verlangt einen zweiten Faktor neben dem Passwort, doch nicht alle Faktoren sind gleich stark: Einmalcodes per SMS oder App lassen sich abfangen und in Echtzeit weiterverwenden. Sicherheitsschlüssel wie der Titan Security Key sind phishingresistent, weil sie kryptografisch an die echte Domain gebunden sind und auf einer nachgebauten Seite nicht funktionieren — für privilegierte Konten die stärkste verfügbare Maßnahme.

Verschlüsselung, Schlüssel und Geheimnisse

Google Cloud verschlüsselt Daten im Ruhezustand standardmäßig, in allen Speicherdiensten, ohne dass die Kundschaft etwas einrichten muss. Ebenso werden Daten bei der Übertragung geschützt, insbesondere zwischen den Rechenzentren von Google. Es braucht dafür keinen angelegten Schlüssel, keine Beschränkung auf einen einzelnen Dienst und kein zusätzliches Produkt.

Die Formulierung in der Frage entscheidet: Wer Schlüssel selbst erzeugen, rotieren und deaktivieren können muss, braucht Cloud KMS mit kundenverwalteten Schlüsseln. Die Standardverschlüsselung genügt dann nicht, weil dort Google die Schlüssel hält.

Secret Manager ist etwas anderes und wird oft danebengestellt: Er ist die zentrale Ablage für Geheimnisse — Datenbankpasswörter, API-Schlüssel, Zertifikate. Die Werte liegen verschlüsselt, sind versioniert, lassen sich rotieren, und der Zugriff läuft über IAM. Damit verschwinden Passwörter aus Konfigurationsdateien und Quellcode. Cloud KMS verwaltet Schlüssel, Secret Manager verwahrt Werte. Ein privater Bucket in Cloud Storage ist für beides nicht der vorgesehene Weg.

Netzschutz und Datenabfluss

Vier Dienste in diesem Bereich lösen vier klar verschiedene Probleme und werden in Prüfungsfragen systematisch gegeneinander ausgespielt.

Zwei Abgrenzungen lohnen sich besonders: Firewallregeln entscheiden über Netzwerkverkehr, IAM über Berechtigungen von Identitäten — eine Frage nach einem erlaubten IP-Bereich ist nie eine IAM-Frage. Und Cloud NAT ist nicht Private Google Access: NAT führt ausgehenden Verkehr über öffentliche Adressen ins Internet, Private Google Access vermeidet das öffentliche Internet gerade.

Standardmäßig blockiert das VPC-Netzwerk eingehenden Verkehr und erlaubt ausgehenden. Wer einen Verwaltungsport öffnen will, legt dafür ausdrücklich eine Eingangsregel an — eng auf den nötigen Quellbereich begrenzt.

Sichtbarkeit, Compliance und physische Sicherheit

• Security Command Center — die zentrale Sicherheitsoberfläche. Sie führt eine Bestandsaufnahme der vorhandenen Ressourcen und meldet Fehlkonfigurationen, Schwachstellen und Bedrohungen an einer Stelle. Sie verwaltet keine Schlüssel und rechnet nichts ab.
• Cloud Audit Logs — die Frage „wer hat wann was geändert“. Die Administratoraktivitätsprotokolle zeichnen Konfigurations- und Berechtigungsänderungen auf, etwa die Änderung einer IAM-Rolle, und sind die Quelle für interne Prüfungen. Abzugrenzen von Cloud Monitoring, das Messwerte zum Zustand von Ressourcen sammelt, nicht die Urheber von Änderungen. Protokolle dokumentieren — verhindern tun sie nichts.
• Sensitive Data Protection (früher Cloud DLP) — durchsucht Daten nach personenbezogenen Angaben wie Namen, Kreditkarten- oder Ausweisnummern und kann sie maskieren oder durch Tokens ersetzen, bevor der Datensatz weitergegeben wird. Es wirkt auf einzelne Felder, während Cloud KMS den Bestand als Ganzes verschlüsselt.

Compliance und Datenhoheit: Google Cloud wird gegen eine große Zahl internationaler und branchenspezifischer Normen geprüft; Nachweise, Zertifikate und Prüfberichte liegen zentral im Compliance Resource Center bereit. Eine Zertifizierung der Plattform macht die darauf betriebene Anwendung aber nicht automatisch konform — die Konfiguration bleibt beim Kunden. Datenhoheit (data sovereignty) meint, dass Daten einem Rechtsraum unterliegen und dort verbleiben müssen. Assured Workloads erzwingt die nötigen Kontrollen in einer regulierten Umgebung: Datenresidenz in festgelegten Regionen und Beschränkung der Supportzugriffe auf Personal mit vorgegebenem Standort. Die bloße Wahl einer europäischen Region genügt dafür nicht.

Physische Sicherheit: Der Zutritt zu Googles Rechenzentren ist mehrfach gestaffelt und stark beschränkt — Kundenteams nehmen dort keine Hardware ab. Bis in die Hardware hinein verankert der von Google entwickelte Titan-Sicherheitschip eine Vertrauenskette: Er prüft den Startvorgang und stellt sicher, dass Server mit unveränderter Firmware anlaufen. Ausgediente Datenträger werden nach festem Verfahren gelöscht und zerstört.

Stand September 2026: Cloud DLP heißt Sensitive Data Protection und Cloud Armor firmiert als Google Cloud Armor. In älteren Lernmaterialien heißt die Zulassungsrichtlinie noch schlicht „IAM-Richtlinie“ und das Hauptkonto „Mitglied“ — gemeint ist dasselbe.

Welches Problem → welcher Dienst

Abrechnung, Budgets und Kostenzuordnung

Bezahlt wird nicht das Projekt, sondern das Abrechnungskonto (Cloud Billing account). Jedes Projekt ist genau einem Abrechnungskonto zugeordnet; ohne diese Zuordnung lassen sich kostenpflichtige Dienste nicht nutzen. Ein Abrechnungskonto kann viele Projekte tragen — die übliche Bauweise ist ein Konto für die Organisation und eine Aufschlüsselung darunter, nicht ein eigenes Konto je Abteilung. Getrennte Abrechnungskonten sind die Antwort nur dort, wo wirklich getrennte Rechnungen und getrennte Zahlungsverantwortung verlangt sind, etwa bei rechtlich eigenständigen Tochtergesellschaften.

Rabatte und Kostensenkung

Google Cloud kennt drei Nachlassarten für Rechenleistung. Die Prüfung stellt sie regelmäßig gegeneinander, und die Unterscheidung hängt allein an zwei Fragen: Gibt es eine Zusage, und darf die Last unterbrochen werden?

Der Recommender wertet die tatsächliche Nutzung aus und schlägt konkrete Maßnahmen vor: ungenutzte Instanzen abschalten, überdimensionierte Maschinentypen verkleinern (rightsizing), nicht mehr angebundene Datenträger und reservierte Adressen löschen, verwaiste Projekte prüfen. Es gibt Empfehlungen auch außerhalb der Kosten, etwa zu zu weit gefassten Berechtigungen. Empfehlungen berichten — umgesetzt wird jede einzeln und bewusst.

Der zweite Hebel liegt in der Architektur, nicht im Einkauf. Wer die Last schwanken lässt, zahlt weniger:

• Autoskalierung in einer verwalteten Instanzgruppe (managed instance group) passt die Zahl der virtuellen Maschinen laufend an die Nachfrage an, statt dauerhaft für die Spitzenlast bereitzuhalten.
• Serverlose Abrechnung bei Cloud Run und Cloud Run functions zählt nur die tatsächliche Nutzung und kann bis auf null Instanzen herunterfahren — nachts fällt dann kaum etwas an.
• Abschaltpläne für Test- und Entwicklungsumgebungen außerhalb der Arbeitszeiten sowie Lebenszyklusregeln in Cloud Storage — wirksam, aber grober als Autoskalierung.

FinOps — Kosten als gemeinsame Aufgabe

FinOps ist keine Technik, sondern eine Arbeitsweise: Technik, Finanzen und Geschäft verantworten die Cloud-Ausgaben gemeinsam und laufend. Die Technik sieht, was eine Architekturentscheidung kostet; die Finanzabteilung sieht, wofür das Geld ausgegeben wird; der Geschäftsbereich beurteilt, ob der Nutzen den Preis rechtfertigt. Typische Prüfungsfallen sind die drei Gegenbilder: eine Obergrenze, die die Finanzabteilung allein vorgibt; ein Technikteam, das allein über Ausgaben entscheidet; und die Betrachtung der Kosten nur einmal im Jahr im Budgetprozess. Allen dreien fehlt genau das, was FinOps ausmacht — die laufende Sichtbarkeit und die geteilte Verantwortung.

DevOps und Site Reliability Engineering

DevOps löst die Trennung von Entwicklung und Betrieb auf und ersetzt seltene Großreleases durch häufige, kleine und automatisierte Auslieferungen. Die beiden Kernpraktiken, nach denen gefragt wird, sind Infrastruktur als Code — Umgebungen werden in versionierten Vorlagen beschrieben und daraus wiederholbar erzeugt statt von Hand geklickt — und die automatisierte Pipeline (CI/CD), die Bauen, Testen und Ausliefern in einem Ablauf zusammenführt. Manuelle Gremienfreigaben je Änderung und getrennte Abteilungen sind das Muster, das DevOps ablöst, nicht sein Ergebnis.

Site Reliability Engineering (SRE) ist Googles konkrete Umsetzung davon: Zuverlässigkeit wird gemessen statt behauptet, und die Messgröße steuert, wie schnell ausgeliefert wird. Vier Begriffe sind dabei sauber zu trennen — sie stehen in Prüfungsfragen regelmäßig nebeneinander:

Das Fehlerbudget ist der Steuerungsmechanismus: Solange es reicht, darf zügig ausgeliefert werden. Ist es vorzeitig aufgebraucht, werden riskante Änderungen und neue Funktionen zurückgestellt, und das Team arbeitet an der Stabilität, bis der Zeitraum neu beginnt. Das Budget nachträglich zu erhöhen, Benachrichtigungen abzuschalten oder das SLA neu zu verhandeln behebt die Ursache nicht, sondern entwertet das Ziel.

Nach einem Ausfall folgt die schuldfreie Nachbetrachtung (blameless postmortem). Sie fragt, welche Bedingungen in System und Prozess den Ausfall möglich gemacht haben, und hält daraus konkrete Maßnahmen fest. Wer stattdessen eine schuldige Person benennt, erreicht nur, dass Vorfälle künftig verschwiegen werden — die Kultur ist hier der eigentliche Prüfungsinhalt. Ein weiteres SRE-Stichwort ist Toil: wiederkehrende Handgriffe ohne dauerhaften Wert, die planmäßig wegautomatisiert werden.

Beobachtbarkeit — fünf Dienste, fünf Fragen

Die Dienste der Google Cloud Observability sind leicht zu verwechseln, weil sie alle „irgendetwas mit Überwachung“ tun. Jeder beantwortet genau eine Frage — daran hängt die Zuordnung in der Prüfung.

Auf virtuellen Maschinen liefert der Ops Agent die Messwerte und Protokolle des Betriebssystems an Monitoring und Logging; verwaltete Dienste wie Cloud Run senden ihre Daten ohne Zutun. Von diesen Diensten zu unterscheiden sind zwei Nachbarn: Cloud Audit Logs beantworten „wer hat wann welche Ressource geändert“ und dienen der Nachvollziehbarkeit, nicht der Leistungsanalyse — und das Google Cloud Service Health Dashboard zeigt Störungen auf Seiten von Google, nicht im eigenen Dienst.

Zuverlässigkeit und Notfallwiederherstellung

Verfügbarkeit entsteht durch Redundanz, und die Ebene der Redundanz muss zum erwarteten Schaden passen. Eine Verteilung auf mehrere Zonen innerhalb einer Region übersteht den Ausfall eines einzelnen Rechenzentrums. Nur eine Bereitstellung über mehrere Regionen übersteht den Ausfall einer ganzen Region. Tägliche Sicherungen in dieselbe Region und größere Maschinentypen erhöhen die Ausfallsicherheit nicht — sie stehen in Antwortoptionen gern daneben.

Zwei Kennzahlen legen fest, wie viel Aufwand gerechtfertigt ist. Sie werden regelmäßig vertauscht:

• RPO — Recovery Point Objective: wie viel Datenverlust hinnehmbar ist. Es bestimmt den Abstand der Sicherungen oder die Art der Replikation. „Höchstens fünfzehn Minuten an Daten dürfen verloren gehen“ ist ein RPO.
• RTO — Recovery Time Objective: wie lange die Wiederherstellung dauern darf. Es bestimmt, ob eine Sicherung eingespielt wird oder eine zweite Umgebung bereitsteht.

Daraus ergeben sich die Muster der Notfallwiederherstellung (disaster recovery): Sicherung und Wiederherstellung sind am günstigsten und am langsamsten; eine kleine mitlaufende Umgebung, die im Ernstfall hochskaliert wird, liegt dazwischen; zwei gleichwertige aktive Umgebungen sind am teuersten und am schnellsten. Entscheidend ist, dass die Wiederherstellung geprobt wird — eine nie getestete Sicherung ist keine Zusicherung.

Kapazitätsplanung verbindet Kosten und Zuverlässigkeit: Aus Messwerten und Wachstumsannahmen wird abgeleitet, welche Kapazität künftig nötig ist. Dabei sind auch die Kontingente zu prüfen — eine Autoskalierung, die am Kontingent der Region anschlägt, skaliert nicht weiter, auch wenn das Budget es hergäbe.

Support und Zuständigkeit

Die Supportstufen (Cloud Customer Care) werden in der Prüfung nur grob eingeordnet, nach Reaktionszeit und Betreuung:

Stand September 2026: Die Stufen heißen Basic, Standard, Enhanced und Premium. Ältere Lernmaterialien nennen noch Silver, Gold, Platinum oder „rollenbasierten Support“ — diese Bezeichnungen sind überholt.

Zum Abschluss die Zuordnung, die dieser Bereich am häufigsten verlangt:

Verwechslungspaare

Bilder, die hängen bleiben

• Die Hierarchie ist ein Trichter: Organisation → Ordner → Projekt → Ressource. Richtlinien laufen nach unten, und was oben erlaubt wurde, gilt auch für Projekte, die es noch gar nicht gibt.
• Speicherklassen sind ein Kühlhaus: Standard steht in der Küche, Nearline im Kühlschrank (30 Tage), Coldline in der Tiefkühltruhe (90 Tage), Archive im Kühlhaus am Stadtrand (365 Tage). Je kälter, desto billiger die Lagerung und desto teurer das Herausholen.
• Geteiltes Schicksal: Google steht nicht nur neben der Verantwortungsgrenze und zeigt darauf, sondern reicht Bauanleitungen und Absicherung über sie hinweg.
• Das Fehlerbudget ist ein Konto: Solange Guthaben da ist, darf riskant geliefert werden. Ist es leer, wird erst stabilisiert.
• Ein Budget ist ein Rauchmelder, kein Löscher: Es meldet, aber schaltet nichts ab.

Listen zum Auswendiglernen

• Der Datenlebenszyklus: erfassen → speichern → verarbeiten → analysieren → aktivieren.
• Die drei Rabattarten: Sustained Use (kommt von selbst), Committed Use (1 oder 3 Jahre zugesagt), Spot (billig, jederzeit weg).
• Immer beim Kunden, in jedem Modell: die eigenen Daten, die Konten und Identitäten, die Endgeräte.
• Die drei Schutzziele: Vertraulichkeit, Integrität, Verfügbarkeit.
• Die Beobachtungswerkzeuge: Monitoring misst, Logging schreibt mit, Trace verfolgt die Anfrage, Profiler schaut in den Code, Error Reporting sammelt die Abstürze.

Signalwörter in der Fragestellung