Amazon SOA-C02: Bereitstellung, Provisionierung und Automatisierung — Lernleitfaden

By Laurynas Brazys · 2 August 2026 · #amazon #soa-c02 #certification #exam-prep #study-guide

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

AWS Systems Manager-Automatisierung, Run Command und Patching

Systems Manager (SSM) zentralisiert operative Aufgaben: Run Command für Ad-hoc-Befehle, State Manager für den Soll-Zustand, Patch Manager für geplantes OS-Patching und Automation für komplexe Workflows. Gängige CLI-Muster:

Ad-hoc senden:

undefined

Vordefinierte Automatisierung starten:

undefined

Verwenden Sie State Manager-Assoziationen, um Konfigurationen (z. B. SSM-Agent-Konfiguration, Cron-Jobs) durchzusetzen, und Patch Manager-Baselines für Genehmigungsregeln und Compliance-Scans.

Konfigurationsdetails und Entscheidungspunkte:

Verwenden Sie Patch Manager mit Baselines und Maintenance Windows für vorhersagbares, konformes Patching; wählen Sie Tage für die automatische Genehmigung und lehnen Sie nicht genehmigte AMI-Images ab, wenn Sie eine unveränderliche Strategie (Immutable Strategy) verwenden.
Für Instanzen ohne SSM-Agent oder mit eingeschränktem Netzwerk ziehen Sie den Session Manager mit VPC-Endpunkten in Betracht, um das Öffnen von SSH-Ports zu vermeiden.
Erfordern Sie immer ein Instanzprofil mit der Richtlinie AmazonSSMManagedInstanceCore für den SSM-Zugriff; grenzen Sie zusätzliche Berechtigungen nach Bedarf ein.

Änderungsmanagement, Drift-Erkennung und Rollback

Implementieren Sie eine Änderungskontrolle, die Pipeline-Durchläufe, Tags und Genehmigungen integriert. Verwenden Sie CloudFormation Change Sets zur Vorschau von Unterschieden (Diffs) und Stack-Richtlinien (Stack Policies), um destruktive Aktualisierungen abzulehnen. CLI-Muster:

Drift erkennen:

undefined

und

undefined

Verwenden Sie eine Stack-Richtlinie (Stack Policy) zum Schutz kritischer Ressourcen während Aktualisierungen und setzen Sie eine RollbackConfiguration mit Rollback-Triggern, um bei fehlgeschlagenen Updates benachrichtigt zu werden.

Rollback-Strategien:

Für CloudFormation: Der automatische Rollback bei einem Fehler ist Standard; verwenden Sie Rollback-Trigger und behalten Sie Ressourcen bei Bedarf bei (Retain).
Für Anwendungen: Bevorzugen Sie Blue/Green oder Canary mit Traffic-Verschiebung, um einen sofortigen Rollback durch Neugewichtung von ALB/Route 53 oder die Wiederherstellung früherer Task-Sets zu ermöglichen.
Pflegen Sie unveränderliche Artefakte (AMI-IDs, Container-Images) und bewahren Sie frühere Versionen in Registries/SSM auf, damit Rollbacks deterministisch sind.

Entscheidungskriterien:

Wenn zustandsbehaftete Datenmigrationen beteiligt sind, fügen Sie umkehrbare Migrationsskripte hinzu oder verwenden Sie Feature-Flags, um die Code-Veröffentlichung von der Schema-Migration zu trennen.
Verwenden Sie Zustandsprüfungen (Health Checks) für das Deployment und automatisierte Smoke-Tests als Pipeline-Gating, um Rollbacks frühzeitig auszulösen.

Häufige Fallstricke und Entscheidungskriterien

