VPC & Networking

Correct answer: B. No, a route to an internet gateway in the subnet's route table is required regardless of whether instances have public IPs

Having a public IP address alone does not grant internet access; AWS only routes traffic to the internet gateway (IGW) if the subnet's route table contains an explicit route sending 0.0.0.0/0 (or the relevant IPv6 range) to that IGW. Option A is wrong because address assignment is separate from routing. Option C is wrong because a NAT gateway elsewhere in the VPC has no effect on this subnet's own route table; NAT gateways serve only the subnets whose route tables point at them, and even then only for outbound traffic from private instances. Option D is wrong because subnets can absolutely contain instances with public IPs — that is exactly what defines a typical public subnet once paired with an IGW route. The defining feature of a public subnet is the IGW route, not the presence of public IPs on its instances.

Source: AWS VPC docs: Route tables — routing traffic to the internet

Correct answer: B. The response is automatically allowed because security groups are stateful and track connections

Security groups are stateful: once an inbound connection is permitted, the corresponding return traffic is automatically allowed regardless of outbound rules, so no outbound rule is needed for the reply to a permitted inbound request (this rules out A and D, which describe stateless firewall behavior, not security group behavior). Option C is a distractor that conflates two independent layers: even though the default NACL does happen to allow all traffic both ways, this question is specifically about the security group layer, which behaves statefully on its own regardless of what the NACL does. Network ACLs, by contrast, are stateless and would require explicit rules for both the request and the reply direction. Confusing these two mechanisms, and assuming security groups need matching outbound rules for return traffic, is one of the most commonly tested VPC misconceptions.

Source: AWS VPC docs: Security groups vs network ACLs comparison table

Correct answer: A. NAT gateways must be deployed in a public subnet that itself routes to an internet gateway

A NAT gateway needs its own path out to the internet, so it must be launched in a public subnet — one whose route table sends 0.0.0.0/0 to an internet gateway — and be assigned an Elastic IP. Placing it in a private subnet leaves the NAT gateway itself with no way to reach the internet, so nothing it forwards on behalf of private instances can get out either. Option B is wrong because NAT gateways translate IPv4 traffic; the IPv6 equivalent is an egress-only internet gateway, a different resource entirely. Option C is wrong because pointing the private subnet's route table directly at an internet gateway would require the instances to have public IPs, defeating the purpose of keeping them private. Option D is wrong because NAT gateways are fully AWS-managed and are not controlled by security groups; only the subnet's network ACL can restrict their traffic.

Source: AWS VPC docs: NAT gateways — how NAT gateways work

Correct answer: B. Associate an Elastic IP address with the instance before stopping it

Only an Elastic IP is a fixed, account-owned address that stays associated with an instance (or its network interface) across stop/start cycles until it is explicitly disassociated or released. The automatically assigned public IP in option A is released back to the AWS pool whenever the instance stops, and a new one is drawn on start, so it is not stable — that false assumption is the flaw in A. Option C is invalid because route tables direct traffic by destination CIDR at the VPC networking layer; they have no mechanism to reserve a public IP for a specific instance. Option D only controls whether a newly launched instance in that subnet receives an auto-assigned public IP at all, and that address remains just as ephemeral as in option A, so it does not solve the persistence problem the engineer needs solved.

Source: AWS EC2 docs: Elastic IP addresses

Correct answer: A. VPC peering connections are not transitive; A must be peered directly with C

VPC peering works strictly point-to-point: each connection only carries traffic between the two specific VPCs it links, and AWS does not route traffic across a chain of peering connections on your behalf. To let A reach C, the engineer must create a separate, direct peering connection between A and C, or replace the arrangement with a Transit Gateway, which does support transitive routing among its attachments. Option B is false; peering only requires non-overlapping CIDR blocks between the two peered VPCs, not identical ones — identical CIDRs would in fact make peering impossible to establish at all. Option C is invented; peering connections do not expire on any timer and remain active until deleted. Option D is wrong because NAT gateways translate addresses for internet-bound traffic and play no role whatsoever in routing between two peered VPCs.

Source: AWS VPC Peering docs: VPC peering connections — limitations (non-transitive)

Correct answer: B. Gateway endpoint, implemented as a target added to the route table, with no hourly charge

