Amazon DOP-C02: Infrastruktura jako kod i zarządzanie konfiguracją — Przewodnik do nauki

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

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

Przegląd

Infrastruktura jako kod (IaC) i zarządzanie konfiguracją w AWS zapewniają powtarzalny, audytowalny i zarządzany provisioning oraz konfigurację infrastruktury i aplikacji. CloudFormation i AWS Cloud Development Kit (CDK) opisują zasoby deklaratywnie lub za pomocą kodu, który jest syntetyzowany do szablonów CloudFormation. Warstwy konfiguracyjne, takie jak AWS OpsWorks i AWS Systems Manager, wymuszają i raportują pożądany stan na instancjach w ramach flot EC2 i hybrydowych. Zarządzanie sekretami, parametrami i wypiekanie obrazów dopełniają cykl życia, umożliwiając niezmienne, bezpieczne wdrożenia na dużą skalę.

Stosy CloudFormation, kontrola zmian i ład

Stosy CloudFormation są jednostką wdrożenia. Projektuj stosy wokół granic cyklu życia i własności, aby zminimalizować promień rażenia. Oszczędnie używaj parametrów i preferuj narzucone z góry wartości domyślne z mapowaniami lub odwołaniami do SSM. Eksportuj i importuj tylko stabilne, współdzielone wartości za pomocą Outputs i Fn::ImportValue, aby uniknąć ścisłych powiązań.

Stosy zagnieżdżone hermetyzują komponenty wielokrotnego użytku i pozwalają utrzymać mały rozmiar szablonów nadrzędnych. Stos nadrzędny może przekazywać parametry do stosów podrzędnych i wykorzystywać ich wartości wyjściowe, co umożliwia tworzenie architektur modułowych (na przykład zagnieżdżony stos ze współdzieloną siecią, wykorzystywany przez stos aplikacji). Utrzymuj stosy zagnieżdżone skoncentrowane na jednym zadaniu (VPC, warstwa danych, warstwa aplikacji) i wersjonuj je niezależnie.

StackSets wdrażają pojedynczy szablon na wielu kontach i w wielu regionach. Użyj modelu uprawnień zarządzanego przez usługę (service-managed) z AWS Organizations, aby automatycznie wdrażać zasoby w jednostkach organizacyjnych (OU) i automatycznie obejmować nowe konta. Skonfiguruj preferencje operacji (maksymalna liczba jednoczesnych kont/regionów, tolerancja na błędy), aby kontrolować proces wdrażania. Nadpisywanie parametrów dla poszczególnych kont lub regionów pozwala dostosować standardowy szablon do lokalnych ograniczeń. Monitoruj dryf w StackSet i instancjach stosów, aby wykrywać zmiany wprowadzane poza standardowym procesem.

Zestawy zmian (change sets) zapewniają bezpieczne aktualizacje, które mogą być weryfikowane przez człowieka. Zawsze używaj CreateChangeSet i sprawdzaj wpływ na poszczególne zasoby, wymiany oraz potencjalną utratę danych przed wykonaniem ExecuteChangeSet. Integruj zestawy zmian z automatycznymi potokami (pipelines) w celu uzyskania kontrolowanych zatwierdzeń.

Wykrywanie dryfu (drift detection) weryfikuje, czy zasoby stosu są zgodne z szablonem. Uruchamiaj regularnie wykrywanie dryfu na krytycznych stosach i StackSets; pamiętaj, że nie wszystkie właściwości są oceniane dla wszystkich typów zasobów (niewspierane właściwości są raportowane jako „not checked”). Traktuj dryf jako incydent: zbadaj go, zbierz kontekst i napraw poprzez aktualizację stosu lub poprzez skodyfikowanie zmiany i ponowne jej zastosowanie.

