Networking and Content Delivery practice questions

Use Amazon Route 53 with a simple routing policy pointing to the ALB DNS name

Why it fails: Amazon Route 53 with a simple routing policy only returns the ALB's DNS name as an A/AAAA alias record. The ALB's underlying IP addresses are ephemeral and can change when the load balancer scales or is recreated, so the third party cannot extract a static, allowlisted IP from this DNS response. Simple routing also provides no mechanism to guarantee a fixed IP for the caller's firewall rules, making it invalid for a static-IP allowlisting requirement.

Use an Amazon CloudFront distribution with the ALB as the origin and provide the CloudFront IP addresses

Why it fails: CloudFront uses a shared IP range that is not dedicated to a specific distribution. These IPs also change when CloudFront updates its edge locations, so they are not a stable, dedicated set of IPs for allowlisting.

Use AWS PrivateLink by creating a Network Load Balancer in VPC C and configuring VPC endpoints in VPC A and VPC B to access the services.

Why it fails: Incorrect. PrivateLink only provides access to specific services (e.g., via NLB and VPC endpoints), not general IP communication between all resources in the VPCs. It does not fulfill the requirement of enabling private IP communication between the VPCs.

Create two VPC peering connections: one between VPC A and VPC C, and one between VPC B and VPC C.

Why it fails: Incorrect. VPC peering does not support overlapping CIDR blocks, so peering between VPC A and VPC C (both using 10.0.0.0/16) would fail due to conflicts.

Set up two AWS Site-to-Site VPN connections from VPC C to VPC A and VPC B using virtual private gateways.

Why it fails: Incorrect. Site-to-Site VPN is typically used for connecting on-premises networks to VPCs, not for VPC-to-VPC communication in the same region. It adds complexity and does not address overlapping CIDRs.

Create a NAT gateway in a public subnet and update the private route tables to point 0.0.0.0/0 to the NAT gateway.

Why it fails: A NAT gateway placed in a public subnet enables outbound internet connectivity, but any traffic sent to Amazon S3 through that path will traverse the public internet to reach the S3 endpoint. This violates the requirement to keep traffic private, and the NAT gateway also incurs hourly charges plus per-GB data processing costs. In contrast, a Gateway VPC endpoint provides direct, private access to S3 by adding a route to the S3 prefix list, so the NAT gateway is neither necessary nor optimal.

Create a VPC endpoint for S3 (Interface type) and assign a security group to the endpoint.

Why it fails: An Interface VPC endpoint for S3, while preventing internet traversal, requires a security group and incurs hourly costs, but the correct solution is a Gateway VPC endpoint that uses route table entries and is free. This option is tempting because Interface endpoints are necessary for services like SQS or DynamoDB, where Gateway endpoints do not exist, and security groups offer granular control.

Create an AWS Direct Connect connection and route traffic to S3 through the on-premises network.

Why it fails: AWS Direct Connect establishes dedicated network connectivity from your on-premises data center to AWS, not from your VPC to S3 within the same region. To use it for S3 access, traffic would need to egress the VPC through a virtual private gateway or transit gateway, travel to the on-premises location, and then return to AWS — a round-trip that adds latency, complexity, and cost. A Gateway S3 endpoint is the region-internal, lowest-cost solution and eliminates the need for Direct Connect in this scenario.

Enable versioning

Why it fails: Enabling versioning preserves every overwritten or deleted object, allowing recovery from accidental changes, but it does not create an HTTP endpoint or serve any content. The website feature is a separate bucket configuration that activates a web server on the S3 service; without it, the bucket remains a private object store. Versioning is therefore entirely orthogonal to hosting a static website.

Configure a bucket policy to allow public read access

Why it fails: Block public access settings and a bucket policy that grants public read access are prerequisites for anyone to view the objects, but they only affect object permissions via the REST API. The static website hosting feature itself must be activated separately to produce a website endpoint and to interpret index/error documents. A public bucket policy alone leaves the bucket as an object store, not a website.

Attach a CloudFront distribution

Why it fails: Attaching a CloudFront distribution is an optional enhancement that provides low-latency delivery, HTTPS, and custom domain support using the S3 bucket as an origin. It does not itself enable S3's static website hosting; if the bucket is not configured for website hosting, CloudFront will use the REST API endpoint, which requires proper permissions and does not serve website features like index documents. Since the question asks to host a static website, CloudFront is not the enabling action.

CloudWatch metrics

