Microsoft AZ-204: Azure Storage i Blob Storage — 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 Storage zapewnia trwałą, masowo skalowalną pamięć masową w chmurze dla danych niestrukturyzowanych i ustrukturyzowanych. W kontekście tworzenia aplikacji należy skupić się na wyborze odpowiedniego typu konta magazynu, konfiguracji redundancji w celu spełnienia celów RTO/RPO, wyborze właściwego typu obiektu blob i warstwy dostępu pod kątem kosztów/wydajności oraz zabezpieczaniu dostępu za pomocą Azure AD i SAS. Używaj zasad cyklu życia do automatyzacji przenoszenia danych między warstwami, serwuj statyczne strony internetowe bezpośrednio z Blob storage, gdy jest to właściwe, i stosuj Azure Files oraz Queue Storage tam, gdzie wymagana jest semantyka plików lub rozdzielenie oparte na komunikatach.

Typy kont magazynu i podstawy redundancji

General-purpose v2 (GPv2) to standardowy typ konta dla większości obciążeń (workloads). Obsługuje obiekty blob, pliki, kolejki i tabele, wszystkie warstwy dostępu, zarządzanie cyklem życia oraz najnowsze funkcje. Starsze konta BlobStorage udostępniają tylko usługę Blob i warstwy, ale brakuje im szerokiego zakresu funkcji i optymalizacji kosztów dostępnych w GPv2; nowe wdrożenia powinny preferować GPv2. Konta FileStorage to konta premium oparte na dyskach SSD, dedykowane dla Azure Files, zapewniające spójne, niskie opóźnienia IOPS i przepustowość dla korporacyjnych obciążeń plikowych (np. udziały profilowe, aplikacje biznesowe). Wybierz FileStorage, gdy wymagasz wydajności premium dla udziałów SMB/NFS; w przeciwnym razie domyślnym wyborem jest GPv2.

Wybór redundancji określa trwałość i dostępność danych w różnych domenach awarii:

LRS (Locally Redundant Storage) synchronicznie przechowuje trzy kopie w jednym centrum danych. Najniższy koszt, brak ochrony strefowej i regionalnej. Używaj do środowisk deweloperskich/testowych, obciążeń efemerycznych lub gdy masz replikację na wyższej warstwie.
ZRS (Zone-Redundant Storage) synchronicznie replikuje dane między strefami dostępności w regionie, chroniąc przed awarią strefy z wysoką dostępnością i zerowym RPO. Wybierz dla środowisk produkcyjnych w regionach strefowych wymagających odporności wewnątrzregionalnej.
GRS (Geo-Redundant Storage) przechowuje trzy synchroniczne kopie w regionie podstawowym (jak LRS) i asynchronicznie replikuje je do sparowanego regionu pomocniczego (tam jako LRS). Typowe RPO wynosi mniej niż 15 minut; region pomocniczy domyślnie nie jest do odczytu. Wybierz dla odtwarzania po awarii (disaster recovery), gdy nie potrzebujesz dostępu do odczytu.
RA-GRS (Read-Access Geo-Redundant Storage) dodaje dostęp do odczytu do regionu pomocniczego poprzez punkty końcowe z sufiksem -secondary. Używaj, gdy wymagasz odporności na awarie między regionami i obsługujesz obciążenia głównie do odczytu podczas incydentów w regionie podstawowym, lub do odczytów z bliskości geograficznej, gdzie spójność ostateczna (eventual consistency) jest akceptowalna.

Gdy potrzebujesz zarówno ochrony przed awarią strefy, jak i odtwarzania po awarii między regionami (cross-region DR), rozważ połączenie ZRS lokalnie z dodatkowym wzorcem konta replikowanego geograficznie na poziomie rozwiązania. Zaplanuj testowanie przełączania awaryjnego (failover) konta, zrozum zmiany punktów końcowych DNS i zweryfikuj zasady ponawiania prób w aplikacji, aby obsłużyć spójność ostateczną i przesunięcie zegara (clock skew) podczas zdarzeń geograficznych.

Model danych blob, warstwy i zarządzanie cyklem życia