Polityki stosu (stack policies) to dokumenty JSON, które chronią krytyczne zasoby podczas aktualizacji. Odmów aktualizacji niezastępowalnym zasobom (np. produkcyjnym bazom danych, strefom Route 53) i użyj StackPolicyDuringUpdateBody, aby tymczasowo otworzyć precyzyjną ścieżkę dla konkretnej zmiany, a następnie przywrócić bardziej restrykcyjną politykę. Połącz to z ochroną przed usunięciem (termination protection) i DeletionPolicy (Retain/Snapshot), aby stworzyć mechanizmy zabezpieczające. Dla zasobów ze stanem zewnętrznym (np. bucketów S3) zaplanuj zachowanie podczas usuwania. Jeśli bucket musi zostać opróżniony przed usunięciem, zaimplementuj zasób niestandardowy (custom resource), który wyczyści obiekty podczas usuwania stosu.

AWS CDK i rozszerzalność CloudFormation

AWS CDK modeluje infrastrukturę w znanych językach programowania (TypeScript, Python, Java, .NET, Go). Konstrukty (constructs) to podstawowe elementy składowe CDK:

• Konstrukty L1 (CfnXxx) są generowane ze specyfikacji CloudFormation i mapują się jeden do jednego na zasoby.
• Konstrukty L2 dodają intencje wysokiego poziomu i rozsądne wartości domyślne (np. ApplicationLoadBalancedFargateService).
• Wzorce L3 („patterns”) składają się z wielu konstruktów L2, tworząc gotowe do użycia architektury.

Aplikacja CDK zawiera jeden lub więcej stosów. Podczas wykonania cdk synth aplikacja rozwiązuje odwołania do kontekstu (np. ID VPC), renderuje zasoby (assets) i tworzy szablon CloudFormation. Przed wdrożeniem, polecenie cdk bootstrap tworzy w środowisku buckety na zasoby (assets) oraz odpowiednie role. Użyj cdk diff, aby podejrzeć zmiany, a następnie cdk deploy, aby wdrożyć szablony i zasoby; CDK wewnętrznie używa zestawów zmian (change sets) i wyświetli oraz poprosi o potwierdzenie zmian wrażliwych na bezpieczeństwo (zmiany w IAM lub wymiana zasobów). Taguj stosy i zasoby za pomocą Aspects, aby wymusić tagowanie w całej organizacji. Gdy abstrakcje L2 są niewystarczające, użyj mechanizmów ucieczki (escape hatches), takich jak node.defaultChild, lub zejdź do poziomu konstruktów L1.

Niestandardowe zasoby CloudFormation (custom resources) rozszerzają IaC o wszystko, co jest dostępne przez API. Zasób niestandardowy oparty na funkcji Lambda otrzymuje zdarzenia Create, Update i Delete wraz z RequestId, PhysicalResourceId i właściwościami. Funkcja musi:

• Być idempotentna i zwrócić status powodzenia/niepowodzenia na podpisany adres URL (presigned ResponseURL) w określonym oknie czasowym (timeout).
• Ustawić stabilny PhysicalResourceId, aby śledzić aktualizacje i sterować czyszczeniem podczas operacji Delete.
• Obsługiwać ponowienia prób i oczekiwanie na stabilizację dla usług podrzędnych o spójności ostatecznej (eventually consistent).

Używać ról wykonawczych IAM o najmniejszych uprawnieniach dla funkcji Lambda, implementować wykładnicze ponawianie (exponential backoff) dla wywołań API i korelować logi za pomocą RequestId. W przypadku dużych lub długotrwałych operacji rozważ użycie Step Functions z zasobem niestandardowym, który czeka na token wykonania. Jeśli to możliwe, preferuj CloudFormation Registry dla dostawców (providers) wielokrotnego użytku i wersjonowanych.

Sekrety i parametry w infrastrukturze jako kodzie

Nigdy nie umieszczaj sekretów na stałe w szablonach ani w kodzie. Używaj dynamicznych referencji, aby odczytywać wrażliwe wartości w czasie wdrożenia:

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

