Amazon SOA-C02: Wdrażanie, aprowizacja i automatyzacja — Przewodnik do nauki

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

Część AWS SysOps Administrator Associate SOA-C02 — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Amazon, albo rozwiąż testy na czas na ExamRoll.io.

Automatyzacja, Run Command i łatanie w AWS Systems Manager

Systems Manager (SSM) centralizuje zadania operacyjne: Run Command do doraźnych poleceń, State Manager do utrzymywania pożądanego stanu, Patch Manager do planowego łatania systemów operacyjnych oraz Automation do złożonych przepływów pracy. Typowe wzorce CLI:

Wysyłanie polecenia ad-hoc: aws ssm send-command –instance-ids i-0123456789abcdef0 –document-name “AWS-RunShellScript” –parameters commands=’[“yum update -y”]'
Uruchamianie predefiniowanej automatyzacji: aws ssm start-automation-execution –document-name “AWS-ApplyPatchBaseline” –parameters “InstanceIds=[‘i-…’]”
Używanie powiązań (associations) w State Manager do wymuszania konfiguracji (np. konfiguracji agenta SSM, zadań cron) oraz wzorców (baselines) w Patch Manager do definiowania reguł zatwierdzania i skanów zgodności.

Szczegóły konfiguracji i punkty decyzyjne:

Używaj Patch Manager z wzorcami (Baselines) i oknami konserwacji (Maintenance Windows) dla przewidywalnego i zgodnego z wymogami łatania; wybierz dni na automatyczne zatwierdzanie i odrzucaj niezatwierdzone obrazy AMI, jeśli stosujesz strategię niemutowalną.
Dla instancji bez agenta SSM lub z ograniczonym dostępem do sieci, rozważ użycie Session Manager z punktami końcowymi VPC, aby uniknąć otwierania portów SSH.
Zawsze wymagaj profilu instancji z polityką AmazonSSMManagedInstanceCore dla dostępu SSM; ograniczaj dodatkowe uprawnienia w miarę potrzeb.

Zarządzanie zmianą, wykrywanie dryfu i wycofywanie zmian

Wdróż kontrolę zmian, która integruje uruchomienia potoku (pipeline), tagi i zatwierdzenia. Używaj zestawów zmian (change sets) w CloudFormation do podglądu różnic oraz polityk stosu (stack policies) do odrzucania destrukcyjnych aktualizacji. Wzorce CLI:

Wykrywanie dryfu: aws cloudformation detect-stack-drift –stack-name my-stack oraz aws cloudformation describe-stack-resource-drifts –stack-name my-stack
Używaj polityki stosu do ochrony krytycznych zasobów podczas aktualizacji i ustaw RollbackConfiguration z wyzwalaczami wycofywania (rollback triggers), aby otrzymywać powiadomienia o nieudanych aktualizacjach.

Strategie wycofywania zmian (rollback):

Dla CloudFormation: automatyczne wycofywanie w przypadku błędu jest domyślne; używaj wyzwalaczy wycofywania i zachowuj zasoby (retain resources), gdy jest to wymagane.
Dla aplikacji: preferuj wdrożenia blue/green lub canary z przesuwaniem ruchu, aby umożliwić natychmiastowe wycofanie zmian poprzez zmianę wag w ALB/Route 53 lub przywrócenie poprzednich zestawów zadań (task sets).
Utrzymuj niemutowalne artefakty (ID obrazów AMI, obrazy kontenerów) i zachowuj poprzednie wersje w rejestrach/SSM, aby wycofywanie zmian było deterministyczne.

Kryteria decyzyjne:

Jeśli proces obejmuje migracje danych stanowych, dołącz odwracalne skrypty migracyjne lub użyj flag funkcyjnych (feature flags), aby oddzielić wydanie kodu od migracji schematu.
Używaj kontroli kondycji wdrożenia i zautomatyzowanych testów dymnych (smoke tests) jako bramkowania w potoku, aby wcześnie uruchamiać proces wycofywania zmian.

Częste pułapki i kryteria decyzyjne

