Un transit gateway en la Cuenta A se comparte mediante AWS RAM para que otras cuentas puedan conectar VPCs en la misma Región. La Cuenta B tiene una VPC (10.0.0.0/16) con subredes 10.0.0.0/24 (us-west-2a) y 10.0.1.0/24 (us-west-2b). Se agregaron dos nuevas subredes: 10.0.2.0/24 (us-west-2b) y 10.0.3.0/24 (us-west-2c). Todas las subredes usan la misma tabla de ruteo; la ruta predeterminada 0.0.0.0/0 apunta al transit gateway. Los recursos en 10.0.2.0/24 pueden alcanzar otras VPCs, pero los recursos en 10.0.3.0/24 no. ¿Qué debe hacer el ingeniero para que los recursos en 10.0.3.0/24 puedan alcanzar otras VPCs?

La opción correcta es actualizar la conexión del Transit Gateway en la Cuenta B, adjuntando el ID de subred para la subred us-west-2c. Cuando se adjunta una VPC a un Transit Gateway, se deben especificar las subredes de al menos una Zona de Disponibilidad (AZ) que el Transit Gateway utilizará para el tráfico. Si una nueva subred se encuentra en una AZ que no está configurada en el adjunto del Transit Gateway, el tráfico de esa subred no podrá alcanzar el Transit Gateway. Al agregar la subred de us-west-2c al adjunto, se habilita la conectividad. Las otras opciones son incorrectas porque: Agregar 10.0.2.0/24 y 10.0.3.0/24 como destinos en la tabla de ruteo de la VPC no es necesario; la ruta predeterminada 0.0.0.0/0 ya apunta al Transit Gateway, lo que debería ser suficiente si la conectividad subyacente estuviera bien configurada. Agregar una ruta estática en las tablas de ruteo del Transit Gateway en la Cuenta A no resolverá el problema si el tráfico de la subred 10.0.3.0/24 no puede llegar al Transit Gateway en primer lugar. Recrear la propagación para 10.0.0.0/16 en las tablas de ruteo del Transit Gateway en la Cuenta A tampoco resolverá el problema de conectividad a nivel de AZ.