Microsoft AZ-900: Magazyn i bazy danych — Przewodnik do nauki

By Laurynas Brazys · 23 July 2026 · #microsoft #az-900 #certification #exam-prep #study-guide

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

Azure zapewnia szeroką podstawę do przechowywania danych nieustrukturyzowanych i ustrukturyzowanych na skalę globalną, z wbudowaną trwałością, bezpieczeństwem i kontrolą kosztów. Zrozumienie właściwego prymitywu magazynu, modelu redundancji, warstwy dostępu i usługi bazy danych pozwala na tworzenie niezawodnych i wydajnych aplikacji, od maszyn wirtualnych po globalnie rozproszone platformy internetowe i mobilne.

Usługi Azure Storage i dyski zarządzane

Azure Blob Storage jest podstawą dla danych nieustrukturyzowanych. Blokowe obiekty blob (Block blobs) obsługują duże obiekty z wydajnym przesyłaniem strumieniowym i równoległym, migawkami, wersjonowaniem i warstwami dostępu (tiering). Stronicowe obiekty blob (Page blobs) są zoptymalizowane pod kątem losowych operacji wejścia/wyjścia (I/O) na stronach o rozmiarze 512 bajtów i stanowią podstawę dla wirtualnych dysków twardych; znajdują się pod dyskami i w scenariuszach wymagających stałej, niskiej latencji IOPS. Dołączane obiekty blob (Append blobs) są dostosowane do scenariuszy z dużą liczbą operacji zapisu, takich jak logi aplikacji, gdzie nowe bloki są wydajnie dodawane na końcu. Azure Files oferuje w pełni zarządzane udziały plików dostępne przez SMB lub NFS z listami ACL systemu NTFS, opcjami integracji z katalogami oraz usługą Azure File Sync do buforowania gorących danych na serwerach Windows Server. Queue Storage zapewnia lekką i trwałą obsługę komunikatów aplikacji w celu oddzielenia komponentów, z semantyką dostarczania „co najmniej raz” (at-least-once). Table Storage dostarcza bezschematowy magazyn klucz/atrybut dla ogromnych, partycjonowanych zestawów danych, gdzie kontrolujesz klucze partycji i wierszy w celu zapewnienia skalowalności i efektywności kosztowej. Dyski zarządzane (Managed disks) zapewniają trwałą, stałą pamięć masową blokową dla maszyn wirtualnych Azure (Azure Virtual Machines) bez konieczności bezpośredniego zarządzania kontami magazynu czy stronicowymi obiektami blob. Wybieraj spośród Standard HDD dla obciążeń zoptymalizowanych pod kątem kosztów i przepustowości, Standard SSD dla zrównoważonej wydajności, Premium SSD i Premium SSD v2 dla wysokiej liczby IOPS przy niskim opóźnieniu oraz Ultra Disk dla najbardziej wymagających obciążeń transakcyjnych z konfigurowalną liczbą IOPS i przepustowością. Dyski zarządzane obsługują migawki, kopie zapasowe przyrostowe, szyfrowanie dysków oraz opcje dostępności dostosowane do umów SLA Twoich maszyn wirtualnych.

• Blob – Block blob
  • Model danych lub wzorzec I/O: Duże obiekty, sekwencyjne I/O
  • Kluczowe możliwości: Warstwy dostępu (tiering), migawki, wersjonowanie, zasady cyklu życia
  • Typowe zastosowania: Obrazy, wideo, kopie zapasowe, strefy docelowe dla big data
  • Istotne ograniczenia/uwagi: Pojedynczy blob do ~190 TiB; brak optymalizacji dla losowego I/O
• Blob – Page blob
  • Model danych lub wzorzec I/O: Losowe I/O na stronach 512-bajtowych
  • Kluczowe możliwości: Niskie opóźnienia odczytu/zapisu, podstawa dla VHD
  • Typowe zastosowania: Magazyn bazowy dla dysków i scenariuszy wymagających dostępu losowego
  • Istotne ograniczenia/uwagi: Rozmiar stronicowego bloba do 8 TiB; dyski zarządzane abstrahują tę warstwę
