Amazon DOP-C02: Infrastruktur als Code und Konfigurationsmanagement — Lernleitfaden

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

Teil des AWS DevOps Engineer Professional DOP-C02 — Lernleitfaden. Üben Sie mit verifizierten Antworten im Amazon-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Überblick

Infrastructure as Code (IaC) und Konfigurationsmanagement auf AWS ermöglichen die wiederholbare, auditierbare und gesteuerte Bereitstellung und Konfiguration von Infrastruktur und Anwendungen. CloudFormation und das AWS Cloud Development Kit (CDK) beschreiben Ressourcen deklarativ oder über Code, der zu CloudFormation synthetisiert wird. Konfigurationsebenen wie AWS OpsWorks und AWS Systems Manager setzen den Soll-Zustand auf Instanzen in EC2- und hybriden Flotten durch und melden diesen. Secrets, Parameter und das Erstellen von Images (Image-Baking) vervollständigen den Lebenszyklus und ermöglichen unveränderliche (immutable), sichere Deployments im großen Maßstab.

CloudFormation-Stacks, Änderungskontrolle und Governance

CloudFormation-Stacks sind die Bereitstellungseinheit. Entwerfen Sie Stacks entlang von Lebenszyklus-Grenzen und Zuständigkeiten, um den „Blast Radius“ (Auswirkungsradius) zu minimieren. Verwenden Sie Parameter sparsam und bevorzugen Sie vordefinierte Standardwerte (opinionated defaults) mit Mappings oder SSM-Lookups. Exportieren und importieren Sie nur stabile, gemeinsam genutzte Werte über Outputs und Fn::ImportValue, um eine enge Kopplung zu vermeiden.

Verschachtelte Stacks (Nested Stacks) kapseln wiederverwendbare Komponenten und halten die übergeordneten Templates klein. Ein Parent-Stack kann Parameter an Child-Stacks übergeben und deren Outputs konsumieren, was modulare Architekturen ermöglicht (z. B. ein verschachtelter Stack für ein gemeinsames Netzwerk, der von einem Anwendungs-Stack genutzt wird). Halten Sie verschachtelte Stacks auf einen einzigen Zweck ausgerichtet (VPC, Datenebene, Anwendungsebene) und versionieren Sie sie unabhängig voneinander.

StackSets stellen ein einziges Template über mehrere Konten und Regionen hinweg bereit. Verwenden Sie das service-verwaltete Berechtigungsmodell mit AWS Organizations, um automatisch in OUs bereitzustellen und neue Konten automatisch einzubeziehen. Konfigurieren Sie die Betriebseinstellungen (maximale gleichzeitige Konten/Regionen, Fehlertoleranz), um den Rollout zu steuern. Parameter-Überschreibungen pro Konto oder Region ermöglichen es Ihnen, ein Standard-Template an lokale Gegebenheiten anzupassen. Überwachen Sie den Drift von StackSets und Stack-Instanzen, um Änderungen außerhalb des definierten Prozesses (out-of-band) zu erkennen.

Change Sets ermöglichen sichere, von Menschen überprüfbare Updates. Führen Sie immer CreateChangeSet aus und prüfen Sie die Auswirkungen auf jede einzelne Ressource, Ersetzungen und potenziellen Datenverlust, bevor Sie ExecuteChangeSet ausführen. Integrieren Sie Change Sets in automatisierte Pipelines für gestaffelte Freigaben (gated approvals).

Die Drift-Erkennung (Drift Detection) überprüft, ob die Stack-Ressourcen mit dem Template übereinstimmen. Führen Sie die Drift-Erkennung routinemäßig für kritische Stacks und StackSets aus. Beachten Sie, dass nicht alle Eigenschaften für alle Ressourcentypen ausgewertet werden (nicht unterstützte Eigenschaften werden als „nicht geprüft“ gemeldet). Behandeln Sie Drift als einen Vorfall (Incident): Untersuchen Sie ihn, erfassen Sie den Kontext und korrigieren Sie ihn entweder durch ein Stack-Update oder indem Sie den Drift kodifizieren und erneut anwenden.

