You’re designing a spoke virtual network in Azure to host a multi-tier application. Corporate IP strategy reserves 10.0.0.0/8 for on-premises and existing hub VNets. The new spoke must avoid overlap to allow peering to the hub. The app will use an Azure Storage account that must never be reachable via its public endpoint. You expect about 500 VMs with room to scale. What should you design?

The correct answer provides a non-overlapping IP range (172.16.0.0/16) for the spoke VNet, crucial for peering with existing 10.0.0.0/8 networks. It allocates appropriately sized subnets (/23 for app/DB, /24 for web) to accommodate 500+ VMs with room for growth, and a dedicated /27 for private endpoints, which is a best practice for managing these resources. Using Private Endpoints for the storage account, linking a private DNS zone, and disabling public network access ensures the storage account is only accessible privately, meeting the security requirement. Incorrect options: A 172.16.0.0/24 VNet is too small for 500+ VMs and multiple subnets. Service Endpoints still use the public endpoint, which is not allowed. A 10.250.0.0/16 VNet overlaps with the existing 10.0.0.0/8 range. Keeping the public endpoint enabled violates the requirement. A 192.168.0.0/20 VNet is a valid range, but placing private endpoints directly in production subnets is less secure than a dedicated subnet, and leaving subnet network policies enabled might interfere with private endpoint functionality if not configured carefully. A 172.16.0.0/16 VNet with a single /16 subnet lacks proper segmentation for a multi-tier application. Service Endpoints don't meet the "never reachable via public endpoint" requirement.