• Blob – Append blob
  • Model danych lub wzorzec I/O: Zapisy tylko do dołączania (append-only)
  • Kluczowe możliwości: Wydajne dołączanie logów, opcje niezmienności
  • Typowe zastosowania: Telemetria i logi aplikacji
  • Istotne ograniczenia/uwagi: Aktualizacja w miejscu nie jest obsługiwana; obowiązują limity liczby bloków
• Azure Files
  • Model danych lub wzorzec I/O: Semantyka plików POSIX/SMB/NFS
  • Kluczowe możliwości: Dostęp SMB/NFS, listy ACL systemu NTFS, integracja z AD DS/Azure AD DS, File Sync
  • Typowe zastosowania: Udziały plików przenoszone metodą „lift-and-shift”, konfiguracja aplikacji, katalogi domowe użytkowników
  • Istotne ograniczenia/uwagi: Warstwy Standard i Premium; duże udziały plików do 100 TiB
• Queue Storage
  • Model danych lub wzorzec I/O: Kolejka komunikatów
  • Kluczowe możliwości: Dostarczanie „co najmniej raz”, limity czasu widoczności, obsługa zatrutych komunikatów (poison message)
  • Typowe zastosowania: Przetwarzanie w tle, oddzielone mikrousługi
  • Istotne ograniczenia/uwagi: Rozmiar komunikatu do 64 KB (użyj Service Bus dla większych/zaawansowanych wzorców)
• Table Storage
  • Model danych lub wzorzec I/O: Klucz/atrybut NoSQL
  • Kluczowe możliwości: Ogromna skala, partycjonowanie według PartitionKey, niski koszt
  • Typowe zastosowania: Telemetria, katalogi, profile użytkowników
  • Istotne ograniczenia/uwagi: Brak złączeń (joins) i indeksów wtórnych; Cosmos DB Table API dla potrzeb globalnych
• Managed disks
  • Model danych lub wzorzec I/O: Pamięć masowa blokowa dla maszyn wirtualnych
  • Kluczowe możliwości: Jednostki SKU Standard/Premium/Ultra, migawki, skalowanie, szyfrowanie dysków
  • Typowe zastosowania: Dyski systemowe/danych dla maszyn wirtualnych, bazy danych, aplikacje biznesowe (line-of-business)
  • Istotne ograniczenia/uwagi: Do 32 TiB na dysk; ZRS dostępne dla wybranych jednostek SKU

Opcje redundancji i trwałości

Modele redundancji definiują, gdzie i ile synchronicznych oraz asynchronicznych replik danych utrzymuje usługa Azure. Magazyn lokalnie nadmiarowy (LRS) przechowuje trzy kopie w jednym centrum danych w jednym regionie, chroniąc przed awariami dysków i szaf serwerowych przy najniższym koszcie. Magazyn strefowo nadmiarowy (ZRS) rozmieszcza trzy synchroniczne kopie w oddzielnych strefach dostępności w jednym regionie, zapewniając odporność na awarię strefy bez konieczności przełączania awaryjnego aplikacji. Magazyn geograficznie nadmiarowy (GRS) rozszerza LRS, asynchronicznie replikując dane do sparowanego regionu, co daje łącznie sześć kopii w dwóch regionach; po zainicjowaniu przez Microsoft przełączenia awaryjnego konta, region pomocniczy staje się nowym regionem podstawowym. Magazyn geograficznie nadmiarowy z dostępem do odczytu (RA-GRS) dodaje aktywny, pomocniczy punkt końcowy tylko do odczytu, dzięki czemu aplikacje mogą odczytywać dane z regionu pomocniczego nawet przed przełączeniem awaryjnym, co umożliwia globalną dystrybucję odczytu i odciążanie analityki. Magazyn geograficznie i strefowo nadmiarowy (GZRS) łączy ZRS w regionie podstawowym z asynchroniczną replikacją do LRS w sparowanym regionie, chroniąc zarówno przed awariami strefowymi, jak i regionalnymi; wariant z dostępem do odczytu (RA-GZRS) udostępnia punkty końcowe do odczytu w regionie pomocniczym. Wybór jest podyktowany celami odzyskiwania, oczekiwaniami dotyczącymi opóźnień i budżetem. W obrębie jednego regionu ZRS chroni przed awariami stref, utrzymując niskie opóźnienie zapisu. W przypadku scenariuszy obejmujących wiele regionów, GRS/RA-GRS i GZRS są preferowane do odzyskiwania po awarii i odczytu międzyregionalnego. Spójność danych w regionie pomocniczym jest z założenia asynchroniczna w opcjach geograficznych, więc aplikacje powinny tolerować docelową spójność do czasu zakończenia przełączenia awaryjnego.

