AWS SysOps Networking and Content Delivery: 90 practice questions

12 of the 90 Networking and Content Delivery questions in the Certsqill AWS SysOps bank, shown in full below. Each one carries an explanation for every option, not just the correct one — the wrong answers are where the marks go.

Preparing for AWS SysOps? Take the free 5-min readiness check →

1. The Subnet-A instance can both initiate outbound: Which statement correctly describes the network behavior?

1. A public IP address by itself lets an instance reach the internet, so the route table configuration of its subnet has no real bearing on connectivity

   A public IP is necessary but not sufficient for internet communication. The subnet's route table must also have a route to an internet gateway. Without the route, the public IP cannot be used for internet communication.
2. The instance in Subnet-B can start outbound internet connections through its private IP address but is unable to accept any inbound internet connections

   Without a route to an internet gateway or NAT gateway, instances in Subnet-B cannot initiate outbound internet connections either. Outbound internet access for private subnets requires a NAT gateway in a public subnet.
3. The Subnet-A instance can both initiate outbound and accept inbound internet connections, while the Subnet-B instance cannot reach the internet at all ✓

   A subnet is public when its route table has a route to an internet gateway (0.0.0.0/0 → igw-xxx). The EC2 instance in Subnet-A has both a public IP and a route to the internet gateway, enabling bidirectional internet communication. Subnet-B has no internet gateway route, making it a private subnet — instances cannot reach the internet or be reached from the internet.
4. Both instances can accept inbound connections from the internet because they share the same VPC and therefore inherit the same reachability

   Being in the same VPC enables intra-VPC communication, but internet accessibility requires a public IP and a route to the internet gateway. Subnet-B has neither, so its instance is not accessible from the internet.

A public subnet has a route to an internet gateway; instances with public IPs can communicate bidirectionally with the internet. Private subnets have no internet gateway route — instances cannot reach or be reached from the internet.

2. Deploy a NAT gateway in a public subnet and point: Which solution is most appropriate?

1. Deploy an EC2 NAT instance inside the private subnet, enable IP forwarding on it, and route all outbound traffic through it for internet software updates

   NAT instances must be deployed in PUBLIC subnets (with IGW route), not private subnets. Additionally, NAT instances require manual management (patching, HA) — the question asks for a managed solution.
2. Create a VPC peering connection to a VPC that has internet access and route the private instances' internet-bound traffic through that peer

   VPC peering does not support transitive routing. You cannot route internet traffic through a peered VPC's internet gateway. Each VPC must have its own internet access mechanism.
3. Assign Elastic IP addresses directly to the private-subnet EC2 instances so they can send outbound requests to the internet for updates

   Elastic IPs require the instances to be in a public subnet (with IGW route) to communicate with the internet. Assigning an EIP to an instance in a private subnet (with no IGW route) does not enable internet access.
4. Deploy a NAT gateway in a public subnet and point the private subnet route tables' 0.0.0.0/0 default route at that NAT gateway for outbound traffic ✓

   AWS NAT gateway is a fully managed service that enables instances in private subnets to initiate outbound connections to the internet while preventing inbound connections from the internet. It is placed in a public subnet and scales automatically. Private subnet route tables are updated to route 0.0.0.0/0 traffic to the NAT gateway.

NAT gateway is a managed service placed in a public subnet. Private subnet route tables point 0.0.0.0/0 to the NAT gateway, enabling outbound-only internet access for private instances.

3. VPC-A and VPC-B have overlapping CIDR blocks because: What is the cause?

1. VPC-A and VPC-B have overlapping CIDR blocks because 10.0.0.0/24 sits entirely within 10.0.0.0/16, and peering rejects overlapping ranges ✓

   VPC peering requires non-overlapping CIDR blocks. Since 10.0.0.0/24 (256 addresses: 10.0.0.0–10.0.0.255) is entirely contained within 10.0.0.0/16 (65,536 addresses: 10.0.0.0–10.0.255.255), the CIDRs overlap. AWS prevents peering between VPCs with overlapping CIDR ranges because routing would be ambiguous.
