Hard Difficulty Questions

Use VPC peering to connect all VPCs to the shared services VPC and route traffic through the firewall.

Why wrong: VPC peering is not transitive and does not scale well for many VPCs.

Attach all VPCs to a Transit Gateway and configure a Network Load Balancer in the shared services VPC to distribute traffic to firewall instances.

Why wrong: Network Load Balancer does not support packet inspection; a Gateway Load Balancer is needed.

Attach all VPCs to a Transit Gateway and use a single firewall instance with elastic network interfaces in each VPC.

Why wrong: Single firewall instance is not highly available.

Create a VPC peering connection between VPC A and VPC B, and attach firewall appliances in both VPCs.

Why wrong: VPC peering does not support transitive routing; traffic would go directly.

Use AWS PrivateLink to create VPC endpoints in VPC A and VPC B, and route traffic through the firewall VPC.

Why wrong: PrivateLink is for accessing services, not for routing VPC-to-VPC traffic.

Deploy AWS Network Firewall in each VPC and configure VPC route tables to send traffic to the firewall endpoint.

Why wrong: This is a valid approach but does not use Transit Gateway as specified.

Change the VPN connection from static to dynamic routing.

Why wrong: Routing type does not affect latency.

Enable BGP route propagation on the transit VPC's route tables.

Why wrong: Route propagation is likely already enabled.

Deploy a new transit VPC in eu-west-1.

Why wrong: Adding another transit VPC increases complexity.

Deploy a NAT Gateway in a public subnet.

Why wrong: NAT Gateway is for outbound internet without on-premises routing.

Attach an internet gateway to the VPC.

Why wrong: IGW would provide direct internet access, bypassing on-premises.

The VPCs have overlapping CIDR blocks.

Why wrong: CIDR blocks are different.

Security groups are blocking ICMP traffic.

Why wrong: Security groups allow all traffic.

The route tables are missing routes to the peering connection.

Why wrong: Routes are present.

Associate VPC A's and VPC B's route tables with a different Transit Gateway route table that has a default route pointing to the VPC C attachment.

Why wrong: This would affect all traffic, not just between A and B.

Enable route propagation for VPC A and VPC B attachments in the same Transit Gateway route table.

Why wrong: Propagation would automatically add routes, potentially allowing direct communication.

Create a VPC peering connection between VPC A and VPC B.

Why wrong: VPC peering would allow direct connectivity, bypassing the NVA.

Deploy a NAT Gateway in each VPC to force symmetric traffic.

Why wrong: NAT Gateways do not control routing between VPCs and on-premises.

Create a Transit Gateway peering attachment between the two VPCs.

Why wrong: Peering attachments connect Transit Gateways, not VPCs directly, and do not resolve asymmetric routing.

Enable VPC Flow Logs to detect and alert on asymmetric flows.

Why wrong: Flow Logs are monitoring tools, not routing controls.

Check the Direct Connect virtual interface status.

Why wrong: Direct Connect is for on-premises connectivity, not VPC-to-VPC communication.

Verify that the NAT Gateway in each VPC is properly configured.

Why wrong: NAT Gateways are for outbound internet traffic, not VPC-to-VPC routing.

Provision one Direct Connect connection with a single private VIF, and enable BFD on the VIF to detect failures quickly.

Why wrong: A single VIF is a single point of failure; BFD only helps detect failures but does not provide redundancy.

Provision one Direct Connect connection with two private VIFs, and use a second Direct Connect connection as backup with a single VIF. Configure route tables to prefer the primary.

Why wrong: This design still has a single point of failure at the primary Direct Connect location and does not provide active-active load balancing.

Provision two Direct Connect connections, each with a single private VIF, and use AWS Site-to-Site VPN as a backup for each.

Why wrong: While having two connections is good, using a single VIF per connection does not leverage ECMP, and VPN backup may have slower failover.

Launch a NAT instance in a public subnet and assign an Elastic IP. Configure the private subnet route table to point to the NAT instance.

Why wrong: NAT instance is not highly available.

Create an internet gateway and attach it to the private subnet, then configure the route table.

Why wrong: Internet gateway cannot be attached to a private subnet.

Create a VPC endpoint for Amazon S3 and route software update traffic through that endpoint.

Why wrong: Does not provide internet access.

Create a NAT gateway in each Availability Zone and assign the same Elastic IP to both.

Why wrong: Cannot assign same EIP to multiple NAT gateways.