S3 and DynamoDB support gateway endpoints, which work by adding a special prefix-list target to the route table entries of the affected subnets; traffic destined for the service's IP ranges routes privately through this target rather than through a NAT gateway or internet gateway, and AWS does not charge an hourly fee for a gateway endpoint. Option A describes an interface endpoint, which does exist for many services and does use an ENI with a private IP, but it bills hourly plus per-GB and is not the mechanism used to keep S3 endpoint access free. Option C is wrong because S3 and DynamoDB specifically support the cheaper gateway model instead of requiring an interface endpoint. Option D is wrong because gateway endpoints work through route table entries, never through an attached Elastic IP, and they never expose any routable public address at all.

Source: AWS PrivateLink docs: Gateway VPC endpoints

Correct answer: B. The traffic is denied because NACL rules are evaluated in ascending numeric order and the first match applies

Network ACLs process their numbered rules in ascending order and stop at the first rule that matches the traffic; whatever that rule specifies, allow or deny, is final for that packet, and no later rule is ever consulted. Here rule #100 matches first because its CIDR includes the source address, so its deny takes effect immediately, and rule #200 is never reached even though it would otherwise authorize the traffic. Option A wrongly imagines a priority based on rule scope; NACLs have no such concept, since rule number order is what governs evaluation, not how broad or narrow a rule's CIDR happens to be. Option C is wrong because only one rule ever applies per packet; NACLs never merge the effects of multiple matching rules. Option D invents a specificity-based ordering that network ACLs simply do not use, unlike some other stateful firewall products.

Source: AWS VPC docs: Network ACLs — evaluating rules

Correct answer: B. X is a public subnet and Y is a private subnet

A subnet is classified as public specifically when its own route table sends internet-bound traffic directly to an internet gateway, which is true of subnet X. Subnet Y's traffic instead goes to a NAT gateway, so its instances get outbound-only internet access without needing, or being reachable at, a public IP; that behavior is what defines a private subnet. Option A collapses this distinction by treating "eventually reaches the internet" as equivalent to "public," which ignores that only inbound-reachable subnets with a direct IGW route count as public. Option C simply reverses the correct labels. Option D is wrong because subnet classification is a routing property, not a property of individual instances; an instance could have a public IP assigned in a subnet that still lacks an IGW route, and it still would not be reachable from the internet.

Source: AWS VPC docs: Subnet routing — public and private subnets

Correct answer: A. Attach all 12 VPCs and the VPN connection to a single Transit Gateway

A Transit Gateway acts as a regional routing hub: each VPC and the VPN attachment connects to it once, replacing the 66-connection full mesh with 13 simple attachments, and Transit Gateway natively supports transitive routing between attachments, which VPC peering never does. Option B looks similar but fails on transitivity: routing traffic through a central hub VPC via peering still would not let two spoke VPCs reach each other, because peering itself remains strictly point-to-point and non-transitive no matter what topology of peering connections is built around it. Option C is not achievable, since peering route table entries cannot be summarized away; each peering connection still needs its own explicit route per attached CIDR block, regardless of how the routes are organized. Option D is impractical and unrelated to the stated requirement, and it would also force resolving any overlapping CIDR ranges across the merged environment and rebuilding existing infrastructure from scratch.

Source: AWS Transit Gateway docs: How Transit Gateways work

Correct answer: A. Yes, because enabling private DNS makes the standard public hostname resolve to the endpoint's private IP addresses inside the VPC

When private DNS is enabled on an interface endpoint, AWS overrides resolution of the service's standard public regional DNS name within the VPC, using a private hosted zone, so that it resolves to the endpoint's private IP addresses instead of the public service IPs. Existing application code that already calls the standard hostname keeps working unmodified, while traffic now flows privately through the endpoint's elastic network interfaces instead of over the internet or a NAT gateway. Option B describes the fallback needed only when private DNS is disabled or unsupported for a given service, which is unnecessary here since private DNS is enabled and Kinesis supports it. Option C is false because DNS resolution and endpoint routing are independent of whether an internet gateway exists elsewhere in the VPC; the gateway's presence does not interfere with a private DNS override. Option D is incorrect because interface endpoints are addressed by hostname exactly like any other AWS service endpoint, not only by raw IP address.

Source: AWS PrivateLink docs: Interface VPC endpoints — private DNS names