Obiekty blob występują w trzech typach o odrębnej semantyce. Blokowe obiekty blob (Block blobs) są zoptymalizowane pod kątem przesyłania strumieniowego i losowego odczytu dużych obiektów, takich jak obrazy, filmy i kopie zapasowe. Przesyłane dane są dzielone na bloki i zatwierdzane, co umożliwia równoległe przesyłanie i efektywne ponawianie prób. Dołączane obiekty blob (Append blobs) są zoptymalizowane pod kątem obciążeń typu “tylko dołączanie”, takich jak telemetria i przechwytywanie logów; dozwolone są tylko operacje dołączania, co upraszcza współbieżność. Stronicowe obiekty blob (Page blobs) udostępniają strony wyrównane do 512 bajtów dla losowych operacji wejścia/wyjścia (I/O) i stanowią podstawę dla wirtualnych dysków twardych Azure (VHD) używanych przez dyski maszyn wirtualnych Azure; są jedynym obsługiwanym typem obiektu blob dla dysków IaaS i dużych obciążeń z losowym I/O.

Warstwy dostępu do obiektów blob kontrolują koszty i wydajność. Hot jest zoptymalizowana pod kątem częstego dostępu, z najniższym opóźnieniem odczytu/zapisu i najwyższym kosztem przechowywania. Cool jest przeznaczona dla rzadko używanych danych przechowywanych przez co najmniej 30 dni, z niższym kosztem przechowywania, ale wyższymi kosztami transakcji/odczytu i opłatami za minimalny okres przechowywania. Archive to najtańsza warstwa do długoterminowego przechowywania; obiekty są w trybie offline i muszą zostać “przywrócone” (rehydrated) do warstwy Hot lub Cool przed odczytem. Przywracanie można zlecić z priorytetem standardowym lub wysokim, wymieniając koszt na szybkość. Możesz ustawić domyślną warstwę dostępu na poziomie konta (Hot lub Cool) i nadpisać ją dla każdego obiektu blob; warstwa Archive jest dostępna tylko na poziomie pojedynczego obiektu blob.

Zasady zarządzania cyklem życia automatyzują przenoszenie i przechowywanie danych w celu kontroli kosztów i spełnienia wymogów ładu korporacyjnego. Na poziomie konta zdefiniuj reguły, które:

Przenoszą obiekty blob lub ich wersje/migawki do warstwy Cool lub Archive po N dniach od ostatniej modyfikacji
Usuwają obiekty blob, migawki lub wersje po przekroczeniu progów wiekowych
Filtrują według prefiksu kontenera i tagów indeksu obiektów blob, aby objąć określone zbiory danych (na przykład tag env=prod i policy=retention-7y) Połącz reguły cyklu życia z wersjonowaniem i usuwaniem nietrwałym (soft delete), aby chronić przed przypadkowym usunięciem, jednocześnie egzekwując zasady przechowywania. Pamiętaj, że warstwa Archive ma minimalny okres przechowywania i opłaty za wcześniejsze usunięcie; projektuj zasady tak, aby zminimalizować niepotrzebne przywracanie danych.

Aby śledzić zmiany i przetwarzać je w dalszych systemach, włącz kanał zmian (change feed) konta magazynu, aby konsumować uporządkowany, niezmienny dziennik operacji tworzenia, aktualizacji, usuwania i kopiowania obiektów blob. Wspiera to zgodność z przepisami oraz procesory asynchroniczne, które wymagają semantyki “dokładnie raz” (exactly-once) lub “co najmniej raz” (at-least-once) z mechanizmem punktów kontrolnych (checkpointing).

Hostowanie statycznych stron internetowych w Blob storage udostępnia specjalny kontener $web, obsługiwany przez dedykowany internetowy punkt końcowy. Skonfiguruj dokumenty indeksu i błędów oraz publikuj zasoby statyczne bezpośrednio. Punkt końcowy statycznej strony internetowej zapewnia anonimowy dostęp do odczytu zawartości witryny, niezależnie od ustawienia publicznego dostępu do obiektów blob; dostęp przez punkt końcowy obiektów blob może pozostać wyłączony. Dla domen niestandardowych i globalnej akceleracji, umieść przed punktem końcowym usługę Azure Front Door lub Azure CDN. Prywatne punkty końcowe (Private endpoints) nie są obsługiwane dla punktu końcowego statycznej strony internetowej; użyj usługi brzegowej (edge service), aby zabezpieczyć i przyspieszyć dostarczanie tam, gdzie wymagany jest dostęp prywatny.

