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

Arbeite dich rückwärts durch das, was das Szenario bereits ausschließt. Der allgemeine Internetzugang beweist, dass das Routing funktioniert. Die Network Access Control Lists sind offen, das Subnetz filtert also nicht. Die S3-Bucket-Policy erlaubt Zugriff aus der VPC, und genau das ist der Hinweis, denn eine so geschriebene Policy ist nur dann erfüllt, wenn die Anfrage tatsächlich über den privaten Endpoint-Pfad ankommt. Datenverkehr, der über ein NAT-Gateway hinausgeht, erreicht den öffentlichen S3-Endpoint und trägt keinen Endpoint-Kontext, deshalb verweigert die Policy ihn, obwohl die Pakete ankommen.

Damit ist der VPC-Endpoint für S3 das, was du prüfen musst. Gibt es in dieser VPC einen Gateway-Endpoint für S3, und umfasst dessen Route-Table-Zuordnung das private Subnetz? Den Endpoint anzulegen ist nur die halbe Arbeit; anschließend fügst du ihn als Ziel in die Route Table für den nach S3 gerichteten Datenverkehr ein, und ein Subnetz, dessen Route Table nie zugeordnet wurde, nutzt weiterhin den Internetpfad.

Die anderen drei passen nicht zu den Symptomen. Die Bandbreite des NAT-Gateways würde eher zu Langsamkeit führen als zu einer glatten Verweigerung. Bucket-Versioning ist eine Einstellung zum Datenschutz und hat mit dem Zugriff nichts zu tun. Die Berechtigung der Instance-Rolle ist eine plausibel klingende Falle, aber der Aufgabentext sagt dir, dass die Bucket-Policy die maßgebliche Kontrolle ist.

Prüfungstipp: Wenn die Konnektivität allgemein funktioniert und ein einzelner Dienst versagt, suche in der Resource Policy nach einer Bedingung, die den Pfad einschränkt, und nicht nur den Principal.

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.