• LRS
  • Układ replikacji: 3 kopie w jednym centrum danych (region)
  • Dostęp do odczytu w regionie pomocniczym: Nie
  • Odporność na awarie regionalne/strefowe: Chroni przed lokalnymi awariami sprzętu/szaf serwerowych
  • Typowe obciążenia: Tworzenie/testowanie oprogramowania, tani magazyn, dane niekrytyczne
• ZRS
  • Układ replikacji: 3 kopie replikowane synchronicznie w 3 strefach dostępności (region)
  • Dostęp do odczytu w regionie pomocniczym: Nie
  • Odporność na awarie regionalne/strefowe: Przetrzymuje awarie stref bez konieczności przełączania awaryjnego na poziomie aplikacji
  • Typowe obciążenia: Produkcyjna zawartość internetowa/aplikacji wymagająca wysokiej dostępności regionalnej
• GRS
  • Układ replikacji: LRS w regionie podstawowym + asynchroniczny LRS w sparowanym regionie (łącznie ~6 kopii)
  • Dostęp do odczytu w regionie pomocniczym: Nie
  • Odporność na awarie regionalne/strefowe: Regionalne odzyskiwanie po awarii (DR) przez przełączenie awaryjne konta; brak ochrony strefowej w regionie podstawowym
  • Typowe obciążenia: Kopie zapasowe/archiwizacja z regionalnym planem odzyskiwania po awarii
• RA-GRS
  • Układ replikacji: GRS + punkt końcowy do odczytu w regionie pomocniczym
  • Dostęp do odczytu w regionie pomocniczym: Tak
  • Odporność na awarie regionalne/strefowe: Taka sama jak w GRS; umożliwia globalną dystrybucję odczytu
  • Typowe obciążenia: Globalne odczyty zawartości, analityka/raportowanie z regionu pomocniczego
• GZRS
  • Układ replikacji: ZRS w regionie podstawowym + asynchroniczny LRS w sparowanym regionie
  • Dostęp do odczytu w regionie pomocniczym: Nie (użyj RA-GZRS)
  • Odporność na awarie regionalne/strefowe: Chroni przed awariami strefowymi i katastrofami regionalnymi
  • Typowe obciążenia: Aplikacje o znaczeniu krytycznym wymagające odporności strefowej i geograficznej

Warstwy dostępu i zarządzanie cyklem życia