Why it fails: CloudWatch metrics for an Application Load Balancer publish aggregated, time-series data such as request count, average latency, and error counts (e.g., 5xx responses). They are sampled and summarized (usually at 1-minute granularity) and do not contain per-request fields like client IP address, URI path, or individual response times. Therefore, while useful for monitoring trends and alarms, they cannot satisfy a requirement to analyze details of each specific request.

Connection logs

Why it fails: Connection logs are a feature of the Network Load Balancer (NLB) that capture TCP/UDP/TLS connection-level metadata, such as connection handshake durations and throughput, but they are not available for Application Load Balancers. The ALB operates at Layer 7 and does not generate connection logs; it instead provides access logs as its HTTP-level logging mechanism. Selecting connection logs would be invalid because the resource type in question is an ALB, not an NLB.

Request tracing

Why it fails: Request tracing in AWS, typically implemented via AWS X-Ray, collects trace data and produces a map of how requests travel through microservices and backend components, including timing of each downstream call. It does not, by itself, produce HTTP access log entries with client IP and request path; rather, it tracks a trace ID across service calls and requires instrumentation in the application. Therefore, request tracing is meant for distributed application performance analysis, not for obtaining granular per-request logs directly from the load balancer.

Verify the network ACL associated with the subnet allows inbound traffic from the internet

Why it fails: Network ACL inbound rules filter traffic entering the subnet from the internet, not traffic originating from the instance. The reported symptom is an inability to initiate outbound connectivity, which is governed by outbound NACL rules (and, importantly, security group outbound rules). While NACLs are stateless and return traffic would also need an inbound allow rule, a missing inbound rule would manifest as no response packets, not as a failure to send requests. Since the question centers on outbound access, checking inbound NACL rules is not the immediate or correct diagnostic step.

Confirm that the route table has a route to the IGW for 0.0.0.0/0

Why it fails: The route table already contains the required default route to the internet gateway (0.0.0.0/0), so this cannot be the root cause. A missing or incorrect route to the IGW would prevent any non-local traffic from leaving the subnet, but the scenario explicitly confirms the route exists. Additionally, even with the correct route, the instance still needs proper security group outbound rules and a public IP to complete end-to-end internet communication. Therefore, verifying the route table is redundant in this situation and does not address the actual failure.

Ensure the instance has a public IP address

Why it fails: The instance already has a public IP address assigned, so this configuration is not causing the lack of outbound connectivity. A public IP is necessary for internet reachability, but it only provides the address; it does not automatically allow traffic through the security group or network ACLs. Even with a public IP, outbound packets will be silently dropped if the security group lacks an outbound allow rule or if the route table lacks an IGW route. Thus, while a public IP is required, its presence alone does not prove that egress traffic is permitted, and it is not the element causing the issue here.

The CloudFront distribution uses the S3 bucket's regional domain name instead of the distribution domain name

Why it fails: Using the S3 bucket's regional domain name as the origin is expected when you configure CloudFront with a private S3 bucket via OAI; the bucket policy only needs to grant access to the OAI, not to the general public. The distribution domain name is what users actually hit, and the origin configuration does not affect whether access is denied. Therefore, this misconfiguration would not produce a 403 Access Denied response.

The CloudFront distribution is in a different region than the S3 bucket

Why it fails: CloudFront is a global content delivery network, not a regional service, so its "region" is not a concept that applies to distributions. An S3 bucket is regional, but CloudFront can be attached to a bucket in any AWS Region; cross-region architectures are fully supported and do not alter S3 access. Hence, a region mismatch cannot cause the lack of access.

The S3 bucket has Block Public Access settings enabled that deny all access

Why it fails: Enabling S3 Block Public Access, especially the 'Block all public access' setting, overrides permissions granted by a bucket policy. Even when the policy explicitly allows s3:GetObject for the CloudFront Origin Access Identity, S3 denies the request because the bucket-level block supersedes any policy-based grants. This is a common root cause: you have a valid OAI policy, but the bucket is configured to ignore all public or policy-based access, producing a 403 Access Denied even for CloudFront.

The default route (0.0.0.0/0) is missing

Why it fails: The default route (0.0.0.0/0) exists and points to the NAT gateway, so it is not missing. The issue is that the NAT gateway itself may lack internet access.

The route table is not associated with the subnet

Why it fails: The route table is associated with the subnet; the exhibit shows the route table for subnet-0a1b2c3d4e5f6g7h8, so association is not the problem.

The VPC CIDR route is misconfigured

