Microsoft AZ-204: Azure API Management — Przewodnik do nauki

By Laurynas Brazys · 5 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

Część Microsoft Azure Developer Associate AZ-204 — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Microsoft, albo rozwiąż testy na czas na ExamRoll.io.

Przegląd

Usługa Azure API Management (APIM) zapewnia zunifikowaną fasadę dla różnorodnych usług backendowych, łącząc wysokowydajną bramę z konfigurowalnym silnikiem zasad, procesem wdrażania deweloperów i pełną płaszczyzną zarządzania. Umożliwia spójne mechanizmy bezpieczeństwa, ograniczania przepustowości, transformacji, obserwowalności i kontroli cyklu życia dla backendów REST, SOAP i GraphQL. APIM jest zarówno bramą wykonawczą (runtime) dla ruchu, jak i systemem sterowanym konfiguracją, którym zarządzasz za pośrednictwem portalu Azure, ARM/Bicep/CLI lub CI/CD. Zrozumienie potoku przetwarzania żądań, możliwości zasad, wersjonowania/rewizji, modelu subskrypcji i charakterystyki warstw jest fundamentalne do budowania solidnych i bezpiecznych API na dużą skalę.

Architektura, warstwy i kluczowe komponenty

Brama (gateway) to płaszczyzna danych. Kończy połączenia klientów, stosuje zasady w deterministycznej kolejności, kieruje ruch do backendów i zwraca odpowiedzi. Obsługuje wbudowane buforowanie, walidację JWT, wzajemne uwierzytelnianie TLS (mutual TLS) i transformację treści z prędkością łącza. Bramy mogą być hostowane przez Microsoft w danym regionie lub hostowane samodzielnie (skonteneryzowane), aby działać bliżej obciążeń lokalnych (on-premises) lub brzegowych (edge), pozostając jednocześnie centralnie zarządzane. Brama udostępnia śledzenie i metryki oraz integruje się z Application Insights w celu uzyskania telemetrii rozproszonej.

Portal dewelopera (developer portal) to interfejs dla konsumentów służący do odnajdywania, przeglądania dokumentacji i zarządzania subskrypcjami. Renderuje dokumentację OpenAPI/GraphQL, udostępnia interaktywne konsole „wypróbuj”, obsługuje przepływy OAuth 2.0 w przeglądarce oraz wspiera niestandardowy branding i dostawców tożsamości. Deweloperzy samoobsługowo zarządzają tutaj subskrypcjami produktów i rotują klucze.

Płaszczyzna zarządzania (management plane) to powierzchnia do konfiguracji i nadzoru. Przechowuje definicje API, operacji, zasad, produktów, użytkowników/grup, backendów, certyfikatów i diagnostyki. Jest dostępna za pośrednictwem portalu Azure, ARM/Bicep/CLI/PowerShell, Management REST API oraz synchronizacji konfiguracji opartej na Git. Ta płaszczyzna orkiestruje wdrożenia, wersjonowanie, rewizje i RBAC.

Warstwy (tiers) APIM określają skalę, funkcje i możliwości sieciowe:

Consumption jest bezserwerowa i rozliczana za wywołanie. Skaluje się automatycznie, jest idealna dla scenariuszy o nieregularnym/niskim natężeniu ruchu i obsługuje większość podstawowych zasad. Nie zawiera wbudowanego buforowania odpowiedzi i nie posiada zaawansowanych funkcji sieciowych ani wieloregionowych.
Developer jest przeznaczona do celów nieprodukcyjnych. Oferuje niemal pełną funkcjonalność bez umowy SLA i bez przepustowości na skalę produkcyjną.
Basic i Standard to dedykowane, jednoregionowe warstwy produkcyjne o przewidywalnej przepustowości, z jednostkami skalowania w poziomie i wbudowanym buforowaniem odpowiedzi. Są odpowiednie dla wielu obciążeń korporacyjnych, które nie wymagają wdrożenia wieloregionowego ani zaawansowanych funkcji sieciowych.
Premium dodaje wdrożenie wieloregionowe, zaawansowane funkcje sieciowe (w tym integrację z VNet), wyższą skalę, strefy dostępności w obsługiwanych regionach oraz licencjonowanie bramy hostowanej samodzielnie. Wybierz warstwę Premium dla globalnych, krytycznych dla działalności wdrożeń i sieci prywatnych.

Zasady i potok przetwarzania żądań