Enable VPC Flow Logs on all subnets and send logs to Amazon S3.

Why wrong: Flow Logs are for monitoring, not enforcement.

Attach an internet gateway to the VPC and add a default route to the internet gateway in the web tier subnet's route table.

Why wrong: This is needed for internet access but does not enforce tier-to-tier restrictions.

A VPN CloudHub topology

Why wrong: VPN CloudHub is for VPN-based connectivity.

A private virtual interface on the Direct Connect connection

Why wrong: Private VIF is for VPC connectivity, not public prefixes.

A transit virtual interface on the Direct Connect connection

Why wrong: Transit VIF is for transit gateway attachments.

NLB can forward traffic to third-party virtual appliances.

Why wrong: GWLB is specifically designed for that purpose, not NLB.

NLB can handle higher throughput than GWLB.

Why wrong: Both can handle high throughput; NLB is not necessarily higher.

NLB supports TLS termination, while GWLB does not.

Why wrong: Both support TLS termination.

Use security groups on VPC-C to deny traffic from VPC-A and VPC-B.

Why wrong: Security groups are stateful and do not control routing.

Establish VPC peering connections between VPC-C and VPC-A, and VPC-C and VPC-B.

Why wrong: Peering is not needed and adds complexity.

Apply a network ACL on VPC-C subnets to block traffic from VPC-A and VPC-B.

Why wrong: Network ACLs are stateless and not the best approach for routing isolation.

Set up a VPN connection over the Direct Connect link and attach the VPN to the Transit Gateway.

Why wrong: VPN is an alternative, not a direct integration.

Attach the existing private VIFs directly to the Transit Gateway.

Why wrong: VIFs cannot attach directly to Transit Gateway; a Direct Connect gateway is needed.

Create a new private VIF on the Direct Connect connection and attach it to the Transit Gateway.

Why wrong: New VIFs are not necessary; existing VIFs can be associated with a Direct Connect gateway.

Place the web servers and app servers in the same private subnet behind an internal Network Load Balancer. Route web traffic through the NLB.

Why wrong: Introduces an NLB as a single point of failure and unnecessary component; also web servers need public access.

Place the web servers in a public subnet with an Internet Gateway. Place the app servers in a private subnet with a NAT Gateway for outbound traffic. Use NACLs to allow inbound from the web subnet CIDR.

Why wrong: NAT Gateway is for outbound traffic only and does not allow inbound from web servers; NACLs are stateless and add complexity.

Place the web servers in a public subnet with a NACL allowing inbound on port 443. Place the app servers in a private subnet with a NACL allowing inbound from the web subnet CIDR on the application port.

Why wrong: NACLs are stateless and require separate inbound and outbound rules; also more complex to manage than security groups.

Create a single Transit Gateway that spans both Regions and attach VPCs in both Regions.

Why wrong: A Transit Gateway is regional and cannot span multiple Regions.

Use VPC peering between the VPCs and route Direct Connect traffic through the VPC peering connection.

Why wrong: VPC peering does not support transitive routing and does not integrate with Direct Connect gateway.

Associate the Direct Connect gateway with both Transit Gateways in us-east-1 and eu-west-1.

Why wrong: A Direct Connect gateway can be associated with only one Transit Gateway per Region, and cross-Region association is not supported.

Configure the ALB to use subnets that span multiple Availability Zones.

Why wrong: Subnets are specific to one AZ; ALB must have one subnet per AZ.

Use VPC peering to connect the ALB to subnets in other VPCs.

Why wrong: ALB is regional and does not use VPC peering.

The BGP session is not established.

Why wrong: If BGP were down, no routes would be exchanged.

The VPC route table does not have a route to the internet gateway for the on-premises traffic.

Why wrong: The default route to internet gateway exists but may not be used due to route preference.

The private VIF is associated with the wrong VLAN.

Why wrong: VLAN association would prevent connectivity entirely.

The VPC has a route that points to the transit gateway for the on-premises CIDR, causing asymmetric routing.

Why wrong: Asymmetric routing can cause issues, but the scenario describes traffic being dropped, not asymmetric routing.

The Direct Connect VIF is not configured with BFD.

Why wrong: BFD is for fast failure detection, not for routing traffic; lack of BFD would not cause drops.

The VPC route table does not have a route for the on-premises CIDR pointing to the transit gateway.

Why wrong: The VPC route table is for traffic leaving the VPC; the issue is with the transit gateway routing return traffic.