2. Both VPCs must be configured with the same CIDR prefix length before a peering connection between them can be successfully established

   VPC peering does not require matching CIDR prefix lengths. VPCs with different-sized CIDRs can be peered as long as the CIDRs do not overlap. The issue here is overlap, not size difference.
3. VPC peering cannot be established between two VPCs that both use private RFC 1918 address ranges, which happens to be the case for these two CIDR blocks

   VPC peering is designed for private IP address space (RFC 1918: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). Using private address ranges is standard and not a restriction.
4. VPC peering is not permitted between two VPCs that reside in the same AWS Region, so the request between VPC-A and VPC-B is rejected

   VPC peering is fully supported within the same region (same-region peering), across regions (inter-region peering), and across accounts. Region restriction is not the cause.

VPC peering requires non-overlapping CIDR blocks. 10.0.0.0/24 is a subset of 10.0.0.0/16 (overlapping), which prevents the peering connection from being established.

4. The Elastic IP stays allocated to the account but detaches: What happens to the Elastic IP address and associa

1. The Elastic IP stays associated with the stopped instance and keeps functioning normally, with no additional charges applied while that instance is stopped

   Elastic IPs disassociate from stopped instances automatically. Additionally, AWS charges for EIPs that are not associated with running instances — so stopping the instance while keeping the EIP allocated does incur charges.
2. The Elastic IP stays allocated to the account but detaches from the instance, and AWS charges for the unassociated address while the instance is stopped ✓

   When an EC2 instance is stopped, the Elastic IP address is automatically disassociated from the instance but remains allocated to the account. AWS charges for Elastic IPs that are allocated but not associated with a running instance (to discourage IP hoarding). The charges are approximately $0.005/hour for an unassociated EIP.
3. The Elastic IP is automatically released back to the AWS pool the moment the instance stops, so no further charges are incurred for it

   Elastic IPs are not automatically released when instances stop. They remain allocated until explicitly released. Releasing the EIP when not needed is a cost optimization best practice.
4. AWS automatically re-associates the Elastic IP with another running instance in the same VPC so that no idle-address charges are ever incurred

   AWS does not automatically reassign customer Elastic IPs to other instances. Elastic IPs are customer-owned resources that must be explicitly managed. Automatic reassignment would violate customers' IP address control.

When an EC2 instance is stopped, the Elastic IP disassociates but remains allocated. AWS charges for EIPs not associated with a running instance — release EIPs when not needed to avoid charges.

5. 10.1.0.0/16 → tgw-transit-gateway is chosen because it is: Which route is selected?

1. 10.0.0.0/8 → pcx-peering-connection is chosen because the VPC route table evaluates its entries in order and selects the first one that matches

   AWS VPC route tables use longest prefix match, not first-match. Route order in the table does not determine selection — the most specific (longest prefix) matching route is always chosen.
2. 0.0.0.0/0 → igw-internet-gateway is chosen as the default route whenever more than one route in the table happens to match the destination

   0.0.0.0/0 (/0 = no bits) is the least specific route — it matches everything but loses to any more specific route. It is only used when no other route matches. 10.1.5.25 matches both 10.0.0.0/8 and 10.1.0.0/16 specifically.
3. 10.1.0.0/16 → tgw-transit-gateway is chosen because it is the most specific longest-prefix match covering the destination address 10.1.5.25 ✓

   AWS route tables use longest prefix match: the route with the most specific CIDR (longest prefix length) that covers the destination IP is selected. 10.1.5.25 matches both 10.0.0.0/8 (/8 = 8 bits) and 10.1.0.0/16 (/16 = 16 bits). The /16 is more specific (longer prefix), so 10.1.0.0/16 → tgw-transit-gateway wins.
4. Traffic is spread across all three matching routes using equal-cost multi-path routing, which the VPC route table performs automatically here

   VPC route tables do not automatically load-balance across multiple matching routes using ECMP. VPC routing uses longest prefix match to select a single route. Transit Gateway supports ECMP for specific configurations, but the VPC route table itself selects one route.