Why it fails: The VPC CIDR route is a local route and is correct; misconfiguration of that route is not the issue.

The instance security group does not allow outbound traffic to the ALB.

Why it fails: Security groups are stateful; inbound rule implicitly allows return traffic.

The ALB security group does not allow outbound traffic to the instances.

Why it fails: The ALB security group's outbound rules are not the issue; the instance security group must allow inbound from the ALB.

The ALB is in a public subnet without an internet gateway.

Why it fails: The ALB can communicate with instances in private subnets via the VPC; an internet gateway is not required for health checks.

The network ACLs in subnets are blocking ICMP traffic.

Why it fails: Network ACLs are stateless and must explicitly allow inbound and outbound ICMP traffic; however, even if they do, the default NACL for a custom VPC allows all traffic, and custom NACLs typically require a deliberate rule. If the instances can reach each other over other protocols such as SSH, the NACL is unlikely to be the sole blocker because the same NACL rules would affect all traffic. The more common cause of VPC peering failure is the absence of a route entry pointing to the peered VPC CIDR.

VPC Peering is not supported across AWS Regions.

Why it fails: AWS does support inter-region VPC peering, so the statement that VPC peering is not supported across AWS Regions is factually incorrect. Inter-region peering connections allow resources in different regions to communicate privately over the AWS backbone, though they cannot reference each other's security group IDs. Even if the regions were different, the underlying fault is still likely a routing misconfiguration, not an unsupported feature.

The security groups do not allow traffic from the peered VPC's security group ID.

Why it fails: Security groups cannot reference a security group ID that resides in a peered VPC; AWS only allows security group ID references within the same VPC, so using the peer VPC's SG ID in an inbound rule is not a valid configuration, not merely a rule that 'does not allow' traffic. For peering, inbound rules must use the peer VPC's CIDR blocks as sources, so this option describes an impossible or malformed rule that would never be evaluated. Hence, the actual cause would not be a firewall rule on the SG, but rather the missing route in the route table.

Create a rule with a host header condition matching 'api.example.com' and forward to target group A, and a default rule forward to target group B.

Why it fails: Incorrect. A host header condition does not route based on path; it routes based on domain. The requirement is path-based routing, not host-based.