Warstwy dostępu do obiektów blob dopasowują koszt magazynowania do wzorców dostępu. Warstwa Gorąca (Hot) jest zoptymalizowana pod kątem częstego dostępu, oferując najniższe koszty transakcji odczytu i zapisu przy wyższej cenie za GB magazynu. Warstwa Chłodna (Cool) obniża cenę za GB magazynu i zwiększa koszty transakcji oraz wczesnego usunięcia, co czyni ją odpowiednią dla zestawów danych, do których dostęp uzyskuje się rzadko, takich jak miesięczne raporty czy krótkoterminowe kopie zapasowe. Warstwa Archiwalna (Archive) oferuje najniższy koszt magazynowania, ale wymaga przywrócenia (rehydracji) przed uzyskaniem dostępu, przy najwyższych opłatach za dostęp i wczesne usunięcie; jest przeznaczona do scenariuszy długoterminowego przechowywania i zgodności z przepisami. Zasady zarządzania cyklem życia automatyzują przenoszenie między warstwami i przechowywanie na poziomie kontenera lub konta. Reguły mogą przenosić obiekty blob między warstwami Gorącą, Chłodną i Archiwalną na podstawie czasu ostatniej modyfikacji, czasu ostatniego dostępu lub tagów indeksu obiektu blob; oraz usuwać wersje, migawki lub podstawowe obiekty blob po określonym czasie. Zasady pomagają zmniejszyć całkowity koszt posiadania (TCO), przenosząc zimne dane z magazynu Gorącego i wycofując przestarzałe dane bez ręcznej interwencji. Zarządzanie cyklem życia jest dostępne dla kont magazynu ogólnego przeznaczenia w wersji 2 (general-purpose v2) i Blob storage i działa na blokowych oraz uzupełniających obiektach blob; nie ma zastosowania do magazynu premium block blob. Przywracanie (rehydracja) z warstwy Archiwalnej obsługuje opcje o standardowym i wysokim priorytecie, wymieniając koszt na szybkość. Należy planować okna czasowe odzyskiwania mierzone w godzinach dla standardowej rehydracji i od minut do godzin dla opcji o wysokim priorytecie dla mniejszych obiektów. W celu zapewnienia zgodności, połącz warstwę Archiwalną z zasadami niezmienności (przechowywanie oparte na czasie lub blokada prawna), aby wymusić gwarancje zapisu jednokrotnego i wielokrotnego odczytu (WORM) na poziomie kontenera lub obiektu blob.

• Hot
  • Koszt magazynowania: Najwyższy
  • Koszt dostępu/transakcji: Najniższy
  • Minimalny okres przechowywania: Brak
  • Opóźnienie odzyskiwania: Milisekundy (online)
  • Typowe dane: Aktywna zawartość, często odczytywane/zapisywane dane
• Cool
  • Koszt magazynowania: Niższy niż w warstwie Hot
  • Koszt dostępu/transakcji: Wyższy niż w warstwie Hot; obowiązuje opłata za wczesne usunięcie
  • Minimalny okres przechowywania: 30 dni
  • Opóźnienie odzyskiwania: Milisekundy (online)
  • Typowe dane: Rzadko używane dane, krótkoterminowe kopie zapasowe
• Archive
  • Koszt magazynowania: Najniższy
  • Koszt dostępu/transakcji: Najwyższy; obowiązuje opłata za wczesne usunięcie
  • Minimalny okres przechowywania: 180 dni
  • Opóźnienie odzyskiwania: Godziny (wymagana rehydracja)
  • Typowe dane: Długoterminowe przechowywanie, archiwa zgodności, rzadko używane kopie zapasowe

Bezpieczeństwo, szyfrowanie i kontrola dostępu

Szyfrowanie danych w spoczynku jest domyślnie włączone za pomocą Storage Service Encryption (SSE). Domyślnie klucze zarządzane przez firmę Microsoft chronią dane w sposób transparentny. W celu zapewnienia ściślejszej kontroli i rozdziału obowiązków można skonfigurować klucze zarządzane przez klienta (CMK) dla każdego konta magazynu, używając kluczy z Azure Key Vault lub Managed HSM, co wspiera przepływy pracy związane z rotacją i unieważnianiem kluczy. W przypadku wrażliwych obciążeń roboczych opcje podwójnego szyfrowania i przetwarzania poufnego dodatkowo zmniejszają ryzyko ujawnienia danych. Podczas przesyłania danych należy wymuszać użycie protokołu HTTPS z TLS dla wszystkich operacji na płaszczyźnie danych. Kontrola dostępu obejmuje autoryzację opartą na tożsamości oraz tokeny o ograniczonym zakresie. Usługa Azure RBAC integruje się z Microsoft Entra ID, aby przyznawać dostęp do płaszczyzny danych na zasadzie najniższych uprawnień, np. role Storage Blob Data Reader/Contributor, użytkownikom, grupom i tożsamościom zarządzanym. RBAC eliminuje potrzebę stosowania współdzielonych kluczy tajnych i wspiera dostęp warunkowy, Privileged Identity Management oraz inspekcję. Sygnatury dostępu współdzielonego (SAS) delegują dostęp ograniczony czasowo i zakresem uprawnień klientom, którzy mogą nie mieć tożsamości; SAS mogą być podpisywane kluczami konta lub za pomocą delegowania użytkownika przy użyciu poświadczeń Microsoft Entra, aby uniknąć ujawniania kluczy konta. Łącz dostęp oparty na RBAC dla komunikacji między usługami i dostępu administracyjnego z SAS dla tymczasowych przepływów dostępu klienta. Chroń klucze konta i regularnie je rotuj; w miarę możliwości preferuj SAS z delegowaniem użytkownika. Izolacja sieciowa za pomocą Private Endpoints lub punktów końcowych usługi, reguły zapory oraz zasady niezmienności magazynu uzupełniają strategię obrony w głąb dla kont magazynu.