Manuelle Änderungen über die Konsole („out-of-band“), die den IaC-Zustand abweichen lassen (Drift): Erzwingen Sie die Drift-Erkennung (aws cloudformation detect-stack-drift) und fordern Sie, dass Korrekturen über IaC-Vorlagen angewendet werden; verwenden Sie IAM-Kontrollen, um Bearbeitungen in der Konsole einzuschränken.
Kein sicherer Rollback-Plan für Releases: Führen Sie Blue/Green- oder Canary-Deployments ein und halten Sie frühere Artefakte/AMIs verfügbar, um sofort zurückkehren zu können.
Übermäßig freizügige IAM-Berechtigungen für Pipelines und Rollen: Wenden Sie das Prinzip der geringsten Rechte (Least Privilege) an; teilen Sie Rollen auf (Pipeline-Servicerolle, Build-Rolle, Instanzprofil) und gewähren Sie nur den notwendigen Zugriff auf ssm:GetParameter, secretsmanager:GetSecretValue, kms:Decrypt und s3.
Speichern von Secrets direkt in Vorlagen oder als Klartext: Verschieben Sie Secrets in den Secrets Manager oder den SSM Parameter Store als SecureString und referenzieren Sie sie zum Zeitpunkt des Deployments mit den entsprechenden Entschlüsselungsberechtigungen.
Patchen der Produktion „in-place“ ohne Tests: Erstellen Sie AMIs („baking“) in der CI mit aktualisierten Paketen und Smoke-Tests und rollen Sie dann unveränderliche Images über ASG- oder Blue/Green-Pipelines aus.
Ignorieren von Drift und Schutz zustandsbehafteter Ressourcen: Verwenden Sie Stack-Richtlinien (Stack Policies) und erkennen Sie Drift regelmäßig; fordern Sie für zustandsbehaftete Ressourcen eine manuelle Genehmigung und Snapshots vor destruktiven Änderungen.

Praktisches Problem: Anwendungsfallszenario

Acme Payments muss einen PCI-konformen API-Dienst bereitstellen, monatliche Betriebssystem-Patches anwenden und in der Lage sein, schnell ein Rollback durchzuführen, wenn ein Deployment während der Geschäftszeiten Fehler verursacht.

Implementieren Sie eine unveränderliche (Immutable) Pipeline: Verwenden Sie CodePipeline/CodeBuild, um AMIs mit dem EC2 Image Builder (oder Packer) zu erstellen („baking“), AMIs zu taggen und die AMI-ID im SSM Parameter Store zu veröffentlichen.
Stellen Sie über CloudFormation-Vorlagen bereit, die den SSM-Parameter für das AMI referenzieren, und erstellen Sie für jedes Release eine neue Version der ASG + Launch Template; verwenden Sie Change Sets für eine Überprüfung vor dem Start (Pre-Flight Review).
Verwenden Sie CodeDeploy oder Blue/Green-Traffic-Shifting auf ALB-Zielgruppen mit Zustandsprüfungen (Health Checks) und automatisierten Smoke-Tests; konfigurieren Sie einen automatischen Rollback bei fehlgeschlagenen Zustandsprüfungen.
Planen Sie den Patch Manager über Systems Manager Maintenance Windows für die Anwendung von Patches außerhalb der Spitzenzeiten; führen Sie „Bake-and-Deploy“ für gepatchte Images durch, um das „In-Place“-Patchen der Produktion zu vermeiden.
Erzwingen Sie IAM mit den geringsten Rechten (Least-Privilege) für Pipeline-Rollen, speichern Sie Secrets im Secrets Manager und aktivieren Sie die CloudFormation Drift-Erkennung und Stack-Richtlinien (Stack Policies) für kritische Ressourcen.

Begründung: Das Erstellen von Images („Baking“) und die unveränderliche Bereitstellung (Immutable Deployment) trennen die Belange von Build und Betrieb, was zu reproduzierbaren Artefakten und sicheren Rollback-Pfaden führt; automatisiertes Patching über SSM in Verbindung mit unveränderlichen Deployments minimiert das Risiko, unterstützt die Compliance und erhält die Wiederherstellbarkeit.

← Hochverfügbarkeit · Alle Domänen · Sicherheit →

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