Você está projetando uma rede virtual spoke no Azure para hospedar um aplicativo de múltiplas camadas. A estratégia de IP corporativa reserva 10.0.0.0/8 para redes locais e VNets de hub existentes. O novo spoke deve evitar sobreposição para permitir o emparelhamento com o hub. O aplicativo usará uma conta do Azure Storage que nunca deve ser acessível através de seu endpoint público. Você espera cerca de 500 VMs com espaço para escalar. O que você deve projetar?

A opção correta atende a todos os requisitos: a VNet 172.16.0.0/16 evita sobreposição com 10.0.0.0/8. As sub-redes /23 e /24 fornecem espaço IP suficiente para 500+ VMs. Uma sub-rede /27 dedicada para Private Endpoints é uma prática recomendada para isolamento e gerenciamento. O uso de Private Endpoints com uma zona DNS privada e a desativação do acesso público garantem que a conta de armazenamento seja acessível apenas internamente, conforme exigido. As outras opções estão incorretas porque: Uma VNet /24 não tem espaço IP suficiente para 500+ VMs. Service Endpoints não desabilitam o acesso público à conta de armazenamento. Uma VNet 10.250.0.0/16 se sobrepõe ao espaço 10.0.0.0/8, e manter o endpoint público habilitado viola o requisito de segurança. Colocar Private Endpoints diretamente em sub-redes de produção sem uma sub-rede dedicada não é a melhor prática, e as políticas de rede da sub-rede podem interferir. Uma única sub-rede /16 não permite isolamento de camadas e Service Endpoints não desabilitam o acesso público.