Network Design: 5 ANS-C01 Questions with Full Explanations
Network Design is a recurring theme in the AWS Advanced Networking – Specialty (ANS-C01) exam. It carries about 30% of the exam score. The 5 questions below come with a full explanation of why each option is right or wrong.
AWS Advanced Networking – Specialty (ANS-C01) · Network Design · 5 questions with answers and explanations
🧭 What these questions look for
Network design scenarios combine DNS, Transit Gateway, Direct Connect, edge services and load balancing across many VPCs, accounts and Regions. You choose the topology or the sequence of steps that meets an isolation, scale or address-overlap requirement. Several options often look workable; the right one enforces the rule at the correct layer and uses the fewest moving parts.
Watch for these while you work
• For any multi-VPC question, check connection count, transitivity, service versus network level and overlapping CIDRs before reading the options closely.
• Remember what peering carries and what it does not: transit gateway peering moves traffic, but routes for the remote side must be added explicitly.
• When a requirement says two networks must never talk, look for separation in route tables rather than relying only on security groups or NACLs.
📊 About this set
Exam: ANS-C01 · 65 questions · 170 minutes · passing score 750 · the largest of 4 domains
This set: 5 advanced · 4 scenario, 1 troubleshooting · 1 with more than one answer
Topics: Amazon Route 53, Amazon VPC, AWS Transit Gateway, AWS Direct Connect, Direct Connect gateway
Question 1 of 5
Account A owns a Route 53 private hosted zone that needs to be resolvable from a VPC that lives in Account B. What two actions, in order, are required to associate Account B's VPC with Account A's private hosted zone? (Select TWO)
Show answer
✅ Answer: A, D
Difficulty: advanced · Topic: Amazon Route 53
Private hosted zones and VPC association
A private hosted zone answers only for VPCs associated with it. Associating a VPC in the same account is one step. When the zone and the VPC are in different accounts, both owners must take part, using the API, CLI or SDK:
• Step 1, zone owner (Account A): create a VPC association authorization (CreateVPCAssociationAuthorization) naming Account B's VPC ID and Region.
• Step 2, VPC owner (Account B): associate the VPC with the zone (AssociateVPCWithHostedZone) using Account A's hosted zone ID.
After the association exists, Account A can delete the authorization; the association stays.
Example
aws route53 create-vpc-association-authorization --hosted-zone-id Z123 --vpc VPCRegion=eu-west-1,VPCId=vpc-0b1 in Account A, then aws route53 associate-vpc-with-hosted-zone --hosted-zone-id Z123 --vpc ... in Account B.
Why each option works or fails
• ✓ A. Account B associates the VPC (correct): the VPC owner performs the actual association, referencing Account A's hosted zone ID. It succeeds only after the authorization exists.
• ✗ B. Recreate the zone as shared: hosted zones are not recreated as shared resources for this; the authorization and association work with the existing zone.
• ✗ C. Share the VPC with RAM: the process needs no RAM share of the VPC; the authorization in Account A is the only cross-account permission required.
• ✓ D. Account A creates the authorization (correct): the zone owner first authorizes that specific VPC, which is the permission step that allows another account's VPC to be associated.
• ✗ E. NACL entry on the hosted zone: network ACLs belong to subnets, not hosted zones, and a hosted zone has no CIDR allow-list.
🎯 Key idea: Cross-account private hosted zone access: the zone owner authorizes the VPC, then the VPC owner associates it.
Question 2 of 5
After several acquisitions, 12 VPCs attached to a transit gateway all use 10.0.0.0/16 for their workloads. Workloads in each VPC must open connections to hundreds of hosts on a routable on-premises network reached over Direct Connect, and re-addressing the workloads is not possible this year. Which design allows this traffic?
Show answer
✅ Answer: B
Difficulty: advanced · Topic: Amazon VPC, AWS Transit Gateway, AWS Direct Connect
Why overlapping VPCs cannot route to shared networks
When 12 VPCs all use 10.0.0.0/16, an on-premises host replying to 10.0.4.7 has no idea which VPC that address belongs to, and the transit gateway route table can point 10.0.0.0/16 to only one attachment.
Private NAT gateway pattern
A private NAT gateway performs source NAT to its own private IP, without internet access.
1. Add a secondary CIDR that is unique across the company to each VPC, for example 100.64.1.0/28 for VPC 1 and 100.64.2.0/28 for VPC 2.
2. Create a routable subnet in that range and place a private NAT gateway there.
3. Route the on-premises prefixes from the workload subnets to the NAT gateway, and from the routable subnet to the transit gateway.
On-premises now sees each VPC as its own unique range, so replies return correctly, while workloads keep their overlapping addresses.
Why each option works or fails
• ✗ A. Separate route tables: separate tables stop the VPCs from reaching each other, but return traffic from on-premises still arrives for one 10.0.0.0/16 destination that can map to only one attachment.
• ✓ B. Routable secondary CIDR with a private NAT gateway (correct): each VPC translates outbound connections to a unique routable address, so the transit gateway and on-premises routers can return traffic to the right VPC without re-IP.
• ✗ C. Appliance mode: it keeps flows pinned to one AZ for stateful appliances in an inspection VPC; it does nothing about identical source addresses from different VPCs.
• ✗ D. PrivateLink endpoint services: PrivateLink lets consumers connect in to a service; here the workloads initiate connections out to hundreds of on-premises hosts, which PrivateLink does not provide.
🎯 Key idea: Overlapping VPCs that must initiate traffic to a shared network → translate through a private NAT gateway in a unique routable CIDR.
Question 3 of 5
A company must ensure that a set of VPCs handling PCI-regulated workloads can never establish direct network connectivity to a set of general-purpose VPCs, even though both sets are attached to the same Transit Gateway and occasionally need to reach a shared services VPC. How should Transit Gateway route tables be designed?
Show answer
✅ Answer: C
Difficulty: advanced · Topic: AWS Transit Gateway
Segmentation with transit gateway route tables
Each attachment is associated with exactly one TGW route table, which decides where its traffic can go. Attachments can propagate their CIDRs into any number of route tables.
A common isolation design:
• PCI route table: associated with PCI VPC attachments; contains only the shared services routes.
• General route table: associated with general VPC attachments; contains only the shared services routes.
• Shared services route table: associated with the shared services attachment; contains routes to both PCI and general VPCs so it can reply.
Because the PCI table has no route to general VPCs (and the reverse), the transit gateway drops that traffic regardless of security group mistakes.
Example: PCI VPC 10.10.0.0/16 and general VPC 10.20.0.0/16 both reach shared services 10.0.0.0/16, but neither table has the other's CIDR.
Why each option works or fails
• ✗ A. Disable propagation, use NACLs only: turning off propagation does not segment anything by itself, and NACLs are per-subnet rules that are easy to miss across many VPCs, so a gap would allow direct connectivity.
• ✗ B. Separate TGW and copied rules: a second transit gateway adds cost and complexity for shared services, and manually copying security group rules is error-prone; the question asks for a route table design, which handles this on one gateway.
• ✓ C. Separate route tables with shared services in both (correct): routing itself makes PCI and general VPCs unreachable from each other while both can still reach shared services.
• ✗ D. One route table plus security groups: with one route table every VPC can route to every other; security groups are per-instance allow lists, so one wrong rule creates the forbidden path.
🎯 Key idea: Enforce "never" at the routing layer: separate TGW route tables with only shared-services routes in common, not security groups or NACLs alone.
Question 4 of 5
Two Transit Gateways in us-east-1 and eu-west-1 are connected by an inter-Region peering attachment. VPC routes propagate correctly within each Region, but VPCs cannot reach VPCs in the other Region. What is the MOST likely missing configuration?
Show answer
✅ Answer: A
Difficulty: advanced · Topic: AWS Transit Gateway
Route propagation versus peering attachments
A transit gateway route table can learn routes in two ways:
• Propagation: VPC, VPN (BGP) and Direct Connect gateway attachments can automatically install their CIDRs into a route table.
• Static routes: you add a route such as 10.20.0.0/16 pointing to a specific attachment yourself.
Inter-Region peering
Two transit gateways in different Regions can be linked with a peering attachment. Traffic between them rides the AWS global network and is encrypted. But a peering attachment does not exchange routes: neither transit gateway learns the other side's VPC CIDRs automatically.
Example: the us-east-1 route table needs a static route 10.128.0.0/12 to the peering attachment, and the eu-west-1 route table needs a static route 10.0.0.0/12 back. Without both, traffic has no route in at least one direction. The VPC route tables must also send those remote CIDRs to the transit gateway.
Why each option works or fails
• ✓ A. Static routes via the peering attachment (correct): transit gateway peering does not support route propagation or BGP, so each side's route table needs static routes for the remote Region's CIDRs pointing to the peering attachment.
• ✗ B. Jumbo frames: MTU affects whether large packets fit, not whether a route exists. Here nothing reaches the other Region at all, which is a routing gap, not a packet-size issue.
• ✗ C. Enable BGP on the peering: there is no BGP session on a transit gateway peering attachment and no setting to turn one on. Dynamic routing between Regions requires a different design, such as AWS Cloud WAN.
• ✗ D. Direct Connect gateway on both: a Direct Connect gateway connects on-premises networks over Direct Connect to transit gateways. It does not route traffic between two transit gateways, and the peering attachment already provides the inter-Region path.
🎯 Key idea: Transit gateway peering carries traffic but not routes: add static routes for the remote CIDRs to the peering attachment on both sides.
Question 5 of 5
A company has one Direct Connect connection in Frankfurt and 80 VPCs attached to Transit Gateways in eu-central-1 and eu-west-1. It wants on-premises access to all VPCs over this connection with the fewest virtual interfaces. Which design fits BEST?
Show answer
✅ Answer: C
Difficulty: advanced · Topic: AWS Direct Connect, Direct Connect gateway, AWS Transit Gateway
The three Direct Connect virtual interface types
• Private VIF: reaches one virtual private gateway (one VPC) or a Direct Connect gateway associated with virtual private gateways.
• Public VIF: reaches AWS public endpoints (public IPs), not private VPC addresses.
• Transit VIF: attaches to a Direct Connect gateway that is associated with one or more transit gateways.
Scaling to many VPCs
A Direct Connect gateway is a global object, so a single transit VIF on the Frankfurt connection can reach transit gateways in eu-central-1 and eu-west-1 at the same time. Each transit gateway already has the VPCs attached, so on-premises routes flow to all 80 VPCs through:
• on-premises router -> transit VIF -> Direct Connect gateway -> transit gateway -> VPC attachments.
You control which VPC prefixes are advertised to on premises with the "allowed prefixes" list on each Direct Connect gateway association, often summarized to a few aggregates.
Why each option works or fails
• ✗ A. One private VIF per VPC: 80 VIFs means 80 BGP sessions to build and operate, and a dedicated connection supports only a limited number of private VIFs, so this is the opposite of "fewest VIFs".
• ✗ B. Peering from a hub VPC: VPC peering is not transitive, so on-premises traffic arriving at the hub VPC through a private VIF cannot continue across peering connections to the other VPCs.
• ✓ C. (correct): One transit VIF to a Direct Connect gateway associated with both transit gateways: one VIF on the single connection reaches every VPC attached to either transit gateway, in both Regions, with no per-VPC configuration on the Direct Connect side.
• ✗ D. Public VIF with VPN tunnels: this needs a separate VPN connection per VPC or per gateway, IPsec throughput limits apply, and it adds far more configuration than a single transit VIF.
🎯 Key idea: Many VPCs behind transit gateways over Direct Connect -> one transit VIF to a Direct Connect gateway associated with the transit gateways, not one VIF per VPC.
🔗 Keep practicing on this blog
• All ANS-C01 practice sets
• Every exam on this blog
📚 Keep studying ANS-C01
More ANS-C01 questions: https://hyunhp.github.io/cert-bank/#exam=ANS-C01
Study guide: https://hyunhp.github.io/cert-bank/study.html#exam=ANS-C01
These are original practice questions, not real exam questions, and cert-bank is not affiliated with any certification vendor.
Original practice questions written for this blog, not exam dumps.
Comments
Post a Comment