Bezpieczeństwo, tożsamość i kontrolowany dostęp do danych

Usługa Azure Storage domyślnie szyfruje dane w spoczynku (at-rest) za pomocą 256-bitowego algorytmu AES, używając kluczy zarządzanych przez Microsoft. Aby uzyskać ściślejszą kontrolę, włącz klucze zarządzane przez klienta (CMK) przechowywane w Azure Key Vault lub Managed HSM w celu zarządzania rotacją kluczy i separacją obowiązków; nadaj tożsamości zarządzanej konta magazynu uprawnienia do opakowywania/odpakowywania kluczy (wrap/unwrap). W przypadku obciążeń podlegających ścisłym regulacjom włącz szyfrowanie infrastruktury, aby zastosować drugą, niezależną warstwę szyfrowania. Połącz szyfrowanie po stronie serwera z szyfrowaniem po stronie klienta, jeśli wymagana jest pełna kontrola kryptograficzna (end-to-end).

Autoryzacja Azure AD integruje płaszczyznę danych z RBAC dla usług Blob i Queue oraz dla interfejsu Files REST API. Przypisuj role o najniższych uprawnieniach, takie jak Storage Blob Data Reader lub Storage Blob Data Contributor, do tożsamości zarządzanych, użytkowników lub grup. W kodzie używaj

undefined

, aby pozyskiwać tokeny OAuth 2.0 i unikać osadzania kluczy. W przypadku dostępu SMB do Azure Files włącz uwierzytelnianie oparte na tożsamości przy użyciu Active Directory: przyłącz konto magazynu do lokalnej usługi AD DS (za pośrednictwem Azure AD Kerberos dla tożsamości hybrydowych) lub Azure AD DS, a do autoryzacji na poziomie udziału użyj list ACL systemu NTFS i RBAC (np. roli Storage File Data SMB Share Contributor). Upewnij się, że używasz protokołu SMB 3.x z szyfrowaniem w tranzycie (over the wire) i rozważ użycie Private Endpoints, VPN lub ExpressRoute do przechodzenia przez sieci, które blokują port 445.

Sygnatury dostępu współdzielonego (SAS) delegują ograniczony w czasie i zakresie dostęp bez ujawniania kluczy konta. SAS usługi (Service SAS) przyznaje dostęp do określonej usługi i zasobu (np. pojedynczego bloba lub kontenera) z precyzyjnymi uprawnieniami oraz czasem rozpoczęcia/wygaśnięcia. SAS konta (Account SAS) działa na poziomie konta, obejmując wiele usług (bloby, pliki, kolejki, tabele) i interfejsy API usług, takie jak list lub create. SAS delegowania użytkownika (User delegation SAS) jest specyficzny dla Blob storage i jest podpisywany kluczem delegowania użytkownika uzyskanym przez Azure AD dla jednostki usługi (principal) z odpowiednimi uprawnieniami RBAC; eliminuje to zależność od kluczy i centralizuje kontrolę dostępu w Azure AD. Stosuj ograniczenia, takie jak zakresy adresów IP, dozwolone protokoły (tylko HTTPS) i krótki czas życia. Przechowywane zasady dostępu (Stored access policies) centralizują ograniczenia SAS i umożliwiają unieważnienie dostępu poprzez aktualizację lub usunięcie zasady; mają one zastosowanie do SAS usługi i SAS konta. SAS delegowania użytkownika nie używa przechowywanych zasad dostępu; dostęp unieważnia się poprzez wygaśnięcie klucza delegowania użytkownika lub usunięcie przypisań ról Azure AD. Zawsze preferuj SAS zamiast kluczy konta, a SAS delegowania użytkownika, gdy aplikacja może pozyskiwać tokeny Azure AD.

