AWS Networking Specialty common mistakes
AWS Networking Specialty · Understand the traps and how to avoid them.
When a scenario asks for private connectivity between VPCs across accounts or Regions, the candidate immediately selects a transit gateway or VPC peering without first checking whether the requirement is really about transitive routing, bandwidth, or cost, and then justifies the choice with a single generic sentence.
Transit Gateway, peering, and PrivateLink are all taught as 'private connectivity' options, so under time pressure the candidate pattern-matches on the phrase rather than on the topology constraints. Peering is non-transitive and does not scale to many VPCs; a transit gateway adds hourly and per-GB attachment costs; PrivateLink only exposes a specific service endpoint and does not provide full VPC-to-VPC routing.
What to do instead
Before choosing, write down three facts from the stem: number of VPCs and accounts, whether traffic must be transitive (spoke-to-spoke), and whether the target is a whole network or a single service. Non-transitive two-VPC connectivity points to peering; many VPCs with shared routing points to a transit gateway; a single service consumed by many consumers points to PrivateLink. Then state the trade-off you are accepting (cost, non-transitivity, endpoint-only scope) in the justification.
The candidate designs a hybrid architecture and picks a specific option (for example a Site-to-Site VPN, Direct Connect, or Transit Gateway Connect) without reconciling the stated bandwidth, latency, SLA, or encryption requirements against that option's actual characteristics, and without addressing redundancy.
Hybrid connectivity questions combine several variables at once, and candidates latch onto the option that sounds most 'enterprise' (usually Direct Connect) even when the stem specifies rapid deployment, encryption over the public internet, or a low budget. They also forget that a single Direct Connect connection or a single VPN tunnel is not highly available.
What to do instead
Build a small requirement table from the stem: required bandwidth, encryption mandate, acceptable deployment lead time, and availability target. Map each candidate against it. Use VPN when encryption and fast setup matter; use Direct Connect when consistent bandwidth and latency matter; combine them (VPN over Direct Connect, or a backup VPN) when both are required. Always name the redundant path explicitly, since 'highly available' in the stem is a signal to describe two independent connections or tunnels.
The candidate treats a route table entry as sufficient for traffic to flow, and does not verify that security groups, network ACLs, subnet associations, and return routes all permit the traffic.
Routing is the most visible part of networking, so candidates stop at 'add the route'. In AWS, a route to a transit gateway or peering connection still fails if the target subnet's route table lacks a return path, if a security group does not reference the peer security group, or if a network ACL blocks ephemeral ports. Peering in particular requires routes in both VPCs and does not support edge-to-edge routing through a transit gateway unless the attachment is configured for it.
What to do instead
Adopt a checklist for any connectivity scenario: forward route, return route in the destination subnet's route table, security group inbound and outbound (remember stateful behavior), network ACL inbound and outbound including ephemeral port range, and subnet association of the correct route table. When the question involves peering plus a transit gateway, explicitly confirm whether the peering attachment is on the transit gateway and whether the route tables on both sides reference it.
The candidate assumes that enabling a feature such as VPC flow logs, Reachability Analyzer, or Network Access Analyzer is the same as configuring it correctly, and does not distinguish what each tool can and cannot prove.
The monitoring and analysis services overlap in description but answer different questions. Flow logs record metadata about accepted and rejected IP traffic at the ENI, subnet, or VPC level but do not capture packet contents or prove application reachability. Reachability Analyzer performs static configuration analysis between a source and destination and does not send packets. Network Access Analyzer evaluates resource configurations against scope criteria. Candidates conflate 'I can see traffic' with 'I can prove the path works'.
What to do instead
Memorize the one-line purpose of each tool and the question it answers. For 'why is traffic being dropped at the network layer', use flow logs with a rejected-traffic filter. For 'will this configuration allow the path', use Reachability Analyzer. For 'does my network meet an intended access policy', use Network Access Analyzer. When a stem asks for packet-level inspection or deep content analysis, recognize that native flow logs are insufficient and that a traffic mirroring or third-party inspection solution is needed.
The candidate answers a DNS or name resolution question by choosing Route 53 without specifying the hosted zone type, record type, routing policy, or resolver path, and ignores the interaction between private hosted zones and VPC association.
Route 53 appears in many domains, and candidates treat it as a single product. In practice the answer depends on whether the zone is public or private, whether the VPC has enableDnsHostnames and enableDnsSupport set, whether the query comes from on-premises through a Resolver inbound endpoint, and which routing policy (failover, weighted, latency, geolocation, multivalue) matches the stated goal.
What to do instead
For every DNS scenario, state four things: zone type (public or private), the VPC association and DNS attributes required, the record type and routing policy that implements the stated behavior, and the resolver path for hybrid queries (inbound endpoint for on-premises to AWS, outbound endpoint plus forwarding rules for AWS to on-premises). If the stem mentions failover, name the health check and the failover record pair explicitly.
The candidate designs security controls only at the security group level and does not layer subnet-level controls, centralized inspection, or egress control, so the design fails when the stem requires inspection of traffic between VPCs or outbound traffic filtering.
Security groups are the most familiar control, so candidates stop there. Many scenarios require traffic to be steered through a central inspection VPC using a transit gateway with appliance mode or a gateway load balancer endpoint, and require egress restrictions that security groups alone cannot express (for example FQDN-based filtering). Candidates also forget that security groups are stateful while network ACLs are stateless, which changes which rules are needed.
What to do instead
When a stem mentions inspection, centralized policy, or egress control, describe the steering path: source subnet route table to the inspection attachment, inspection VPC route tables returning traffic to the source, and the inspection appliance or gateway load balancer in the middle. Note that transit gateway appliance mode preserves flow symmetry for stateful appliances. For egress filtering by domain, name a managed firewall or proxy capability rather than a security group. State the stateful versus stateless distinction when justifying ACL rules.
The candidate ignores the shared responsibility boundary and assumes that enabling an AWS security or encryption feature automatically satisfies a compliance control, without identifying what the customer must still configure or document.
Compliance questions often describe a control objective (encryption in transit, logging retention, segmentation) and expect the candidate to separate the AWS-provided capability from the customer's configuration obligation. Candidates either over-attribute controls to AWS or assume compliance is inherited once a service is used, and they neglect evidence and auditability requirements such as log retention and centralized logging.
What to do instead
For each control in the stem, write two lines: what AWS provides (for example, the ability to encrypt traffic with TLS or IPsec) and what the customer must do (enable it, enforce it, retain logs for the required period, and produce evidence). Then name the specific configuration that produces the evidence, such as organization-level log archival or a centralized logging account. If the stem asks about an audit, describe how the configuration is demonstrated, not just that it exists.
The candidate manages multi-account networking by configuring each VPC individually and does not use centralized constructs such as shared VPCs, transit gateway sharing through Resource Access Manager, or organization-level policy enforcement.
The exam frequently frames scenarios at the organization level, and candidates default to per-account manual configuration because that is how they learned VPCs. This produces answers that do not scale, duplicate route tables, and cannot enforce consistent policy. Candidates also miss that sharing a transit gateway or subnet through Resource Access Manager changes who owns and who can use the resource.
What to do instead
When the stem mentions many accounts, a central network team, or consistent policy, prefer centralized patterns: a networking account that owns the transit gateway and shares it through Resource Access Manager, shared subnets for workload accounts, and service control policies or declarative policies to prevent noncompliant configurations. Be explicit about ownership versus usage rights, and about where route tables and attachments are managed.
The candidate misreads the question's operative constraint, answering the 'most cost-effective' or 'least operational overhead' variant with the most capable or most manual solution, or vice versa.
AWS questions frequently embed a qualifier that changes the correct answer, and candidates skim the stem and answer the generic version of the question. A design that is technically correct is still wrong if the stem asked for the lowest operational overhead and the answer requires managing appliances, or if it asked for the lowest cost and the answer adds per-GB transit charges.
What to do instead
Before evaluating options, underline the qualifier in the stem (cost, latency, operational overhead, security, deployment speed) and eliminate any option that does not optimize for it, even if it is technically valid. When two options both work, use the qualifier as the tiebreaker and state the trade-off explicitly in the justification.
The candidate selects a load balancer type or target configuration without matching the OSI layer, protocol, and client-IP preservation requirements to the correct load balancer, and does not account for cross-zone or target health behavior.
Application, Network, and Gateway Load Balancers look interchangeable in summaries, but they differ in supported protocols, whether they preserve source IP, whether security groups apply, and what traffic they can inspect. Candidates also forget that health check configuration and cross-zone load balancing change observed behavior, and that a target must be in a subnet with a route back to the client.
What to do instead
Map the requirement to a load balancer in one step: HTTP or HTTPS with host and path routing points to Application Load Balancer; TCP, UDP, or extreme performance with source IP preservation points to Network Load Balancer; inline inspection of third-party appliances points to Gateway Load Balancer. Then verify the supporting details the stem implies: security group placement, health check protocol and path, cross-zone setting, and return routing from the target subnet.