Stack Policies sind JSON-Dokumente, die kritische Ressourcen bei Updates schützen. Verweigern Sie Updates für unersetzliche Ressourcen (z. B. Produktionsdatenbanken, Route 53-Zonen) und verwenden Sie StackPolicyDuringUpdateBody, um vorübergehend einen gezielten Pfad für eine bestimmte Änderung zu öffnen und anschließend die strengere Richtlinie wiederherzustellen. Kombinieren Sie dies mit dem Terminationsschutz (Termination Protection) und der DeletionPolicy (Retain/Snapshot) als Leitplanken (Guardrails). Planen Sie für Ressourcen mit externem Zustand (S3-Buckets) das Verhalten beim Löschen. Wenn ein Bucket vor dem Löschen geleert werden muss, implementieren Sie eine Custom Resource, um Objekte beim Löschen des Stacks zu entfernen.

AWS CDK und Erweiterbarkeit von CloudFormation

Das AWS CDK modelliert Infrastruktur in bekannten Sprachen (TypeScript, Python, Java, .NET, Go). Constructs sind die Bausteine des CDK:

L1-Constructs (CfnXxx) werden aus der CloudFormation-Spezifikation generiert und bilden Ressourcen eins-zu-eins ab.
L2-Constructs fügen eine übergeordnete Absicht (high-level intent) und sinnvolle Standardwerte hinzu (z. B. ApplicationLoadBalancedFargateService).
L3-„Patterns“ setzen mehrere L2s zu einsatzbereiten Architekturen zusammen.

Eine CDK-App enthält einen oder mehrere Stacks. Während cdk synth löst die App Kontext-Lookups auf (z. B. VPC-IDs), rendert Assets und erzeugt ein CloudFormation-Template. Bevor Sie das Deployment durchführen, erstellt cdk bootstrap die Asset-Buckets und Rollen der Umgebung. Verwenden Sie cdk diff für eine Vorschau der Änderungen und dann cdk deploy, um Templates und Assets zu übermitteln. Das CDK verwendet intern Change Sets und zeigt sicherheitsrelevante Änderungen (IAM oder Ressourcenersetzungen) an und fordert eine Bestätigung an. Taggen Sie Stacks und Ressourcen mithilfe von Aspects, um ein unternehmensweites Tagging durchzusetzen. Wo L2-Abstraktionen nicht ausreichen, verwenden Sie „Escape Hatches“ (node.defaultChild) oder greifen Sie auf L1-Constructs zurück.

CloudFormation Custom Resources erweitern IaC auf alles, was über APIs zugänglich ist. Eine Lambda-gestützte Custom Resource empfängt Create-, Update- und Delete-Ereignisse mit einer RequestId, einer PhysicalResourceId und Eigenschaften. Die Funktion muss:

idempotent sein und innerhalb des Zeitfensters Erfolg/Misserfolg an die vorsignierte ResponseURL zurückmelden.
eine stabile PhysicalResourceId festlegen, um Updates zu verfolgen und die Bereinigung bei einem Delete-Vorgang zu steuern.
Wiederholungsversuche (Retries) und Wartezeiten zur Stabilisierung für nachgelagerte, eventuell konsistente Dienste handhaben.

Verwenden Sie IAM Execution Roles mit den geringsten Rechten (Least Privilege) für die Lambda-Funktion, implementieren Sie exponentielles Backoff bei API-Aufrufen und nutzen Sie die RequestId zur Log-Korrelation. Für große oder langlebige Operationen ziehen Sie Step Functions mit einer Custom Resource in Betracht, die auf ein Execution-Token wartet. Bevorzugen Sie, wo anwendbar, die CloudFormation Registry für wiederverwendbare, versionierte Provider.

Secrets und Parameter in Infrastructure as Code