Dokonywanie ręcznych zmian w konsoli poza procesem (out-of-band), które powodują dryf stanu IaC: wymuszaj wykrywanie dryfu (aws cloudformation detect-stack-drift) i wymagaj, aby poprawki były wprowadzane przez szablony IaC; używaj kontroli IAM, aby ograniczyć możliwość edycji w konsoli.
Brak bezpiecznego planu wycofywania zmian dla wydań: zaadaptuj wdrożenia blue/green lub canary i utrzymuj dostępność poprzednich artefaktów/AMI, aby móc natychmiast przywrócić poprzednią wersję.
Zbyt szerokie uprawnienia IAM dla potoków i ról: stosuj zasadę najmniejszych uprawnień; rozdzielaj role (rola serwisowa potoku, rola budowania, profil instancji) i nadawaj tylko niezbędny dostęp do ssm:GetParameter, secretsmanager:GetSecretValue, kms:Decrypt i S3.
Przechowywanie sekretów bezpośrednio w szablonach lub jako zwykły tekst: przenieś sekrety do Secrets Manager lub Parameter Store jako SecureString i odwołuj się do nich w czasie wdrożenia z odpowiednimi uprawnieniami do deszyfrowania.
Łatanie produkcji w miejscu (in-place) bez testowania: twórz (piecz) obrazy AMI w procesie CI z zaktualizowanymi pakietami i testami dymnymi, a następnie wdrażaj niemutowalne obrazy za pomocą ASG lub potoków blue/green.
Ignorowanie dryfu i ochrony zasobów stanowych: używaj polityk stosu i regularnie wykrywaj dryf; dla zasobów stanowych wymagaj ręcznego zatwierdzenia i tworzenia snapshotów przed wprowadzeniem destrukcyjnych zmian.

Problem praktyczny: Scenariusz użycia

Firma Acme Payments musi wdrożyć usługę API zgodną z PCI, aplikować comiesięczne łatki systemu operacyjnego i mieć możliwość szybkiego wycofania zmian, jeśli wdrożenie spowoduje błędy w godzinach pracy.

Zaimplementuj niemutowalny potok: użyj CodePipeline/CodeBuild do tworzenia (pieczenia) obrazów AMI za pomocą EC2 Image Builder (lub Packer), taguj obrazy AMI i publikuj ich ID w SSM Parameter Store.
Wdrażaj za pomocą szablonów CloudFormation, które odwołują się do parametru SSM z ID obrazu AMI i tworzą nową wersję ASG + Launch Template dla każdego wydania; używaj zestawów zmian (change sets) do przeglądu przed wdrożeniem.
Użyj CodeDeploy lub przesuwania ruchu blue/green w grupach docelowych ALB z kontrolami kondycji i zautomatyzowanymi testami dymnymi; skonfiguruj automatyczne wycofanie zmian w przypadku niepowodzenia kontroli kondycji.
Zaplanuj działanie Patch Manager za pomocą okien konserwacji (Maintenance Windows) w Systems Manager, aby aplikować łatki poza godzinami szczytu; wykonuj proces tworzenia i wdrażania (bake-and-deploy) dla załatanych obrazów, aby uniknąć łatania produkcji w miejscu (in-place).
Wymuszaj zasadę najmniejszych uprawnień IAM dla ról potoku, przechowuj sekrety w Secrets Manager oraz włącz wykrywanie dryfu i polityki stosu w CloudFormation dla krytycznych zasobów.

Uzasadnienie: Tworzenie obrazów i niemutowalne wdrażanie oddziela procesy budowania i uruchamiania, co daje odtwarzalne artefakty i bezpieczne ścieżki wycofywania zmian; zautomatyzowane łatanie przez SSM w połączeniu z niemutowalnymi wdrożeniami minimalizuje ryzyko i wspiera zgodność z wymogami, zachowując jednocześnie możliwość odzyskiwania systemu.

← Wysoka dostępność · Wszystkie domeny · Bezpieczeństwo →

Przećwicz te pytania → · Testy na czas na ExamRoll.io →