U ontwerpt een spoke virtueel netwerk in Azure om een multi-tier applicatie te hosten. De IP-strategie van het bedrijf reserveert 10.0.0.0/8 voor on-premises en bestaande hub VNets. De nieuwe spoke moet overlap vermijden om peering met de hub mogelijk te maken. De app zal een Azure Storage account gebruiken dat nooit bereikbaar mag zijn via zijn publieke endpoint. U verwacht ongeveer 500 VM's met ruimte om te schalen. Wat moet u ontwerpen?

De correcte optie voldoet aan alle vereisten. Het 172.16.0.0/16 VNet vermijdt IP-overlap met 10.0.0.0/8. De /23 en /24 subnetten bieden voldoende IP-adressen voor 500+ VM's (een /23 heeft 510 bruikbare IP's, een /24 heeft 254). Een dedicated /27 subnet voor Private Endpoints is een best practice voor isolatie en beheer. Het gebruik van Private Endpoints voor het Storage Account in combinatie met een private DNS zone en het uitschakelen van publieke netwerktoegang garandeert dat het storage account nooit via zijn publieke endpoint bereikbaar is, wat een cruciale beveiligingsvereiste is. De andere opties zijn incorrect omdat: Een 172.16.0.0/24 VNet te klein is voor 500 VM's. Service Endpoints bieden geen volledige isolatie van het publieke endpoint. Een 10.250.0.0/16 VNet overlapt met de gereserveerde 10.0.0.0/8 ruimte. Het publieke endpoint ingeschakeld laten is een beveiligingsrisico. Het plaatsen van Private Endpoints binnen productiesubnets is mogelijk, maar een dedicated subnet is beter voor beheer. Subnet netwerkbeleid is niet direct gerelateerd aan de IP-strategie of Private Endpoint-implementatie. Een enkel /16 subnet is onvoldoende voor segmentatie en beveiliging. Service Endpoints voldoen niet aan de vereiste om het publieke endpoint volledig te blokkeren.