Zasady APIM to deklaratywne instrukcje wykonywane w ścisłej kolejności w czterech sekcjach: inbound (przychodzące), backend, outbound (wychodzące) i on-error (błędy).

Zasady inbound są uruchamiane, zanim żądanie zostanie przekazane do backendu. Typowe zadania obejmują wymaganie lub walidację kluczy subskrypcji, walidację tokenów JWT (wymuszanie wystawcy, audytorium, podpisu), sprawdzanie adresów IP klienta, stosowanie limitów szybkości i przydziałów (quotas), normalizowanie nagłówków, przepisywanie URI i transformację payloadu. Można warunkowo kierować ruch do różnych backendów i ustawiać zmienne dla późniejszych etapów.

Sekcja backend konfiguruje i modyfikuje wywołanie do usługi nadrzędnej. Użyj jej, aby wybrać encję backendu, dołączyć poświadczenia klienta (uwierzytelnianie Basic, certyfikaty klienta lub tokeny uzyskane za pomocą tożsamości zarządzanej dla backendów chronionych przez Azure AD), ustawić limity czasu, włączyć ponowienia i stosować mechanizm circuit breaker. Wzajemne uwierzytelnianie TLS (mutual TLS) z backendem jest konfigurowane tutaj poprzez skojarzenie certyfikatu klienta, który brama będzie prezentować.

Zasady outbound są uruchamiane po otrzymaniu odpowiedzi z backendu. Zazwyczaj wykonują transformacje odpowiedzi (np. z JSON na XML lub odwrotnie), przepisywanie nagłówków, kształtowanie danych, maskowanie wewnętrznych szczegółów i buforowanie odpowiedzi. Jest to również miejsce, w którym można zastosować konwersje wynikające z negocjacji treści lub normalizować kody statusu.

Zasady on-error są wykonywane, jeśli wystąpi wyjątek w którejkolwiek z wcześniejszych sekcji, w tym podczas wywołania backendu. Użyj tej sekcji, aby mapować błędy backendu na ustandaryzowane formaty błędów API, ustawiać odpowiednie kody statusu, redagować wrażliwe komunikaty, dodawać identyfikatory korelacji lub dostarczać odpowiedzi zapasowe.

Typowe wzorce użycia zasad:

Ograniczanie szybkości (Rate limiting) kontroluje chwilowe skoki przepustowości i chroni backendy. Zasada rate-limit-by-key wymusza ograniczenie per tożsamość, używając klucza takiego jak klucz subskrypcji, oświadczenie (claim) z JWT lub adres IP. Dla dłuższych okien czasowych, połącz ją z quota-by-key, aby ograniczyć dzienne lub miesięczne użycie.
Filtrowanie IP blokuje lub zezwala na ruch na podstawie adresu IP klienta lub zakresów CIDR za pomocą zasady ip-filter, często umieszczanej na początku sekcji inbound, aby zminimalizować koszty i ryzyko.
Walidacja JWT za pomocą validate-jwt wymusza parametry OpenID Connect. Skonfiguruj adres URL konfiguracji OpenID lub wystawcę (issuer), zdefiniuj akceptowalne audytoria (audiences)/zakresy (scopes), wybierz wymagane oświadczenia (claims) i dostosuj dopuszczalne przesunięcie zegara oraz sprawdzanie czasu życia tokenu. Odmów dostępu anonimowego, wymagając ważnego tokenu dla wszystkich operacji, gdzie anonimowe wywołania nie są dozwolone.
Transformacja obejmuje zasady rewrite-uri, set-header, set-query-parameter, set-body i find-and-replace. Użyj xml-to-json lub json-to-xml, aby łączyć niedopasowane formaty klienta i backendu bez zmiany kodu.
Buforowanie (Caching) wykorzystuje cache-lookup i cache-store do buforowania całych odpowiedzi w oparciu o klucze, które mogą zawierać ścieżkę, parametry zapytania, nagłówki i oświadczenia JWT. Użyj cache-lookup-value/cache-store-value do buforowania klucz/wartość w ramach zasad, na przykład do buforowania tokenów. Zauważ, że wbudowane buforowanie odpowiedzi nie jest dostępne w warstwie Consumption.

Bezpieczeństwo, tożsamość i subskrypcje

Należy uwzględnić zarówno bezpieczeństwo front-endowe (klient-brama), jak i back-endowe (brama-usługa).

