Amazon DVA-C02: Bereitstellung und CI/CD (CodePipeline, CodeBuild, CodeDeploy, Elastic Beanstalk, Containers) — Lernleitfaden

By Laurynas Brazys · 27 July 2026 · #amazon #dva-c02 #certification #exam-prep #study-guide

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

Validierung vor der Bereitstellung, Rollbacks und Beobachtbarkeit: Tests, Hooks und betriebliche Sicherheitsmaßnahmen

Integrieren Sie automatisierte Unit-, Integrations- und Smoke-Tests in die Pipeline-Phasen. Verwenden Sie CodeBuild zur Ausführung von Tests und AWS X-Ray oder CloudWatch Logs für Tracing und strukturierte Protokolle; annotieren Sie X-Ray-Traces mit PutAnnotation in den SDKs, damit nachgelagerte Abfragen nach Benutzer- oder Anforderungsattributen filtern können. Für die Phase vor der Bereitstellung (Pre-Deployment) nutzen Sie manuelle Genehmigungsaktionen in CodePipeline oder automatisierte Validierungsschritte: führen Sie Canary-Prüfungen über CodeBuild aus, die den bereitgestellten Endpunkt testen, oder rufen Sie CloudWatch Synthetics Canaries auf, um skriptgesteuerte Überprüfungen durchzuführen. Verwenden Sie CodeDeploy-Lifecycle-Hooks (BeforeAllowTraffic, AfterAllowTraffic), um Zustandsprüfungen (Health Checks) und Registrierungs-/Deregistrierungslogik auszuführen. Implementieren Sie automatische Rollback-Trigger: konfigurieren Sie CodeDeploy so, dass bei einem Deployment-Status ungleich Null oder bei fehlgeschlagenen Alarmen (CloudWatch-Alarme, die der Deployment-Gruppe zugeordnet sind) ein Rollback durchgeführt wird. Für Lambda verwenden Sie Aliase mit Traffic Shifting, um ein schnelles Rollback zu ermöglichen, indem Sie den Alias so aktualisieren, dass er auf die vorherige Version verweist. Zu den Fallen für Entwickler gehören nicht übereinstimmende Timeouts (Lambda-Timeout kürzer als das SQS Visibility Timeout), das Vergessen, AppSpec-Hooks für ECS/CodeDeploy korrekt zu setzen, und das Verlassen auf den Erfolg von Deployment-API-Aufrufen, ohne das Laufzeitverhalten zu validieren. Instrumentieren Sie Deployments mit Metriken und Alarmen und verwenden Sie unveränderliche Bezeichner (immutable identifiers) in Artefakten zur Nachverfolgbarkeit.

Praktisches Problem: Anwendungsfallszenario

Szenario: ExampleRetail betreibt eine Microservices-Storefront in AWS über Dev-, Test- und Prod-Konten hinweg. Sie verwenden CodeCommit für den Quellcode, CodePipeline/CodeBuild für CI, ECR für Images, ECS/Fargate für Services hinter einem ALB und Lambda für asynchrone Worker.

Herausforderung: Ein Entwickler muss eine sichere, automatisierte Pipeline hinzufügen, um einen neuen Checkout-Service-Container mit Canary-Traffic-Shifting und automatisierter Validierung vor der Bereitstellung bereitzustellen, die bei einem Fehler ein Rollback durchführt.

Empfohlener Ansatz:

1. Erstellen Sie ein CodeBuild-Projekt, das das Docker-Image baut, Unit-Tests ausführt, sich bei ECR anmeldet (aws ecr get-login-password | docker login –username AWS –password-stdin ${ACCOUNT}.dkr.ecr.${REGION}.amazonaws.com), das Image pusht und ein JSON-Artefakt mit dem Image-Digest ausgibt.
2. Fügen Sie in CodePipeline eine Bereitstellungsphase (Deploy Stage) hinzu, die eine neue ECS-Task-Definition über ecs.registerTaskDefinition unter Referenzierung des Image-Digests registriert. Erstellen Sie anschließend ein CodeDeploy-ECS-Deployment durch Aufrufen von codedeploy.createDeployment mit einer AppSpec, die die neue Task-Definition und eine für Canary festgelegte deploymentConfig (z. B. CodeDeployDefault.ECSCanary10Percent5Minutes) bindet.
3. Fügen Sie eine CodeBuild-basierte Validierungsaktion oder einen CloudWatch Synthetics Canary als Test nach der Bereitstellung (Post-Deploy-Test) hinzu, der kritische Checkout-Endpunkte aufruft und die Antworten validiert. Sorgen Sie dafür, dass die Pipeline auf eine erfolgreiche Validierung wartet.
4. Konfigurieren Sie CodeDeploy-Rollback-Optionen und einen CloudWatch-Alarm, der mit der Deployment-Gruppe verknüpft ist (z. B. 5xx-Fehlerrate oder Latenz), um bei Überschreitung der Schwellenwerte automatisch abzubrechen und ein Rollback durchzuführen.

Begründung: Das Erstellen von unveränderlichen Images (immutable images), das Registrieren von Task-Definitionen mit expliziten Image-Digests und die Verwendung von CodeDeploys Traffic-Shifting plus automatisierter Validierung ermöglichen sichere Canary-Releases und ein schnelles, automatisiertes Rollback, während gleichzeitig sichergestellt wird, dass die Bereitstellungen reproduzierbar und beobachtbar sind.

← CloudFormation und Infrastruktur als Code (SAM · Alle Domänen · Sicherheit →

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

Amazon durchsuchen →