Dynamiczne referencje zapobiegają przechowywaniu sekretów w szablonie stosu lub w jego zdarzeniach. Nie umieszczaj sekretów w sekcji Outputs ani we właściwościach zasobów, które CloudFormation loguje jako czysty tekst. Nadaj roli wykonawczej CloudFormation uprawnienia do deszyfrowania lub pobierania wartości z referencji i ogranicz zasięg kluczy KMS CMK do podmiotów (principals), które potrzebują dostępu.

Parameter Store jest idealny do przechowywania konfiguracji niebędącej sekretem (np. flagi funkcjonalności, identyfikatory AMI, punkty końcowe). Używaj wersjonowanych parametrów SSM, aby umożliwić bezpieczne wycofywanie zmian (rollback) i atomowe promowanie konfiguracji między środowiskami. W CDK importuj wartości za pomocą ssm.StringParameter.fromStringParameterName lub fromSecureStringParameterAttributes dla wartości bezpiecznych, a odczyty parametrów włącz do skryptów user data lub procesów bootstrap aplikacji.

Secrets Manager jest przeznaczony do zarządzania cyklem życia sekretów, ich rotacji i audytu. Zintegruj rotację z obsługiwanymi silnikami (RDS, Aurora) lub z własnymi funkcjami Lambda. Odwołuj się do sekretów w czasie działania aplikacji, zamiast wbudowywać je w obrazy AMI, aby uniknąć rozprzestrzeniania się nieaktualnych danych. W przypadku obciążeń skonteneryzowanych lub serverless, wstrzykuj sekrety poprzez zmienne środowiskowe oparte na referencjach do Secrets Manager lub montuj je za pomocą mechanizmu secrets w ECS/TaskDefinition; zapewnij rotację z minimalnym przestojem, używając pul połączeń z krótkim czasem życia (TTL) i mechanizmów ponawiania prób.

Zarządzanie konfiguracją i niezmienna infrastruktura

AWS OpsWorks zapewnia predefiniowane zarządzanie konfiguracją. OpsWorks Stacks używa książek kucharskich (cookbooks) Chef i zdarzeń cyklu życia (Setup, Configure, Deploy, Undeploy, Shutdown) do orkiestracji konfiguracji i wdrożeń aplikacji, a także wspiera automatyczne naprawianie (auto-healing) za pomocą kontroli stanu (health checks), które zatrzymują/uruchamiają lub zastępują instancje. Historycznie OpsWorks oferował również zarządzane instancje Chef Automate i Puppet Enterprise; dziś wiele zespołów standaryzuje się na Systems Manager do orkiestracji opartej na agentach lub samodzielnie uruchamia płaszczyzny sterowania Ansible/Chef/Puppet. Ansible nie jest natywnie zintegrowany z OpsWorks; zamiast tego należy użyć Systems Manager State Manager do uruchamiania playbooków lub AWX/Ansible Automation Platform z łącznością przez SSM Session Manager i dynamicznym inwentarzem EC2 (dynamic inventory).

AWS Systems Manager to nowoczesna płaszczyzna sterowania dla konfiguracji hybrydowej:

• State Manager wymusza pożądany stan poprzez powiązania (Associations), które uruchamiają dokumenty SSM (YAML/JSON) zgodnie z harmonogramem, w odpowiedzi na zdarzenie lub przy starcie instancji. Użyj dokumentów

undefined

,

undefined

,

undefined

i niestandardowych, aby ujednolicić konfigurację. Parametryzuj powiązania i kieruj je na zasoby według tagów, aby wprowadzać zmiany w całej flocie.

• Configuration Compliance (zgodność konfiguracji) prezentuje status powiązań i wyniki Patch Manager. Użyj wzorców poprawek (patch baselines) do definiowania zatwierdzonych klasyfikacji, powiąż je z oknami konserwacyjnymi (Maintenance Windows) i śledź zgodność według tagu instancji, grupy poprawek (patch group) lub grupy zasobów. Hybrid Activations umożliwiają włączenie węzłów on-premises jako zarządzanych instancji (managed instances) w celu jednolitego zarządzania.
• Inventory rejestruje pakiety, pliki i aktualizacje Windows; Resource Data Sync eksportuje dane do S3 i Athena w celu raportowania na poziomie przedsiębiorstwa. Połącz zgodność SSM z regułami AWS Config i automatyczną naprawą (runbooki Systems Manager Automation), aby zamknąć pętlę od wykrycia do naprawy.

