Vérification des connaissances - Réseau et connectivité
Évaluez 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 au moins 60 % pour réussir.
FinCorp conçoit un VDC à trois niveaux : un niveau web public, un niveau d'application privé et un niveau de données privé. L'équipe de sécurité souhaite que le niveau de données soit accessible uniquement depuis le niveau d'application, et suppose que le Load Balancer géré placé devant le niveau de données peut être restreint à l'aide d'une liste d'autorisation IP. Que doit leur dire l'architecte ?
Les pare-feu NIC et les Network Security Groups sont liés aux NIC des serveurs et au VDC, et non au ALB/NLB géré ou à l'abstraction du cluster Kubernetes. La posture correcte consiste à isoler le niveau de données par la topologie (LAN privé) et à filtrer sur les cibles elles-mêmes ; s'attendre à ce que le load balancer géré effectue un filtrage par source est une erreur de limite que la plateforme ne prend explicitement pas en charge.
Un pare-feu réseau auto-géré doit présenter une seule IP publique stable et basculer vers une instance en veille si l'instance active est perdue. L'équipe exécutera son propre logiciel de haute disponibilité à l'intérieur de l'appliance. Quelle construction IONOS CLOUD convient, et que doivent-ils en comprendre ?
Le basculement IP correspond exactement au modèle actif-passif auto-géré : il provisionne une IP publique réservée unique sur des NIC redondantes et laisse au logiciel de haute disponibilité de l'invité le soin de décider quand basculer, car la plateforme ne surveille pas l'état 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 destiné à la sortie sortante ; le basculement DNS dirige les noms, et non une IP partagée unique sur un LAN.
FinCorp doit connecter son centre de données sur site à un VDC via un lien chiffré de site à site pendant la migration. L'appareil sur site est actuellement configuré pour IKEv1 avec une routage dynamique basé sur BGP. Que l'architecte doit-il planifier sur le VPN Gateway d'IONOS CLOUD ?
Le VPN Gateway d'IONOS CLOUD prend en charge IKEv2 et WireGuard, mais pas IKEv1, et le routage est statique via les listes CIDR du réseau cloud et du réseau pair ; il n'y a pas de BGP. Le pair legacy doit être reconfiguré, et les sous-réseaux routés doivent être déclarés explicitement. NAT Gateway et DNAT sont sans rapport avec cette exigence.
Les serveurs d'application privés dans un VDC doivent télécharger des correctifs du système d'exploitation et accéder à une API SaaS externe, mais ils ne doivent jamais être accessibles depuis Internet et ne doivent pas posséder d'IP publique. L'architecte provisionne 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 est uniquement SNAT et ne transfère le trafic qu'une fois que les VM privées acheminent le trafic à destination d'Internet vers celle-ci ; la modification de routage (route par défaut vers la passerelle, ou routes par destination) est l'étape la plus souvent oubliée. Une règle DNAT n'existe pas sur ce produit, et l'attribution d'IP publiques irait à l'encontre de l'objectif d'accès sortant privé.
Un architecte a besoin d'un lien privé à faible latence pour échanger des données entre deux VDC appartenant à FinCorp. Les deux VDC se trouvent dans des régions différentes et, pour une isolation de la facturation, sont soumis à des contrats distincts. Quelle option est viable ?
Le Private Cross-Connect 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 inter-régions et inter-contrats l'exclut, si bien que l'architecte doit utiliser un modèle de connectivité différent. Le NAT Gateway assure une sortie internet sortante, et non une interconnexion privée entre VDC.
FinCorp a besoin d'une bascule automatique pour un service public lorsque le point d'accès de la région principale échoue, en redirigeant les clients vers un point d'accès de la région secondaire. Aucun produit de bascule géré n'est disponible. Comment l'architecte doit-il concevoir cette solution, et quel est le levier principal sur le temps de récupération ?
En l'absence de produit de bascule géré, le modèle natif est la bascule DNS orchestrée par le client : une vérification d'état externe (par exemple, provenant du plan de l'équilibreur de charge) pilote la redirection de l'enregistrement Cloud DNS vers un point d'accès sain, et le TTL de l'enregistrement détermine la rapidité avec laquelle les clients redirigés prennent en compte le changement, ce qui en fait le levier principal du RTO. Cloud DNS lui-même n'est pas conscient de l'état. Comme DNS ne dirige que les nouvelles connexions, la couche front-end doit être sans état. La bascule IP est limitée à une région et à un LAN, et les leviers NAT/équilibrage de charge ne traitent pas la bascule inter-régions des points d'accès.