VPC & Networking

Correct answer: .

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. The option claiming public IP addresses alone are enough is wrong because address assignment is separate from routing. The option requiring a NAT gateway somewhere in the VPC 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. The option asserting subnets can never have instances with public IPs 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: .

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 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: .

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 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 the option that relies on it never changing. Adding a static route for the instance's current public IP 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. Enabling "Auto-assign Public IP" on the subnet 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 any other auto-assigned public IP, so it does not solve the persistence problem the engineer needs solved.

Source: AWS EC2 docs: Elastic IP addresses

Correct answer: .

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. The option requiring identical CIDR blocks 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. The claim that peering connections expire after 24 hours is invented; peering connections do not expire on any timer and remain active until deleted. The option calling for a NAT gateway in VPC B 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: .

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. The option describing an ENI with a private IP refers to 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. The claim that an interface endpoint is required for all AWS services is wrong because S3 and DynamoDB specifically support the cheaper gateway model instead of requiring an interface endpoint. The option involving an attached Elastic IP 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: .

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. The option giving priority to the broader rule 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. The suggestion that both rules combine into a partial allow is wrong because only one rule ever applies per packet; NACLs never merge the effects of multiple matching rules. The claim that more specific CIDR ranges are always evaluated last 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: .

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. The option calling both subnets public 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. The option calling X private and Y public simply reverses the correct labels. The option tying classification to instance public IPs 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 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: .

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 D 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 A 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

Correct answer: .

AWS explicitly states that when managing IPv4 CIDR blocks for a VPC, 'you cannot increase or decrease the size of an existing CIDR block,' and a VPC's primary CIDR block additionally can never be disassociated at all — only secondary CIDR blocks can be added later or removed. If the engineer needs a different address range, the only supported path is associating a differently sized secondary CIDR block (subject to the /16-/28 sizing and non-overlap rules) rather than resizing the primary block. The option promising a direct resize with automatic subnet shrinking is wrong because no automatic subnet-shrinking mechanism exists — subnets are never resized by AWS in response to a CIDR change. The option requiring every subnet to be deleted first is wrong because emptying the VPC of subnets has no bearing on this restriction; the limitation is on the CIDR association itself, not on what is deployed inside it. The claim about an AWS Support resize once per calendar year invents a support-mediated annual resize process that does not exist anywhere in AWS documentation.

Source: AWS VPC docs: VPC CIDR blocks — Manage IPv4 CIDR blocks for a VPC

Correct answer: .

AWS documentation states plainly that 'when you associate a CIDR block with your VPC, a route is automatically added to your VPC route tables to enable routing within the VPC (the destination is the CIDR block and the target is local),' so intra-VPC routing to the new range works immediately without manual route entries. Option D is wrong because it contradicts this automatic behavior. Option B is wrong because NAT gateways translate addresses only for internet-bound traffic leaving the VPC; they play no role in routing between two CIDR ranges that already belong to the same VPC, and none is created automatically. Option C is wrong because the two CIDR blocks remain two separate, independently associated and disassociated ranges — AWS tracks and can later disassociate the secondary block on its own, which would be impossible if it had been merged into one supernet with the primary.

Source: AWS VPC docs: VPC CIDR blocks — Manage IPv4 CIDR blocks for a VPC

Correct answer: .

AWS provisions a default VPC per Region with a public subnet already created in each Availability Zone, an internet gateway already attached and routed from those subnets, and DNS resolution already enabled; default subnets also auto-assign a public IPv4 address to any instance launched into them, so no manual networking setup is required to get a reachable instance. The claim that the default VPC has no subnets at all is wrong because a default VPC is pre-populated with default subnets, not empty. The option describing a pre-configured NAT gateway in every subnet is wrong because no NAT gateway is created by default — the internet gateway route, not NAT, is what makes the public subnets reachable. The claim that default VPCs disable security groups is wrong because security groups are never disabled; the instance still gets a default security group, which allows all outbound traffic and inbound traffic only from other resources in the same security group, so any additional inbound access still has to be explicitly authorized.

Source: AWS VPC docs: Default VPCs

Correct answer: .