Niezmienna infrastruktura eliminuje dryf konfiguracyjny i przyspiesza wycofywanie zmian (rollback). EC2 Image Builder kodyfikuje potoki (pipelines) do tworzenia obrazów za pomocą:

• Komponentów (kroki instalacji, wzmacniania zabezpieczeń i walidacji) wyrażonych jako dokumenty.
• Receptur obrazów (image recipes), które składają komponenty i obrazy bazowe.
• Konfiguracji infrastruktury definiujących podsieci, grupy bezpieczeństwa, profile instancji i logowanie.
• Konfiguracji dystrybucji do replikowania obrazów AMI do Regionów i udostępniania ich innym kontom.

Dodaj komponenty testowe do walidacji benchmarków CIS, stanu agentów (SSM/CloudWatch) i podstawowych testów aplikacji (smoke checks). Wersjonuj obrazy i oznaczaj je tagami semantycznymi. Publikuj identyfikatory AMI w Parameter Store (na przykład /app/frontend/ami) i odwołuj się do nich w szablonach uruchamiania (launch templates) Auto Scaling. Wdrażaj za pomocą strategii rolling lub blue/green; zastępuj instancje zamiast patchować je w miejscu, aby zachować niezmienność. Przekazuj wyniki skanowania podatności (Amazon Inspector) do bramek promujących w potoku (pipeline promotion gates). Nie umieszczaj na stałe sekretów w obrazach; pobieraj je podczas uruchamiania za pomocą Instance Metadata Service v2 oraz odwołań do SSM/Secrets Manager.

Praktyczny scenariusz problemowy

Firma Capital One musi ustandaryzować wdrożenia w środowisku wielokontowym i wieloregionowym dla platformy skierowanej do klienta, jednocześnie egzekwując ścisły nadzór, zarządzanie sekretami i eliminując dryf konfiguracyjny. Środowisko obejmuje setki kont w AWS Organizations, z rygorystycznymi kontrolami dostępu do baz danych i wzmacnianiem zabezpieczeń systemu operacyjnego.

1. Modeluj infrastrukturę za pomocą AWS CDK i syntezuj do CloudFormation

• Zaimplementuj konstrukty L2/L3 dla VPC, ALB, grup Auto Scaling i Aurora. Użyj cdk synth i cdk diff w CI do generowania i walidacji szablonów oraz zestawów zmian (change sets).
• Dlaczego CDK: Silna kompozycja i ponowne wykorzystanie dzięki konstruktom, programistyczne polityki za pomocą Aspects do tagowania i zabezpieczeń (guardrails) w całej organizacji oraz natywna integracja z CloudFormation zapewniająca audytowalność.

2. Dystrybuuj bazowe stosy sieciowe i zabezpieczające (guardrail stacks) za pomocą CloudFormation StackSets

• Utwórz zarządzane przez usługę (service-managed) StackSets, kierując je na jednostki organizacyjne (OU) ds. bezpieczeństwa i środowisk testowych (sandbox), aby wdrożyć współdzielone punkty końcowe VPC, standardowe alarmy CloudWatch i granice IAM. Włącz automatyczne wdrażanie na nowych kontach z tolerancją na błędy i kontrolą współbieżności.
• Dlaczego StackSets: Skala całej organizacji, spójne wdrożenia z automatycznym dołączaniem nowych kont i wbudowanym wykrywaniem dryfu.

3. Chroń krytyczne zasoby za pomocą polityk stosu (stack policies) i zestawów zmian (change sets)

