Vous concevez un réseau virtuel spoke dans Azure pour héberger une application multiniveau. La stratégie IP de l'entreprise réserve 10.0.0.0/8 pour les réseaux sur site et les réseaux virtuels hub existants. Le nouveau spoke doit éviter tout chevauchement pour permettre le peering avec le hub. L'application utilisera un compte Azure Storage qui ne doit jamais être accessible via son point de terminaison public. Vous prévoyez environ 500 machines virtuelles avec une capacité d'évolution. Que devriez-vous concevoir ?

L'option correcte répond à toutes les exigences. L'espace d'adressage 172.16.0.0/16 évite le chevauchement avec 10.0.0.0/8. Les sous-réseaux /23 (510 adresses utilisables) et /24 (254 adresses utilisables) offrent une capacité suffisante pour 500 VM et une évolution future. Un sous-réseau /27 dédié aux points de terminaison privés est une bonne pratique pour l'organisation. L'utilisation de Private Endpoints pour Azure Storage, associée à une zone DNS privée et la désactivation de l'accès public, garantit que le compte de stockage n'est jamais accessible via son point de terminaison public, conformément aux exigences de sécurité. Les autres options sont incorrectes car : Un VNet 172.16.0.0/24 est trop petit pour 500 VM. Les points de terminaison de service n'empêchent pas l'accès public au compte de stockage. Un VNet 10.250.0.0/16 chevauche l'espace réservé 10.0.0.0/8. Maintenir le point de terminaison public activé contredit l'exigence de sécurité. Placer les points de terminaison privés dans les sous-réseaux de production n'est pas une bonne pratique de conception. Un seul sous-réseau /16 ne permet pas une segmentation appropriée pour une application multiniveau. Les points de terminaison de service n'empêchent pas l'accès public.