Ein Transit Gateway in Konto A wird über AWS RAM freigegeben, sodass andere Konten VPCs in derselben Region verbinden können. Konto B verfügt über eine VPC (10.0.0.0/16) mit den Subnetzen 10.0.0.0/24 (us-west-2a) und 10.0.1.0/24 (us-west-2b). Zwei neue Subnetze wurden hinzugefügt: 10.0.2.0/24 (us-west-2b) und 10.0.3.0/24 (us-west-2c). Alle Subnetze verwenden dieselbe Routing-Tabelle; die Standardroute 0.0.0.0/0 zeigt auf das Transit Gateway. Ressourcen in 10.0.2.0/24 können andere VPCs erreichen, aber Ressourcen in 10.0.3.0/24 nicht. Was muss der Ingenieur tun, damit Ressourcen in 10.0.3.0/24 andere VPCs erreichen können?

Die Transit Gateway-VPC-Anbindung muss die Subnetze kennen, die sie bedienen soll. Wenn ein neues Subnetz (10.0.3.0/24 in us-west-2c) hinzugefügt wird, muss die vorhandene Transit Gateway-Anbindung in Konto B aktualisiert werden, um dieses neue Subnetz einzuschließen. Dies stellt sicher, dass der Datenverkehr von und zu diesem Subnetz über das Transit Gateway geleitet werden kann. Da 10.0.2.0/24 bereits funktioniert, ist es wahrscheinlich, dass es bereits Teil der Anbindung war oder in einem Subnetz liegt, das von der Anbindung abgedeckt wird. Die Option, Routen in der VPC-Routing-Tabelle hinzuzufügen, ist falsch, da die Standardroute 0.0.0.0/0 bereits auf das Transit Gateway zeigt, was für den ausgehenden Verkehr aus der VPC ausreichend ist. Das Hinzufügen statischer Routen im Transit Gateway-Routing-Tabelle in Konto A ist nicht die primäre Lösung, da das Problem darin besteht, dass das Subnetz 10.0.3.0/24 nicht mit dem Transit Gateway verbunden ist. Die Neuerstellung der Propagierung in Konto A ist ebenfalls nicht korrekt, da die Propagierung die Routen vom Transit Gateway zu den Anhängen betrifft, nicht die Verbindung der Subnetze zum Transit Gateway.