VPC route tables use longest prefix match — the most specific CIDR covering the destination wins. 10.1.0.0/16 (/16 bits) is more specific than 10.0.0.0/8 (/8 bits) for destination 10.1.5.25.

6. Set the enableDnsHostnames attribute to true on the VPC so: What additional VPC setting is required?

1. Add a custom DHCP option set that specifies the VPC's own DNS server address so that the instances are able to resolve each other's private DNS hostnames

   The default DHCP option set already configures instances to use the Amazon-provided DNS resolver. Custom DHCP options are only needed when using custom DNS servers. The issue is hostname assignment (enableDnsHostnames), not DNS server configuration.
2. Create a Route 53 private hosted zone and manually add an A record for every EC2 instance so their private DNS hostnames resolve correctly

   Route 53 private hosted zones can provide custom DNS records but are not required for the built-in AWS DNS hostname resolution. Setting enableDnsHostnames to true is the simpler solution that enables automatic DNS hostname assignment.
3. Enable VPC Flow Logs so the built-in DNS resolver can log the queries and begin returning private hostnames for the instances in the VPC

   VPC Flow Logs capture IP traffic metadata for monitoring — they have no relationship to DNS hostname assignment or resolution. This is an unrelated feature.
4. Set the enableDnsHostnames attribute to true on the VPC so instances receive private DNS hostnames like ip-10-0-1-25.ec2.internal that resolve ✓

   Two VPC DNS settings work together: (1) enableDnsSupport (default true): enables the Amazon-provided DNS resolver (VPC+2 address) to resolve AWS DNS hostnames, (2) enableDnsHostnames (default false for non-default VPCs): assigns public and private DNS hostnames to EC2 instances. Both must be true for instances to have private DNS hostnames like ip-10-0-1-25.ec2.internal.

enableDnsHostnames must be set to true alongside enableDnsSupport for EC2 instances to be assigned and resolvable by private DNS hostnames (e.g., ip-10-0-1-25.ec2.internal).

7. NACLs are evaluated before security groups: Why does the connection fail?

1. NACLs are evaluated before security groups, and the DENY at the lower rule number 100 takes precedence over the ALLOW at the higher rule number 200 ✓

   Network ACLs process rules in number order (lowest number first) and stop processing once a matching rule is found. The DENY at rule 100 matches SSH traffic first and denies it — the ALLOW at rule 200 is never evaluated. Since NACLs are evaluated before security groups, the traffic is blocked at the NACL before even reaching the security group.
2. The NACL ALLOW rule at 200 overrides the DENY at 100 because network ACLs always give ALLOW entries precedence over DENY entries regardless of number

   NACLs do not have an ALLOW-over-DENY precedence — they use first-match by rule number. Rule 100 is matched first and the DENY is applied. Rule 200 is never evaluated. This is different from security groups which have no Deny rules (all rules are Allow, and default is implicit Deny).
3. Security groups are evaluated before NACLs, so because the instance's security group permits SSH the inbound connection on port 22 should succeed

   NACLs are evaluated at the subnet boundary before traffic reaches the EC2 instance's security group. The correct evaluation order is NACL → Security Group (for inbound), or Security Group → NACL (for outbound).
4. NACLs process their rules from the highest number down to the lowest, so rule 200 ALLOW is evaluated and applied before the rule 100 DENY entry

   NACLs process rules from lowest rule number to highest — not reverse. Rule 100 is evaluated before rule 200. This is why lower rule numbers (higher priority) take effect first.

NACLs evaluate rules in ascending rule number order (lowest first) and stop at the first match. Rule 100 DENY is evaluated before rule 200 ALLOW, blocking SSH. NACLs are evaluated before security groups.

8. Egress-Only Internet Gateway: Which VPC component provides outbound-only IPv6 internet access?