Schreiben Sie Secrets niemals fest in Vorlagen oder Code. Verwenden Sie dynamische Referenzen, um sensible Werte zur Bereitstellungszeit aufzulösen:

Secrets Manager: {{resolve:secretsmanager:secret-id:SecretString:json-key:version-stage}}
SecureString Parameter Store: {{resolve:ssm-secure:parameter-name:version}}

Dynamische Referenzen verhindern, dass Secrets in der Stack-Vorlage oder in den Ereignissen gespeichert werden. Platzieren Sie keine Secrets in Outputs oder Ressourcen-Eigenschaften, die CloudFormation als Klartext protokolliert. Erteilen Sie der Ausführungsrolle von CloudFormation die Berechtigung zum Entschlüsseln oder Abrufen der referenzierten Werte und beschränken Sie den Geltungsbereich von KMS CMKs auf die Prinzipale, die Zugriff benötigen.

Der Parameter Store ist ideal für nicht-geheime Konfigurationen (Feature-Flags, AMI-IDs, Endpunkte). Verwenden Sie versionierte SSM-Parameter, um sichere Rollbacks und atomare Promotions über Umgebungen hinweg zu erstellen. Im CDK importieren Sie Werte mit ssm.StringParameter.fromStringParameterName oder fromSecureStringParameterAttributes für sichere Werte und binden Sie das Auslesen der Parameter in User Data oder Anwendungs-Bootstraps ein.

Der Secrets Manager ist für Lebenszyklus-Kontrollen, Rotation und Auditing ausgelegt. Integrieren Sie die Rotation mit unterstützten Engines (RDS, Aurora) oder benutzerdefinierten Lambdas. Referenzieren Sie Secrets zur Laufzeit, anstatt sie in AMIs einzubacken, um die Verbreitung von veraltetem Material zu vermeiden. Für containerisierte oder serverlose Workloads injizieren Sie Secrets über Umgebungsvariablen, die durch Secrets Manager-Referenzen gestützt werden, oder mounten Sie sie über ECS/TaskDefinition Secrets; rotieren Sie sie mit minimaler Ausfallzeit, indem Sie Connection-Pools mit kurzer TTL und Wiederholungsversuche (Retries) verwenden.

Konfigurationsmanagement und unveränderliche Infrastruktur

AWS OpsWorks bietet ein vorgegebenes (opinionated) Konfigurationsmanagement. OpsWorks Stacks verwendet Chef-Cookbooks und Lebenszyklus-Ereignisse (Setup, Configure, Deploy, Undeploy, Shutdown), um die Anwendungskonfiguration und -bereitstellung zu orchestrieren, und unterstützt die Selbstheilung durch Zustandsprüfungen (Health Checks), die Instanzen anhalten/starten oder ersetzen. In der Vergangenheit bot OpsWorks auch verwaltetes Chef Automate und Puppet Enterprise an. Heute standardisieren viele Teams auf den Systems Manager für die agentenbasierte Orchestrierung oder betreiben ihre eigenen Ansible/Chef/Puppet-Steuerungsebenen. Ansible ist nicht nativ in OpsWorks integriert. Verwenden Sie stattdessen den Systems Manager State Manager, um Playbooks auszuführen, oder AWX/Ansible Automation Platform mit SSM Session Manager-Konnektivität und dynamischem EC2-Inventar.

AWS Systems Manager ist die moderne Steuerungsebene für hybride Konfigurationen:

Der State Manager erzwingt den Soll-Zustand durch Associations (Verknüpfungen), die SSM-Dokumente (YAML/JSON) nach einem Zeitplan, bei einem Ereignis oder beim Start einer Instanz ausführen. Verwenden Sie AWS-RunShellScript, AWS-ApplyAnsiblePlaybooks, AWS-ConfigureDocker und benutzerdefinierte Dokumente, um die Konfiguration zu konvergieren. Parametrisieren Sie Associations und wählen Sie Ziele über Tags für flottenweite Änderungen aus.
Die Konfigurations-Compliance zeigt den Status von Associations und die Ergebnisse des Patch Managers an. Verwenden Sie Patch-Baselines, um genehmigte Klassifizierungen zu definieren, diese mit Wartungsfenstern (Maintenance Windows) zu verknüpfen und die Compliance nach Instanz-Tag, Patch-Gruppe oder Ressourcengruppe zu verfolgen. Hybrid Activations binden On-Premises-Knoten als verwaltete Instanzen für eine einheitliche Governance ein.
Inventory erfasst Pakete, Dateien und Windows-Updates; Resource Data Sync exportiert diese Daten nach S3 und Athena für das unternehmensweite Reporting. Kombinieren Sie die SSM-Compliance mit AWS Config-Regeln und automatischer Behebung (Systems Manager Automation Runbooks), um den Kreislauf von der Erkennung bis zur Korrektur zu schließen.

Unveränderliche Infrastruktur (Immutable Infrastructure) eliminiert Drift und beschleunigt Rollbacks. EC2 Image Builder kodifiziert Image-Pipelines mit:

Komponenten (Schritte zur Installation, Härtung und Validierung), die als Dokumente ausgedrückt werden.
Image-Rezepte, die Komponenten und Basis-Images zusammensetzen.
Infrastrukturkonfigurationen, die Subnetze, Sicherheitsgruppen, Instanzprofile und Protokollierung definieren.
Verteilungskonfigurationen, um AMIs in Regionen zu replizieren und für andere Konten freizugeben.

Fügen Sie Testkomponenten hinzu, um CIS-Benchmarks, den Zustand von Agenten (SSM/CloudWatch) und Anwendungs-Smoke-Tests zu validieren. Versionieren Sie Images und versehen Sie sie mit semantischen Tags. Veröffentlichen Sie AMI-IDs im Parameter Store (z. B. /app/frontend/ami) und referenzieren Sie diese in Auto Scaling Launch Templates. Führen Sie Deployments mit Rolling- oder Blau/Grün-Strategien durch; ersetzen Sie Instanzen anstatt In-Place-Patching durchzuführen, um die Unveränderlichkeit zu wahren. Speisen Sie Schwachstellenscans (Amazon Inspector) in die Promotion-Gates der Pipeline ein. Backen Sie keine Secrets in Images ein; rufen Sie diese beim Start über den Instance Metadata Service v2 und Referenzen auf SSM/Secrets Manager ab.

Praktisches Problemszenario

Capital One muss Multi-Account-, Multi-Region-Deployments für eine kundenorientierte Plattform standardisieren und dabei eine strikte Governance, Geheimnisverwaltung (Secret Management) und die Eliminierung von Konfigurationsdrift durchsetzen. Die Umgebung erstreckt sich über Hunderte von Konten in AWS Organizations, mit strengen Kontrollen für den Datenbankzugriff und die Härtung des Betriebssystems.

Infrastruktur mit AWS CDK modellieren und zu CloudFormation synthetisieren

Implementieren Sie L2/L3-Konstrukte für VPCs, ALBs, Auto Scaling Groups und Aurora. Verwenden Sie cdk synth und cdk diff in der CI, um Vorlagen und Change Sets zu generieren und zu validieren.
Warum CDK: Starke Komposition und Wiederverwendung durch Konstrukte, programmatische Richtlinien über Aspects für organisationsweites Tagging und Leitplanken (Guardrails) sowie native Integration mit CloudFormation für die Auditierbarkeit.

Baseline-Netzwerk- und Guardrail-Stacks über CloudFormation StackSets verteilen

Erstellen Sie service-verwaltete StackSets, die auf Sicherheits- und Sandbox-OUs abzielen, um gemeinsam genutzte VPC-Endpunkte, Standard-CloudWatch-Alarme und IAM-Grenzen (Boundaries) auszurollen. Aktivieren Sie die automatische Bereitstellung für neue Konten mit Fehlertoleranz und Parallelitätskontrollen.
Warum StackSets: Konsistentes Rollout im Organisationsmaßstab mit automatischer Einbeziehung neuer Konten und integrierter Drift-Erkennung.

