Microsoft AZ-400: Infrastruktura jako kod i zarządzanie konfiguracją — Przewodnik do nauki

By Laurynas Brazys · 10 August 2026 · #microsoft #az-400 #certification #exam-prep #study-guide

Część Microsoft DevOps Engineer Expert AZ-400 — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Microsoft, albo rozwiąż testy na czas na ExamRoll.io.

Przegląd

Infrastruktura jako kod (IaC) i zarządzanie konfiguracją na Azure pozwalają na wielokrotne i bezpieczne definiowanie, udostępnianie i egzekwowanie ustawień infrastruktury oraz aplikacji. Azure natywnie wspiera ARM JSON i Bicep oraz dobrze integruje się z Terraform i Ansible. Stan konfiguracji można deklarować za pomocą PowerShell Desired State Configuration (DSC), Azure Automation DSC, Chef i Puppet. Wdrażanie funkcji aplikacji i zarządzanie kluczami są scentralizowane dzięki Azure App Configuration i Key Vault. Niezmienne obrazy (immutable images) zbudowane za pomocą Packer redukują dryf konfiguracji. Ład jest egzekwowany jako polityka-jako-kod (policy-as-code) za pomocą Azure Policy oraz OPA/Gatekeeper dla Kubernetes.

Natywne IaC na Azure: Szablony ARM i Bicep

Szablony ARM to deklaratywne dokumenty JSON, których Azure Resource Manager używa do tworzenia i aktualizowania zasobów. Struktura najwyższego poziomu obejmuje $schema, contentVersion, parameters, variables, resources i outputs. Parametry (parameters) pozwalają na wprowadzanie danych specyficznych dla środowiska; zmienne (variables) pomagają w tworzeniu wartości obliczeniowych; zasoby (resources) deklarują pożądany stan; a dane wyjściowe (outputs) publikują wyniki, takie jak identyfikatory zasobów. Szablony obsługują wyrażenia i funkcje czasu wykonania (np. resourceId, reference, concat, uniqueString), dzięki czemu można tworzyć nazwy i pobierać właściwości.

Aby podzielić duże wdrożenia na łatwe w utrzymaniu jednostki, można używać szablonów zagnieżdżonych lub połączonych. Szablon zagnieżdżony osadza JSON we właściwości template zasobu

undefined

. Szablon połączony odwołuje się do zdalnego szablonu poprzez templateLink.uri, zazwyczaj przechowywanego w Azure Storage z sygnaturą SAS o ograniczonym czasie ważności w celu zapewnienia integralności. Używaj szablonów zagnieżdżonych, gdy wszystko może znajdować się w jednym artefakcie i chcesz uzyskać transakcyjne wdrożenie dla wszystkich jego części. Używaj szablonów połączonych w przypadku bardzo dużych topologii lub przy ponownym wykorzystywaniu szablonów w różnych repozytoriach lub zespołach. Określ zakres wdrożeń (resource group, subscription, management group lub tenant) w zależności od potrzeb, ustawiając scope wdrożenia w zasobie deployments.

ARM obsługuje dwa tryby wdrażania. Przyrostowy (domyślny) tworzy lub aktualizuje zasoby obecne w szablonie, nie usuwając niczego, co nie zostało w nim zadeklarowane. Kompletny usuwa zasoby w docelowym zakresie, które nie są określone w szablonie, co jest przydatne do zagwarantowania minimalnego dryfu, ale jest też bardziej ryzykowne, jeśli szablon nie jest autorytatywny dla tego zakresu. Operacje Validate i What-If pomagają uzyskać podgląd zmian przed wykonaniem, aby zmniejszyć ryzyko.

Bicep to język dziedzinowy (DSL), który kompiluje się do ARM JSON i oferuje najwyższej klasy ergonomię tworzenia kodu. Deklaracje zasobów używają nazw symbolicznych, wymuszają typy i obsługują słowo kluczowe existing do odwoływania się do istniejących zasobów bez konieczności ich ponownego wdrażania. Parametry, zmienne, dane wyjściowe i deklaracje zasobów są zwięzłe, a relacje rodzic-dziecko oraz zakresy są jawnie zdefiniowane. Moduły umożliwiają kompozycję i ponowne użycie; każdy moduł to plik Bicep, do którego odwołuje się słowo kluczowe module, i który może być publikowany i pobierany z rejestrów specyfikacji szablonów (template spec) lub artefaktów OCI. Warunki są wyrażane bezpośrednio za pomocą if przy zasobach lub modułach, a pętle używają wyrażeń for do deklarowania wielu instancji z przejrzystą obsługą zależności. Migracja z ARM JSON jest prosta: polecenie