enableDnsSupport controls whether the Amazon-provided DNS resolver answers queries at all — since it's true here, general DNS resolution (including public internet hostnames) keeps working. enableDnsHostnames separately controls whether instances with public IP addresses are assigned a public DNS hostname; per AWS's own rules, 'if at least one of the attributes is set to false,' instances with public IPs do not receive public DNS hostnames and the resolver cannot resolve Amazon-provided private DNS hostnames either, even though it otherwise works fine. The claim that the instance cannot resolve any DNS names at all is wrong because it conflates the hostname-assignment attribute with resolver availability, which enableDnsSupport alone governs. The option saying a public DNS hostname is assigned while all resolver queries fail reverses the actual effect of the two attributes. The idea that AWS rejects the combination is wrong because the two attributes are independently toggleable settings with no such enforced-equality validation.

Source: AWS VPC docs: Understanding Amazon DNS — DNS attributes for your VPC

Correct answer: .

VPC Flow Logs support ACCEPT, REJECT, or ALL as a traffic filter at creation time, and rejected-only capture is explicitly called out as useful for 'diagnosing overly restrictive security group rules.' Flow log data can be published to Amazon CloudWatch Logs, Amazon S3, or Amazon Data Firehose, and AWS documents querying flow logs stored in S3 using Amazon Athena, so REJECT-filtered logs delivered to S3 satisfy both requirements. Option D is wrong on two counts: ACCEPT captures the opposite traffic than requested, and while CloudWatch Logs is a valid destination, it isn't the one AWS pairs with Athena querying. Option A is wrong because REJECT-only filtering is a first-class, documented flow log option, not something requiring extra tooling. Option B is wrong because Athena querying against flow logs delivered to S3 is a documented, supported workflow, not a console-only limitation.

Source: AWS VPC docs: Logging IP traffic using VPC Flow Logs

Correct answer: .

AWS's own NAT gateway vs. NAT instance comparison table explicitly marks 'Bastion servers' and 'Port forwarding' as 'Not supported' for NAT gateways, while both are available on NAT instances (port forwarding via manual configuration, bastion usage because it's just a regular EC2 instance you can SSH into and configure freely). So migrating away from a NAT instance to a NAT gateway would lose both capabilities, requiring a separate dedicated instance for bastion access and any custom forwarding rules. The option treating a NAT gateway as a managed NAT instance with identical features incorrectly assumes feature parity; NAT gateways trade away instance-level flexibility for AWS-managed high availability and scale. The two options claiming NAT gateways keep one capability but not the other each get half the comparison backwards — both listed capabilities are unsupported on NAT gateways, not just one of them.

Source: AWS VPC docs: Compare NAT gateways and NAT instances

Correct answer: .

When a VPC requests an Amazon-provided IPv6 CIDR block, AWS documentation gives the example of Amazon assigning a /56 block such as 2001:db8:1234:1a00::/56 and states directly, 'You cannot choose the range of IP addresses yourself' — the customer only chooses to request an Amazon-provided block, not which specific addresses it contains. Option A is wrong because self-selection of the specific range is exactly what AWS says is not possible with Amazon-provided blocks; choosing your own range requires bringing your own IPv6 range (BYOIP) instead. Option C is wrong because Amazon-provided IPv6 allocation has no prerequisite tied to owning a public IPv4 range. Option D is wrong because IPv6 CIDR blocks, like additional IPv4 CIDR blocks, can be associated with an existing VPC after creation, not only at creation time.

Source: AWS VPC docs: IP addressing for your VPCs and subnets — VPC CIDR blocks

Correct answer: .

AWS explicitly supports cross-VPC security group referencing for inbound rules 'if... there is a peering connection between the VPCs that the security groups are associated with' (also via a shared transit gateway), so this rule is valid and lets sg-app's instances reach sg-db's instances on 5432 using their private IPs; AWS also states 'no rules from the referenced security group are added to the security group that references it,' so sg-app's own rule set is not imported. Option B is wrong because same-VPC is only one of three documented conditions that make a reference valid — an active peering connection is another. Option C is wrong because security-group referencing is resolved by private IP addresses of the referenced group's instances automatically; manually enumerating public IPs isn't how the feature works and would defeat its purpose. Option D is wrong because referencing a security group in one rule creates only that one-directional permission; it neither reciprocates access in the opposite direction nor imports any rules from the referenced group.

Source: AWS VPC docs: Security group rules — Security group referencing

Correct answer: .

