La empresa desea centralizar la gestión de los VPC endpoints de interfaz y las zonas de Route 53 en una cuenta de servicios compartidos, utilizando un modelo hub-and-spoke de Transit Gateway entre cuentas. El equipo de servicios de red debe gestionar de forma centralizada todas las zonas de Route 53 y los endpoints de interfaz, y proporcionar acceso privado a AWS KMS sin que el tráfico pase por la internet pública. ¿Qué debe implementar el ingeniero para lograr esto?

La opción correcta centraliza la gestión de los endpoints de interfaz y las zonas de Route 53 en la cuenta de servicios compartidos, como se solicita. Al crear un endpoint de interfaz de KMS en la cuenta central y deshabilitar su DNS privado, se evita que AWS resuelva automáticamente el nombre de servicio. Luego, una zona alojada privada en la cuenta central con un registro de alias apunta al endpoint, permitiendo un control DNS centralizado. Asociar esta zona alojada privada con las VPC spoke en cada cuenta de AWS asegura que todas las VPC puedan resolver el nombre de KMS a través del endpoint central, manteniendo el tráfico privado y sin pasar por internet. Las opciones incorrectas no cumplen con la centralización. La segunda opción crea zonas alojadas privadas en cada cuenta spoke, lo que va en contra de la gestión centralizada. La tercera y cuarta opciones crean endpoints de interfaz en cada cuenta spoke, lo que también es inconsistente con el requisito de centralización.