Está diseñando una red virtual spoke en Azure para alojar una aplicación de múltiples niveles. La estrategia de IP corporativa reserva 10.0.0.0/8 para redes locales y VNets hub existentes. La nueva spoke debe evitar la superposición para permitir el emparejamiento con el hub. La aplicación utilizará una cuenta de Azure Storage que nunca debe ser accesible a través de su endpoint público. Espera unas 500 VM con espacio para escalar. ¿Qué debería diseñar?

La opción correcta aborda todos los requisitos. La VNet 172.16.0.0/16 evita la superposición con 10.0.0.0/8. Las subredes /23 y /24 proporcionan suficiente espacio para 500+ VMs. Una subred /27 dedicada para Private Endpoints es una buena práctica de seguridad y gestión. El uso de Private Endpoints para la cuenta de almacenamiento, junto con la deshabilitación del acceso público y la vinculación a una zona DNS privada, asegura que el almacenamiento sea inaccesible públicamente y se resuelva internamente. Las opciones incorrectas fallan en varios puntos: Una VNet /24 con subredes /28 no proporciona suficiente espacio para 500+ VMs. Los Service Endpoints no cumplen el requisito de "nunca accesible a través de su endpoint público". Una VNet 10.250.0.0/16 se superpone con 10.0.0.0/8. Habilitar el endpoint público para administración contradice el requisito de que nunca sea accesible públicamente. Colocar Private Endpoints dentro de subredes de producción y dejar las políticas de red habilitadas puede causar problemas de conectividad para los Private Endpoints, que requieren políticas de red deshabilitadas en su subred. Una VNet /16 con una única subred /16 no permite la segmentación de red necesaria para una aplicación de múltiples niveles. Los Service Endpoints no cumplen el requisito de "nunca accesible a través de su endpoint público".