ANS-C01 Flashcards — Free AWS Certified Advanced Networking Specialty ANS-C01 Study Cards

Flow logs must be created specifically for the NAT gateway's elastic network interface to capture its traffic.

VPC Flow Logs capture traffic at the elastic network interface (ENI) level. A centralized NAT gateway has its own ENI in the public subnet, and traffic from private instances is routed through that ENI when it reaches the internet. To log that traffic, flow logs must be created specifically for the NAT gateway's ENI, not just at the VPC level, because VPC-level flow logs capture traffic for ENIs within that VPC but do not inherently capture traffic passing through the NAT gateway's ENI unless that ENI is explicitly targeted.

Create a TGW route table with a blackhole route for 0.0.0.0/0 and associate it with application VPC attachments; attach the inspection VPC to a different TGW route table that has a route to the internet via an egress VPC.

Option D is correct because it uses separate Transit Gateway route tables to enforce traffic isolation: the application VPC attachments use a route table with a blackhole for 0.0.0.0/0, preventing direct internet access, while the inspection VPC uses a different route table with a route to an egress VPC that has an internet gateway. This ensures all outbound traffic from application VPCs must first traverse the inspection VPC for security monitoring before reaching the internet.

Use a Direct Connect gateway and associate it with the VPCs.

A Direct Connect gateway allows a single Direct Connect connection to connect to multiple VPCs in the same or different AWS Regions, minimizing latency by using a private, dedicated network path and reducing cost by eliminating the need for separate virtual interfaces or VPN tunnels per VPC. It also maximizes bandwidth utilization by aggregating traffic from multiple VPCs over the same Direct Connect link.

Deploy a Network Load Balancer (NLB) in each region with targets in public subnets. Use Route 53 latency-based routing to the NLB.

Option A is correct because Network Load Balancer (NLB) preserves the client source IP by default, meeting the requirement for source IP preservation. Targets can be placed in public subnets, and traffic between the NLB and targets remains within the VPC, satisfying the condition that traffic stays within AWS. With an internet-facing NLB, Route 53 latency-based routing can be used to distribute traffic to the closest healthy NLB across regions. Options B, C, D, and E are incorrect: B incorrectly relies on an internal ALB with PrivateLink, which does not support Route 53 latency routing and does not preserve source IP; C and E use ALB, which does not preserve source IP; D uses Global Accelerator, which does not use Route 53 and does not preserve source IP when ALB is an endpoint.

The route table for the public subnet does not have a default route (0.0.0.0/0) pointing to an internet gateway

The most likely cause is that the route table for the public subnet (where the NAT gateway resides) does not have a default route (0.0.0.0/0) pointing to an internet gateway. The NAT gateway needs this route to forward traffic from private instances to the internet. Option A is incorrect because security groups for NAT gateways do not block inbound traffic from private instances; they only control traffic to the NAT gateway itself. Option B is incorrect because bandwidth provisioning is not related to connectivity; the NAT gateway can handle traffic up to its bandwidth limit. Option C is incorrect because NAT gateways do not require IAM roles to access the internet; they use Elastic IPs.

Create a Transit Gateway with separate route tables for each VPC and a shared route table for the inspection VPC. Use Gateway Load Balancer to distribute traffic to a fleet of firewall instances.

Option B is correct because it combines AWS Transit Gateway with separate route tables per VPC and a shared inspection route table, enabling centralized traffic steering to a fleet of firewall instances behind a Gateway Load Balancer (GWLB). GWLB transparently distributes traffic across multiple firewall instances at the network layer (GENEVE protocol), providing both horizontal scalability and high availability without introducing a single point of failure or requiring complex VPC peering meshes.

Use a private VIF and establish an IPsec VPN tunnel over the Direct Connect connection.

Option B is correct because AWS Direct Connect does not natively encrypt traffic; it provides a private, dedicated network connection. To meet the encryption requirement, you can establish an IPsec VPN tunnel over the private VIF, which encrypts all traffic between the on-premises network and the VPC. This approach combines the low latency and reliability of Direct Connect with the security of IPsec encryption.

Attach all VPCs to a Transit Gateway. Create separate route tables: one for inspection VPC attachments and one for others. In VPC A's route table, route to VPC B via the inspection VPC attachment.

Option A is correct because it uses separate Transit Gateway route tables to isolate the inspection VPC and other VPCs. By configuring the route table for VPC A to point to VPC B's CIDR via the inspection VPC attachment, all inter-VPC traffic is forced through the centralized firewall appliances. This leverages Transit Gateway's ability to route traffic between attachments based on route table associations and propagations, ensuring traffic flows through the inspection VPC without requiring VPC peering or additional per-VPC firewalls.

The ALB security group is not set as the source for inbound traffic; instead, traffic reaches the ALB directly from the internet.

Option A is correct because the ALB security group is configured to allow inbound traffic from the Client VPN CIDR range, but if the ALB itself is internet-facing (i.e., it has public IP addresses and is deployed in public subnets), traffic can bypass the security group rules if the security group is not actually applied to the ALB's network interfaces. The most likely cause is that the ALB security group is not set as the source for inbound traffic; instead, traffic reaches the ALB directly from the internet, meaning the security group rules are not being enforced on the ALB's listener. This allows users outside the VPN to access the application because the ALB accepts traffic from any source unless the security group explicitly restricts it.

Enable jumbo frames on the transit VPC's EC2-based virtual appliances.

The issue is intermittent connectivity between an on-premises office in ap-southeast-1 and a spoke VPC in eu-west-1, traversing a transit VPC in us-east-1. The VPN is up, so the problem is likely packet fragmentation or MTU mismatch across the long-haul path. Enabling jumbo frames on the transit VPC's EC2-based virtual appliances (e.g., firewall or router instances) increases the maximum transmission unit, reducing fragmentation and improving performance for large packets, which is a common cause of intermittent issues in hub-and-spoke topologies.

