Cloud Digital Leader — Übungsfragen und Probeprüfung

Cloud Trace ist der Distributed-Tracing-Dienst von Google Cloud, der Anfragen über Microservices hinweg verfolgt und die Latenz bei jedem Schritt aufzeichnet (docs.cloud.google.com/trace/docs/overview). Er erzeugt Wasserfall-Visualisierungen, die zeigen, wie lange jeder Service für die Verarbeitung einer Anfrage braucht, sodass sich Engpässe leicht lokalisieren lassen. Cloud Trace lässt sich mit GKE, Cloud Run und App Engine integrieren und unterstützt Instrumentierung mit OpenTelemetry. Warum nicht Cloud Monitoring? Es erfasst Metriken wie CPU- und Speicherauslastung, verfolgt aber keine einzelnen Anfragepfade über Services hinweg. Warum nicht Error Reporting? Es identifiziert Anwendungsfehler und Exceptions, keine Latenzengpässe. Warum nicht Cloud Logging? Es sammelt Logeinträge, bietet aber kein Latenz-Tracing auf Anfrageebene über Servicegrenzen hinweg. Prüfungstipp: herausfinden, welcher konkrete Service in einer verteilten Aufrufkette die Latenz verursacht = Cloud Trace.

AutoML auf der Agent Platform automatisiert die Auswahl der Algorithmen, das Abstimmen der Hyperparameter und das Modelltraining und erfordert weder ML-Erfahrung noch Programmierung (docs.cloud.google.com/vertex-ai/docs/start/training-methods). Für Teams mit wenig ML-Erfahrung und kleineren Datensätzen liefert AutoML schneller hochwertige Modelle, weil eigener Trainingscode und der Aufbau von Datenpipelines entfallen. Der offizielle Vergleich der Trainingsmethoden bestätigt: AutoML braucht keine Data-Science-Expertise und kommt ohne Code aus. Warum nicht eigenes Training? Es erfordert erhebliche ML-Erfahrung, um Trainingsanwendungen zu entwickeln—es liefert nicht unabhängig von der Erfahrung immer bessere Modelle. Warum nicht nur vortrainierte APIs? Vortrainierte APIs decken gängige Aufgaben ab, können aber nicht auf deinem eigenen Datensatz trainieren. Warum nicht „AutoML ist nur etwas für große Unternehmen“? AutoML steht allen Nutzenden offen, unabhängig von der Größe der Organisation. Prüfungstipp: wenig ML-Erfahrung + schnelle Ergebnisse nötig + kleiner Datensatz = AutoML.

Google Cloud verschlüsselt Daten während der Übertragung sowohl über das öffentliche Internet als auch innerhalb des eigenen internen Netzwerks (docs.cloud.google.com/docs/security/encryption-in-transit). Externer Traffic wird über die Google Front Ends (GFEs) mit TLS/QUIC verschlüsselt, während interner Traffic zwischen Diensten ALTS (Application Layer Transport Security) für gegenseitige Authentifizierung und Verschlüsselung nutzt. Google verwendet außerdem das Sicherheitsprotokoll PSP für die Verschlüsselung auf Netzwerkebene mit SmartNIC-Offloading. Das geschieht automatisch und erfordert für regulären Traffic keine Konfiguration durch Kundinnen und Kunden. Warum nicht nur beim Premium Tier? Die Verschlüsselung während der Übertragung gilt unabhängig vom Netzwerk-Tier. Warum nicht nur über das öffentliche Internet? Die Dokumentation sagt ausdrücklich, dass Google Daten innerhalb des internen Netzwerks mit ALTS verschlüsselt. Warum nicht manuelle TLS-Konfiguration? Google übernimmt die Verschlüsselung für seine Dienste automatisch—kundenverwaltete Zertifikate sind nicht nötig. Prüfungstipp: TLS = extern; ALTS = intern. Beides automatisch.

Die Skalierung auf null ist die Eigenschaft, die eine serverlose Anwendungsplattform am deutlichsten von einem Cluster unterscheidet, den du dauerhaft betreibst. Cloud Run fügt Instanzen passend zu den eingehenden Anfragen hinzu und entfernt sie wieder, wenn die Nachfrage sinkt, und standardmäßig wird eine Revision, die keinen Traffic erhält, auf null Instanzen skaliert. Das geschieht nicht in dem Moment, in dem die letzte Anfrage endet: Um Kaltstarts zu verringern, kann Cloud Run eine Instanz nach der Verarbeitung von Anfragen bis zu 15 Minuten lang im Leerlauf vorhalten, und eine Instanz im Leerlauf kann Ressourcen wie offene Datenbankverbindungen behalten. Für Workloads mit langen Leerlaufphasen, etwa interne Tools oder saisonal genutzte Endpoints, bedeutet das, dass über Nacht keine Instanzen weiterlaufen. Der Preis dafür ist der Kaltstart: Die erste Anfrage, nachdem die Revision auf null skaliert wurde, muss warten, bis eine neue Instanz erstellt ist, was spürbare Latenz verursachen kann. Teams, die diese Latenz nicht hinnehmen können, legen eine Mindestanzahl an Instanzen fest, damit eine Instanz warm bleibt, und nehmen damit bewusst gewisse Leerlaufkosten für eine vorhersehbare Antwortzeit in Kauf.