Entscheidungsrahmen für professionelle Szenarien
Prüfungsbezug: Dieser Rahmen gilt für alle Szenariofragen in Domain 1. Auf Professional-Niveau sind häufig mehrere Architekturen technisch möglich; gesucht ist die Lösung, die alle genannten Randbedingungen am besten erfüllt.
Lernziel
Harte Anforderungen aus einem langen Szenario extrahieren, in Architektureigenschaften übersetzen, ungültige Antworten ausschließen und die beste verbleibende Lösung durch ausdrückliche Trade-off-Analyse auswählen.
| Schwierigkeitsgrad | Mittel |
| Lernzeit | 150 Minuten |
| Voraussetzungen | AWS-Architektur auf Associate-Niveau und die vorherigen Kapitel-Lektionen |
Warum professionelle Szenarien schwierig wirken
Auf Associate-Niveau prüft eine Frage häufig, ob eine Dienstfunktion bekannt ist. Auf Professional-Niveau können alle vier Optionen gültige AWS-Dienste verwenden. Der Unterschied liegt darin, wie gut jede Option gleichzeitig Anforderungen an Verfügbarkeit, Kontengrenzen, Automatisierung, Rollback, Sicherheit, Audit, Kosten und Betriebsaufwand erfüllt.
Eine plausible Antwort kann falsch sein, weil sie nur einen Satz des Szenarios verletzt. Ziel ist daher nicht, irgendeine funktionierende Option zu finden. Gesucht ist die Option, die alle harten Anforderungen mit dem besten Gesamt-Trade-off erfüllt.
Fakten, Ziele und Randbedingungen trennen
Ordne jede wichtige Aussage ein, bevor du Dienste vergleichst.
| Aussageart | Beispiel | Wirkung auf die Entscheidung |
|---|---|---|
| Ist-Zustand | Releases werden manuell nach ECS deployt | Erklärt den Ausgangspunkt, aber nicht zwingend das Zieldesign |
| Geschäftsziel | Häufiger veröffentlichen | Erfordert schnelleren und zuverlässigeren Fluss |
| Harte Randbedingung | Downtime ist nicht zulässig | Schließt unterbrechende Deployment-Verfahren aus |
| Fehleranforderung | Bei erhöhten 5xx-Fehlern automatisch zurückrollen | Erfordert Zustandsnachweis, der mit Deployment-Steuerung verbunden ist |
| Sicherheitsanforderung | Produktion liegt in einem getrennten Konto | Erfordert einen kontenübergreifenden Autorisierungspfad |
| Betriebspräferenz | Laufende Administration minimieren | Bevorzugt verwaltete native Funktionen, wenn sie die Anforderungen erfüllen |
| Kostenpräferenz | Zusätzliche Kosten minimieren | Wählt unter ansonsten gültigen Lösungen; überstimmt selten eine harte Verfügbarkeitsanforderung |
Hintergrunddetails liefern Kontext, aber besitzen nicht alle dasselbe Gewicht. Wörter wie muss, automatisch, ohne Downtime, zentral, kontenübergreifend, Least Privilege und minimaler Betriebsaufwand markieren häufig entscheidende Randbedingungen.
Anforderungssprache in Eigenschaften übersetzen
Springe nicht direkt von einer Formulierung zu einem Dienstnamen. Übersetze sie zuerst in eine Eigenschaft.
| Formulierung im Szenario | Gesuchte Architektureigenschaft |
|---|---|
| Keine Downtime | Alte und neue Kapazität überlappen sich; Datenverkehr wird kontrolliert verlagert |
| Automatischer Rollback | Deployment-Zustand ist mit getesteten Alarmen oder Fehlerbedingungen verbunden |
| Dasselbe Artefakt in jeder Umgebung | Unveränderliches versioniertes Artefakt mit eindeutiger Herkunft |
| Über mehrere Konten | Rollen, Trust, Resource Policy und Verschlüsselungsautorisierung |
| Zentral durchsetzen | Organizations-fähige oder delegierte Verwaltungsfunktion |
| Innerhalb weniger Minuten wiederherstellen | Vorgegebener automatisierter Wiederherstellungspfad und bereite Kapazität |
| Minimaler Betriebsaufwand | Verwaltete Integration mit weniger eigenen Komponenten |
| Nachweise erhalten | Protokollierte Actions, Berichte, Freigaben und unveränderliche Historie |
| Änderungen müssen umkehrbar sein | Versionierter Zustand, Verkehrssteuerung und getesteter Rollback oder Korrektur nach vorn |
Erst nach Festlegung der Eigenschaft erfolgt die Abbildung auf CodePipeline, CodeDeploy, ECS, Lambda-Aliase, CloudWatch-Alarme, Step Functions oder eine andere AWS-Funktion.
Die Entscheidungsmethode in sechs Durchläufen
Durchlauf 1: Workload und Steuerungsebene erkennen
Deployment-Plattform, Konten, Regionen, Artefakttyp und steuernden Deployment-Dienst markieren. EC2, ECS, EKS und Lambda besitzen unterschiedliche Verkehrs- und Rollback-Mechanismen.
Durchlauf 2: harte Randbedingungen aufschreiben
Jede Randbedingung als kurzen prüfbaren Satz neu formulieren. Zum Beispiel:
- Produktionskapazität muss während des Deployments verfügbar bleiben.
- Bei einem Anwendungsalarm muss der Prozess automatisch zurückkehren.
- Die Pipeline muss aus dem Tooling-Konto nach Produktion deployen.
- Die Lösung darf keinen eigenen Orchestrierungsdienst benötigen.
Durchlauf 3: Widersprüche ausschließen
Eine Option sofort entfernen, wenn sie eine harte Randbedingung verletzt. Ergänze keine Funktionen, die in der Antwort nicht genannt werden.
Durchlauf 4: den vollständigen Pfad prüfen
Eine Antwort kann das Deployment lösen, aber Artefaktverschlüsselung, Rollenvertrauen, Zustandserkennung oder Rollback auslassen. Source, Artefakt, Identität, Deployment, Datenverkehr, Zustand und Wiederherstellung vom Anfang bis zum Ende verfolgen.
Durchlauf 5: gültige Optionen vergleichen
Nur die verbleibenden Optionen vergleichen:
- Sicherheit und Least Privilege
- Resilienz und Blast Radius
- Wiederherstellungsverhalten
- Auditierbarkeit
- Betriebsaufwand
- Kosten
Das Szenario kann diese Reihenfolge verändern. Eine harte Kostengrenze kann entscheidend sein; „kosteneffektiv“ bedeutet jedoch meist: die günstigste Option wählen, die weiterhin alle harten Anforderungen erfüllt.
Durchlauf 6: Gewinner belegen und Zweitbesten erklären
Erkläre, wie der Gewinner jede harte Anforderung erfüllt. Nenne anschließend den genauen Trade-off, durch den die zweitbeste Antwort verliert. So wird verhindert, dass Vertrautheit oder die Anzahl der AWS-Dienstnamen entscheidet.
Durchgängiges Szenario
Frage
Ein Unternehmen deployt einen Amazon-ECS-Service aus einem Tooling-Konto in ein Produktionskonto. Releases dürfen keine Downtime verursachen. Überschreitet die ALB-5xx-Rate des neuen Task Sets einen Grenzwert, muss der Datenverkehr automatisch zum vorherigen Task Set zurückkehren. Gewünscht ist die Lösung mit dem geringsten Betriebsaufwand.
Welche Architektur erfüllt die Anforderungen am besten?
Optionen
A. ECS-Blue/Green-Deployment über CodeDeploy verwenden. Produktions- und Test-Listener, einen CloudWatch-Alarm für die ALB-5xx-Metrik, automatischen Rollback und eine begrenzte kontenübergreifende Deployment-Rolle konfigurieren.
B. ECS-Rolling-Update verwenden. Nach dem Deployment prüft eine Person das CloudWatch-Dashboard und stellt bei erhöhten Fehlern manuell die vorherige Task Definition wieder her.
C. Eine eigene Lambda-Funktion aus CodePipeline aufrufen. Die Funktion erstellt einen zweiten ECS-Service, ändert Listener Rules, fragt CloudWatch ab und löscht anschließend den alten Service.
D. Das Container-Image auf eine EC2-Instanz im Produktionskonto kopieren und die Anwendung im Wartungsfenster neu starten.
Anforderungen extrahieren
| Anforderung | Hart oder Präferenz? |
|---|---|
| ECS-Workload | Plattformfakt |
| Tooling- zu Produktionskonto | Harte Sicherheits- und Deployment-Randbedingung |
| Keine Downtime | Harte Verfügbarkeitsanforderung |
| Automatische Reaktion auf ALB 5xx | Harte Fehleranforderung |
| Rückkehr zum vorherigen Task Set | Harte Rollback-Anforderung |
| Geringster Betriebsaufwand | Präferenz unter gültigen Antworten |
Ausschluss
- D ist ungültig, weil der Neustart einer Instanz kein ECS-Deployment ohne Downtime liefert und die angegebene Plattform ignoriert.
- B ist ungültig, weil der Rollback manuell erfolgt, das Szenario aber eine automatische Reaktion verlangt.
- C kann technisch gültig gebaut werden, bildet aber Traffic Shifting, Zustandsverwaltung, Wiederholungen, Cleanup und Alarmauswertung mit eigenem Code nach.
- A erfüllt alle harten Anforderungen mit nativen ECS- und CodeDeploy-Blue/Green-Funktionen, CloudWatch-Alarm, automatischem Rollback und kontenübergreifender Rolle.
Beste und zweitbeste Antwort
A ist die beste Antwort. Sie erfüllt alle harten Randbedingungen und minimiert eigene Betriebsverantwortung.
C ist die zweitbeste Antwort. Sie kann die funktionalen Anforderungen erfüllen, erzeugt aber Verantwortung für Code, Idempotenz, Wiederholungen, Race Conditions und Cleanup, obwohl kein eigenes Verhalten gefordert ist. „Serverless“ bedeutet nicht automatisch „geringster Betriebsaufwand“.
Wann Managed nicht automatisch besser ist
„Verwaltete Dienste bevorzugen“ ist eine nützliche Grundregel, aber kein absolutes Gesetz. Eine verwaltete Option verliert, wenn sie ein gefordertes Verhalten, eine Plattform, Skalierung, Latenz, Compliance-Grenze oder Integration nicht unterstützt.
Vor der Auswahl einer verwalteten Funktion prüfen:
- Unterstützt sie den genannten Workload und Deployment-Typ?
- Funktioniert sie über die erforderlichen Konten und Regionen?
- Passt ihr Rollback-Verhalten zur Fehleranforderung?
- Passen Quotas und Ausführungsverhalten zur Skalierung?
- Liefert sie geforderte Nachweise und Sicherheitskontrollen?
- Verlangt das Szenario ausdrücklich eigenes Verhalten, das der Dienst nicht ausdrücken kann?
Die beste Antwort ist die am wenigsten komplexe vollständig gültige Antwort und nicht einfach die mit den wenigsten Komponenten.
Häufige Anforderungskonflikte
Niedrigste Kosten und keine Downtime
Blue/Green-Deployment betreibt vorübergehend doppelte Kapazität. Ist „keine Downtime“ hart und Kosten nur eine Präferenz, ist die zusätzliche Kapazität gerechtfertigt. Ein In-Place-Neustart ist günstiger, aber ungültig.
Schnellster Release und stärkste Nachweise
Pflichttests oder Audit-Kontrollen dürfen nicht entfernt werden. Stattdessen schnelle deterministische Prüfungen nach vorn verschieben, unabhängige Prüfungen parallelisieren, ein Artefakt weiterreichen und Nachweiserfassung automatisieren.
Automatische Korrektur und Blast Radius
Automatisierung muss aktuellen Zustand, Scope und Ausnahmen prüfen. Bei destruktiven oder schwer umkehrbaren Actions kann eine manuelle Prüfung angemessen sein, obwohl die Erkennung automatisch erfolgt.
Zentrale Kontrolle und Teamautonomie
Zentrale Leitplanken, wiederverwendbare Komponenten und delegierte Rollen verwenden. Zentrale Kontrolle bedeutet nicht, dass ein Team jede Änderung manuell ausführt.
Fehler in der Entscheidungslogik
- Dienstnamen-Matching: Option wählen, weil sie den in der Frage genannten Dienst enthält.
- Einzelanforderung optimieren: Kosten lösen und dabei Verfügbarkeit oder Sicherheit verletzen.
- Fehlende Funktionen erfinden: Annehmen, eine Option enthalte Alarme, Verschlüsselung oder Rollback, obwohl dies nicht genannt ist.
- Nur Authentifizierung betrachten: Rollenannahme ermöglichen, aber Zielrechte, Resource Policies und KMS ignorieren.
- Nur Erfolgsweg betrachten: Deployment ohne Fehlererkennung und Wiederherstellung entwerfen.
- Absolute Regeln: „Immer Managed“, „immer mehrere Konten“ oder „immer Blue/Green“ als universell korrekt behandeln.
- Längste-Antwort-Bias: Mehr Umsetzungsdetails mit größerer Korrektheit verwechseln.
Entscheidungsarbeitsblatt
Ziel:
Workload/Plattform:
Konten/Regionen:
Artefakt- und Quellidentität:
Harte Randbedingungen:
1.
2.
3.
Fehlersignal:
Gefordertes Wiederherstellungsverhalten:
Sicherheitsgrenzen:
Option A - ungültig/gültig, weil:
Option B - ungültig/gültig, weil:
Option C - ungültig/gültig, weil:
Option D - ungültig/gültig, weil:
Beste Antwort:
Zweitbeste Antwort:
Entscheidender Trade-off:
Praxislabor: Entscheidungskarten lösen
Ziel: Anforderungsextraktion und Ausschluss vor dem Dienstvergleich üben.
Entscheidungskarten
Für jede Karte vier Optionen selbst erstellen oder Optionen aus einer Übungsprüfung verwenden.
- Ein Lambda-Release benötigt zehn Prozent Datenverkehr für zehn Minuten und automatischen Rollback bei Fehlern.
- Eine EC2-Flotte benötigt keine Downtime, unveränderliche Hosts und eine schnelle Rückkehr zur vorherigen Version.
- Eine kontenübergreifende Pipeline kann ihre Zielrolle annehmen, aber das Artefakt nicht entschlüsseln.
- Mehrere Commits überschreiben eine gemeinsam genutzte Integrationsumgebung.
- Ein regulierter Release braucht verantwortliche Freigabe, darf nach der Freigabe aber nicht neu bauen.
- Eine Pipeline muss dasselbe Container-Image in zwei Regionen deployen.
Aufgaben
- Fakten, harte Randbedingungen, Fehleranforderungen und Präferenzen trennen.
- Jede harte Randbedingung in eine Architektureigenschaft übersetzen.
- Optionen ausschließen, die einer Eigenschaft widersprechen.
- Artefakt, Identität, Deployment, Zustand und Wiederherstellung für die verbleibenden Optionen verfolgen.
- Gültige Optionen nach den genannten Prioritäten ordnen.
- Gewinner und Zweitbesten jeweils in zwei Sätzen erklären.
- Jede noch zu prüfende AWS-Funktion notieren.
Validierungscheckliste
- Der Gewinner erfüllt jede harte Randbedingung.
- Der Antwort wurde keine ungenannte Funktion hinzugefügt.
- Die Begründung folgt den Workload-spezifischen Deployment-Mechanismen.
- Kontenübergreifende und Verschlüsselungsebenen werden getrennt bewertet.
- Wiederherstellungsverhalten ist mit einem echten Signal verbunden.
- Die zweitbeste Antwort verliert wegen eines genauen Trade-offs.
Kostenkontrolle: Dies ist ein Denk-Labor ohne AWS-Ressourcen.
Aufräumen
In der Cloud ist kein Aufräumen erforderlich. Kopierte proprietäre Übungsfragen aus geteilten Notizen entfernen; nur eigene Zusammenfassungen und Begründungen behalten.
Prüfungsfallen
- Annehmen, die längste Antwort sei die beste.
- Wörter wie automatisch, zentral, ohne Downtime oder kontenübergreifend ignorieren.
- Einen eigenen Lambda-Ablauf wählen, obwohl eine native Funktion alle Anforderungen erfüllt.
- Eine native Funktion wählen, ohne Workload-Unterstützung und Rollback-Verhalten zu prüfen.
- „Kosteneffektiv“ als „ungeachtet der Randbedingungen am billigsten“ verstehen.
- Nur den Normalweg lösen und Fehlerwiederherstellung ignorieren.
Wichtigste Erkenntnisse
- Anforderungen extrahieren, bevor Dienste verglichen werden.
- Harte Randbedingungen schließen Optionen aus; Präferenzen ordnen gültige Kandidaten.
- Sprache zuerst in Architektureigenschaften und dann in AWS-Funktionen übersetzen.
- Den vollständigen Pfad von Source bis Wiederherstellung prüfen.
- Erklären, warum die zweitbeste Antwort verliert.
- Die am wenigsten komplexe vollständig gültige Lösung bevorzugen.
Wiederholungsfragen
- Was muss vor dem Vergleich von AWS-Diensten geschehen?
- Worin unterscheiden sich harte Randbedingung und Präferenz?
- Warum darf eine Antwort nicht durch eine erfundene Komponente repariert werden?
- Was begünstigt „geringster Betriebsaufwand“ normalerweise?
- Wann kann eine eigene Lösung besser als eine verwaltete Integration sein?
- Warum ist die billigste Antwort nicht immer die kosteneffektivste?
- Was beweist die Erklärung des Zweitbesten?
- Welche Pfade müssen für jede Deployment-Antwort verfolgt werden?
Modellantworten
- Ziel, Workload, Konten, harte Randbedingungen, Fehlersignal und Wiederherstellungsanforderung identifizieren und anschließend in Architektureigenschaften übersetzen.
- Die Verletzung einer harten Randbedingung macht eine Antwort ungültig. Eine Präferenz ordnet Antworten, die bereits alle harten Anforderungen erfüllen.
- Die Prüfung bewertet die Option wie beschrieben. Ein nicht genannter Alarm, eine Rolle oder ein Rollback kann aus einer ungültigen Antwort eine erfundene Antwort machen.
- Eine verwaltete native Funktion mit weniger eigenen Komponenten, sofern sie alle funktionalen, Sicherheits- und Wiederherstellungsanforderungen erfüllt.
- Wenn gefordertes Verhalten, Integration, Skalierung, Richtlinien oder Wiederherstellungssemantik nicht durch die verwaltete Funktion ausdrückbar sind und der Nutzen die zusätzliche Verantwortung rechtfertigt.
- Kosteneffektivität schließt die Zielerfüllung ein. Ein günstigeres Design, das Verfügbarkeit oder Wiederherstellung verletzt, erzeugt unakzeptable Geschäftskosten und ist ungültig.
- Sie zeigt, dass der entscheidende Trade-off verstanden wurde und nicht nur der Dienstname der Gewinneroption erkannt wurde.
- Source-Trigger und Version, Artefaktfluss, Identität und Autorisierung, Deployment-Mechanik, Zustandsnachweis und Fehlerwiederherstellung.