Une passerelle de transit (transit gateway) dans le Compte A est partagée à l'aide d'AWS RAM afin que d'autres comptes puissent connecter des VPC dans la même Région. Le Compte B possède un VPC (10.0.0.0/16) avec les sous-réseaux 10.0.0.0/24 (us-west-2a) et 10.0.1.0/24 (us-west-2b). Deux nouveaux sous-réseaux ont été ajoutés : 10.0.2.0/24 (us-west-2b) et 10.0.3.0/24 (us-west-2c). Tous les sous-réseaux utilisent la même table de routage ; la route par défaut 0.0.0.0/0 pointe vers la passerelle de transit. Les ressources dans 10.0.2.0/24 peuvent atteindre d'autres VPC, mais les ressources dans 10.0.3.0/24 ne le peuvent pas. Que doit faire l'ingénieur pour que les ressources dans 10.0.3.0/24 puissent atteindre d'autres VPC ?

La bonne réponse est de mettre à jour l'attachement de la passerelle de transit dans le Compte B. Un attachement de passerelle de transit est spécifique à une Zone de Disponibilité (AZ). Si un VPC s'étend sur plusieurs AZ et que de nouveaux sous-réseaux sont ajoutés dans une AZ qui n'est pas encore associée à l'attachement de la passerelle de transit, les ressources de ces nouveaux sous-réseaux ne pourront pas acheminer le trafic via la passerelle de transit. En ajoutant l'ID de sous-réseau de us-west-2c à l'attachement existant, on s'assure que le trafic de cette AZ peut utiliser la passerelle de transit. Les autres options sont incorrectes car : L'ajout de destinations dans la table de routage du VPC est déjà fait, car la route par défaut 0.0.0.0/0 pointe vers la passerelle de transit pour tous les sous-réseaux. L'ajout d'une route statique dans la table de routage de la passerelle de transit dans le Compte A n'est pas nécessaire, car la propagation de la route du VPC (10.0.0.0/16) est déjà configurée. Le problème est l'accessibilité de l'AZ, pas le routage au niveau de la passerelle de transit. La recréation de la propagation dans le Compte A n'est pas nécessaire, car la propagation de 10.0.0.0/16 est déjà en place et couvre le CIDR du VPC. Le problème est l'attachement au niveau de l'AZ.