undefined

(lub

undefined

) konwertuje JSON na Bicep; następnie refaktoryzujesz kod do modułów i wprowadzasz nazwy symboliczne. Bicep jest bezstratny w stosunku do ARM i obsługuje całą powierzchnię platformy; polecenie

undefined

generuje standardowy ARM JSON gotowy do wdrożenia.

Wieloplatformowe IaC na Azure z Terraform

Terraform uzupełnia natywne dla Azure IaC, gdy potrzebne są przepływy pracy wielochmurowe lub niezależne od dostawcy. Dostawca (provider) azurerm zarządza zasobami Azure Resource Manager i jego wersja powinna być przypięta; dołącz blok

undefined

, nawet jeśli jest pusty, aby włączyć funkcje dostawcy. Inni popularni dostawcy to azuread dla obiektów AAD i random dla wartości pomocniczych. Uwierzytelniaj się za pomocą jednostki usługi (service principal), tożsamości zarządzanej (Managed Identity) na hostowanych agentach lub przez Azure CLI. Przyjmij jasną strategię konfiguracji dostawcy dla każdego środowiska i scentralizuj moduły wielokrotnego użytku ze zmiennymi wejściowymi i wyjściowymi.

Zarządzanie stanem (state) jest kluczowe. Użyj backendu azurerm do przechowywania zdalnego stanu w Azure Storage: skonfiguruj

undefined

; uwierzytelniaj się za pomocą tożsamości zarządzanej lub SAS; oraz włącz usuwanie nietrwałe (soft delete) i wersjonowanie na kontenerze blob. Backend używa dzierżaw obiektów blob (blob leases) do blokowania stanu i zapobiegania jednoczesnym modyfikacjom. Dostęp do konta magazynu powinien być chroniony przez RBAC i opcjonalnie ograniczony za pomocą Private Endpoints. Utrzymuj pliki stanu odizolowane dla każdego środowiska i z założenia nigdy nie przechowuj w nich sekretów — w razie potrzeby używaj Key Vault i źródeł danych (data sources) do ich pobierania.

Obszary robocze (workspaces) zapewniają logiczną izolację stanu w ramach tej samej konfiguracji, umożliwiając rozgałęzianie środowisk, takich jak dev, test i prod. Użyj

undefined

i upewnij się, że klucz backendu koduje nazwę obszaru roboczego, aby uniknąć kolizji (np.

undefined

). Obszary robocze są doskonałe do utrzymania równoważności środowisk z niewielkimi różnicami; gdy topologie znacznie się różnią, użyj oddzielnych konfiguracji lub modułów, aby uniknąć dryfu i złożoności warunkowej. Zintegruj z Azure Pipelines za pomocą połączeń usług (service connections) i zadań Terraform CLI, aby standaryzować kroki init/plan/apply na różnych etapach oraz aby uzależnić wykonanie apply od zatwierdzeń i kontroli polityk.

Zarządzanie konfiguracją na dużą skalę: DSC, Azure Automation DSC, Ansible, Chef i Puppet

PowerShell Desired State Configuration (DSC) deklaruje stan systemów Windows i wieloplatformowych za pomocą zasobów. Istnieją dwa tryby dostarczania: push wysyła pliki MOF bezpośrednio do węzłów; pull polega na tym, że węzły pobierają swoje pliki MOF z usługi pull zgodnie z harmonogramem. Local Configuration Manager (LCM) wymusza stosowanie polityki. Kluczowe ustawienia LCM obejmują:

ConfigurationMode: ApplyOnly (konfiguracja jednorazowa, bez korekty dryfu), ApplyAndMonitor (wykrywanie dryfu, bez korekty), ApplyAndAutoCorrect (wykrywanie i naprawa dryfu).
ConfigurationModeFrequencyMins i RefreshFrequencyMins do dostrajania częstotliwości wymuszania stanu i pobierania konfiguracji.
RebootNodeIfNeeded i ActionAfterReboot do obsługi ponownych uruchomień.
Konfiguracje częściowe (partial configurations) do komponowania stanu węzła z wielu plików MOF, które niezależnie celują w określone funkcje (np. hardening systemu operacyjnego i rola aplikacji).