1. NAT gateway — configure it for IPv6 by enabling IPv6 NAT so private instances get outbound-only IPv6 access without inbound reachability

   NAT gateways support only IPv4 NAT (translating private IPv4 to public IPv4). They do not support IPv6. IPv6 addresses in AWS are globally unique and publicly routable — NAT is not used with IPv6. Egress-only IGW is used instead.
2. Egress-Only Internet Gateway — attach it to the VPC and add a ::/0 route pointing to it so instances get outbound-only IPv6 internet access ✓

   An Egress-Only Internet Gateway is designed specifically for IPv6 outbound-only internet access. It allows instances to initiate outbound IPv6 connections to the internet while preventing inbound IPv6 connections from being established. It is the IPv6 equivalent of a NAT gateway for IPv4 private subnets.
3. AWS PrivateLink — build an interface endpoint service configured for IPv6 to give the instances outbound-only connectivity to the internet

   AWS PrivateLink provides private connectivity to AWS services and third-party services — it is not a general-purpose outbound internet connectivity mechanism and doesn't provide IPv6 outbound internet access.
4. Internet Gateway — attach it and use security group rules to permit outbound IPv6 while blocking every inbound IPv6 connection to the instances

   A regular internet gateway allows bidirectional IPv6 traffic. While security groups can block specific inbound connections, the requirement for outbound-only access at the network level is better served by the Egress-Only Internet Gateway, which architecturally prevents inbound connections.

Egress-Only Internet Gateway provides outbound-only IPv6 internet access for EC2 instances — it allows instances to initiate IPv6 connections but prevents inbound IPv6 connections from the internet.

9. Network Load Balancer: Which AWS load balancer type is most suitable?

1. Classic Load Balancer (CLB) — it supports TCP pass-through and can preserve the client source IP, giving this trading workload the behavior it requires

   Classic Load Balancer (CLB) does support TCP and can preserve source IPs in TCP mode, but CLB is a legacy service. NLB is the recommended replacement for TCP load balancing with superior performance, static IPs, and better features.
2. Application Load Balancer (ALB) — it operates at Layer 7 and delivers the lowest possible latency for the TCP-based trading connections described

   ALB operates at Layer 7 (HTTP/HTTPS) and is designed for web applications. It adds latency from HTTP inspection and does not pass through the original client IP (it uses X-Forwarded-For header). ALB is not suitable for non-HTTP protocols.
3. Network Load Balancer (NLB) — it operates at Layer 4, preserves the client's source IP, and delivers ultra-low latency for these TCP connections ✓

   Network Load Balancer operates at TCP/UDP Layer 4, providing ultra-low latency and high throughput. By default, NLB preserves the client's source IP address to backend targets (unlike ALB which uses X-Forwarded-For headers). It is ideal for non-HTTP protocols and latency-sensitive applications.
4. Gateway Load Balancer (GWLB) — it offers transparent Layer 3 pass-through for any protocol, meeting the source-IP and low-latency requirements

   Gateway Load Balancer is designed for deploying, scaling, and managing third-party network appliances (firewalls, IDS/IPS). It operates at Layer 3 and is used for traffic inspection architectures, not for application load balancing.

NLB operates at Layer 4, preserves client source IPs natively, provides ultra-low latency, and supports any TCP/UDP protocol — ideal for non-HTTP applications requiring source IP logging.

10. The health check port is 80 but the application listens: What is the most likely cause?

1. The ALB requires HTTPS health checks, so the plain HTTP health check that is configured here on port 80 cannot validate the encrypted application targets

   ALB health checks support both HTTP and HTTPS. The protocol must match what the application responds to. HTTP health checks are fully supported — the issue described is a port mismatch, not protocol restriction.
2. The security group attached to the EC2 instances does not permit inbound health-check traffic arriving from the Application Load Balancer nodes

   Security group misconfiguration could also cause health check failures, but the scenario specifies all targets show unhealthy with a specific port mismatch configuration. The security group issue would be a secondary concern if the port was already correct. The port mismatch is the direct and most likely cause.