When a destination address matches more than one route in a route table, AWS VPC routing always selects the route with the longest (most specific) matching prefix, independent of when each route was added or what type of target it points to; 10.0.1.150 falls inside all three CIDR ranges given, but 10.0.1.128/25 is the narrowest match, so that 'local' route wins. The creation-order answer is wrong because route selection is based purely on prefix specificity, not insertion order — AWS does not track or use a creation-order priority at all. The idea that all three routes are used simultaneously is wrong because exactly one route is ever chosen per packet; VPC route tables do not support splitting or load-balancing traffic across multiple simultaneously matching routes. The claim that NAT gateway targets take precedence is wrong because there is no target-type-based precedence in VPC routing; a /24 pointing at a NAT gateway never outranks a more specific /25 local route just because of what its target is.

Source: AWS VPC docs: Route tables — route selection

Correct answer: .

AWS's own guidance states NAT gateways in each Availability Zone are implemented with redundancy, but recommends you 'create a NAT gateway in each Availability Zone to ensure zone-independent architecture' — a single NAT gateway is redundant only within its own AZ, not across AZs, so relying on one NAT gateway for a multi-AZ VPC creates a single point of failure and also routes cross-AZ traffic that incurs inter-AZ data transfer charges. The claim that nothing needs to change is wrong because AWS does not automatically stretch a single NAT gateway's availability across multiple AZs — it explicitly lives in one AZ's subnet. The option recommending a NAT instance is wrong because NAT instances require the customer to script their own failover and are generally less available than NAT gateways, not more. The option adding a second Elastic IP is wrong because a NAT gateway supports only a fixed set of Elastic IPs for its own outbound traffic and has no mechanism to 'serve' a second Availability Zone by adding an address.

Source: AWS VPC docs: Compare NAT gateways and NAT instances — Availability

Correct answer: .

AWS documents the egress-only internet gateway as 'for use with IPv6 traffic only,' explicitly stateful ('it forwards traffic from the instances in the subnet to the internet or other AWS services, and then sends the response back to the instances'), and notes 'you can't associate a security group with an egress-only internet gateway,' though a network ACL on the subnet can still control its traffic. Because IPv6 addresses are globally routable by default, this component lets instances reach out over IPv6 without becoming reachable from unsolicited inbound connections. Option A is wrong because NAT gateways handle IPv4 translation; the IPv6 outbound-only equivalent is specifically the egress-only internet gateway, a separate resource. Option C is wrong because a standard internet gateway is bidirectional for any address it routes and has no such built-in IPv6-outbound-only restriction. Option D is wrong on the statefulness: the egress-only internet gateway is stateful, so no matching inbound rule is required for return traffic, unlike a stateless device such as a network ACL.

Source: AWS VPC docs: Enable outbound IPv6 traffic using an egress-only internet gateway

Correct answer: .

AWS states directly that 'an endpoint policy does not override or replace identity-based policies or resource-based policies' — it's an additional, independent authorization layer attached to the endpoint itself, alongside identity-based IAM policies and any resource policies (like an S3 bucket policy). Standard IAM evaluation logic still applies across all applicable policies: an explicit deny in any evaluated policy, including an identity-based one, blocks the action even if every other applicable policy would allow it. The option claiming the endpoint policy always overrides the other policy types inverts this relationship; the endpoint policy is not a trump card over other policy types. The claim that endpoint policies only apply to gateway endpoints is wrong because endpoint policies apply to both interface and gateway endpoints, just with slightly different principal-specification rules (gateway endpoints require the Principal element to be '*' and use a condition key instead). The deny-all-by-default option is wrong because AWS attaches a default endpoint policy that grants full access if you don't provide a custom one, rather than denying everything.

Source: AWS PrivateLink docs: Control access to VPC endpoints using endpoint policies

Correct answer: .

Unlike VPC and VPN attachments to a transit gateway, peering attachments between transit gateways do not support automatic route propagation; AWS documentation is explicit that to route traffic between peered transit gateways, you must add a static route to the transit gateway route table that points to the peering attachment, and this route table must then be associated with the peering attachment. Skipping this manual step is the most common reason two peered transit gateways still cannot pass traffic even after acceptance succeeds. The option expecting automatic route propagation is wrong because it assumes the very propagation behavior AWS documentation says is unsupported for this attachment type. The option requiring identical CIDR blocks is wrong; while overlapping CIDRs would break routing (as with any routed connection), the two VPCs are not required to have identical ranges — quite the opposite, identical ranges would make routing between them impossible. The IPv6-only claim is wrong because transit gateway peering explicitly supports routing both IPv4 and IPv6 traffic between the peered gateways, not IPv6 exclusively.