• Azure RBAC (Microsoft Entra ID)
  • Zakres: Role oparte na tożsamości na płaszczyźnie danych i płaszczyźnie zarządzania magazynu
  • Najlepsze dla: Administratorów, usług i aplikacji z tożsamościami zarządzanymi
  • Kluczowe właściwości: Zasada najniższych uprawnień, dostęp warunkowy, możliwość audytu, brak współdzielonych kluczy tajnych
  • Kwestie ryzyka: Wymaga integracji tożsamości; unieważnianie poprzez zmiany ról
• Sygnatura dostępu współdzielonego (SAS)
  • Zakres: Tokeny ograniczone czasowo i zakresem uprawnień dla określonych zasobów
  • Najlepsze dla: Delegowania ograniczonego dostępu klientom/partnerom
  • Kluczowe właściwości: Szczegółowe uprawnienia, ograniczenia IP/czasowe; SAS z delegowaniem użytkownika pozwala uniknąć użycia kluczy konta
  • Kwestie ryzyka: Wyciek tokenu zapewnia dostęp do jego wygaśnięcia; chroń dystrybucję i ustawiaj krótkie okresy ważności

Relacyjne PaaS i globalnie rozproszone NoSQL

Azure SQL Database dostarcza zarządzany silnik relacyjny z automatycznym stosowaniem poprawek, wbudowaną wysoką dostępnością, kopiami zapasowymi i skalowaniem. Wdrażaj pojedyncze bazy danych lub pule elastyczne, aby konsolidować zmienne obciążenia. Usługa utrzymuje wiele replik w regionie i obsługuje nadmiarowość strefową; szyfrowanie Transparent Data Encryption (TDE) jest domyślnie włączone. Zautomatyzowane kopie zapasowe umożliwiają przywracanie do punktu w czasie (point-in-time restore), zazwyczaj przez 7–35 dni, z opcjonalnym długoterminowym przechowywaniem do kilku lat w usłudze Azure Storage. Aby uzyskać odporność w wielu regionach i odczyty o niskim opóźnieniu, użyj aktywnej replikacji geograficznej (do czterech czytelnych replik pomocniczych) lub grup Auto-failover dla skoordynowanego odzyskiwania po awarii (DR) na dużą skalę. Azure SQL Managed Instance oferuje niemal 100% zgodność z silnikiem SQL Server dla funkcji na poziomie instancji, takich jak SQL Agent, zapytania międzybazodanowe, Service Broker i CLR, umożliwiając prostą modernizację z systemów lokalnych bez refaktoryzacji. Dzieli tę samą zarządzaną architekturę wysokiej dostępności (HA), stosowanie poprawek online, zautomatyzowane kopie zapasowe, domyślnie włączone TDE i obsługuje grupy auto-failover między regionami. Izolacja sieciowa z użyciem Private Endpoints oraz skalowanie zasobów obliczeniowych/magazynowych na poziomie bazy danych lub instancji zapewniają przewidywalne parametry wydajności. Azure Cosmos DB zapewnia w pełni zarządzaną, wielomodelową bazę danych NoSQL z gotową do użycia globalną dystrybucją i zapisami w wielu regionach. Gwarantuje jednocyfrowe milisekundowe opóźnienia na 99. percentylu w obrębie regionu i oferuje pięć dostrajalnych poziomów spójności, aby zrównoważyć wydajność i poprawność danych między regionami. Przydzielaj przepustowość w RU/s lub używaj autoskalowania, dodawaj lub usuwaj regiony bez przestojów i konfiguruj automatyczne przełączanie awaryjne. Interfejsy API obejmują Core (SQL), MongoDB, Cassandra, Gremlin i Table, co upraszcza migrację i integrację z różnorodnymi stosami aplikacji.

