Vérification des connaissances - Réseau et connectivité
Testez votre compréhension des concepts clés du Module 3. Sélectionnez la meilleure réponse pour chaque question, puis soumettez pour voir vos résultats. Vous devez obtenir un score d'au moins 60 % pour réussir.
FinCorp conçoit un centre de données virtuel à trois niveaux : un niveau web public, un niveau d'application privé et un niveau de données privé. L'équipe de sécurité veut que le niveau de données soit accessible uniquement à partir du niveau d'application, et suppose que le Managed Network Load Balancer devant le niveau de données peut être verrouillé avec une liste d'autorisation IP. Que devrait dire l'architecte à ce sujet ?
Les pare-feu de carte réseau et les Network Security Groups sont liés aux cartes réseau des serveurs et au centre de données virtuel, et non à l'équilibreur de charge géré ALB/NLB ou au niveau d'abstraction Kubernetes Cluster. La bonne posture consiste à isoler le niveau de données par la topologie (LAN privé) et à filtrer sur les cibles elles-mêmes ; s'attendre à ce que l'équilibreur de charge géré Load Balancer effectue un filtrage de source est l'erreur de limite que la plateforme ne prend explicitement pas en charge.
Un appareil pare-feu réseau autonome doit présenter une seule adresse publique IP stable et basculer vers une instance de secours si l'instance active est perdue. L'équipe exécutera son propre logiciel HA à l'intérieur de l'appareil. Quel constructeur IONOS convient, et que doivent-ils comprendre à ce sujet ?
Le basculement IP est exactement le modèle actif-passif autonome : il met en place une adresse publique réservée IP à travers des cartes réseau redondantes et laisse le logiciel HA de l'invité décider quand basculer, car la plateforme ne surveille pas la santé du service. Un Load Balancer géré ne peut pas partager un LAN avec le basculement IP et est destiné aux couches élastiques ; le NAT Gateway est pour la sortie ; le basculement DNS dirige les noms, et non une seule adresse publique partagée IP sur un LAN.
FinCorp doit connecter son centre de données local à un centre de données virtuel sur un lien de site à site chiffré pendant la migration. L'appareil local est actuellement configuré pour IKEv1 avec un routage dynamique basé sur BGP. Que doit planifier l'architecte sur l'IONOS VPN Gateway ?
L'IONOS VPN Gateway prend en charge IKEv2 et WireGuard mais pas IKEv1, et le routage est statique via les listes cloud-network et peer-network CIDR ; il n'y a pas de BGP. Le pair hérité doit être reconfiguré, et les sous-réseaux routés doivent être déclarés explicitement. La passerelle NAT et DNAT ne sont pas liés à cette exigence.
Les serveurs d'applications privés dans un centre de données virtuel doivent télécharger des correctifs de système d'exploitation et accéder à un SaaS API externe, mais ne doivent jamais être accessibles depuis internet et ne doivent pas contenir de IP publics. L'architecte met en place une passerelle NAT avec une IP publique réservée et une règle SNAT, mais les serveurs ne peuvent toujours pas accéder à internet. Quelle est la cause la plus probable ?
Une passerelle NAT n'est que SNAT et transmet le trafic uniquement une fois que les machines virtuelles privées acheminent le trafic destiné à internet vers celle-ci ; le changement de routage (route par défaut vers la passerelle, ou routes par cible) est l'étape la plus souvent oubliée. Une règle DNAT n'existe pas sur ce produit, et l'attribution d'adresses IP publiques contredirait l'objectif de sortie privée.
Un architecte a besoin d'un lien privé à faible latence pour échanger des données entre deux centres de données virtuels (VDC) appartenant à FinCorp. Les deux VDC sont situés dans différentes régions et, pour une isolation de facturation, sont soumis à des contrats différents. Quelle option est viable ?
Le Cross-Connect privé est catégoriquement limité aux VDC situés dans la même région et soumis au même contrat, partageant une seule plage IP ; il ne peut pas s'étendre sur plusieurs régions ou contrats. L'exigence de cross-région, cross-contrat l'exclut, donc l'architecte doit utiliser un modèle de connectivité différent. La passerelle NAT fournit une sortie internet, et non une interconnexion privée VDC-à-VDC.
FinCorp a besoin d'un basculement automatique pour un service public lorsque le point de terminaison de la région principale échoue, en redirigeant les clients vers un point de terminaison de la région secondaire. Il n'y a pas de produit de basculement géré. Comment l'architecte devrait-il concevoir cela, et quel est le levier dominant sur le temps de récupération ?
Sans produit de basculement géré, le modèle natif est le basculement DNS orchestré par le client : une vérification de santé externe (par exemple à partir du plan de charge équilibrée) détermine la réorientation de l'enregistrement Cloud DNS vers un point de terminaison sain, et le TTL de l'enregistrement détermine combien rapidement les clients redirigés prennent en compte le changement, en faisant de celui-ci le levier RTO dominant. Cloud DNS lui-même n'est pas conscient de la santé. Puisque DNS ne dirige que les nouvelles connexions, le niveau frontal doit être sans état. Le basculement IP est lié à une région et à un LAN, et les leviers NAT/charge équilibrée n'abordent pas le basculement du point de terminaison inter-région.