3. The /health path is returning a non-200 status code, and the ALB marks a target unhealthy whenever the configured path replies with any other code

   ALB health checks have configurable success codes (default is 200, but can be configured as 200-399 or specific codes). More importantly, if the health check cannot connect to port 80 (because the app runs on 8080), the failure would be a connection error, not a non-200 response. The port mismatch is the most likely cause.
4. The health check port is 80 but the application listens on 8080, so the check should target the traffic port 8080 that the application actually uses ✓

   ALB health checks can be configured with a specific port or to use 'traffic port' (the port used by the target group). If the health check port is 80 but the application listens on 8080, the health check connection to port 80 fails (connection refused or returns wrong response), causing all targets to appear unhealthy.

The health check port (80) doesn't match the application port (8080). ALB health checks must target the port where the application actually listens — either set explicitly or use 'traffic port'.

11. Enable sticky sessions on the ALB target group so every: Which ALB feature resolves this issue?

1. Enable sticky sessions on the ALB target group so every request in a user's session is consistently routed to the same backend target instance ✓

   ALB sticky sessions (session affinity) use a cookie to route all requests from a user session to the same backend target. This ensures users with in-memory sessions on a specific instance always return to that instance, preventing session loss from being routed to a different instance.
2. Increase the health check interval on the ALB target group so targets are replaced less often and users stop being shifted to other instances

   Health check intervals affect how quickly the ALB detects unhealthy targets — they don't address the session routing problem. Users are being routed to different healthy instances, which is normal ALB behavior without sticky sessions.
3. Use connection draining, also called deregistration delay, so a user's existing connections finish gracefully before that target leaves rotation

   Connection draining allows in-flight requests to complete when a target is deregistered. It doesn't solve the problem of requests from the same user being routed to different instances during normal operation.
4. Configure ALB access logging to record which instance serves each user and then use those logs to manually keep session routing consistent

   ALB access logs are for monitoring and diagnostics — they cannot be used to influence routing decisions or manage session affinity. Sticky sessions is the built-in feature for this use case.

ALB sticky sessions route all requests from a user to the same target via a cookie, ensuring in-memory session state on a specific instance is always accessed by the same user.

12. Replace the ALB with a Network Load Balancer: Which solution provides static, predictable IP addresses for the

1. Enable cross-zone load balancing on the ALB so that all outbound API traffic is funneled through a single consistent IP address the partner is able to whitelist

   Cross-zone load balancing distributes traffic evenly across all targets regardless of AZ — it doesn't affect the ALB's IP addresses. ALBs always use dynamic IPs regardless of cross-zone settings.
2. Replace the ALB with a Network Load Balancer, which can be assigned static Elastic IP addresses, one per Availability Zone, for the partner to whitelist ✓

   Network Load Balancers can be assigned Elastic IP addresses — one per Availability Zone. These static IPs are consistent and predictable, allowing partners to whitelist a known set of IP addresses. ALBs use dynamic IPs that can change, which is why the partner sees different IPs.
3. Assign Elastic IP addresses to each EC2 instance behind the ALB so their outbound API calls always leave from that fixed set of known addresses

   If the company's application is making outbound API calls, the outbound IP would be the instance's IP (or NAT gateway), not the ALB's IP. ALBs receive inbound traffic. The architecture needs to be clarified, but the question context implies using NLB for its static IP feature.
4. Register a custom Route 53 domain that points at the ALB and give the partner the domain name so they can whitelist it instead of raw IPs

   Using a domain name doesn't provide static IP addresses — it resolves to the dynamic IPs of the ALB, which can change. The partner would still see different IPs from DNS resolution.

NLB supports Elastic IP assignment (one per AZ) providing static, predictable IP addresses for partner whitelisting — ALBs use dynamic IPs that can change.

Other AWS SysOps domains

• Monitoring, Logging, and Remediation — 100 questions →
• Deployment, Provisioning, and Automation — 89 questions →
• Reliability and Business Continuity — 80 questions →
• Security and Compliance — 79 questions →
• Cost and Performance Optimization — 60 questions →
• All 498 AWS SysOps questions →