Create one rule with a condition that matches /api/* and forward to target group A, and another condition in the same rule for /* to forward to target group B.

Why it fails: Incorrect. A single listener rule can have multiple conditions, but each condition can only forward to one target group. You cannot assign two different target groups within one rule.

Create two rules with path patterns /api/* and /*, and set priority based on the pattern length.

Why it fails: Incorrect. While path patterns are allowed, the ALB does not automatically set priority based on pattern length. Priority must be explicitly assigned to ensure correct order of evaluation.

Configure the DHCP option set to assign a static IP

Why it fails: DHCP option sets in a VPC only propagate configuration parameters such as DNS servers, domain name, and NTP servers to instances that use DHCP; they do not control or allocate private IP addresses at all. Private IPv4 assignment is handled by the VPC's built-in DHCP mechanism based on the subnet's CIDR, so modifying the DHCP option set cannot make an instance's IP address static or predefined.

Assign an Elastic IP to each instance and use that as the private IP

Why it fails: An Elastic IP (EIP) is a public IPv4 address provided for internet-facing connectivity or NAT, not a private address inside the VPC. You cannot assign an EIP to an ENI or instance as its private IP because EIPs are mapped to public IPs or NAT gateways, and using one would not meet the requirement for a stable private IP reachable within the VPC.

Use a custom AMI that configures a static private IP address via user data

Why it fails: Executing user data from a custom AMI runs inside the operating system at boot time, long after the instance's primary ENI has already been assigned a dynamic private IP by the VPC's DHCP from the subnet range. Configuring a static private IP at the OS level in user data would conflict with the address actually attached to the ENI, would not be reflected in AWS's networking controls, and would not guarantee the desired IP is reachable, making this solution unreliable and outside AWS's supported networking model.

The VPN tunnel is not in the UP state

Why it fails: The VPN tunnel not being UP could prevent connectivity, but the scenario states the VPN connection is established, which implies the tunnel is likely up. Therefore, this is not the most likely cause.

The security group for the VPC instances does not allow ICMP traffic

Why it fails: While security groups must allow ICMP for ping, the fundamental issue is the missing route. Even with proper security group rules, traffic would not reach the on-premises server without a route.

The VPC does not have a VPC endpoint for the VPN service

Why it fails: VPC endpoints are used to connect to AWS services privately, not for VPN connections. VPN connections use a virtual private gateway and do not require a VPC endpoint.

Assign security groups to the NLB to allow inbound traffic

Why it fails: Network Load Balancer doesn't support security groups; SG rules cannot be attached to its ENIs and AWS explicitly prevents assigning them to NLB. Traffic filtering for NLB is handled by subnet-level network ACL and any SG on the targets themselves. The NLB's connection tracker and IP-based forwarding operate independently of SG state, so attempting to set an SG on the NLB is impossible. Instead, to control inbound traffic you must rely on network ACLs or the SG attached to the target instances.

Configure a NAT gateway in each Availability Zone for the NLB to access the instances

Why it fails: A NAT gateway provides outbound internet connectivity for resources in private subnets, but NLB-to-target communication occurs entirely inside the VPC and does not require internet access. Since the NLB preserves the client source IP and forwards packets directly toward the target ENI, the VPC router delivers them based on local routes; no NAT is involved. Deploying a NAT gateway in each AZ adds cost and complexity while doing nothing to fix NLB routing to the target subnets. The only required path is a valid route entry between the NLB subnet and the target subnet.

Attach an internet gateway to the VPC and add a route to the NLB subnets

Why it fails: Attaching an internet gateway (IGW) and adding its route is only necessary when the NLB must be internet-facing, meaning clients connect from the public internet and the NLB gets public addresses. For a VPC-internal scenario—such as an internal NLB targeting private instances—the IGW is irrelevant, and even for an internet-facing NLB, the IGW does not affect routing to private targets. The problem is about the NLB's ability to reach private subnets, which is solved by adding specific routes to those target subnets in the NLB subnet's route table, not by a default route to an IGW. Adding an IGW may create a public route but does not resolve the missing private route.

The route tables do not have a route to the other VPC's CIDR.

Why it fails: This is incorrect because the stem explicitly states that route tables in both VPCs include the CIDR of the other VPC with the peering connection as the target.

There is a third VPC C that is peered with both VPC A and VPC B, and VPC A is trying to reach VPC B through VPC C.

Why it fails: This is not the most likely issue because the stem does not mention a third VPC. Transitive routing is not supported, but there is no evidence of a third VPC.

The VPCs are in different AWS regions.

Why it fails: This is incorrect because the stem states the VPCs are in the same AWS region.

Configure the ALB to send a Cache-Control: no-cache header.

Why it fails: Setting Cache-Control: no-cache on the ALB would force CloudFront to revalidate each request with the origin, but it does not invalidate already cached objects and increases origin load.

Set up a Lambda@Edge function to change the origin request path.

Why it fails: Lambda@Edge can modify origin requests, but changing the request path does not force CloudFront to fetch new content unless the path is versioned; it does not invalidate existing cache.

Reduce the CloudFront TTL to 0 seconds.

Why it fails: Setting TTL to 0 seconds causes CloudFront to treat all objects as expired immediately, but it does not actively invalidate cached objects and leads to constant origin fetches.

The ALB's security group blocks inbound traffic from the on-premises CIDR.

Why it fails: The ALB's security group controls network traffic to the load balancer only after DNS resolution has successfully provided an IP address. On-premises clients first perform a DNS lookup for the ALB's DNS name; if the Route 53 inbound resolver cannot answer that query, the client never obtains an IP to connect to, so the security group is never reached. A restrictive security group would cause connection timeouts on established traffic, but it cannot explain a DNS resolution failure. Even with a permissive security group, the resolver would still fail to resolve the ALB's name because it is not in the private hosted zone.

The ALB is internal and does not have a public DNS name.

Why it fails: Internal Application Load Balancers do receive a DNS name from AWS, formatted as internal-<name>-<id>.<region>.elb.amazonaws.com, and this name resides in the public amazonaws.com DNS namespace, resolving to the ALB's private IP addresses. The statement that internal ALBs do not have a public DNS name is incorrect; the name is publicly registered and resolvable, though not routable from the internet. The actual issue is that this public DNS name is not added to the Route 53 private hosted zone used by the on-premises forwarder, so the hybrid DNS setup cannot map that name to the internal IP.

The Route 53 inbound resolver is not configured to forward queries to the public internet.

Why it fails: The Route 53 inbound resolver is a recursive DNS resolver that can resolve public names using the VPC's resolver logic, so it does not require a special 'forwarding to the public internet' configuration to handle the ALB's amazonaws.com DNS name. In a common hybrid setup, the on-premises DNS server forwards only queries for the private hosted zone's domain (e.g., example.internal) to the inbound resolver; queries for other names like the ALB's are either forwarded elsewhere or handled recursively. The real failure is that the ALB's DNS name is simply not present in the private hosted zone, so even if the resolver had full internet forwarding enabled, it would not know the mapping. The fix is to create a record in the private zone (e.g., an alias to the ALB) or add a Resolver forwarding rule for the relevant domain.

Attach an internet gateway to the private subnet.

Why it fails: An Internet Gateway is a VPC-level resource that attaches to the VPC itself, not to an individual subnet, and it is already present in the VPC to serve the public subnet. You cannot attach an IGW to a private subnet, and even if you added a 0.0.0.0/0 route to the IGW in the private subnet's route table, instances would need public IPs and lose the security of being in a private subnet. The NAT Gateway, not the IGW, is the correct egress path for private instances.

Associate an Elastic IP with the NAT Gateway.

Why it fails: The NAT Gateway already has an Elastic IP associated with it at creation time, so associating another EIP would either fail or require replacing the NAT Gateway; it does not affect how the private subnet's route table forwards traffic. The symptom of intermittent access stems from the missing route to the NAT Gateway, not from the NAT's public IP address. EIP association only impacts the NAT Gateway's internet-facing endpoint, not the routing behavior inside the VPC.

Enable DNS resolution in the VPC.

Why it fails: Enabling DNS resolution (enableDnsSupport) and DNS hostnames (enableDnsHostnames) in the VPC controls whether instances can query the Route 53 Resolver and receive public DNS names, but it has no effect on IP routing or the default route to the internet. This setting is irrelevant to outbound connectivity via a NAT Gateway; the traffic path is determined solely by route tables and network ACLs. Instances may resolve names successfully yet still fail to connect if the route to the NAT Gateway is absent.

Configure BGP metrics to prefer the primary VIF.

Why it fails: BGP metrics such as MED or local preference only influence which route is preferred when multiple paths are available; they do not initiate failover when the primary path fails. Failover occurs only when the BGP session on the primary VIF goes down, causing the route to be withdrawn and the backup route to become active. Preferring the primary VIF with metrics may actually delay recovery because the session must still time out before the backup is used. Thus, metrics alone cannot ensure automatic failover.

Place both VIFs in the same VLAN.

Why it fails: Placing both virtual interfaces on the same VLAN is a Layer 2 configuration that only affects how Ethernet frames are tagged on the Direct Connect circuit. VLAN assignments have no bearing on BGP route selection or route propagation, so they cannot trigger failover in any way. Moreover, using the same VLAN for two VIFs on the same Direct Connect could actually cause one of them to be unusable or create a partitioning issue, undermining redundancy. In short, this option changes tagging behavior, not availability.

Enable equal-cost multi-path (ECMP) routing.

Why it fails: Equal-cost multi-path routing enables traffic to be load-balanced across multiple BGP paths that have the same AS path and metrics, allowing both Direct Connect VIFs to be used simultaneously. ECMP itself does not provide automatic failover; if one path goes down, BGP withdraws its routes and the other path continues carrying traffic, but ECMP does not detect or react to the failure beyond what BGP already does. It also does nothing to protect against a total Direct Connect outage because both VIFs share the same physical connection. Therefore, ECMP optimizes utilization, not resilience.

Security groups

Why it fails: Security groups are stateful instance-level filters evaluated at the elastic network interface, so they cannot block traffic at the AWS edge before it enters the network. They are tempting because they are the default access-control tool, and would be correct for controlling traffic to specific EC2 instances or ENIs.

AWS Shield Advanced

Why it fails: AWS Shield Advanced is a managed DDoS protection service that continuously monitors traffic and mitigates volumetric or state-exhaustion attacks at the edge, but it does not offer a simple user-defined mechanism to deny a specific IP address. It operates on traffic patterns and attack signatures, not on explicit allow/block lists. While you can get cost protection and DDoS response support, for denying a particular source you must use AWS WAF or other access control mechanisms.

Network ACLs

Why it fails: Network ACLs are stateless, subnet-level firewall rules that allow or deny traffic as it crosses the subnet boundary in a VPC. They can block specific IP addresses, but only for traffic to or from that subnet; they are not global and cannot be applied to CloudFront or to resources outside a single VPC. Because NACLs are stateless, you must define both inbound and outbound rules, which adds complexity when trying to block a source IP at the organization edge.