• Azure SQL Database
  • Model: Relacyjne PaaS (pojedyncza baza danych/pula elastyczna)
  • Zgodność: Najnowsze funkcje SQL; zgodność na poziomie aplikacji
  • HA/DR: Wbudowane repliki, nadmiarowość strefowa; aktywna replikacja geograficzna; grupy Auto-failover
  • Kopie zapasowe/TDE: Automatyczne PITR 7–35 dni; LTR do kilku lat; TDE domyślnie włączone
  • Opcje geograficzne: Czytelne repliki pomocnicze w różnych regionach; skoordynowane grupy failover
  • Najlepiej nadaje się do: Aplikacji SaaS/wielodostępnych, nowych relacyjnych obciążeń natywnych dla chmury
• Azure SQL Managed Instance
  • Model: Relacyjne PaaS (instancja)
  • Zgodność: Wysoka zgodność funkcji z SQL Server, w tym SQL Agent, zapytania międzybazodanowe
  • HA/DR: Wbudowane HA; nadmiarowość strefowa; grupy Auto-failover
  • Kopie zapasowe/TDE: Automatyczne PITR 7–35 dni; LTR; TDE domyślnie włączone; obsługa natywnego przywracania
  • Opcje geograficzne: Wiele regionów z grupami failover i czytelnymi replikami pomocniczymi
  • Najlepiej nadaje się do: Migracji lift-and-shift lokalnego SQL z minimalnymi zmianami
• Azure Cosmos DB
  • Model: NoSQL, wielomodelowy (Core, MongoDB, Cassandra, Gremlin, Table)
  • Zgodność: Zgodność na poziomie API dla popularnych stosów NoSQL
  • HA/DR: Wiele regionów, zapisy multi-master; SLA na poziomie 99,99%
  • Kopie zapasowe/TDE: Opcje zautomatyzowanych i ciągłych kopii zapasowych; szyfrowanie danych w spoczynku
  • Opcje geograficzne: Dodawanie/usuwanie regionów na żywo; dostrajalna spójność; automatyczne przełączanie awaryjne
  • Najlepiej nadaje się do: Globalnych aplikacji o niskim opóźnieniu, IoT, katalogów, personalizacji

Problem praktyczny: Tailwind Traders: Dwuregionalna odporność z bezpiecznymi, zoptymalizowanymi kosztowo warstwami danych

Scenariusz: Firma Tailwind Traders prowadzi działalność e-commerce, gdzie główne obciążenia robocze znajdują się w regionie East US, a infrastruktura odzyskiwania po awarii w West US. Obrazy produktów i logi są przechowywane w magazynie obiektów, natomiast zamówienia i stany magazynowe działają na zarządzanej relacyjnej bazie danych. Podczas incydentów regionalnych firma wymaga dostępu do odczytu mediów produktowych z regionu pomocniczego, aby katalog pozostawał możliwy do przeglądania. Zarządzanie danymi wymaga szyfrowania przy użyciu kluczy zarządzanych przez klienta oraz retencji logów audytowych opartej na czasie.

Wyzwanie: Zaprojektuj usługi magazynu i bazy danych, które zapewnią międzyregionalny dostęp do odczytu dla mediów, zautomatyzowany cykl życia i retencję dla logów, silne szyfrowanie i dostęp z najniższymi uprawnieniami, a także zarządzany backend relacyjny z wbudowaną wysoką dostępnością i odzyskiwaniem po awarii.