Source: AWS Transit Gateway docs: Transit gateway peering attachments

Correct answer: .

AWS PrivateLink lets a provider create a VPC endpoint service fronted by a Network Load Balancer, then grant specific AWS principals — including other accounts — permission to connect via an interface VPC endpoint; the consumer only gets access to the specific service exposed through that load balancer, not general L3 reachability into the provider's VPC, and because traffic is proxied through elastic network interfaces rather than routed at the CIDR level, the two VPCs never need non-overlapping or coordinated address ranges. The VPC peering option is wrong because peering grants broad network-level reachability between the peered CIDR ranges (subject to route tables and security groups), which is exactly the exposure the company wants to avoid, and it also requires non-overlapping CIDRs, unlike PrivateLink. The Transit Gateway option is wrong because Transit Gateway is a separate routing hub service and is not a prerequisite for AWS PrivateLink endpoint services, which work standalone across accounts. The gateway endpoint option is wrong because gateway endpoints exist only for a small set of AWS-managed services like S3 and DynamoDB and cannot be used to expose a customer's own custom application; that provider-side capability is specifically what endpoint services (interface endpoints) enable.

Source: AWS PrivateLink docs: Share your services through AWS PrivateLink

Correct answer: .

A VPC can have at most one internet gateway attached at a time; to attach a different one, the existing internet gateway must first be detached. This isn't a redundancy gap, because an internet gateway is itself a horizontally scaled, redundant AWS-managed component that spans the Region rather than living in a single device or Availability Zone, so it needs no second instance for high availability. The load-balancing option is wrong because there is no mechanism for splitting traffic across two internet gateways on one VPC — the attach operation itself is rejected while an internet gateway is already attached. The 'only one active in route tables' option is wrong for the same reason: the second internet gateway is never actually attached, so there's nothing to select between in a route table. The Availability-Zone option is wrong because internet gateways are not zonal resources at all; they operate at the VPC level across every Availability Zone the VPC uses, so creating one in a 'different Availability Zone' isn't a meaningful distinction that changes the one-per-VPC rule.

Source: AWS VPC User Guide: Internet gateways — 'A VPC can have only one internet gateway attached at a time.'

Correct answer: .

By default, every AWS account has a quota of five Elastic IP addresses per Region, because public IPv4 addresses are a scarce shared resource; that quota is enforced at the account-and-Region level regardless of what the address will be used for, so the sixth allocation attempt is rejected until the account requests and receives a quota increase from the Service Quotas console. The per-Availability-Zone option is wrong because Elastic IP quotas are tracked per Region, not per Availability Zone, and the intended purpose of the address (NAT gateway versus EC2 instance) doesn't change which pool it draws from. The 'exempt for NAT gateways' option is wrong for the same reason: a NAT gateway's Elastic IP address counts against the exact same account-and-Region quota as any other Elastic IP address. The 'hard limit' option is wrong because this quota, unlike some AWS limits, is explicitly adjustable — the account can request and be granted a higher quota rather than being permanently capped at five.

Source: AWS documentation and AWS re:Post: default Elastic IP address quota is 5 per Region for EC2-VPC, adjustable via a Service Quotas increase request

Correct answer: .