Azure Automation State Configuration (Azure Automation DSC) to zarządzana usługa typu pull. Tworzysz konfiguracje w PowerShell, importujesz je do Automation Account i uruchamiasz zadania kompilacji, które tworzą konfiguracje węzłów (MOF). Węzły rejestrują się za pomocą polecenia Register-AzAutomationDscNode, używając klucza rejestracyjnego/punktu końcowego, i mogą być grupowane oraz mieć przypisane konfiguracje z wartościami parametrów dla każdego węzła. Raportowanie zgodności pokazuje ostatnio zastosowaną konfigurację i status dryfu; węzły w trybie ApplyAndAutoCorrect automatycznie naprawią stan przy następnym zgłoszeniu. Zadania kompilacji są audytowalnymi artefaktami, a kontrola dostępu oparta na rolach (RBAC) ogranicza możliwość tworzenia konfiguracji i przypisywania węzłów.

Ansible jest bezagentowy i dobrze nadaje się do konfiguracji floty systemów Linux oraz do doraźnej orkiestracji. W Azure używa się kolekcji azure.azcollection, która dostarcza moduły do obsługi zasobów compute, networking, Key Vault i innych. Dynamiczny inwentarz (dynamic inventory) z wtyczką azure_rm wykrywa hosty z Twoich subskrypcji lub określonych grup zasobów i tagów; pozyskiwanie poświadczeń może wykorzystywać jednostkę usługi (service principal), Azure CLI lub tożsamość zarządzaną (managed identity). Integracja z Azure Pipelines polega na instalacji Ansible na agencie Linux, zalogowaniu się za pomocą zadania AzureCLI@2 lub połączenia usługowego Azure Resource Manager i uruchamianiu playbooków, które odwołują się do dynamicznego inwentarza, grup zmiennych i bezpiecznych plików (secure files). Ansible doskonale sprawdza się w idempotentnych, czytelnych zadaniach i może uzupełniać DSC w środowiskach z dużą liczbą systemów Windows, obsługując wieloplatformowe przepływy pracy i orkiestrację.

Chef i Puppet dostarczają dojrzałe modele polityki jako kodu (policy-as-code) oraz raportowanie zgodności. Na maszynach wirtualnych Azure, rozszerzenia VM dla Chef i Puppet inicjują agentów w momencie provisioningu, gwarantując wczesną zbieżność stanu (convergence). Chef Infra używa tzw. cookbooks i Policyfiles do przypinania zależności i zapewniania powtarzalnych uruchomień; Chef InSpec wyraża zgodność jako kod (compliance-as-code) i przesyła raporty do Chef Automate w celu analizy dryfu i stanu kontroli. Manifesty i moduły w Puppet kodują pożądany stan, a Code Manager i środowiska (environments) zapewniają przepływy promocyjne; Puppet Enterprise dostarcza scentralizowane raportowanie, klasyfikację opartą na rolach i mechanizmy naprawcze. Oba narzędzia integrują się z Azure za pomocą modułów i dostawców zasobów i mogą współistnieć z natywnym dla Azure DSC, gdy wymaga tego migracja lub środowiska mieszane.

Konfiguracja aplikacji, niezmienne obrazy i polityka jako kod

Usługa Azure App Configuration centralizuje ustawienia aplikacji i flagi funkcji. Flagi funkcji umożliwiają progresywne wdrażanie: definiujesz flagi i, w razie potrzeby, dołączasz filtry, takie jak wdrażanie oparte na procentach lub targetowanie użytkowników za pomocą bibliotek Feature Manager. Etykiety pozwalają rozdzielać wartości według środowiska lub pierścienia wdrożenia (ring). Migawki konfiguracji przechwytują niezmienny widok zestawu kluczy i etykiet w danym punkcie czasowym, co pozwala na spójne, powtarzalne wdrożenia w wielu usługach bez warunków wyścigu wynikających z jednoczesnych zmian kluczy. Referencje do Key Vault pozwalają przechowywać sekrety w Key Vault, podczas gdy w App Configuration przechowywane są tylko odwołania; tożsamość zarządzana aplikacji musi mieć uprawnienie get do sekretu, a biblioteki klienckie rozwiązują i buforują sekrety z opcjonalnym dynamicznym odświeżaniem. Używaj RBAC i izolacji sieciowej w obu usługach, aby chronić dostęp.

