AWS CloudOps Engineer - Associate (SOA-C03) — Übungsfragen und Probeprüfung

Den Verlust einer Availability Zone zu überstehen erfordert zwei Dinge: eine Kopie der Daten an einem anderen Ort und etwas, das diese Kopie automatisch befördert. Cluster Mode mit über mehrere Availability Zones verteilten Replicas liefert die Kopie, und Multi-AZ-Auto-Failover liefert die Beförderung: Es erkennt, dass der Primary nicht erreichbar ist, und wählt ohne Zutun eines Operators ein Replica in einer überlebenden Zone. Genau deshalb verbessert diese Konfiguration die Fehlertoleranz exakt bei dem Ausfall, den das Szenario beschreibt.

Achte auf die sorgfältige Formulierung zum Datenverlust. Die Replikation zu den Replicas ist asynchron, deshalb haben Writes, die der Primary einen Augenblick vor seinem Ausfall bestätigt hat, unter Umständen nie ein Replica erreicht. Vertretbar ist die Aussage minimaler Datenverlust, nicht null — und eine Antwort, die bei asynchroner Replikation null Verlust verspricht, ist meistens die falsche.

Die Distraktoren scheitern an der Verfügbarkeit. Tägliche Snapshots sind ein Backup, nützlich zur Wiederherstellung nach einer Datenbeschädigung, aber mit einem Verlust im Stundenbereich und einer manuellen Wiederherstellung. Unabhängige eigenständige Knoten in verschiedenen Zonen teilen keine Daten, der Ausfall eines Knotens kostet dich also alle Sessions, die dort lagen. Append-only-Persistenz auf einem einzelnen Knoten übersteht einen Prozess-Neustart auf diesem Knoten, aber der Knoten steht weiterhin in einer einzigen Zone und es gibt nichts, wohin ein Failover führen könnte.

Prüfungstipp: Trenne Dauerhaftigkeit von Verfügbarkeit. Snapshots und Persistenz geben dir Dauerhaftigkeit; Replicas plus automatische Beförderung geben dir Verfügbarkeit.

Einer Instanz einen Tag zuzuweisen ist ein API-Aufruf, und genau dieser Aufruf ist der Haken, an dem die ganze Automatisierung hängt. Das Tagging läuft über die Amazon-EC2-Aktion CreateTags, AWS CloudTrail protokolliert diesen Aufruf als Management-Event, CloudTrail liefert seine protokollierten Events an Amazon EventBridge, und eine EventBridge-Regel, deren Event-Pattern auf genau diesen API-Aufruf und diesen Tag-Key passt, ruft AWS Lambda als Ziel auf. Die Lambda-Funktion erstellt dann über das SDK das S3-Bucket. Nichts fragt per Polling ab, nichts läuft nach Zeitplan, und die Reaktion erfolgt, weil der API-Aufruf stattgefunden hat — und genau das bedeutet ereignisgesteuert.

Die anderen drei Kombinationen scheitern schon im ersten Schritt. Amazon-CloudWatch-Metriken sind numerische Zeitreihen, und keine Metrik trägt einen Tag-Key samt Wert, also kann in dieser Kette nichts die Änderung erkennen; Amazon SNS vor AWS Lambda zu setzen leitet nur eine Benachrichtigung weiter, die nie erzeugt wurde. Eine geplante Amazon-EventBridge-Regel, die Tags per Polling abfragt, ist das Gegenteil von ereignisgesteuert: Sie wacht nach Zeitplan auf, fügt Latenz bis zur Länge des Polling-Intervalls hinzu und läuft dauernd, obwohl sich nichts geändert hat — AWS Step Functions dahinter erbt diese Verzögerung. Die AWS-Config-Option kommt der Plausibilität am nächsten, denn AWS Config wertet tatsächlich Konfigurationsänderungen von Ressourcen aus, aber der Umweg über AWS Systems Manager und AWS CloudFormation, um ein einziges Bucket zu erstellen, ist deutlich schwereres Gerät, als das Szenario braucht, und es lässt das EventBridge-Pattern-Matching weg, das die eigentliche Filterung leistet.

Prüfungstipp: Bei einer Anforderung der Form „wenn das passiert, tu das“ lautet die AWS-Standardantwort: CloudTrail zeichnet den API-Aufruf auf, EventBridge gleicht das Event-Pattern ab, und Lambda führt die Aktion aus. Wenn du dieses Trio erkennst, beantwortest du die meisten Fragen zu ereignisgesteuerter Automatisierung auf einen Blick.

Lies die beiden Vorgaben zusammen: Verschlüsselung während der Übertragung und von AWS verwaltete Zertifikate. AWS Certificate Manager, kurz ACM, stellt öffentliche Zertifikate bereit, validiert sie und erneuert sie automatisch, und ACM ist in Elastic Load Balancing integriert, sodass du das Zertifikat direkt auf dem Load Balancer ausrollen kannst. Du hängst das bereitgestellte Zertifikat an den HTTPS-Listener des ALB, und die Plattform übernimmt den Rest des Lebenszyklus, ohne Schlüsselmaterial, das du auf Instanzen kopieren müsstest, und ohne Erneuerungsdatum, an das du denken müsstest.

Jeder Distraktor verletzt eine der Vorgaben. Selbstsignierte Zertifikate, die auf jeder Instanz mit OpenSSL erzeugt werden, sind überhaupt nicht von AWS verwaltet, und Clients weisen sie zurück, solange du das Vertrauen nicht von Hand verteilst. AWS KMS erstellt und kontrolliert kryptografische Schlüssel; es ist keine Zertifizierungsstelle und erzeugt keine TLS-Zertifikate. Das Hochladen von IAM-Serverzertifikaten funktioniert für ältere Setups noch, aber diese Zertifikate stammen von woanders, und die Erneuerung liegt bei dir, also genau der Verwaltungsaufwand, den du laut Frage vermeiden sollst.

Prüfungstipp: Von AWS verwaltete Zertifikate plus Load Balancer sind ein festes Paar. Wenn eine Frage dann noch die Verschlüsselung zwischen dem Load Balancer und den dahinterliegenden Instanzen ergänzt, behandle die Backend-Verbindung als eigene Entscheidung, getrennt vom Zertifikat des Listeners.

AWS Global Accelerator stellt einer Anwendung statische IP-Adressen bereit, die von AWS-Edge-Standorten aus angekündigt werden. Der Datenverkehr gelangt am nächstgelegenen Edge-Standort in das globale AWS-Netzwerk und wird an den besten fehlerfreien Endpunkt in einer der konfigurierten Regionen weitergeleitet, abhängig vom Zustand der Endpunkte, vom Standort des Clients und von den Datenverkehrseinstellungen. Endpunkte können Network Load Balancers, Application Load Balancers, EC2-Instances oder Elastic IP-Adressen sein, und Standard-Accelerators übertragen TCP und UDP. Da sich die IP-Adressen beim Failover nicht ändern, brauchen Clients und Firewalls keine DNS-Aktualisierungen. CloudFront liefert Inhalte aus, die über HTTP und HTTPS bereitgestellt werden, was nicht zu einem eigenen UDP-Protokoll passt, und DNS-basiertes Failover hängt von den TTLs der Einträge und vom Caching auf Clientseite ab. Prüfungstipp: Statische IPs plus UDP plus schnelles Failover über mehrere Regionen deuten auf Global Accelerator hin.