Podstawy usług Azure Files i Queue Storage

Usługa Azure Files zapewnia w pełni zarządzane udziały SMB oraz opcję NFS dla scenariuszy POSIX. Udziały SMB należy stosować w przypadku migracji typu lift-and-shift oraz w celu zapewnienia zgodności aplikacji. Konta Premium FileStorage dostarczają przewidywalną wydajność o niskim opóźnieniu, podczas gdy udziały w warstwie standard są ekonomiczne dla danych plików ogólnego przeznaczenia. Udziałami i plikami można zarządzać za pomocą klientów SMB lub interfejsu REST API/zestawów SDK. Usługa Azure File Sync umożliwia tworzenie hybrydowych usług plików poprzez buforowanie udziału w chmurze na serwerze Windows Server, zapewniając lokalną wydajność i przenoszenie zimnych danych do chmury (tiering), synchronizację wielooddziałową oraz kopie zapasowe/odzyskiwanie po awarii poza siedzibą firmy (DR) bez tradycyjnych cykli odświeżania pamięci masowej NAS. Połącz tożsamość opartą na Azure AD z listami ACL systemu NTFS, aby egzekwować zasadę najniższych uprawnień, i użyj prywatnych punktów końcowych (Private Endpoints), aby ograniczyć ryzyko eksfiltracji danych.

Usługa Azure Queue Storage umożliwia tworzenie rozdzielonych, odpornych na błędy przepływów pracy aplikacji. Każda wiadomość może mieć rozmiar do 64 KB (większe ładunki powinny odwoływać się do identyfikatorów URI obiektów blob). Czas życia wiadomości (time-to-live, TTL) określa jej automatyczne wygasanie; należy podać wartość dodatnią od kilku sekund do siedmiu dni lub -1, aby wiadomość nie wygasała. Gdy proces roboczy pobiera wiadomość, staje się ona niewidoczna na czas określony przez limit czasu widoczności (visibility timeout). Jeśli przetwarzanie nie powiedzie się, a wiadomość nie zostanie usunięta przed upływem tego limitu, pojawi się ponownie dla innego konsumenta. Limit czasu widoczności należy dostroić tak, aby przekraczał najgorszy możliwy czas przetwarzania, oraz stosować idempotentne procedury obsługi i wykładnicze ponawianie (exponential backoff), aby zmniejszyć rywalizację o zasoby. Śledź licznik pobrań (dequeue count), aby wykrywać wiadomości zatrute (poison messages); gdy przekroczy on określony próg, przenieś wiadomość do dedykowanej kolejki zatrutych wiadomości w celu poddania jej kwarantannie i analizie. Wyzwalacze kolejek w Azure Functions automatycznie implementują ten wzorzec, tworząc kolejkę -poison. W przypadku potrzeby wyższej przepustowości lub obsługi FIFO z gwarancją kolejności, rozważ użycie kolejek Service Bus; w przeciwnym razie Azure Queue Storage jest rozwiązaniem lekkim i efektywnym kosztowo.

Praktyczny scenariusz problemowy

National Geographic musi opublikować mikrowitrynę fotograficzną o dużym natężeniu ruchu z bezserwerowym przetwarzaniem obrazów, zoptymalizowaną kosztowo pamięcią masową oraz hybrydowym dostępem dla lokalnego narzędzia redakcyjnego. Wymagają również bezpiecznych, ograniczonych czasowo linków do udostępniania dla agencji partnerskich oraz solidnej obsługi wiadomości dla przetwarzania w tle.

Utwórz konto magazynu GPv2 z replikacją RA-GRS

Dlaczego: GPv2 odblokowuje usługi Blob, Files i Queue z funkcjami cyklu życia i tieringu. RA-GRS zapewnia odporność na awarie międzyregionalne oraz dostęp do odczytu w dodatkowych punktach końcowych w celu zapewnienia ciągłości dostępu do zasobów głównie odczytywanych podczas incydentów regionalnych.

Włącz hosting statycznych witryn internetowych i wdróż zasoby witryny w kontenerze $web

