How to minimize administrative overhead for AWS Site-to-Site VPN route expansion?

A company has an AWS Site-to-Site VPN connection between AWS and its branch office. A network engineer is troubleshooting connectivity issues that the connection is experiencing. The VPN connection terminates at a transit gateway and is statically routed. In the transit gateway route table, there are several static route entries that target specific subnets at the branch office. The network engineer determines that the root cause of the issues was the expansion of underlying subnet ranges in the branch office during routine maintenance. Which solution will solve this problem with the LEAST administrative overhead for future expansion efforts?

Determine a supernet for the branch office. In the transit gateway route table, add an aggregate route that targets the VPN attachment. Replace the specific subnet routes in the transit gateway route table with the new supernet route.
Create an AWS Direct Connect gateway and a transit VIF. Associate the Direct Connect gateway with the transit gateway. Create a propagation for the Direct Connect attachment to the transit gateway route table.
Create a dynamically routed VPN connection on the transit gateway. Connect the dynamically routed VPN connection to the branch office. Create a propagation for the VPN attachment to the transit gateway route table. Remove the existing static VPN connection. Source Reference Answer
Create a prefix list that contains the new subnets and the old subnets for the branch office. Remove the specific subnet routes in the transit gateway route table. Create a prefix list reference in the transit gateway route table.

Community Votes

64%

18%

64% of anonymous learners picked answer C. Votes are pick records left by other test-takers — they are not the verified answer.

Community Insight

The question really tests choosing a self-maintaining routing mechanism (BGP propagation) over manual/static route management to eliminate future administrative overhead when on-prem networks expand.

This question tests how to handle expanding on-premises subnets behind a Transit Gateway-attached Site-to-Site VPN with minimal future operational effort. Community consensus favors replacing static routes with a dynamically routed (BGP) VPN so routes propagate automatically.

Candidates often pick A (supernet/aggregate route) or D (prefix list) because they reduce manual work short-term, but both still require manual updates when subnets grow beyond the defined range or list.

Community Discussion (11 comments)

Kupaloid 👍 9 Selected: C

Move from static to dynamic routing to remove administrative overhead

TechAwesome 👍 1 Selected: D

D is correct. A for sure is wrong. The on-premises could expand it's network with a different RFC1918 subnet. For C, you need to build another connection.

AzureDP900 👍 1 Selected: C

Here's why: Option C: This solution involves creating a dynamically routed VPN connection on the transit gateway and connecting it to the branch office. It then creates a propagation for the VPN attachment to the transit gateway route table. After that, it removes the existing static VPN connection.

woorkim 👍 1 Selected: C

A: Using a supernet (aggregate route) can work if the branch office subnets fit neatly within a single supernet. However, if future expansions include subnets outside the supernet, manual updates will still be required. This does not fully solve the problem of minimizing administrative overhead. B: While AWS Direct Connect offers high bandwidth and low latency, it is unnecessary for addressing the root cause (static route updates). It also involves additional costs and complexity. D: A prefix list simplifies management compared to individual static routes, but it still requires manual updates whenever new subnets are added or existing ones change. This does not eliminate administrative overhead as effectively as dynamic routing.

Spaurito 👍 2

C - Let dynamic routing do the work. Static routes are operational overhead.

6cae226 👍 1 Selected: A

The solution that provides the LEAST administrative overhead for future expansion efforts is Option A. By determining a supernet and using an aggregate route, you can significantly reduce the need for future updates to the Transit Gateway route table as the branch office network expands. This approach ensures that as long as the expansion stays within the defined supernet, no further route updates will be necessary.

rltk8029 👍 4

Why not C? Site-to-Site VPN config lets use BGP. As a traditional network engineer I'd always prefer dynamic routing.

973b658 👍 2 Selected: A

it is A.

JoellaLi 👍 2 Selected: D

You can reference a prefix list in your transit gateway route table. A prefix list is a set of one or more CIDR block entries that you define and manage. You can use a prefix list to simplify the management of the IP addresses that you reference in your resources to route network traffic. For example, if you frequently specify the same destination CIDRs across multiple transit gateway route tables, you can manage those CIDRs in a single prefix list, instead of repeatedly referencing the same CIDRs in each route table. If you need to remove a destination CIDR block, you can remove its entry from the prefix list instead of removing the route from every affected route table. When you create a prefix list reference in your transit gateway route table, each entry in the prefix list is represented as a route in your transit gateway route table.

Kayceetalks 👍 4

A - Correct

psou7 👍 1

I vote C

Comments & Corrections

No comments yet — spotted an error or have a note? Share it below.

Expert Analysis

The scenario describes a statically routed Site-to-Site VPN terminating at a Transit Gateway (TGW), with explicit static routes in the TGW route table pointing to the VPN attachment. The root cause of the outage is that the branch office expanded its subnet ranges, and those new prefixes were not reflected in the TGW route table.

The key requirement is LEAST administrative overhead for future expansion. Let's evaluate each option:

Why Option C is correct

Option C replaces the static VPN with a dynamically routed (BGP) Site-to-Site VPN attached to the Transit Gateway. With BGP:

The on-premises router advertises its prefixes (including any future expansions) to the AWS Customer Gateway over the VPN tunnel.
AWS automatically learns these routes and, because the VPN attachment is configured to propagate into the TGW route table, the routes appear dynamically — no manual TGW route edits required.
Future subnet expansions at the branch simply require the on-prem router to advertise the new prefixes; AWS handles the rest.

This is the textbook AWS best practice for minimizing operational overhead in hybrid connectivity, and it aligns with the majority community vote (65%).

Why Option A is tempting but wrong

Option A suggests using a supernet (aggregate route) such as 10.0.0.0/8. While this reduces the number of entries, it is still static. If the branch later expands into a different RFC 1918 block (e.g., from 10.x to 172.16.x), the supernet must be manually updated. As several commenters noted, this does not truly eliminate administrative overhead.

Why Option B is wrong

Option B proposes AWS Direct Connect with a transit VIF. Direct Connect is a physical dedicated connection — it is more expensive, requires additional provisioning, and does not solve the stated problem (the company already has a VPN). It also introduces more operational overhead, not less.

Why Option D is wrong

Option D uses a managed prefix list. While prefix lists simplify referencing groups of CIDRs across multiple resources, the list itself must still be manually updated every time the branch adds a new subnet. It is a management convenience, not an automation of route learning, so it does not meet the "least administrative overhead for future expansion" requirement.

Community insight

Top-voted comments reinforce the reasoning: "Move from static to dynamic routing to remove administrative overhead" and "Let dynamic routing do the work. Static routes are operational overhead." The minority votes for A and D reflect a common trap of confusing fewer static entries with no manual updates.

Official Reference

Exam Strategy

When an AWS networking question emphasizes 'least administrative overhead' for changing or growing networks, always prefer the dynamic/automated option (BGP, propagation, auto-association) over static configurations like supernetting or prefix lists, which still require manual updates.

Related Analysis

Practice All ANS-C01 Questions

Access 137 questions with complete answers and detailed explanations.

View Full ANS-C01 Practice Test →

← Back to ANS-C01 Study Guide