Projektujesz szprychową sieć wirtualną w Azure do hostowania wielowarstwowej aplikacji. Korporacyjna strategia IP rezerwuje 10.0.0.0/8 dla sieci lokalnych i istniejących sieci wirtualnych typu hub. Nowa sieć szprychowa musi unikać nakładania się adresów, aby umożliwić peering z hubem. Aplikacja będzie korzystać z konta Azure Storage, które nigdy nie może być dostępne poprzez swój publiczny punkt końcowy. Spodziewasz się około 500 maszyn wirtualnych z możliwością skalowania. Co powinieneś zaprojektować?

Poprawna odpowiedź tworzy sieć wirtualną (VNet) z przestrzenią adresową 172.16.0.0/16, która nie nakłada się na istniejące sieci 10.0.0.0/8. Podsieci /23 i /24 zapewniają wystarczającą liczbę adresów IP dla 500 maszyn wirtualnych z możliwością skalowania (np. /23 daje 510 adresów, /24 daje 254 adresy). Dedykowana podsieć /27 dla prywatnych punktów końcowych (Private Endpoints) jest najlepszą praktyką bezpieczeństwa, izolując ruch do Azure Storage. Użycie Private Endpoints i wyłączenie publicznego dostępu do konta magazynu spełnia wymóg, aby nigdy nie było ono dostępne publicznie, a integracja z prywatną strefą DNS zapewnia prawidłowe rozpoznawanie nazw. Pozostałe opcje są nieprawidłowe, ponieważ: 172.16.0.0/24 z podsieciami /28 jest za mała dla 500 maszyn wirtualnych. Service Endpoints nie spełniają wymogu braku publicznego dostępu. 10.250.0.0/16 nakłada się na 10.0.0.0/8. Pozostawienie publicznego punktu końcowego włączonego jest niezgodne z wymaganiami bezpieczeństwa. 192.168.0.0/20 jest prawidłową przestrzenią adresową, ale umieszczenie prywatnych punktów końcowych w podsieciach produkcyjnych bez dedykowanej podsieci jest mniej bezpieczne. Pojedyncza podsieć /16 jest nieefektywna i nie pozwala na segmentację, a Service Endpoints nie spełniają wymogu braku publicznego dostępu.