W przypadku bezpieczeństwa front-endowego dominującym wzorcem jest OAuth 2.0 z Azure AD. Klienci pozyskują tokeny z Azure AD i przedstawiają je bramie. APIM wymusza wymagania dotyczące tokenów za pomocą validate-jwt, odwołując się do metadanych OpenID Connect Azure AD (dobrze znanego punktu końcowego tenanta). Zasady mogą wymuszać sprawdzanie odbiorców (audience checks), aby upewnić się, że token jest przeznaczony dla właściwego API, oświadczeń zakresu (scope claims), aby zapewnić, że wywołujący mają odpowiednie uprawnienia, oraz opcjonalnych oświadczeń, takich jak role aplikacji. Aby wyeliminować anonimowe wywołania, zasada validate-jwt powinna być stosowana do wszystkich operacji. Portal deweloperski można skonfigurować z Azure AD, aby uprościć pozyskiwanie tokenów podczas testowania.

W przypadku certyfikatów klienckich i wzajemnego TLS (mTLS), APIM może wymagać od wywołujących przychodzących certyfikatów klienckich, walidując wystawcę/podmiot/datę wygaśnięcia oraz opcjonalnie status CRL/OCSP za pomocą validate-client-certificate. Jest to odpowiednie dla integracji B2B i tych o wysokim poziomie zaufania. W przypadku mTLS między bramą a backendem, prześlij certyfikat klienta do APIM, powiąż go z encją backendu lub set-backend-service, a APIM przedstawi go podczas uzgadniania TLS (TLS handshake) w celu uwierzytelnienia w backendzie. Takie podejście jest często wymagane przez zabezpieczone usługi App Service lub usługi niestandardowe wymuszające uwierzytelnianie certyfikatem.

W przypadku backendów chronionych przez Azure AD, użyj authentication-managed-identity w sekcji backendu, aby uzyskać token dostępu przy użyciu tożsamości zarządzanej przypisanej przez system lub przez użytkownika dla APIM. Zasada wstrzykuje nagłówek Authorization do wywołania backendu. Pozwala to uniknąć przechowywania sekretów i spełnia nowoczesne wymagania zero-trust.

Subskrypcje zapewniają ogólny (coarse-grained) model dostępu i monetyzacji. Produkty to pakiety API zarządzane przez warunki, proces zatwierdzania i limity użycia. Deweloperzy subskrybują produkty, aby uzyskać klucze subskrypcji (główny i zapasowy), używane za pośrednictwem nagłówka Ocp-Apim-Subscription-Key lub parametru zapytania. Klucze można rotować bez przestojów dzięki podwójnym kluczom. Zakres subskrypcji określa, gdzie obowiązują klucze: wszystkie API, pojedyncze API lub określony produkt. Dostęp oparty na subskrypcji jest komplementarny do OAuth 2.0; oba mogą być wymagane, co umożliwia oddzielne ograniczanie przepustowości (throttling) i rozliczanie, podczas gdy uwierzytelnianie opiera się na tokenach. Produkty mogą wymuszać limity przydziału (quotas) i limity szybkości (rate limits) na subskrypcję, niezależnie od zasad na poziomie operacji, zapewniając warstwową ochronę i zarządzanie.

Zaplecza, odporność, wersjonowanie i rewizje

Zaplecza (backends) w APIM są pełnoprawnymi, reużywalnymi encjami, które hermetyzują bazowy adres URL usługi docelowej, protokół, poświadczenia, ustawienia TLS, szablony nagłówków i konfigurację proxy. Powiązanie API i operacji z zapleczami oddziela routing od polityk i centralizuje szczegóły połączeń. Użyj set-backend-service według ID zaplecza w politykach, aby routować żądania bez sztywnego kodowania adresów URL, co upraszcza promowanie między środowiskami deweloperskim, testowym i produkcyjnym.

Odporność jest wymuszana poprzez ponawianie prób (retries) i wyłączniki awaryjne (circuit breaking). Ponawianie prób z wykładniczym backoffem może łagodzić przejściowe awarie; powinno być ograniczone do operacji idempotentnych i limitowane rozsądnymi timeoutami, aby zapobiec ich wzmacnianiu. Polityka wyłącznika awaryjnego otwiera się, gdy wskaźnik błędów, liczba kolejnych awarii lub opóźnienie przekroczą skonfigurowane progi w oknie próbkowania, zwierając obwód dla żądań na zdefiniowany czas przerwy. W stanie otwartym polityka może natychmiast zwrócić odpowiedź zapasową (fallback) lub przekierować ruch do zaplecza rezerwowego. W stanie półotwartym ograniczona liczba próbnych żądań sonduje kondycję zaplecza przed zamknięciem obwodu. Chroni to zaplecza, poprawia doświadczenie klienta i stabilizuje systemy w warunkach częściowej awarii.

