L'entreprise souhaite centraliser la gestion des points d'accès d'interface VPC et des zones Route 53 dans un compte de services partagés, tout en utilisant un modèle Transit Gateway hub-and-spoke à travers les comptes. L'équipe des services réseau doit gérer de manière centralisée toutes les zones Route 53 et les points d'accès d'interface, et fournir un accès privé à AWS KMS sans que le trafic ne passe par l'internet public. Que doit implémenter l'ingénieur pour y parvenir ?

L'option correcte permet une gestion centralisée et un accès privé. En créant un point d'accès d'interface KMS dans le compte de services partagés et en désactivant le DNS privé, on s'assure que le trafic KMS utilise le point d'accès. La zone hébergée privée centralisée dans le compte de services partagés, avec un enregistrement d'alias pointant vers ce point d'accès, permet de résoudre le nom de domaine KMS vers le point d'accès privé. L'association de cette zone hébergée privée aux VPC spoke garantit que tous les comptes peuvent résoudre KMS via le point d'accès centralisé. Les options incorrectes échouent pour diverses raisons : La deuxième option crée des zones hébergées privées dans chaque compte spoke, ce qui va à l'encontre de l'objectif de gestion centralisée. La troisième option crée des points d'accès d'interface dans chaque compte spoke, ce qui n'est pas centralisé et augmente la complexité. La quatrième option crée des points d'accès dans chaque compte spoke et tente de les gérer via une zone hébergée privée centralisée, ce qui est inefficace et ne correspond pas à l'architecture souhaitée.