Zalecane podejście:

1. 1. Utwórz konto magazynu ogólnego przeznaczenia w wersji 2 (general-purpose v2) w regionie East US z replikacją RA-GRS (lub RA-GZRS, jeśli wymagana jest również odporność na awarie strefy) dla kontenerów z mediami produktowymi.
2. 2. Włącz obsługę wyłącznie przez HTTPS, skonfiguruj prywatny punkt końcowy do sieci VNet i zintegruj klucze zarządzane przez klienta z usługi Azure Key Vault dla konta magazynu.
3. 3. Zdefiniuj zasady cyklu życia: przenieś media, do których nie uzyskano dostępu przez 30 dni, do warstwy Cool, a po 180 dniach do warstwy Archive; usuń zarchiwizowane media po 5 latach.
4. 4. Dla logów aplikacji przeznaczonych tylko do dołączania (append-only) użyj kontenera typu append blob z niezmiennymi (opartymi na czasie) zasadami retencji i oddzielną regułą cyklu życia, aby przenieść starsze logi do warstwy Archive.
5. 5. Udziel dostępu aplikacji przy użyciu ról Azure RBAC (Storage Blob Data Contributor) dla tożsamości zarządzanych; wystawiaj krótkotrwałe sygnatury SAS z delegowaniem użytkownika dla przesyłania plików przez partnerów do kontenera przejściowego (staging).
6. 6. Zainicjuj usługę Azure SQL Database (w warstwie Business Critical lub General Purpose z redundancją strefową) dla zamówień i stanów magazynowych; skonfiguruj grupy Auto-failover w celu replikacji do regionu West US.
7. 7. Zweryfikuj automatyczne kopie zapasowe (PITR na 7–35 dni) i włącz długoterminową retencję dla baz danych wymagających zgodności z przepisami, jeśli jest to konieczne.
8. 8. Zaimplementuj Transparent Data Encryption (TDE, włączone domyślnie) i, jeśli jest to wymagane, użyj własnego klucza (bring your own key) dla zasobu serwera SQL.
9. 9. Zaktualizuj aplikację e-commerce, aby odczytywała media produktowe przez pomocniczy punkt końcowy RA, gdy wydajność głównego regionu jest obniżona; kontynuuj zapisy transakcyjne do głównej bazy SQL aż do momentu przełączenia awaryjnego.
10. 10. Przeprowadź testy przełączania awaryjnego zarówno dla magazynu (przełączanie awaryjne konta), jak i SQL (grupa Auto-failover) oraz udokumentuj wartości RTO/RPO w odniesieniu do celów biznesowych.

Uzasadnienie użycia Azure: Replikacja RA-GRS zapewnia trzy synchroniczne repliki w regionie głównym oraz asynchroniczną replikację do sparowanego regionu i udostępnia pomocniczy punkt końcowy tylko do odczytu, spełniając wymóg obsługi odczytów katalogu podczas zakłóceń regionalnych. Zasady cyklu życia dostosowują koszty magazynowania do wzorców dostępu poprzez przenoszenie rzadko używanych mediów do warstw Cool i Archive oraz egzekwowanie retencji opartej na czasie dla logów z zapewnieniem niezmienności. Klucze zarządzane przez klienta i prywatne punkty końcowe wzmacniają bezpieczeństwo i zgodność z przepisami, podczas gdy Azure RBAC i sygnatury SAS z delegowaniem użytkownika wymuszają zasadę najniższych uprawnień i bezpieczne delegowanie. Usługa Azure SQL Database oferuje wbudowaną wysoką dostępność (HA), TDE i zautomatyzowane kopie zapasowe; grupy Auto-failover zapewniają kontrolowane, przetestowane przełączanie awaryjne między regionami dla obciążeń transakcyjnych w celu utrzymania ciągłości usług.

← Sieci · Wszystkie domeny · Tożsamość →

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

Przeglądaj Microsoft →