Cross-Account Event Routing und Governance

Prüfungsbezug: DOP-C02 Domain 5 — event processing, configuration response, and troubleshooting.

Lernziel

Central Event Buses, Resource Policies, Organization Conditions, Source Validation und Delegated Operations mit präzisen Event Contracts, Least-Privilege Execution, begrenzten Retries, verlässlichen Nachweisen und sicherer Recovery entwerfen, implementieren und troubleshooten.

Berufliches Szenario

Eine Production-Umgebung nutzt Central Event Buses, Resource Policies, Organization Conditions, Source Validation und Delegated Operations. Bei einem Operational Event verliert der Workflow Kontext, wiederholt eine unsafe Action oder bietet keinen zuverlässigen Pfad von Detection zu Mitigation und verifizierter Recovery.

Kernkonzepte

• Die Lektion fokussiert Central Event Buses, Resource Policies, Organization Conditions, Source Validation und Delegated Operations.
• Ein Event beschreibt, was geschehen ist; ein Command fordert eine Aktion an.
• Event Consumer müssen idempotent sein, weil Retries und Duplicate Delivery vorkommen.
• Jede Automation benötigt Scope, Preconditions, Permissions, Rate Limits, Failure Handling und Evidence.
• Detection, Notification, Mitigation, Recovery und Prevention sind unterschiedliche Phasen.
• Die erste fehlerhafte Komponente oder der früheste unerwartete State liefert oft den besten Troubleshooting-Hinweis.

Architektur- und Response-Schrittfolge

1. Trigger und Business Impact definieren.
2. Representative Event, Alarm, Log oder Failure State erfassen.
3. Source, Routing, Target, Execution Role und Ressourcen identifizieren.
4. Event Contracts, Permissions, Quotas und Dependency Readiness validieren.
5. Kleine kontrollierte Response oder Diagnostic Action ausführen.
6. Resultierenden State prüfen und Evidence erhalten.
7. Escalaten, rollbacken oder nächste Hypothese testen.
8. Prevention dokumentieren und retesten.

Entscheidungshilfe

Anforderung	Bevorzugte Richtung	Warum
Known Event mit Routing	EventBridge Rule mit präzisem Pattern	Native Event-Driven Response
Durable Decoupling	SQS Queue und idempotenter Consumer	Puffert und erhält Work
Multi-Step Response	Step Functions oder Systems Manager Automation	Explizite Retries, Branching und History
Resource-State-Verstoß	AWS Config plus sichere Remediation	Evaluates und korrigiert Non-Desired State
Unknown Failure	Hypothesis-Driven Investigation mit Logs, Metrics, Traces, Events und Health	Keine zufälligen Changes

Fehlerbilder und Fehlersuche

• Rule matched zu breit und startet fremde Actions.
• Retry wiederholt destruktive nicht-idempotente Operation.
• Execution Role hat fehlende oder zu breite Permissions.
• Remediation Target ist stale, schon recovered oder genehmigte Exception.
• Responder ändern mehrere Variablen gleichzeitig und zerstören Evidence.
• Recovery stellt Service her, aber Risk wird nicht korrigiert oder retested.

Sicherheits- und Betriebskontrollen

• Detection-, Orchestration-, Remediation- und Audit-Rollen trennen.
• Reversible Containment/Mitigation vor destruktiven Actions bevorzugen.
• Event Buses, Runbooks, Pipelines, Incident Data und Evidence schützen.
• Keine Secrets, Credentials oder sensitive Payloads in Events/Notifications/Channels.
• Initiator, Approver, Executor und Verifier sensibler Actions erfassen.

Praxislabor

Ziel: Einen kleinen Incident- oder Event-Response-Workflow für dieses Thema bauen und validieren.

Aufgaben

1. Trigger Event oder Failure Condition definieren.
2. Source, Routing, Target, Permissions, Retries und Failure Destinations zeichnen.
3. Minimalen Workflow oder detaillierte Config bauen.
4. Controlled Failure einführen.
5. Erste fehlerhafte Komponente diagnostizieren.
6. Safe Remediation oder Rollback.
7. Service State prüfen und Evidence erfassen.
8. Prevention Action mit Owner und Retest Date.

Validierung

• Trigger matched nur gewünschte Bedingung.
• Duplicate Delivery erzeugt keine Duplicate Effects.
• Execution Role ist scoped.
• Failure ist sichtbar und recoverbar.
• Finaler Service-/Configuration-State ist verifiziert.

Kostenkontrolle: Synthetic Events und kleinen Test-Scope verwenden. Rules, Queues, State Machines, Runbooks, Testressourcen, Logs und Notifications entfernen.

Aufräumen

1. Test Publisher und Scheduled Rules stoppen.
2. Temporäre Targets, Queues, DLQs, Functions, State Machines, Runbooks und Alarms löschen.
3. Test-Configuration-Changes zurücksetzen und finalen State bestätigen.

Prüfungsfallen

• Event als garantierte Exactly-Once Delivery behandeln.
• Auf jedes Event ohne Severity/Impact pagen.
• Automatisch remediaten ohne Scope/Current-State-Validation.
• Infrastruktur manuell ändern ohne Evidence/IaC-Reconciliation.
• Nach Mitigation ohne RCA und Prevention stoppen.

Wichtigste Erkenntnisse

• Central Event Buses, Resource Policies, Organization Conditions, Source Validation und Delegated Operations.
• Automated Response muss präzise, idempotent, begrenzt, observable und möglichst reversibel sein.
• Troubleshooting beginnt mit Evidence und Hypothesen, nicht mit zufälligen Configuration Changes.

Wiederholungsfragen

1. Was sind Trigger und Business Impact?
2. Welcher Service produziert oder erfasst das Event?
3. Wie Duplicate Delivery behandeln?
4. Welche Execution Role führt aus?
5. Was ist Failure Destination?
6. Wie Current Target State validieren?
7. Was ist Rollback-/Escalation-Pfad?
8. Welche Evidence belegt Recovery?

Antworten

1. Präzise definiertes Event, Alarm, Health State oder Failure mit messbarem Impact.
2. AWS Service, CloudTrail, AWS Health, EventBridge, Custom Producer oder Telemetry System.
3. Idempotency Key, State Check, Conditional Write oder repeatable Runbook.
4. Least-Privilege-Rolle für den Workflow Step.
5. DLQ, Failed Execution, OpsItem, Alert oder Failed Record.
6. Resource-/Service-State unmittelbar vor Action lesen.
7. Reversible Action, Previous Version, Manual Approval oder Incident Escalation.
8. Metrics, Logs, Traces, Event History, Execution Output, Resource State und User Validation.