Week 2 Synthesis & Networking Lab Exam
Week 2 Recap
Week 2 built a single argument in seven pieces: that connectivity in a multi-account estate is a routing problem before it is a bandwidth problem. Day 8 established Transit Gateway as the regional hub that replaces an unmanageable full mesh of VPC peering, with each attachment associated to one TGW route table and propagating routes into others — the mechanism that makes segmentation possible at all. Day 9 then showed the same service behaving differently across regions: TGW peering runs over the AWS backbone, but peering attachments do not propagate routes, so every path must be added statically, and inter-region MTU is capped at 1500 bytes. Day 10 turned the hub into an inspection point, routing spoke egress through a centralized inspection VPC running Network Firewall with Suricata-compatible rules.
Days 11 through 13 moved outward from the AWS-only topology. Direct Connect introduced Private, Transit, and Public VIFs, and the point that resilience requires redundant connections at separate locations with BGP failover rather than a single link. Route 53 Resolver closed the DNS half of the hybrid story with inbound endpoints for on-prem queries into private hosted zones and outbound endpoints plus forwarding rules for the reverse direction. PrivateLink then offered the deliberate contrast: service-level exposure through an ENI-backed interface endpoint, with no peering, no route table changes, and no CIDR conflict. The week's real deliverable is the decision boundary between those four tools, which is what the rest of this page drills.
Foundations You'll Need Today
Today's page is a synthesis day, which means it assumes the vocabulary of the previous six days is already in place and moves quickly across four different connectivity tools. Before the decision matrix makes sense, it is worth being explicit about the handful of building blocks that every one of those tools is assembled from. None of this is exotic — it is the same small set of ideas reused in different combinations — but the rest of the page will use these terms without stopping to define them.
VPCs, CIDR ranges, and why overlap matters
A Virtual Private Cloud is a private, isolated network inside AWS that you define yourself. When you create one, you pick an address range for it written in CIDR notation — something like 10.0.0.0/16 — which is simply a compact way of saying "this network owns every IP address from 10.0.0.0 through 10.0.255.255." The number after the slash tells you how large the range is: a smaller number means a bigger network. Inside that range you carve out subnets, which are smaller slices tied to a specific data center location, and resources like servers get their IP addresses from those subnets.
The reason this matters today is that connecting two networks together only works cleanly if their address ranges do not overlap. If two VPCs both claim 10.0.0.0/16, a router cannot tell which network a packet addressed to 10.0.0.5 is actually meant for, so route-based connectivity between them is impossible by definition. That single constraint is what makes PrivateLink the answer in several of today's scenarios: it sidesteps the problem entirely by not joining the two networks at all.
Route tables: how traffic knows where to go
A route table is a list of rules that tells a network where to send traffic. Each rule says, in effect, "traffic destined for this range of addresses should be handed to this target." Every subnet in a VPC is associated with a route table, and if there is no matching rule for a destination, the traffic is simply dropped. This is the mechanism behind almost everything on this page: when a VPC is attached to a Transit Gateway, the attachment is associated with a TGW route table, and whether two VPCs can reach each other depends entirely on which routes exist in that table and which attachments have been allowed to contribute their routes to it.
The distinction worth holding onto is between association and propagation. Association decides which route table an attachment uses when it sends traffic out. Propagation decides whether that attachment's own network ranges get added into the table so that other attachments can send traffic back. They are independent settings, and a great many real-world "why can't these two VPCs talk" problems come down to one being configured and the other not.
Security groups: the per-resource firewall
A security group is a set of allow rules attached to a resource — an EC2 instance, a load balancer, or in the case of PrivateLink, the network interface that represents an endpoint. It is stateful, meaning that if you allow a connection in one direction, the reply is automatically allowed back, and it is default-deny, meaning anything you have not explicitly permitted is blocked. Security groups operate at the level of the individual resource rather than the network, which is why they show up in today's discussion of Resolver endpoints: a forwarding rule can be perfectly correct and still fail because the endpoint's security group does not permit DNS traffic to reach it.
BGP: how two networks agree on a path
BGP is the routing protocol that networks use to tell each other which destinations they can reach. When you connect your own data center to AWS over Direct Connect, the two sides exchange BGP advertisements, and each side learns the other's address ranges automatically. More importantly for today, BGP is what makes failover automatic: if you have two connections and one goes down, the routes it was advertising are withdrawn, and traffic shifts to the surviving path without anyone changing a configuration by hand. When this page talks about "BGP failover" or "path preference," that is the machinery being described — the two sides continuously renegotiating which link carries traffic.
DNS resolution and forwarding
DNS is the system that translates human-readable names into IP addresses. Normally a computer asks a DNS server, and that server either knows the answer or asks another server on its behalf. In a hybrid environment, the complication is that some names live only inside AWS and some live only in your own data center, so each side needs a way to ask the other. That is what "forwarding" means: configuring a DNS server to say "for names ending in this domain, do not try to resolve them yourself — pass the question along to this specific other server." Today's section on hybrid DNS is entirely about which direction those questions travel and which AWS component handles each direction.
With that grounding, here is how those pieces combine into the four connectivity tools this week was built around, and how to tell which one a given scenario is actually asking for.
The Connectivity Decision Matrix
Almost every networking scenario on this exam reduces to one question asked in different clothing: what is the smallest connectivity primitive that satisfies the requirement? Candidates reach for Transit Gateway because it is the most capable answer, but capability is not free — a TGW attachment implies route table design, propagation decisions, and a shared routing domain that every connected VPC now participates in. PrivateLink, by contrast, creates no shared routing domain at all; the consumer VPC gets an elastic network interface with a private IP, and the only traffic that can flow is traffic to the service behind that endpoint. The exam rewards the architect who can articulate why the narrower primitive is correct, not the one who reaches for the hub by default.
The second question is whether the requirement is network-level or service-level. Network-level means the consumer needs to reach many things in the provider's network, or needs bidirectional reachability, or needs to be reachable itself. Service-level means the consumer needs exactly one API, one endpoint, one port. That distinction is what separates TGW from PrivateLink in practice, and it is also what makes PrivateLink the only viable answer when CIDR ranges overlap, because overlapping ranges make route-based connectivity impossible by definition. The table below is the compressed form of that reasoning; the subsections that follow unpack each row.
| Requirement | Best fit | Why the others fail |
|---|---|---|
| Many VPCs need broad mutual or shared-services reachability | Transit Gateway | Peering is O(n²) and PrivateLink exposes only one service |
| Two VPCs, same region, few routes, no hub wanted | VPC peering | TGW adds cost and route table management for no benefit |
| Expose one service to many consumer accounts | PrivateLink | TGW shares the whole network, not one endpoint |
| Consumer and provider CIDRs overlap | PrivateLink | Peering and TGW both require non-overlapping ranges |
| On-prem to many VPCs over one private link | DX with a Transit VIF | Private VIF reaches one VPC; Public VIF is for public endpoints |
| On-prem to a single VPC, minimal scope | DX with a Private VIF | A Transit VIF pulls in TGW route tables unnecessarily |
| On-prem resolvers must resolve AWS private zones | Resolver inbound endpoint | Outbound endpoints resolve the opposite direction |
| AWS resources must resolve on-prem names | Resolver outbound endpoint + forwarding rule | Inbound endpoints do not forward queries outward |
TGW vs. Peering vs. PrivateLink
The three AWS-native options differ in what they share. VPC peering shares a route between exactly two VPCs and nothing else — no transitive routing, no shared route tables, no third party. Transit Gateway shares a routing domain: every attached VPC can, subject to route table design, reach every other attached VPC, and the hub becomes the place where policy lives. PrivateLink shares neither routes nor a routing domain; it shares a single service endpoint, and the consumer's only knowledge of the provider is an ENI with a private IP in its own subnets. Once you frame the three that way, the scaling behavior falls out immediately. Peering grows as the square of the VPC count, TGW grows linearly but concentrates risk and cost in one regional resource, and PrivateLink grows linearly per service with no coupling between consumers at all.
The exam's favorite trap is a scenario that mentions many accounts and a single shared service, which reads like a TGW question but is actually a PrivateLink question. The tell is the word "service" or a specific API, port, or endpoint. A second trap runs the other way: a scenario describes overlapping CIDRs and a need for broad connectivity, which is unsatisfiable — the correct answer is usually to re-address one side, or to accept PrivateLink's narrower scope. A third trap involves transitive reachability through peering, which does not exist; if VPC A peers with B and B peers with C, A cannot reach C, and the fix is a TGW rather than more peering.
| Dimension | VPC peering | Transit Gateway | PrivateLink |
|---|---|---|---|
| What is shared | One route between two VPCs | A routing domain across attachments | One service endpoint (ENI) |
| Transitive routing | No | Yes, by route table design | Not applicable |
| CIDR overlap tolerated | No | No | Yes |
| Cross-region | Yes (inter-region peering) | Yes, via TGW peering with static routes | Yes, via endpoint services in the provider region |
| On-prem integration | Not directly | Yes, via Transit VIF or VPN | No |
| Primary cost driver | Data transfer | Attachment-hours plus data processing | Endpoint-hours plus data processing |
| Blast radius of a mistake | One pair of VPCs | Every VPC on the affected route table | One consumer's access to one service |
Direct Connect Resiliency Patterns
Direct Connect questions are almost never about the VIF types; they are about what happens when a link, a device, or an entire location fails. The exam expects you to know that a single connection is a single point of failure regardless of its bandwidth, and that the AWS resiliency model is expressed in terms of diversity: separate connections, terminating on separate devices, at separate DX locations. Two connections at the same location can share a device and therefore share a failure domain, which is why the highest-resiliency answer almost always names two locations. BGP is the mechanism that makes the failover automatic — path preference via AS PATH prepending or local preference determines which link carries traffic while both are healthy, and withdrawal of routes handles the failure case.
The second layer is what happens when both DX paths are unavailable. A VPN backup over the internet is the standard answer for that residual case, and it is worth being precise about why: it is not there to carry production load, it is there to keep control-plane and management access alive while the DX paths are restored. The exam also tests the VIF choice as a scope decision rather than a resiliency decision. A Private VIF terminates on a virtual private gateway and reaches exactly one VPC, which is the right scope for a single-VPC hybrid workload. A Transit VIF terminates on a Transit Gateway and inherits whatever reachability the TGW route tables provide, which is the right scope when on-prem needs to reach many VPCs. A Public VIF is for AWS public service endpoints and does not participate in VPC routing at all.
| Design | Survives | Does not survive |
|---|---|---|
| Single DX connection | Nothing meaningful | Device failure, location failure, fiber cut |
| Two connections, same location | Single connection failure | Shared device or location failure |
| Two connections, two locations | Device and location failure | Simultaneous multi-location event |
| Two locations plus VPN backup | All of the above, with degraded capacity | Nothing short of a full regional event |
Hybrid DNS Resolution Paths
Hybrid DNS is where most candidates lose points, because the two endpoint types are named from the perspective of the AWS VPC rather than the query. A Resolver inbound endpoint accepts queries from outside AWS and answers them from the VPC's private hosted zones — it is the door on-prem resolvers knock on. A Resolver outbound endpoint sends queries from AWS to a destination you specify, and it only does anything when paired with a forwarding rule that matches a domain and names the target resolver IPs. The direction naming is the whole trap: inbound means queries coming in, outbound means queries going out, and a scenario that describes on-prem servers resolving an AWS private zone is an inbound question no matter how it is phrased.
The transport underneath matters too. Resolver endpoints are reachable from on-prem only if there is a network path — Direct Connect or VPN — and the endpoint's ENIs live in subnets you choose, which means the on-prem resolver IPs must be routable to those subnets and the security groups on the endpoint must permit DNS. A common production failure is a correctly configured forwarding rule with no working path, which presents as intermittent resolution timeouts rather than clean failures. The second common failure is a forwarding rule that matches too broadly and captures queries that should have been answered locally, which presents as slow resolution for names that never needed to leave the VPC.
| Direction | Endpoint | Supporting config | Typical scenario phrasing |
|---|---|---|---|
| On-prem to AWS | Inbound endpoint | On-prem conditional forwarder pointing at endpoint IPs | "On-prem servers must resolve names in a private hosted zone" |
| AWS to on-prem | Outbound endpoint | Forwarding rule naming on-prem resolver IPs | "EC2 instances must resolve corp.internal" |
| AWS to AWS, cross-VPC | None required | Private hosted zone associated to the VPCs | "Two VPCs must share a private zone" |
Hands-on Lab / Practical Action (45 min)
Build the smallest topology that exercises all four decision boundaries at once, then break it deliberately. Start with three VPCs in one region: a shared-services VPC, a production VPC, and a development VPC, each with non-overlapping CIDRs. Attach all three to a single Transit Gateway, then create two TGW route tables — one for production and one for development — and associate each spoke with its own table. Propagate only the shared-services attachment into both tables, and propagate nothing between production and development. Verify from an instance in production that shared services is reachable and development is not, and confirm the reverse from development. This is the segmentation pattern from Day 8, and the point of rebuilding it is to feel how much of the isolation lives in route table association rather than in security groups.
Next, add the service-level path. Deploy a simple listener behind a Network Load Balancer in the shared-services VPC, create an endpoint service for it, and consume it from the development VPC through an interface endpoint. Confirm that development can reach the service on its port while still having no route to the shared-services VPC's other subnets — that contrast is the entire TGW-versus-PrivateLink argument in one test. Then add the hybrid DNS half: create a Resolver outbound endpoint in the shared-services VPC, add a forwarding rule for a fake domain such as corp.internal pointing at a resolver you control, and confirm queries leave the VPC. Create an inbound endpoint and confirm a query from outside the VPC resolves a record in a private hosted zone. Finally, write down for each of the four paths you built which single configuration change would break it, and what the symptom would look like in each case. That list is the runbook shape the exam expects you to reason about.
Mixed Scenario Quiz (25 questions)
Q1. A company has 40 VPCs across three accounts that all need to reach a shared-services VPC, but production VPCs must never reach development VPCs. What is the most operationally sustainable design?
Q2. Two VPCs in the same region need to exchange traffic on a small number of routes, and the team wants the lowest possible cost and no shared routing domain. What should they use?
Q3. A SaaS provider must expose a single HTTPS API to 200 customer VPCs, and several customers have CIDR ranges that overlap the provider's. What is the correct approach?
Q4. After creating a Transit Gateway peering attachment between us-east-1 and eu-west-1, spoke VPCs in each region still cannot reach each other. What is the most likely cause?
Q5. A workload transfers large files between two regions through peered Transit Gateways and is seeing throughput well below expectations with no packet loss. What should be checked first?
Q6. An organization wants all internet-bound traffic from 30 spoke VPCs inspected by a single firewall with a consistent rule set. What is the standard pattern?
Q7. A Network Firewall rule set must inspect TLS traffic for a specific set of domains without decrypting all traffic. Which capability applies?
Q8. A company needs a mission-critical hybrid connection with the highest practical resiliency. What should be provisioned?
Q9. On-premises needs to reach workloads in 25 VPCs over a single Direct Connect connection. Which VIF type is appropriate?
Q10. A single-VPC hybrid workload needs the simplest possible Direct Connect termination with no shared routing domain. Which VIF should be used?
Q11. Two Direct Connect connections are active at the same location and both fail simultaneously during a device maintenance event. What design flaw does this reveal?
Q12. On-premises DNS servers must resolve records in an AWS private hosted zone. What must be configured?
Q13. EC2 instances in a VPC must resolve names in an on-premises domain over Direct Connect. What is required?
Q14. A forwarding rule is correctly configured but on-prem name resolution from AWS fails intermittently. What is the most likely cause?
Q15. Two VPCs in the same account need to share a private hosted zone so that each resolves the same internal names. What is required?
Q16. A consumer VPC needs to reach exactly one API in a provider VPC, and the provider does not want the consumer to see any other subnet. What should be used?
Q17. Which statement about S3 and DynamoDB access from a VPC is correct?
Q18. A team wants to expose an internal service to consumers in other accounts without any consumer being able to initiate connections to the provider's other resources. Which property of PrivateLink makes this true?
Q19. VPC A is peered with VPC B, and VPC B is peered with VPC C. Instances in A cannot reach instances in C. What is the correct explanation?
Q20. A central network account owns a VPC and wants application accounts to launch resources into its subnets without owning the VPC. What enables this?
Q21. A Transit Gateway route table has the shared-services attachment associated but not propagated. What is the effect?
Q22. A company wants to reduce the number of Direct Connect connections while increasing aggregate throughput beyond a single connection's capacity. What should they use?
Q23. An inspection VPC uses Network Firewall, and after a route change, spoke VPCs can reach the internet but traffic is no longer inspected. What is the most likely cause?
Q24. Which combination best describes a mature hybrid connectivity baseline for a multi-account enterprise?
Q25. A scenario states that two companies with overlapping CIDRs need full bidirectional network-level reachability between their VPCs. What is the correct architectural response?
Looking Ahead
Everything this week assumed a network that already exists and a workload that already runs somewhere. The open question the week leaves unresolved is what happens when the compute itself is the thing being designed — when there is no VPC to attach, no instance to place, and no host to patch. Day 15 moves into Phase 2 with Amazon ECS on Fargate, where the unit of deployment is a task definition rather than an instance, and where the networking model changes in a way that matters: awsvpc mode gives every task its own elastic network interface and its own security group, so the per-workload isolation this week achieved through route tables and endpoint policies becomes a property of the task itself.
That shift has a direct consequence for the connectivity decisions just reviewed. When each task carries its own ENI, the security group becomes the primary segmentation primitive at the workload layer, and the question of which subnets a task can be placed in becomes a placement decision rather than a routing one. The hybrid paths built this week still carry the traffic, but the thing generating it is now ephemeral and independently addressed. The next day's material is where the governance and networking scaffolding from Phase 1 stops being the subject and starts being the substrate.
Sources
- AWS Transit Gateway — official documentation
- AWS Direct Connect — official documentation
- Route 53 Resolver — official documentation
- AWS PrivateLink — official documentation
- AWS Network Firewall — official documentation
- Building a Scalable and Secure Multi-VPC AWS Network Infrastructure — AWS whitepaper