Create VPC peering connections between each pair of VPCs.

Option C is correct because VPC peering connections provide direct, private IP connectivity between VPCs using the AWS global network, with no bandwidth bottlenecks or single points of failure. It is the most cost-effective solution for a small number of VPCs (e.g., fewer than 10) as there are no hourly charges for the peering connection itself—only data transfer costs. This minimizes operational overhead compared to managing VPN tunnels or a Transit Gateway, as peering is a simple, one-to-one relationship that does not require additional appliances or complex routing policies.

Deploy an AWS Global Accelerator with endpoints in both Regions and use the accelerator's static IP addresses for communication.

AWS Global Accelerator uses the AWS global network and Anycast static IP addresses to route traffic over optimized paths, providing lower and more consistent latency than VPC peering, internet transit, or VPNs. It minimizes jitter by avoiding the public internet and leveraging AWS's internal backbone, which is ideal for latency-sensitive inter-Region communication.

Deploy a NAT Gateway in a public subnet and add a default route to the NAT Gateway in the private subnet route tables.

Option B is correct because a NAT Gateway, deployed in a public subnet with an Elastic IP and a route to an Internet Gateway, enables outbound traffic from private subnets to the internet while blocking unsolicited inbound connections. The private subnet route table directs default traffic (0.0.0.0/0) to the NAT Gateway, which performs source network address translation (SNAT) on outbound packets, ensuring responses return to the NAT Gateway without exposing private instances directly.

Use TLS or IPsec at the application layer between instances.

Option B is correct because VPC peering connections do not support native encryption of traffic. To meet the requirement for encryption in transit between two VPCs connected via a VPC peering connection, you must implement encryption at the application layer using TLS or IPsec between the instances. This ensures that traffic is encrypted end-to-end, independent of the underlying network path.

The security group for the EC2 instance does not allow inbound HTTPS traffic.

Since the on-premises router can ping the EC2 instance's private IP, Layer 3 connectivity is working, which rules out routing and BGP issues. The failure of TCP port 443 specifically points to a firewall or access control blocking the application traffic. A security group acts as a virtual firewall at the instance level, and by default it denies all inbound traffic unless explicitly allowed. Therefore, the most likely cause is that the security group for the EC2 instance does not have an inbound rule permitting HTTPS (TCP 443) traffic.

Use AS_PATH prepending on the BGP advertisements from the on-premises router to influence route preference.

AS_PATH prepending allows the on-premises router to artificially lengthen the AS_PATH for specific BGP routes, making those routes less preferred. This influences route selection in the Transit Gateway and VPC route tables, ensuring that traffic from each VPC takes a consistent path and eliminating asymmetric routing.

Check the VPC route tables to ensure routes to the on-premises network point to the virtual private gateway.

Option D is correct because even if the VPN tunnel is up and BGP is peering, traffic will not flow unless the VPC route tables have a route pointing to the virtual private gateway (VGW) for the on-premises CIDR. Without this route, the VPC has no path to forward return traffic back to the on-premises network, causing asymmetric routing or blackholing.

In the transit gateway route table, verify that the VPN attachment is correctly associated and that the 10.0.0.0/8 route is propagated and has the correct attachment.

Option C is correct because the first diagnostic step for intermittent connectivity through a transit gateway is to verify the route table configuration. The engineer must confirm that the VPN attachment is correctly associated with the transit gateway route table and that the 10.0.0.0/8 route is propagated from the VPN attachment, as a missing or misassociated route would cause traffic to be dropped even if the VPN tunnel is up.

Provision two Direct Connect connections, each with multiple private VIFs, and attach them to the same transit gateway. Use BFD to detect failures and rely on ECMP routing across the VIFs.

Option C is correct because it provides true high availability and fast failover by using two separate Direct Connect connections, each with multiple private VIFs, attached to the same transit gateway. BFD (Bidirectional Forwarding Detection) enables sub-second failure detection, and ECMP (Equal-Cost Multi-Path) routing across the VIFs allows active-active load balancing, minimizing packet loss during failover. This design eliminates single points of failure and meets the requirement for rapid convergence with minimal disruption.

The VPC peering connection does not support transitive routing. If any traffic is being routed through an intermediate device (e.g., a NAT instance or a VPN connection), the peering connection will not forward that traffic.

The intermittent failure is most likely due to VPC peering's lack of transitive routing. If traffic from VPC A to VPC B is routed through an intermediate device (e.g., a NAT instance, VPN connection, or another VPC), the VPC peering connection will not forward that traffic because it does not support transitive routing. This can cause intermittent failures when the intermediate device's route or state changes, even though direct routes and security groups are correctly configured.

Verify that the on-premises route table has a route to the VPC CIDR via the VPN tunnel.

Since the VPN tunnel is up and the on-premises firewall confirms traffic is being sent to the tunnel, the issue is likely on the on-premises routing side. For traffic to flow from on-premises to the VPC, the on-premises router must have a route pointing to the VPC CIDR via the VPN tunnel interface. Without this route, packets will not be forwarded into the tunnel, even though the tunnel itself is operational.

Establish an IPSec VPN connection over the Direct Connect public virtual interface using a customer gateway and a virtual private gateway.

Option A is correct because it establishes an IPSec VPN tunnel over a Direct Connect public virtual interface (VIF), which encrypts traffic between the on-premises network and the VPC. The customer gateway and virtual private gateway create a site-to-site VPN connection that uses IPSec to secure all data traversing the Direct Connect link, meeting the encryption requirement without relying on physical-layer security.