Równoważenie obciążenia i routing można zaimplementować na warstwie polityk. Routing warunkowy za pomocą choose może kierować ruchem w zależności od segmentu użytkownika, geolokalizacji, zawartości żądania lub sygnałów o kondycji. Routing ważony można osiągnąć za pomocą wyrażeń w politykach, które pseudolosowo wybierają zaplecze zgodnie z pożądanymi wagami, umożliwiając wdrożenia typu canary release i stopniowe wdrażanie (gradual rollouts). Zaplecza w trybie active-active w różnych regionach mogą być obsługiwane przez wdrożenie APIM w warstwie Premium w trybie wieloregionalnym w połączeniu z routingiem warunkowym do najbliższego zdrowego regionu; alternatywnie, można zintegrować APIM z Azure Front Door w celu globalnego równoważenia obciążenia na warstwie 7, podczas gdy APIM zajmuje się uwierzytelnianiem i transformacją.

Wersjonowanie i rewizje zarządzają cyklem życia API. Zestawy wersji (version sets) definiują, w jaki sposób wiele wersji API jest udostępnianych klientom przy użyciu schematu wersjonowania opartego na ścieżce, parametrze zapytania (query string) lub nagłówku. Używaj wersji do wprowadzania zmian niekompatybilnych wstecz (breaking changes); każda wersja jest oddzielną encją API powiązaną z tym samym zestawem wersji. Zmiany iteracyjne, które nie łamią kompatybilności, są implementowane jako rewizje. Rewizja to modyfikowalna migawka API, którą można wywoływać jawnie (za pomocą sufiksu rewizji) w celach testowych, podczas gdy wcześniejsza rewizja pozostaje bieżącą rewizją produkcyjną. Po walidacji nowa rewizja jest promowana do statusu bieżącej bez zmiany identyfikatora wersji. Ten podział umożliwia bezpieczne, progresywne dostarczanie: rewizje dla aktualizacji niepowodujących problemów z kompatybilnością; wersje dla zmian łamiących kompatybilność, udostępniane poprzez czytelne mechanizmy odkrywania i dokumentację w portalu deweloperskim.

Na koniec, obserwuj i zarządzaj. Włącz śledzenie (tracing), ustawiaj identyfikatory korelacji i eksportuj diagnostykę do Application Insights, aby uzyskać pełną widoczność end-to-end. Zarządzaj konfiguracją za pomocą ARM/Bicep lub APIM DevOps Resource Kit, aby osiągnąć powtarzalne wdrożenia, i stosuj RBAC na płaszczyźnie zarządzania, aby rozdzielić obowiązki autorów, wydawców i operatorów API.

Praktyczny scenariusz problemowy

Starbucks musi udostępnić ujednolicone publiczne API do składania zamówień mobilnych, które agreguje mikroserwisy w dwóch regionach Azure. API musi blokować anonimowy dostęp, dławić (throttle) nadużywających zasobów klientów, chronić regionalne zaplecza przed kaskadowymi awariami i umożliwiać stopniowe wdrażanie schematu zamówień w wersji v2 bez zakłócania działania klientów v1.