• Zastosuj polityki stosu, które odmawiają aktualizacji klastrów Aurora i stref Route 53. Wymagaj CreateChangeSet i ręcznej akceptacji przed ExecuteChangeSet w potoku dla środowiska produkcyjnego.
• Dlaczego polityki stosu/zestawy zmian: Wymuszanie mutacji z najmniejszymi uprawnieniami i zapewnienie ludzkiej weryfikacji przed zmianami o wysokim ryzyku.

4. Rozszerz IaC za pomocą zasobów niestandardowych (custom resources) opartych na Lambda

• Zaimplementuj Custom::S3BucketCleanup do opróżniania bucketów aplikacji podczas usuwania stosu oraz Custom::AuroraParameterTuner, który stosuje parametry silnika po jego utworzeniu.
• Dlaczego zasoby niestandardowe: Wypełnienie luk funkcjonalnych w deklaratywnym provisioningu przy jednoczesnym zachowaniu cyklu życia powiązanego ze stosem.

5. Centralizuj sekrety i konfigurację za pomocą Secrets Manager i Parameter Store

• Przechowuj poświadczenia baz danych i klucze API w Secrets Manager z funkcjami Lambda do rotacji; publikuj identyfikatory AMI, flagi funkcji i punkty końcowe w Parameter Store. Odwołuj się do wartości za pomocą dynamicznych referencji w CloudFormation i importów CDK w czasie działania aplikacji.
• Dlaczego te usługi: Rozdzielenie odpowiedzialności (separation of concerns) — sekrety z rotacją i audytem, parametry dla konfiguracji niebędącej sekretem i łatwa promocja.

6. Wymuszaj pożądany stan i zgodność za pomocą Systems Manager State Manager

• Utwórz powiązania (associations) do instalacji agentów, konfiguracji ustawień systemu operacyjnego i stosowania playbooków Ansible w razie potrzeby. Użyj Patch Manager z oknami konserwacyjnymi (Maintenance Windows) do patchowania poza godzinami pracy oraz pulpitów zgodności agregowanych przez Resource Data Sync.
• Dlaczego State Manager: Konwergencja oparta na agentach w środowiskach EC2 i on-premises z ciągłym raportowaniem zgodności i naprawą na dużą skalę.

7. Zastosuj niezmienną infrastrukturę z EC2 Image Builder

• Buduj wzmocnione obrazy AMI z komponentami dla bazowych standardów CIS, agentów SSM/Inspector i zależnościami środowiska uruchomieniowego aplikacji. Uruchamiaj testy, publikuj identyfikatory AMI w Parameter Store i podłączaj szablony uruchamiania Auto Scaling do wersjonowanych parametrów. Wdrażaj za pomocą aktualizacji kroczących (rolling updates); wyzwalaj odświeżanie instancji (instance refresh) po aktualizacji AMI.
• Dlaczego Image Builder: Powtarzalne, testowalne obrazy, które eliminują dryf i skracają średni czas do odzyskania (MTTR) dzięki szybkim wycofaniom zmian.

8. Orkiestracja potoku (pipeline) i nadzór (governance)

• Zaimplementuj wieloetapowy potok, który uruchamia cdk synth/diff, tworzy zestawy zmian, wstrzymuje się w celu uzyskania zatwierdzenia, a następnie wykonuje zmiany. Użyj EventBridge do wyzwalania aktualizacji StackSet po zmianach w repozytorium. Dodaj codzienne nocne skanowanie w poszukiwaniu dryfu i otwieraj zgłoszenia (items) w OpsCenter w przypadku wykrycia rozbieżności.
• Dlaczego takie podejście: Ciągłe dostarczanie (continuous delivery) z audytowalnymi promocjami, proaktywne wykrywanie dryfu i zautomatyzowana naprawa dzięki dobrze zdefiniowanym odpowiedzialnościom usług.

← Potoki CI · Wszystkie domeny · Monitorowanie →

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

Przeglądaj Amazon →