Infrastruktura niezmienna eliminuje dryf konfiguracji poprzez przebudowę ze znanego obrazu zamiast modyfikowania istniejących hostów. Builder azure-arm (teraz azure) w narzędziu Packer tworzy obrazy z bazowego systemu operacyjnego, uruchamia provisionery (shell, PowerShell, Ansible) i publikuje je w Shared Image Gallery z replikowanymi regionami i wersjonowaniem semantycznym. Potok „złotego obrazu” zazwyczaj sprawdza poprawność składni (linting) szablonów Packer, buduje obraz, przeprowadza skanowanie pod kątem podatności i zgodności (np. za pomocą InSpec), testuje go integracyjnie, promuje do galerii, a następnie aktualizuje VM Scale Sets lub pule hostów. Dzięki VM Scale Sets, aktualizacjom kroczącym lub opartym na stanie zdrowia oraz automatycznym aktualizacjom obrazu systemu operacyjnego, uzyskujesz bezpieczne, spójne wdrożenia i łatwe wycofywanie zmian poprzez wybór poprzedniej wersji obrazu.

Polityka jako kod (Policy as code) wymusza stosowanie barier ochronnych. Definicje Azure Policy to obiekty JSON z policyRule, która ocenia właściwości zasobów i efekty, takie jak deny, audit, append, modify lub deployIfNotExists w celu automatycznej naprawy. Parametryzuj definicje w celu ich ponownego użycia; grupuj je w inicjatywy (definicje zestawów polityk) dla spójnych przypisań i scentralizowanego śledzenia zgodności. Przypisuj polityki na poziomie grupy zarządzania, subskrypcji lub grupy zasobów; włącz zadania naprawcze dla polityk modify i deployIfNotExists, aby doprowadzić istniejące zasoby do zgodności. Przechowuj artefakty polityk w kontroli wersji, weryfikuj je poprzez pull requesty i wdrażaj za pomocą Bicep, ARM lub Terraform, aby zapewnić spójną promocję między środowiskami.

W przypadku Kubernetes, OPA/Gatekeeper wymusza ograniczenia na etapie przyjmowania żądań (admission-time). ConstraintTemplates definiują polityki Rego i ich schematy; Constraints tworzą instancje tych polityk dla klastra. Typowe mechanizmy kontrolne obejmują ograniczanie obrazów do zaufanych rejestrów, wymaganie określonych etykiet/adnotacji lub zapobieganie uruchamianiu uprzywilejowanych podów. Gatekeeper integruje się z narzędziami GitOps (Flux/Argo CD) i testowaniem w CI za pomocą conftest. Azure Policy for Kubernetes bazuje na Gatekeeper, aby zapewnić natywne dla Azure przypisywanie i widoki zgodności w klastrach AKS, unifikując zarządzanie chmurą i klastrem w jednym pulpicie nawigacyjnym stanu zgodności.

Praktyczny scenariusz problemowy

Spotify musi ustandaryzować infrastrukturę Azure, zredukować dryf konfiguracji i przyspieszyć bezpieczne wdrażanie funkcji w mikrousługach działających na systemach Windows i Linux, w AKS oraz na maszynach wirtualnych.

