Home › Certifications › AWS Certified Advanced Networking ANS-C01 › Network Design
45 multiple-choice questions and 19 flashcards on Network Design, about 30% of the AWS Certified Advanced Networking ANS-C01 bank. Every one carries a written rationale.
Network Design is one of 4 chapters in CoStudy's AWS Certified Advanced Networking — Specialty (ANS-C01) bank, and it holds 45 of the bank's 150 multiple-choice questions — roughly 30% of the total. That proportion is not arbitrary: chapters follow the certifying body's published exam outline, and the number of questions in each is set by that domain's published weight, so the share of your practice time this chapter takes matches the share of the real exam it accounts for.
Studying by chapter is worth doing once you have a diagnostic score. A single overall percentage tells you whether you are close; it does not tell you which domain is dragging. Working a weak chapter in isolation, and re-testing it in isolation, is the fastest way to move a score that has stalled — and it is why the mock exams in CoStudy report by domain rather than as one number.
10 questions drawn from this chapter, with the full rationale shown — the controlling principle behind the right answer, and why each wrong option tempts and fails.
A design must ensure that a load balancer's health checks fail over quickly (within seconds) when a target's application process -- not just its network stack -- becomes unresponsive.
Answer: A — An HTTP/HTTPS health check on ALB hitting an application-level health endpoint
An HTTP health check that hits an actual application endpoint detects application-level failures (e.g., a hung process still holding the TCP port open), which a pure TCP or ICMP check would miss; TCP-only checks only confirm the port accepts connections, not that the app logic is healthy; disabling health checks removes automatic failover entirely; ICMP checks test basic network reachability, not application health, and NLB/ALB health checks don't operate over raw ICMP by default.
A design needs a load balancer that can be referenced by a private, cross-account consumer via AWS PrivateLink without exposing the service to the public internet.
Answer: B — An NLB fronting the service, exposed as a VPC endpoint service for PrivateLink consumers
PrivateLink endpoint services are built on an NLB (or GWLB for appliance use cases) as the entry point that consumers reach privately via an interface VPC endpoint; a public Route 53 record exposes the ALB to the internet, the opposite of the requirement; GWLB endpoints are used for the appliance-insertion pattern, not for exposing a general application service as an endpoint service; CloudFront signed URLs control access to cached content over the public internet, not private cross-account network access.
A design needs content-based routing decisions using HTTP headers, cookies, and query strings, along with native WAF and Cognito authentication integration.
Answer: D — Application Load Balancer (ALB)
ALB is the Layer 7 load balancer supporting host/path/header-based routing plus native WAF and Cognito/OIDC authentication; NLB operates at Layer 4 and can't inspect HTTP content; GWLB is designed for inserting third-party virtual appliances transparently, not content-based app routing; CLB lacks these modern Layer 7 features.
Field offices worldwide need the lowest-latency entry point into the AWS network backbone before traffic reaches an application running in a single Region.
Answer: D — AWS Global Accelerator's edge locations onboarding traffic onto the AWS global network
Global Accelerator's anycast edge locations get user traffic onto AWS's backbone quickly regardless of the application's home Region; multi-Region app deployment solves a different problem (redundancy/latency at the compute layer, at much higher cost/complexity) and isn't the edge-onboarding answer; CloudFront doesn't proxy arbitrary non-HTTP TCP; one shared Direct Connect location doesn't help geographically distributed users reach the network faster.
Routing design must prevent a specific VPC from being reachable via Transit Gateway from certain other attached VPCs, while still allowing it to reach a shared services VPC.
Answer: D — TGW route tables with selective association/propagation, isolating that VPC's routes to only the shared services route table
Transit Gateway route tables let you scope which attachments propagate routes into which table, enabling selective reachability (segmentation) while still allowing access to a specific shared VPC; a single shared route table gives every attachment the same reachability, breaking the isolation requirement; disabling the attachment removes ALL reachability, including to shared services; full-mesh VPC peering doesn't scale for the number of relationships in a segmented multi-VPC design and doesn't provide TGW's centralized route-table control.
A design must let a SaaS provider expose an API to thousands of customer VPCs across separate AWS accounts, without peering with each customer's VPC or exposing the service publicly.
Answer: B — PrivateLink: publish an NLB-backed endpoint service that customers connect to via interface VPC endpoints
PrivateLink/endpoint services are specifically designed for this one-to-many private-service-exposure pattern at scale without peering or public exposure; peering with thousands of accounts is operationally unmanageable and exposes broader network reachability than needed; a public endpoint with IP allowlisting still traverses the public internet and is harder to keep current as customers change IPs; sharing a Transit Gateway with every customer grants far broader network reachability than exposing a single service, a security over-exposure.
On-premises DNS servers must resolve names hosted in a Route 53 private hosted zone over an existing Direct Connect connection.
Answer: D — Route 53 Resolver inbound endpoints in the VPC, referenced by on-prem DNS forwarders
Inbound Resolver endpoints expose VPC/private-hosted-zone resolution to on-premises resolvers that forward queries to those endpoint IPs; a public hosted zone doesn't hold private-only records the way a private hosted zone can, and isn't the mechanism for on-prem lookups of private zones; outbound endpoints go the opposite direction (VPC resolving on-prem/other domains); a self-managed BIND server duplicates Route 53's managed capability and adds operational burden unnecessarily.
A multi-account organization wants every VPC across 50 accounts to automatically use the same set of Resolver forwarding rules for a shared on-premises domain, without manually associating rules account by account.
Answer: B — AWS Resource Access Manager (RAM) sharing the Resolver rule to the AWS Organization, with rule association automated
RAM lets a Resolver rule be shared org-wide, and combined with automation (e.g., a Lambda triggered by new-account events) it can auto-associate to every VPC; manual copying doesn't scale to 50 accounts; a rule with no sharing mechanism stays confined to its owning account; hosted zone replication scripts solve a different problem (zone records, not Resolver forwarding rules) and add unnecessary custom tooling.
A design requires per-country access restrictions on a public website's content delivery, blocking specific countries entirely at the edge.
Answer: C — CloudFront geo-restriction (geo-blocking) on the distribution
CloudFront has built-in geo-restriction that allowlists/blocklists countries at the edge before requests reach the origin; security groups filter by IP/CIDR, not country; Route 53 geolocation routing directs DNS answers by region but doesn't block HTTP requests at the edge; NACLs also filter by IP/CIDR, not country codes, and maintaining GeoIP CIDR lists manually doesn't scale.
A network architecture spanning 40 VPCs across multiple Regions needs a single visual topology map showing all Transit Gateway attachments and their health.
Answer: A — AWS Network Manager (Global Network) topology view
Network Manager's Global Network feature specifically visualizes Transit Gateway-centric topology across Regions/accounts, including attachment health; reviewing Flow Logs per VPC manually doesn't provide topology visualization at all; Logs Insights queries return log data, not a topology diagram; Config aggregators track resource configuration compliance, not a visual network topology map.
4 cards from the 19 in this chapter.
VPC sharing -- who owns what?
The owning account keeps control of the VPC/subnet infrastructure; participant accounts deploy most resource types (EC2, RDS, etc.) directly into shared subnets using their own IAM permissions.
Centralized egress/inspection VPC pattern?
Spoke VPCs route 0.0.0.0/0 via Transit Gateway to a shared inspection VPC holding the only Internet Gateway/NAT path and a Network Firewall; enforced technically via SCPs blocking spoke-account IGW creation.
IPv6 in a VPC -- dual-stack vs IPv6-only subnets?
Dual-stack subnets support both IPv4 and IPv6 addressing on resources. IPv6-only subnets support IPv6-only resources (with NAT64/DNS64 for reaching IPv4-only services), useful when IPv4 address space is exhausted.
ALB vs NLB vs GWLB -- OSI layer and use case?
ALB: Layer 7, HTTP(S) content-based routing, WAF/Cognito integration. NLB: Layer 4, ultra-low latency/high throughput, static IP, preserves source IP. GWLB: transparent third-party appliance insertion via GENEVE encapsulation.
These are a sample. The full Network Design chapter runs 64 items with per-chapter progress tracking, on the web and in the iOS app.
Open AWS Certified Advanced Networking ANS-C01 in CoStudy →
All AWS Certified Advanced Networking ANS-C01 practice questions →