In every AWS subnet CIDR block, the first four addresses and the last address are reserved and cannot be assigned to a resource: the very first address is the network address, the next is reserved for the VPC router, the next is reserved for the Amazon-provided DNS server, the next is reserved by AWS for future use, and the last address is reserved as the network broadcast address (even though VPCs don't support broadcast traffic). For a /27 block, which contains 32 total addresses, subtracting those five reserved addresses leaves 27 usable addresses. The '32, no reservations' option is wrong because AWS explicitly documents these five reserved addresses for every subnet regardless of size. The '30, only network and broadcast reserved' option is wrong because it ignores the three additional AWS-specific reservations (VPC router, DNS, and future use) beyond the traditional two. The '24, eight reserved' option is wrong because it overstates the reservation; AWS reserves exactly five addresses per subnet, not eight, regardless of the subnet's size.

Source: AWS VPC User Guide: Subnet sizing for IPv4 — 'The first four IP addresses and the last IP address in each subnet CIDR block are not available for your use.'

Correct answer: .

An elastic network interface belongs to the Availability Zone it was created in and can only be attached to EC2 instances that also live in that same Availability Zone; its attributes, including its private IP address, follow it as it is detached and reattached, which is exactly what lets this failover pattern preserve the appliance's address on the standby instance. The 'same VPC, any AZ' option is wrong because AZ-scoping, not VPC-scoping, is the binding constraint — a network interface cannot be attached to an instance in a different AZ even within the same VPC. The 'same AZ and account, any VPC' option is wrong because a network interface is also tied to the subnet and VPC it was created in, not just an Availability Zone. The 'primary interface only' option is wrong because it inverts the real restriction: a primary network interface can never be detached from its instance at all, so this kind of detach-and-reattach failover is only possible with a secondary network interface, not the primary one.

Source: AWS EC2 User Guide: Elastic network interfaces — 'You can create and configure network interfaces and attach them to instances that you launch in the same Availability Zone' and 'You can't detach a primary network interface from an instance.'

Correct answer: .

Each IP address on a NAT gateway supports up to 55,000 simultaneous connections to a given unique destination, where 'unique destination' means a specific combination of destination IP address, destination port, and protocol; when traffic to one busy destination saturates that ceiling on the gateway's single IP address, AWS supports associating additional secondary IP addresses with the same NAT gateway, and each added address contributes its own 55,000-connection allowance to that destination, directly raising the ceiling without touching subnets or route tables. The instance-type option is wrong because a NAT gateway is a fully managed AWS service, not a customer-managed EC2 instance with a selectable instance type, so there is no instance-type lever to pull. The Flow Logs option is wrong because Flow Logs are a monitoring and diagnostic feature; enabling them only records traffic metadata and has no effect on any connection ceiling. The internet-gateway option is wrong because it would require giving the private subnet's instances public IP addresses and abandon the NAT model entirely, which is not a targeted fix for a per-destination connection ceiling and defeats the purpose of keeping the subnet private.

Source: AWS What's New (Feb 2023): 'Amazon increases NAT Gateway's capacity to support concurrent connections to a unique destination' — up to 55,000 concurrent connections per IP address per unique destination, extendable via additional secondary IP addresses

Correct answer: .

AWS explicitly documents that you cannot reference the security group of a peer VPC that's in a different Region; for cross-Region VPC peering connections, the workaround is to use the peer VPC's CIDR block as the rule's source or destination instead of a security group ID. This is a real, exam-relevant gap between same-Region and cross-Region peering behavior. The 'works identically' option is wrong because it ignores this documented limitation — same-Region peering does support security group referencing, but cross-Region peering does not, so the two cases are not identical. The 'outbound only' option is wrong because the limitation has nothing to do with rule direction; same-Region peering supports security group referencing for both inbound and outbound rules, and the cross-Region restriction likewise applies to both directions, not selectively to inbound rules. The 'peering doesn't support different Regions at all' option is wrong because inter-Region VPC peering is a fully supported AWS feature for routing traffic between VPCs in different Regions — the restriction is specifically on security-group-ID referencing, not on the peering connection's ability to exist or carry traffic.

Source: AWS VPC Peering Guide: 'Update your security groups to reference peer security groups' — 'You can't reference the security group of a peer VPC that's in a different Region. Instead, use the CIDR block of the peer VPC.'

Correct answer: .

A VPC peering connection has its own DNS settings, separate from the VPCs' own enableDnsSupport/enableDnsHostnames attributes: by default, DNS resolution for the peering connection is disabled, so a public IPv4 DNS hostname resolves to the public IPv4 address even for a request crossing the peering connection; once DNS resolution is enabled, the same public hostname instead resolves to the private IPv4 address, keeping traffic off the internet. Enabling it requires both sides to act — the requester VPC owner enables it for the requester side and the accepter VPC owner enables it for the accepter side (or both at once if the same account owns both). The 'nothing further is possible' option is wrong because AWS documents exactly this peering-connection DNS resolution setting as the mechanism to change the behavior. The Route 53 private-hosted-zone option is wrong because it's a heavier, redundant workaround that duplicates records manually instead of using the built-in per-peering-connection setting AWS already provides for this exact scenario. The 'disable enableDnsHostnames' option is wrong because that VPC-level attribute controls whether instances receive DNS hostnames at all, not how those hostnames resolve across a peering connection, and disabling it would break hostname assignment rather than fix cross-peering resolution.

Source: AWS VPC Peering Guide: 'Enable DNS resolution for a VPC peering connection' — DNS resolution disabled (default) resolves the public hostname to the public IP; enabled resolves it to the private IP, requiring the requester and accepter VPC owners to each modify their side's peering options.

Correct answer: .

Gateway VPC endpoints are a distinct mechanism from AWS PrivateLink interface endpoints — they don't use AWS PrivateLink at all — and AWS documents that they are supported only for Amazon S3 and Amazon DynamoDB, with no additional hourly charge for the endpoint itself. Every other AWS service that offers private VPC connectivity does so through an interface endpoint (which does use AWS PrivateLink and does carry an hourly charge), not a gateway endpoint. The 'any service with an interface endpoint' option is wrong because it conflates the two endpoint types, which differ in mechanism, pricing, and the specific services they support. The 'S3 only, DynamoDB needs PrivateLink' option is wrong because DynamoDB is one of the two services that specifically supports a gateway endpoint, and it is gateway endpoints, not DynamoDB, that don't use PrivateLink. The 'any regional service over HTTPS' option is wrong because gateway endpoints don't work generically for arbitrary services; they rely on a route added for an AWS-managed prefix list that exists only for the two supported services.

Source: AWS PrivateLink Guide: Gateway endpoints — 'Gateway VPC endpoints provide reliable connectivity to Amazon S3 and DynamoDB... Gateway endpoints do not use AWS PrivateLink... There is no additional charge for using gateway endpoints.'

Correct answer: .

When you create a gateway endpoint, AWS only adds the routing entry (destination is the service's prefix list, target is the endpoint) to the specific route tables you selected for that endpoint; a route table you didn't select never receives this route, so any subnet using that unselected route table still sends S3-bound traffic to whatever other route (or no route) it already had, and never reaches the endpoint. Selecting the correct route table for the subnet is therefore the fix. The security group option is wrong because gateway endpoints don't have their own private IP address or elastic network interface the way interface endpoints do — traffic still uses the service's public endpoint address space, so there is no endpoint-side network interface for a security group to filter. The Elastic IP option is wrong for the same structural reason: a gateway endpoint isn't reachable via any IP address of its own at all; it works purely through the route table entry. The enableDnsHostnames option is wrong because that attribute affects DNS hostname assignment for instances, not whether a gateway endpoint's routing takes effect.

Source: AWS PrivateLink Guide: Gateway endpoints — 'When you create a gateway endpoint, you select the VPC route tables for the subnets that you enable... All instances in the subnets associated with a route table associated with a gateway endpoint automatically use the gateway endpoint.'

Correct answer: .

Association and propagation are two distinct, separately-configured relationships in Transit Gateway routing: each attachment can be associated with only one TGW route table at a time, and that association determines which route table's routes govern traffic sent from that attachment, so attachment A is limited to RT1's routes. Propagation is different and many-to-many: an attachment's routes can be propagated into multiple TGW route tables so that other attachments associated with those tables can learn and use them, which is exactly why attachment B's routes can appear in both RT1 and RT2 even though B itself is associated with only one route table. The 'A can be associated with RT2 too' option is wrong because association is strictly one route table per attachment; a second simultaneous association isn't possible. The 'propagation and association are the same action' option is wrong because they are configured and behave independently — an attachment can propagate into a route table it isn't associated with, and vice versa. The 'C needs its own propagation to receive B's routes' option is wrong because receiving propagated routes depends on which route table an attachment is associated with (C is associated with RT2, which already received B's propagated routes), not on whether the receiving attachment itself propagates anything.

Source: AWS Transit Gateway Guide: Transit gateway route tables — 'Transit gateway route tables allows you to associate a table with a transit gateway attachment... An attachment can be propagated to multiple route tables'; each attachment is associated with exactly one route table.

Correct answer: .

AWS documents plainly that Direct Connect does not encrypt traffic in transit by default. To add encryption, a company can combine Direct Connect with an AWS Site-to-Site VPN, layering an IPsec-encrypted VPN connection on top of the private Direct Connect link, or use a Direct Connect connection at a location that supports MACsec, an IEEE standard providing encryption from the customer's router to the Direct Connect location. The 'automatically encrypted at the physical layer' option is wrong because it directly contradicts AWS's documented default behavior. The 'yes, if private virtual interface' option is wrong because the choice between a private and public virtual interface affects what the connection can route to (VPCs versus public AWS service endpoints), not whether the underlying transport is encrypted; neither type is encrypted by default. The 'no supported way to encrypt' option is wrong because it ignores the two AWS-documented options — VPN over Direct Connect and MACsec — that exist specifically to add encryption to a Direct Connect connection.

Source: AWS Direct Connect User Guide: Encryption in AWS Direct Connect — 'AWS Direct Connect does not encrypt your traffic that is in transit by default,' with VPN-over-Direct-Connect and MACsec as the supported encryption options.

Correct answer: .

A Direct Connect gateway is a globally available resource, acting as a distributed set of BGP route reflectors, that can be associated with virtual private gateways (or Transit Gateways) belonging to VPCs in different Regions; this lets a single Direct Connect connection, via one private or transit virtual interface into the Direct Connect gateway, reach VPCs across multiple Regions instead of being confined to the Region where the connection physically terminates. The 'second Direct Connect connection' option is wrong because it describes exactly the costly, connection-per-Region approach that a Direct Connect gateway is designed to eliminate. The 'Transit Gateway peering with no Direct Connect involvement' option is wrong because Transit Gateway peering only connects Transit Gateways to each other; it does nothing to extend an on-premises Direct Connect connection's reach into a second Region's VPCs without a Direct Connect gateway (or a separate Direct Connect connection) in the picture. The 'VPC peering on top of Direct Connect' option is wrong because VPC peering connects VPCs to each other directly and has no role in extending an on-premises Direct Connect connection to a Region it doesn't already terminate in.

Source: AWS Direct Connect User Guide: Direct Connect gateways — 'A Direct Connect gateway is a globally available resource... enables you to use your Direct Connect connection... to access VPCs in your account in both [Region]... and [Region]...'

Correct answer: .

AWS Global Accelerator provides an application with a small, fixed set of static anycast IP addresses that clients connect to directly; because clients target these unchanging IP addresses rather than a hostname whose DNS record has to be re-resolved, Global Accelerator can continuously health-check the regional endpoints and redirect traffic at the network routing layer, giving failover in seconds without ever requiring a client or resolver to notice a DNS change. The Route 53 option is wrong because DNS-based failover fundamentally depends on resolvers eventually re-querying and respecting the record's TTL, and real-world resolver and client-side caching frequently ignores or overshoots configured TTLs, which is precisely the delay Global Accelerator is designed to avoid. The 'rewrites TTL to zero' option is wrong because Global Accelerator's failover mechanism isn't a DNS trick at all; it works by routing already-established anycast IP traffic to a different backend, with no DNS response or TTL involved. The CloudFront option is wrong because CloudFront is a content delivery network for caching and accelerating content delivery from origins, not a mechanism for sub-DNS-TTL regional failover of an application's compute endpoints.

Source: AWS Global Accelerator Developer Guide: How AWS Global Accelerator works — static anycast IP addresses as fixed entry points, continuous health checks, and instant redirection to healthy endpoints without DNS involvement.

Correct answer: .

If you don't attach a policy when you create an interface VPC endpoint, AWS attaches a default endpoint policy for you that allows full access: all principals can perform all actions on the service through that endpoint, the same as if the traffic weren't going through a VPC endpoint at all, and this is still subject to whatever other IAM identity-based or resource-based policies would otherwise apply, since an endpoint policy works alongside those rather than replacing them. The 'implicit deny-all' option is wrong because it describes the opposite of AWS's documented default; a brand-new endpoint with no custom policy is maximally permissive, not locked down. The 'limited to the VPC's own account' option is wrong because the default full-access policy doesn't restrict by account at all — cross-account access is governed by whatever IAM or resource policies would already apply, not by an account-scoping rule baked into the endpoint's default policy. The 'read-only until write is granted' option is wrong because the default policy makes no distinction between read and write actions; it permits every action by default until a custom policy is written to narrow it.

Source: AWS PrivateLink Guide: Control access to VPC endpoints using endpoint policies — 'If you don't attach an endpoint policy... we attach the default endpoint policy... to allow full access to the service.'