Modeluj zasoby chmurowe za pomocą modułów Bicep per domena (sieć, dane, zasoby obliczeniowe) i wdrażaj je poprzez subskrypcje przypisane do grup zarządzania. Daje to typowane, łatwe w utrzymaniu deklaracje, jasny zakres i możliwość ponownego użycia bez nadmiernej szczegółowości charakterystycznej dla ARM JSON.
Użyj niewielkiej liczby połączonych specyfikacji szablonów ARM (template specs) dla współdzielonych usług platformowych, z których korzysta wiele zespołów. Połączone szablony hostowane jako template specs zapewniają wersjonowane, niezmienne artefakty i oddzielają cykl wydawniczy platformy od zespołów aplikacyjnych.
Wybierz Terraform dla zależności brzegowych (edge) i CDN obejmujących wiele chmur, z backendem azurerm przechowującym stan zdalny w Azure Storage per obszar roboczy (dev/test/prod) i wykorzystującym dzierżawy blobów do blokowania. Pozwala to zachować jeden wzorzec potoku, jednocześnie bezpiecznie izolując stan i umożliwiając spójną promocję.
Scentralizuj konfigurację aplikacji i flagi funkcji w Azure App Configuration. Flagi funkcji z filtrami procentowymi i etykietami umożliwiają wdrożenia oparte na pierścieniach (ring-based); migawki konfiguracji zapewniają, że każdy etap wdrożenia korzysta z niezmiennego, audytowanego zestawu kluczy.
Przechowuj sekrety w Azure Key Vault i odwołuj się do nich z Azure App Configuration. Rozwiązywanie referencji w czasie rzeczywistym za pomocą tożsamości zarządzanej umożliwia rotację kluczy bez konieczności ponownego wdrażania i usuwa sekrety z konfiguracji aplikacji i potoków.
Zastosuj niezmienne obrazy dla obciążeń na maszynach wirtualnych, używając Packer do budowania „złotych obrazów” publikowanych w Shared Image Gallery. Potok uruchamia skrypty wzmacniające bezpieczeństwo i skany InSpec, taguje obrazy i promuje tylko te wersje, które przejdą testy. VM Scale Sets wykorzystują obrazy z galerii do wdrożeń typu blue/green i kroczących, eliminując dryf.
Wymuszaj bariery ochronne za pomocą inicjatyw Azure Policy, które blokują ekspozycję publicznych adresów IP w prywatnych podsieciach, wymagają ustawień diagnostycznych do Log Analytics i automatycznie wdrażają polityki tworzenia kopii zapasowych. Przypisuj je na poziomie grupy zarządzania, aby zapewnić szeroki zasięg, i twórz zadania naprawcze dla istniejących zasobów, aby szybko osiągnąć pożądany stan zgodności.
Chroń AKS za pomocą OPA/Gatekeeper, stosując ograniczenia, które blokują niezgodne obrazy i uprzywilejowane pody. Polityki są przechowywane i wersjonowane w Git, walidowane za pomocą conftest w CI i stosowane poprzez GitOps, aby zapewnić, że stan klastra jest zawsze zgodny z polityką.
Zarządzaj konfiguracją serwerów Windows za pomocą Azure Automation DSC. Węzły rejestrują się za pomocą Register-AzAutomationDscNode i używają ConfigurationMode=ApplyAndAutoCorrect do wykrywania i naprawiania dryfu; zadania kompilacji generują pliki MOF dla każdej roli, a pulpity zgodności uwidaczniają dryf w celu dalszej analizy.
Zarządzaj konfiguracją i orkiestracją w systemie Linux za pomocą Ansible, używając dynamicznego inwentarza azure_rm i modułów azure.azcollection. Azure Pipelines uwierzytelnia się za pomocą tożsamości zarządzanej, uruchamia playbooki w sposób idempotentny i koordynuje aktualizacje w różnych usługach, uzupełniając DSC na platformie Windows.
Wykorzystaj profile Chef InSpec do wieloplatformowej zgodności jako kodu (compliance-as-code) zarówno na obrazach, jak i na działających hostach, przesyłając dane do Chef Automate w celu raportowania. Wprowadza to audytowalne, testowalne mechanizmy kontrolne do potoku i środowiska produkcyjnego, zapewniając ciągłą walidację wymagań regulacyjnych.

Ta kombinacja zapewnia typowane, modułowe IaC (Bicep/Terraform), niezmienne hosty (Packer), scentralizowaną konfigurację aplikacji (App Configuration/Key Vault), ciągłe egzekwowanie konfiguracji (Azure Automation DSC, Ansible) oraz silne zarządzanie (Azure Policy, Gatekeeper). Redukuje to dryf, skraca czas odzyskiwania i wdrażania oraz czyni zgodność możliwą do udowodnienia.

← Potoki CI · Wszystkie domeny · Konteneryzacja i Kubernetes →

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