Dlaczego: Statyczne witryny internetowe w usłudze Blob eliminują zarządzanie serwerami WWW, zapewniają odczyty o niskim opóźnieniu z warstwy Hot i skalują się globalnie. W późniejszym etapie można je połączyć z usługą Azure Front Door w celu obsługi domen niestandardowych, WAF i buforowania brzegowego.

Przechowuj oryginalne obrazy RAW jako blokowe obiekty blob; telemetrię zapisywaną jednokrotnie jako uzupełniające obiekty blob

Dlaczego: Blokowe obiekty blob obsługują duże, równoległe przesyłanie oraz wydajne dostarczanie zoptymalizowanych pod kątem sieci Web pochodnych. Uzupełniające obiekty blob upraszczają jednoczesne zapisy logów z potoków przetwarzania bez konfliktów.

Zdefiniuj zasady cyklu życia, aby przenosić oryginały do warstwy Chłodnej (Cool) po 30 dniach i do Archiwalnej (Archive) po 180 dniach; usuwaj wersje starsze niż rok

Dlaczego: Zautomatyzowany tiering redukuje koszty przechowywania w oparciu o wzorce dostępu, jednocześnie zachowując kopie wymagane ze względów zgodności. Czyszczenie wersji i migawek kontroluje rozrost danych bez ręcznej interwencji.

Zabezpiecz dostęp do danych za pomocą Azure AD i sygnatur SAS delegowanych przez użytkownika dla partnerów

Dlaczego: Przypisz rolę Storage Blob Data Reader do tożsamości zarządzanej w usłudze udostępniania, uzyskaj klucze delegowania użytkownika i generuj krótkożyciowe tokeny SAS tylko dla protokołu HTTPS z ograniczeniami IP. Pozwala to uniknąć dystrybucji kluczy konta i wiąże autoryzację z Azure AD.

Włącz klucze zarządzane przez klienta (CMK) z usługą Key Vault i szyfrowaniem infrastruktury

Dlaczego: CMK spełnia surowsze wymagania dotyczące zgodności i rotacji, podczas gdy podwójne szyfrowanie zapewnia dogłębną ochronę (defense in depth) dla wrażliwych mediów.

Zintegruj Azure Queue Storage do przetwarzania obrazów w tle z wyzwalaczem kolejki Azure Functions; ustaw limit czasu widoczności tak, aby przekraczał maksymalny czas przetwarzania i skonfiguruj obsługę zatrutych wiadomości

Dlaczego: Kolejki rozdzielają ścieżkę przesyłania od zasobów obliczeniowych. Limit czasu widoczności zapobiega zduplikowanej pracy, a środowisko uruchomieniowe Functions automatycznie kieruje elementy, których przetwarzanie się nie powiodło, do kolejki -poison w celu dalszej analizy.

Opublikuj narzędzia redakcyjne za pomocą Azure Files, używając konta Premium FileStorage i usługi Azure File Sync na lokalnym serwerze Windows Server

Dlaczego: Redaktorzy uzyskują dostęp SMB o niskim opóźnieniu z listami ACL systemu NTFS i uwierzytelnianiem opartym na tożsamości poprzez AD, podczas gdy Azure File Sync zapewnia lokalne buforowanie i tiering do chmury. Warstwa premium zapewnia stałą wydajność dla obciążeń interaktywnych.

Użyj Azure Front Door jako frontonu dla statycznej witryny i włącz buforowanie oraz niestandardowy protokół HTTPS

Dlaczego: Brzegowe punkty obecności (POP) zmniejszają opóźnienia na całym świecie, domeny niestandardowe spełniają wymagania dotyczące brandingu, a WAF dodaje zabezpieczenia bez zmiany backendu pamięci masowej.

Włącz kanał zmian konta magazynu (change feed) i archiwizuj go w magazynie zgodności

Dlaczego: Niezmienny, uporządkowany dziennik zmian obiektów blob wspiera dalszą analitykę, inspekcję i odtwarzanie w celu tworzenia odtwarzalnych potoków przetwarzania treści.

← Azure Functions i przetwarzanie bezserwerowe · Wszystkie domeny · Azure Cosmos DB →

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