Uruchom instancję APIM Premium w dwóch regionach i włącz wdrożenie wieloregionalne. Warstwa Premium została wybrana ze względu na obecność bram w wielu regionach, zaawansowane funkcje sieciowe i skalę korporacyjną. Bramy regionalne zmniejszają opóźnienia dla klientów mobilnych i zapewniają odporność w trybie active-active.
Zaimportuj usługi zaplecza jako encje zaplecza w APIM, włączając w to instancje App Service w obu regionach. Encje zaplecza centralizują bazowe adresy URL, ustawienia TLS i poświadczeń, umożliwiając tworzenie czystych polityk routingu i przenośność między środowiskami.
Zabezpiecz komunikację klient-brama za pomocą Azure AD OAuth 2.0 i wymuszaj weryfikację tokenów za pomocą polityki validate-jwt w sekcji przychodzącej (inbound). Azure AD zapewnia scentralizowaną tożsamość, dostęp warunkowy i silną walidację tokenów. Polityka validate-jwt zapewnia, że tylko uwierzytelnieni klienci z odpowiednimi odbiorcami/zakresami (audiences/scopes) mogą wywoływać API.
Wymagaj subskrypcji produktów i wydawaj klucze subskrypcji dla każdej aplikacji partnerskiej. Dodaje to warstwę zarządzania i pomiaru niezależną od OAuth i pozwala na definiowanie limitów (quotas) dla poszczególnych partnerów, łatwą rotację kluczy oraz samoobsługowe wdrażanie przez portal.
Skonfiguruj polityki rate-limit-by-key i quota-by-key w sekcji przychodzącej, z kluczem subskrypcji jako identyfikatorem. Dławienie chroni zaplecza przed nagłymi wzrostami ruchu i umożliwia różnicowanie umów SLA dla partnerów. Użycie kluczy subskrypcji jako dyskryminatora dostosowuje egzekwowanie polityk do umów biznesowych.
Zaimplementuj filtrowanie IP, aby blokować znane złośliwe zakresy adresów i zezwalać na dostęp z firmowych zakresów Starbucks w celach administracyjnych. Polityka ip-filter zmniejsza powierzchnię ataku na wczesnym etapie przetwarzania i oszczędza zasoby w dalszej części potoku.
Skonfiguruj wzajemne uwierzytelnianie TLS (mTLS) dla wrażliwych usług, przesyłając certyfikaty klienta do APIM i wiążąc je z odpowiednimi encjami zaplecza. mTLS zapewnia silne uwierzytelnianie między usługami tam, gdzie zaplecza wymagają certyfikatów, spełniając wewnętrzne polityki bezpieczeństwa.
Dodaj politykę authentication-managed-identity w sekcji zaplecza dla usług chronionych przez Azure AD. Tożsamość zarządzana APIM pozyskuje tokeny dostępu dla zaplecza, eliminując potrzebę przechowywania sekretów i integrując się z Azure RBAC oraz dostępem warunkowym.
Zaimplementuj wyłącznik awaryjny (circuit-breaker) z ponawianiem prób i odpowiedzią zapasową (fallback) w sekcji zaplecza. W przypadku powtarzających się awarii w danym oknie czasowym, otwórz obwód i przekieruj żądania do zdrowego zaplecza regionalnego; jeśli oba są niedostępne, zwróć standardową, buforowaną odpowiedź zapasową. Chroni to przeciążone usługi i zapewnia przewidywalne zachowanie w warunkach awarii.
Użyj routingu warunkowego, aby równoważyć obciążenie dla operacji odczytu do najbliższego regionu i przełączać awaryjnie (failover) na podstawie sygnałów o kondycji. Wyrażenia w politykach wybierają lokalny region, sprawdzając niestandardowy nagłówek lub geolokalizację IP; sondy kondycji wypełniają zmienne używane do podejmowania decyzji o routingu. Zapewnia to niskie opóźnienia i ciągłość działania podczas incydentów regionalnych.
Wprowadź zestaw wersji (version set) dla API zamówień z wersjonowaniem opartym na ścieżce (/v1, /v2). Utwórz nową rewizję wersji v2 do testów, zweryfikuj ją z wybranymi klientami, wywołując URL specyficzny dla rewizji, a następnie promuj ją do statusu bieżącej. Zestawy wersji jasno komunikują zmiany niekompatybilne wstecz, podczas gdy rewizje umożliwiają bezpieczną, iteracyjną pracę bez zakłóceń.
Włącz buforowanie odpowiedzi dla punktów końcowych o dużej liczbie odczytów (menu/katalog) w sekcji wychodzącej (outbound) za pomocą polityk cache-lookup i cache-store, z rozróżnieniem na lokalizację i typ urządzenia. Buforowanie odciąża zaplecza od powtarzających się zapytań i poprawia wydajność aplikacji mobilnych; warstwa Premium wspiera te funkcje na dużą skalę.

Taki projekt dostarcza uwierzytelnione, dławione, odporne i ewoluujące API. APIM Premium zapewnia globalną, bezpieczną bramę; polityki wymuszają tożsamość, dławienie, transformację i odporność; encje zaplecza i tożsamości zarządzane zabezpieczają i oddzielają połączenia; zestawy wersji i rewizje zapewniają zdyscyplinowany cykl życia dla ciągłego dostarczania bez zakłócania pracy klientów.

← Uwierzytelnianie · Wszystkie domeny · Rozwiązania oparte na zdarzeniach i komunikatach w Azure →

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