ANS-C01 · Question #210
A company has a transit gateway in AWS Account A. The company uses AWS Resource Access Manager (AWS RAM) to share the transit gateway so that users in other accounts can connect to multiple VPCs in…
The correct answer is B. In Account B, update the transit gateway attachment. Attach the new subnet ID that is associated. When resources in a newly created subnet in a previously unattached Availability Zone cannot communicate via a Transit Gateway, the TGW attachment in that VPC must be updated to include a subnet from the new Availability Zone.
Question
A company has a transit gateway in AWS Account A. The company uses AWS Resource Access Manager (AWS RAM) to share the transit gateway so that users in other accounts can connect to multiple VPCs in the same AWS Region. AWS Account B contains a VPC (10.0.0.0/16) with subnet 10.0.0.0/24 in the us-west-2a Availability Zone and subnet 10.0.1.0/24 in the us-west-2b Availability Zone. Resources in these subnets can communicate with other VPCs. A network engineer creates two new subnets: 10.0.2.0/24 in the us-west-2b Availability Zone and 10.0.3.0/24 in the us-west-2c Availability Zone. All the subnets share one route table. The default route 0.0.0.0/0 is pointing to the transit gateway. Resources in subnet 10.0.2.0/24 can communicate with other VPCs, but resources in subnet 10.0.3.0/24 cannot communicate with other VPCs. What should the network engineer do so that resources in subnet 10.0.3.0/24 can communicate with other VPCs?
Options
- AIn Account B, add 10.0.2.0/24 and 10.0.3.0/24 as the destinations to the route table. Use the
- BIn Account B, update the transit gateway attachment. Attach the new subnet ID that is associated
- CIn Account A, create a static route for 10.0.3.0/24 in the transit gateway route tables.
- DIn Account A, recreate propagation for 10.0.0.0/16 in the transit gateway route tables.
How the community answered
(37 responses)- A14% (5)
- B78% (29)
- C3% (1)
- D5% (2)
Why each option
When resources in a newly created subnet in a previously unattached Availability Zone cannot communicate via a Transit Gateway, the TGW attachment in that VPC must be updated to include a subnet from the new Availability Zone.
The default route 0.0.0.0/0 already points to the Transit Gateway in the VPC's route table, so adding specific subnet destinations will not resolve the underlying issue of the Transit Gateway not having a network interface in us-west-2c.
Transit Gateway attachments must have a network interface in each Availability Zone where resources need to communicate through the TGW. Since subnet 10.0.3.0/24 is in us-west-2c, an Availability Zone not previously covered by the working subnets, updating the VPC attachment in Account B to include a subnet ID from us-west-2c will provision the necessary TGW network interface, allowing communication.
Creating a static route for 10.0.3.0/24 in the Transit Gateway route tables (in Account A) defines how the TGW *forwards* traffic *outbound* to that CIDR, but it doesn't solve the problem of traffic from 10.0.3.0/24 failing to reach the TGW *inbound* from us-west-2c.
Recreating route propagation for 10.0.0.0/16 in the Transit Gateway route tables (in Account A) will not resolve the issue, as the TGW already learns the VPC's CIDRs; the problem is with the TGW's physical presence in the specific Availability Zone.
Concept tested: Transit Gateway VPC attachment and Availability Zone configuration
Source: https://docs.aws.amazon.com/vpc/latest/tgw/tgw-vpc-attachments.html
Community Discussion
No community discussion yet for this question.