Network Management and Operation — AWS Certified Advanced Networking ANS-C01 practice questions

Operations must maintain a Direct Connect BGP session's health, and notices the on-premises router's BGP hold-timer mismatch with AWS's default causing intermittent session flaps.

1. Switch from BGP to static routing to avoid the hold-timer issue entirely
2. Increase the DX connection's physical bandwidth to fix the timer mismatch
3. Align the BGP hold-timer (and keepalive interval) settings on the on-premises router to match or be compatible with AWS's configured values
4. Ignore hold-timer mismatches since BGP always auto-negotiates a working value with zero flapping

Answer: C — Align the BGP hold-timer (and keepalive interval) settings on the on-premises router to match or be compatible with AWS's configured values

BGP hold-timer/keepalive values are negotiated but must be operationally aligned to avoid flapping from mismatched expectations, so aligning the configuration is the direct fix; persistent misconfiguration or unstable timer settings on one side commonly causes real-world flapping that needs investigation, not blind trust that negotiation always resolves cleanly; abandoning BGP for static routing loses dynamic failover/route learning entirely, an overcorrection unrelated to the actual timer issue; bandwidth is unrelated to BGP session timer behavior.

Users report intermittent large file transfer failures over a VPN connection, while small requests succeed reliably.

1. Investigate MTU/fragmentation issues along the path (e.g., verify Path MTU Discovery isn't being blocked, consider reducing MSS/MTU on the tunnel interface)
2. This always indicates a security group misconfiguration
3. This is always caused by IAM permission issues
4. The VPN connection must be completely down

Answer: A — Investigate MTU/fragmentation issues along the path (e.g., verify Path MTU Discovery isn't being blocked, consider reducing MSS/MTU on the tunnel interface)

Symptoms where small requests work but larger transfers intermittently fail are a classic MTU/fragmentation signature, so investigating tunnel MTU/MSS settings is the correct troubleshooting direction; a security group issue would typically block traffic consistently regardless of size, not intermittently based on payload size; IAM governs API/console permissions, not raw network packet delivery; if the VPN were fully down, small requests would fail too, contradicting the symptom described.

Operations must reduce inter-AZ data transfer costs for a chatty microservices application without sacrificing multi-AZ availability.

1. Inter-AZ data transfer has no cost associated with it, so no optimization is needed
2. Disable cross-zone load balancing entirely with no other changes to reduce cost, regardless of the resulting traffic distribution imbalance
3. Prefer routing service-to-service calls to same-AZ instances where possible (e.g., AZ-aware load balancing/service discovery) while still maintaining instances in multiple AZs for failover
4. Consolidate all instances into a single AZ to eliminate inter-AZ charges entirely

Answer: C — Prefer routing service-to-service calls to same-AZ instances where possible (e.g., AZ-aware load balancing/service discovery) while still maintaining instances in multiple AZs for failover

AZ-aware routing/service discovery reduces unnecessary inter-AZ hops for the majority of chatty calls while still preserving genuine multi-AZ redundancy for failover; consolidating to a single AZ eliminates the transfer cost but also eliminates AZ-level fault tolerance, violating the availability requirement; inter-AZ data transfer DOES incur cost in AWS; simply disabling cross-zone load balancing without other traffic-distribution consideration can create uneven load and isn't a targeted fix by itself.

Operations needs to maintain public IP address management for VPC-hosted resources, minimizing manual IP tracking across dozens of VPCs and preventing accidental CIDR overlap on new VPCs.

1. Amazon VPC IP Address Manager (IPAM), managing pools and CIDR allocation centrally
2. A manually maintained spreadsheet of assigned CIDR blocks
3. Assigning CIDRs randomly and resolving overlaps only if they're discovered
4. Elastic IP allocation with no centralized pool management

Answer: A — Amazon VPC IP Address Manager (IPAM), managing pools and CIDR allocation centrally

IPAM is the AWS-managed service purpose-built to centrally plan, track, and prevent overlap of IP address pools across accounts/VPCs at scale; a manual spreadsheet doesn't scale and is error-prone across dozens of VPCs; assigning CIDRs randomly and fixing overlaps reactively risks real outages/routing conflicts when overlap is discovered late; Elastic IPs address individual public IP addresses, not the broader CIDR block planning problem IPAM solves.

A monitoring dashboard shows a Direct Connect connection's 'Connection State' as up, but the associated virtual interface (VIF) shows 'down.'

1. Immediately request AWS to physically replace the Direct Connect connection
2. The issue must be in the customer's LAN switches, unrelated to the DX configuration at all
3. Investigate the VIF-level configuration (VLAN ID, BGP peer IP, BGP ASN, or the BGP session itself) since the physical connection is healthy but the logical interface isn't establishing
4. This state combination is impossible; VIF state always matches connection state

Answer: C — Investigate the VIF-level configuration (VLAN ID, BGP peer IP, BGP ASN, or the BGP session itself) since the physical connection is healthy but the logical interface isn't establishing

Connection state reflects the physical layer, while VIF state reflects the logical BGP/VLAN configuration on top of it -- these CAN differ, and a healthy physical link with a down VIF specifically points to VIF-level configuration as the investigation target; claiming this combination is impossible contradicts the premise; requesting a physical replacement addresses the wrong layer; ruling out DX-side configuration entirely skips the most likely cause without evidence.

An application intermittently can't reach a specific EC2 instance. Operations wants to programmatically verify, hop-by-hop, whether the network path (security groups, NACLs, route tables) between a source and that instance actually allows the traffic, without generating live traffic.

1. A manual review of every security group and NACL in the VPC one by one
2. Restarting the EC2 instance to see if connectivity resumes
3. VPC Reachability Analyzer, tracing the theoretical path and identifying the specific blocking component
4. VPC Flow Logs review only, waiting for the next real connection attempt to be logged

Answer: C — VPC Reachability Analyzer, tracing the theoretical path and identifying the specific blocking component

Reachability Analyzer performs exactly this static, non-traffic-generating path analysis and pinpoints the specific blocking rule/component; Flow Logs only show what already happened and require waiting for/correlating a real connection attempt, which is reactive; manually reviewing every SG/NACL is slow and error-prone at scale; restarting the instance doesn't diagnose a network path/rule problem and may not resolve it if the root cause is a security group or route table misconfiguration.

During routine operations, a VPC's private subnet route table is found routing 0.0.0.0/0 directly to an Internet Gateway instead of a NAT Gateway.

1. Remove the 0.0.0.0/0 route entirely so the subnet has no internet access at all
2. Add a second 0.0.0.0/0 route to the NAT Gateway alongside the existing IGW route
3. Correct the route to point 0.0.0.0/0 at the NAT Gateway, keeping the subnet's resources without direct public IPs from being directly internet-routable
4. This is correct behavior for private subnets by design

Answer: C — Correct the route to point 0.0.0.0/0 at the NAT Gateway, keeping the subnet's resources without direct public IPs from being directly internet-routable

A private subnet should route outbound internet traffic via a NAT Gateway (in a public subnet) so its resources aren't directly internet-routable, so the fix is correcting the route target to the NAT Gateway; routing a 'private' subnet's default route directly to an IGW effectively makes any resource with a public IP directly internet-facing, which is NOT correct private-subnet design; removing the route entirely eliminates needed outbound internet access; a route table cannot have two entries for the identical 0.0.0.0/0 destination -- only one is valid.

An architecture with many small, short-lived Lambda functions in a VPC experiences ENI exhaustion warnings during traffic spikes.

1. The only fix is moving all Lambda functions out of the VPC entirely, losing VPC resource access
2. Add more NAT Gateways to fix ENI exhaustion
3. Increase the subnet size (more available IPs) and/or use Hyperplane ENIs (shared ENI model) which Lambda uses by default in modern configurations to reduce per-invocation ENI overhead
4. Lambda functions in a VPC never consume ENIs; this warning is unrelated to Lambda

Answer: C — Increase the subnet size (more available IPs) and/or use Hyperplane ENIs (shared ENI model) which Lambda uses by default in modern configurations to reduce per-invocation ENI overhead

VPC-connected Lambda functions do consume network capacity, and modern Lambda uses a shared Hyperplane ENI model that's more IP-efficient than the old per-function ENI model, while increasing subnet size directly increases available IP headroom; claiming Lambda never consumes VPC networking resources is factually wrong; removing VPC connectivity entirely sacrifices access to VPC-only resources; NAT Gateways handle outbound internet routing, not ENI/IP address exhaustion within a subnet.

Two VPCs in the same Region need private connectivity for a simple, low-complexity, cost-sensitive use case with only these two VPCs ever needing to talk to each other.

1. VPC peering -- simpler and typically more cost-effective than Transit Gateway for a small, static, point-to-point relationship
2. Transit Gateway is always the more cost-effective choice regardless of scale
3. PrivateLink is required for any VPC-to-VPC connectivity
4. Direct Connect between the two VPCs

Answer: A — VPC peering -- simpler and typically more cost-effective than Transit Gateway for a small, static, point-to-point relationship

For a small number of static VPC-to-VPC relationships, VPC peering avoids Transit Gateway's per-attachment and per-GB processing charges, making it typically more cost-effective at small scale; TGW becomes more cost-effective and operationally simpler at LARGER scale, not universally cheaper regardless of scale; PrivateLink is for exposing individual services, not a requirement for general VPC-to-VPC connectivity; Direct Connect connects on-premises networks to AWS, it's not used for VPC-to-VPC connectivity within AWS.

A troubleshooting session needs to determine the actual round-trip latency and hop count between an application server and its database across a Transit Gateway, without needing raw ICMP access which is blocked by security policy.

1. Use VPC Reachability Analyzer for path validation, plus TCP-based latency testing tools (since ICMP is blocked) at the application layer
2. ICMP-based traceroute is the only way to measure any network path; there's no alternative when ICMP is blocked
3. This can't be determined at all without direct console access to every hop's device
4. Rely solely on CloudTrail logs to infer latency

Answer: A — Use VPC Reachability Analyzer for path validation, plus TCP-based latency testing tools (since ICMP is blocked) at the application layer

Reachability Analyzer validates the theoretical path without needing live ICMP traffic, and TCP-based tools can measure real latency when ICMP is explicitly blocked by policy; claiming ICMP is the ONLY option ignores these viable alternatives; AWS-managed hops (TGW, etc.) aren't directly console-accessible per-hop, yet path/latency analysis is still achievable with the tools mentioned; CloudTrail records API management events, not network path latency data.

BGP hold-timer / keepalive mismatches?

Misaligned or unstable hold-timer/keepalive settings between AWS and an on-premises router are a common real-world cause of BGP session flapping -- align settings on both sides during troubleshooting.

VPC Traffic Mirroring?

Copies actual packet payload from a source ENI to a target (NLB/appliance/ENI) for deep packet inspection -- distinct from Flow Logs, which only capture metadata.

AWS Network Manager (Global Network)?

Visualizes Transit Gateway-centric network topology and health across Regions/accounts in one place; integrates with Reachability Analyzer for path validation.

MTU and Path MTU Discovery (PMTUD) over VPN/DX?

Mismatched MTU (e.g., jumbo frame support not consistent end-to-end) causes silent packet black-holing that manifests as TCP retransmissions or large-transfer failures, especially if ICMP fragmentation-needed messages are blocked.