Kritische Ressourcen mit Stack-Richtlinien und Change Sets schützen

Wenden Sie Stack-Richtlinien an, die Aktualisierungen von Aurora-Clustern und Route 53-Zonen verweigern. Fordern Sie in der Pipeline für die Produktion CreateChangeSet und eine manuelle Genehmigung vor ExecuteChangeSet an.
Warum Stack-Richtlinien/Change Sets: Erzwingen Sie Änderungen nach dem Prinzip der geringsten Rechte (Least Privilege) und ermöglichen Sie eine menschliche Überprüfung vor risikoreichen Änderungen.

IaC mit Lambda-gestützten Custom Resources erweitern

Implementieren Sie eine Custom::S3BucketCleanup, um Anwendungs-Buckets beim Löschen des Stacks zu leeren, und eine Custom::AuroraParameterTuner, die nach der Erstellung Engine-Parameter anwendet.
Warum Custom Resources: Schließen Sie funktionale Lücken in der deklarativen Bereitstellung, während der Lebenszyklus an den Stack gebunden bleibt.

Secrets und Konfiguration mit Secrets Manager und Parameter Store zentralisieren

Speichern Sie Datenbank-Anmeldeinformationen und API-Schlüssel im Secrets Manager mit Rotations-Lambdas; veröffentlichen Sie AMI-IDs, Feature-Flags und Endpunkte im Parameter Store. Referenzieren Sie Werte über dynamische Referenzen in CloudFormation und CDK-Importe zur Laufzeit für Anwendungen.
Warum diese Services: Trennung der Belange (Separation of Concerns) – Secrets mit Rotation und Audit, Parameter für nicht-geheime Konfigurationen und einfache Promotion.

Soll-Zustand und Compliance über den Systems Manager State Manager durchsetzen

Erstellen Sie Associations, um Agenten zu installieren, Betriebssystemeinstellungen zu konfigurieren und bei Bedarf Ansible-Playbooks anzuwenden. Verwenden Sie den Patch Manager mit Maintenance Windows für das Patchen außerhalb der Geschäftszeiten und Compliance-Dashboards, die durch Resource Data Sync aggregiert werden.
Warum State Manager: Agentenbasierte Konvergenz über EC2 und On-Premises hinweg mit kontinuierlichem Compliance-Reporting und skalierbarer Problembehebung.

Unveränderliche Infrastruktur mit EC2 Image Builder einführen

Erstellen Sie gehärtete AMIs mit Komponenten für CIS-Baselines, SSM/Inspector-Agenten und App-Laufzeitabhängigkeiten. Führen Sie Tests durch, veröffentlichen Sie AMI-IDs im Parameter Store und verknüpfen Sie Auto Scaling Launch Templates mit den versionierten Parametern. Führen Sie Deployments über Rolling Updates durch; lösen Sie bei AMI-Aktualisierungen eine Instanzaktualisierung (Instance Refresh) aus.
Warum Image Builder: Reproduzierbare, testbare Images, die Drift eliminieren und die mittlere Wiederherstellungszeit (MTTR) durch schnelle Rollbacks reduzieren.

Pipeline-Orchestrierung und Governance

Implementieren Sie eine mehrstufige Pipeline, die cdk synth/diff ausführt, Change Sets erstellt, auf eine Genehmigung wartet und dann die Ausführung startet. Verwenden Sie EventBridge, um StackSet-Updates bei Änderungen im Repository auszulösen. Fügen Sie nächtliche Scans zur Drift-Erkennung hinzu und öffnen Sie bei Abweichungen OpsCenter-Items.
Warum dieser Ansatz: Continuous Delivery mit auditierbaren Promotions, proaktiver Drift-Erkennung und automatisierter Behebung durch klar definierte Service-Zuständigkeiten.

← CI · Alle Domänen · Monitoring →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →