How should I use these VPC Endpoint practice questions?

Read each scenario carefully and choose your answer before revealing the explanation. Then check why your choice was right or wrong. Repeat until the reasoning feels automatic.

Can I practise just VPC Endpoint questions in a focused session?

Yes — use the session launcher on this page to start a 10-, 20-, 30- or 50-question session drawn entirely from the VPC Endpoint domain.

SAP-C02 · topic practice

VPC Endpoint practice questions

Practise AWS Certified Solutions Architect Professional SAP-C02 VPC Endpoint practice questions — original exam-style scenarios with answer choices, explanations, and analysis of common mistakes.

Courseiva uses original exam-style practice questions designed for learning and revision. The goal is to understand the concepts, recognise exam patterns, and improve through explanations — not memorise copied exam dumps.

Editorial oversight:Johnson Ajibi· MSc IT Security, IEEE Senior Member

8 questionsDomain: VPC Endpoint

Practice 10 questions Browse domain →

What the exam tests

What to know about VPC Endpoint

IPv6 questions usually test address types (link-local, global unicast, ULA), autoconfiguration (SLAAC), Neighbor Discovery Protocol and the differences from IPv4.

IPv6 address types and their scopes (link-local, global unicast, multicast, ULA).

SLAAC vs DHCPv6 vs stateful assignment.

Neighbor Discovery Protocol replacing ARP.

IPv6 routing differences and dual-stack coexistence.

Watch out for

Common VPC Endpoint exam traps

▸Link-local addresses are not routable beyond the local link.
▸SLAAC uses EUI-64 or random interface IDs — not a DHCP server.
▸NDP uses ICMPv6, not ARP.
▸An IPv6 prefix is /64 for most host subnets, not /24.

Practice set

VPC Endpoint questions

8 questions · select your answer, then reveal the explanation

Question 1mediummultiple choice

Review the full subnetting walkthrough →

A company runs a production AWS Lambda function that processes orders. Recently, the function has been timing out occasionally. The function uses a VPC with a single private subnet and has a timeout of 30 seconds. What is the MOST likely cause of the timeout?

Trap 1: The function is experiencing cold starts due to high concurrency.

Cold starts add latency at invocation, not the sustained 30-second timeouts described, and high concurrency does not itself cause them. It tempts because cold-start latency is a well-known Lambda performance issue, and would fit if the symptom were sporadic slow first invocations rather than timeouts.

Trap 2: The function is hitting the maximum concurrent execution limit.

Concurrency limits cause throttling with 429 TooManyRequestsException errors, not invocation timeouts, since Lambda rejects excess requests rather than letting them run. It tempts because concurrency is a common Lambda scaling concern, and would be correct if the symptom were throttled invocations under burst load.

Trap 3: The function needs to be attached to a public subnet.

Lambda functions in a VPC never require a public subnet; they need NAT or endpoints for outbound internet, and a public subnet does not fix timeouts. It tempts because public subnets are associated with internet reachability, and would be relevant if the function needed direct inbound internet access.

Study all VPC Endpoint common traps →

A
The function is experiencing cold starts due to high concurrency.
Why it fails: Cold starts add latency at invocation, not the sustained 30-second timeouts described, and high concurrency does not itself cause them. It tempts because cold-start latency is a well-known Lambda performance issue, and would fit if the symptom were sporadic slow first invocations rather than timeouts.
B
The function is hitting the maximum concurrent execution limit.
Why it fails: Concurrency limits cause throttling with 429 TooManyRequestsException errors, not invocation timeouts, since Lambda rejects excess requests rather than letting them run. It tempts because concurrency is a common Lambda scaling concern, and would be correct if the symptom were throttled invocations under burst load.
C
The function needs to be attached to a public subnet.
Why it fails: Lambda functions in a VPC never require a public subnet; they need NAT or endpoints for outbound internet, and a public subnet does not fix timeouts. It tempts because public subnets are associated with internet reachability, and would be relevant if the function needed direct inbound internet access.
D
The function does not have a NAT gateway or VPC endpoints to access external resources.
A Lambda function in a private subnet has no route to the internet without a NAT gateway, and no path to AWS services without VPC endpoints. Calls to external order-processing resources therefore hang until the 30-second timeout expires, producing the intermittent failures described.

Full breakdown with real-world context →

Question 2easymultiple choice

Read the full VPC Endpoint explanation →

A company is designing a new application that will process sensitive financial transactions. The application must be deployed in a VPC with no public internet access. The application needs to send logs to Amazon CloudWatch Logs and store files in Amazon S3. Which set of actions should be taken to meet these requirements without allowing internet access?

Trap 1: Place the application behind a public Application Load Balancer

A public Application Load Balancer requires internet-facing subnets and an internet gateway, which directly violates the no-public-internet-access requirement. Sending logs to CloudWatch Logs and storing objects in S3 from an isolated VPC is achieved with VPC endpoints (interface endpoints for CloudWatch Logs and a gateway endpoint for S3), keeping traffic on the AWS network.

Trap 2: Set up a NAT gateway in a public subnet and route traffic through it

A NAT gateway provides outbound internet access, which the scenario explicitly forbids; it also cannot reach CloudWatch Logs or S3 privately. NAT gateways suit private subnets needing software updates or public API calls, not fully isolated VPCs requiring VPC endpoints.

Trap 3: Use AWS PrivateLink to connect to CloudWatch Logs and S3

S3 gateway endpoints, not PrivateLink interface endpoints, are the mechanism for private S3 access from a VPC; PrivateLink does support S3 but requires interface endpoints with per-GB charges and does not cover all S3 features. PrivateLink is correct for privately reaching services lacking gateway endpoints, such as Kinesis or EC2 APIs.

Study all VPC Endpoint common traps →

A
Create a Gateway VPC endpoint for S3 and an Interface VPC endpoint for CloudWatch Logs
Gateway VPC endpoints route S3 traffic privately over the AWS network, while Interface VPC endpoints (powered by AWS PrivateLink) provide private connectivity to CloudWatch Logs. Together they satisfy the no-public-internet constraint for both logging and object storage.
B
Place the application behind a public Application Load Balancer
Why it fails: A public Application Load Balancer requires internet-facing subnets and an internet gateway, which directly violates the no-public-internet-access requirement. Sending logs to CloudWatch Logs and storing objects in S3 from an isolated VPC is achieved with VPC endpoints (interface endpoints for CloudWatch Logs and a gateway endpoint for S3), keeping traffic on the AWS network.
C
Set up a NAT gateway in a public subnet and route traffic through it
Why it fails: A NAT gateway provides outbound internet access, which the scenario explicitly forbids; it also cannot reach CloudWatch Logs or S3 privately. NAT gateways suit private subnets needing software updates or public API calls, not fully isolated VPCs requiring VPC endpoints.
D
Use AWS PrivateLink to connect to CloudWatch Logs and S3
Why it fails: S3 gateway endpoints, not PrivateLink interface endpoints, are the mechanism for private S3 access from a VPC; PrivateLink does support S3 but requires interface endpoints with per-GB charges and does not cover all S3 features. PrivateLink is correct for privately reaching services lacking gateway endpoints, such as Kinesis or EC2 APIs.

Full breakdown with real-world context →

Question 3hardmultiple choice

Review the full subnetting walkthrough →

A company is migrating a stateful firewall appliance to AWS. The appliance currently inspects traffic between multiple on-premises segments. In AWS, the company wants to deploy the appliance in a VPC to inspect traffic between subnets. Which architecture should the company use to ensure that the appliance can inspect all traffic?

Trap 1: Deploy the appliance behind an Application Load Balancer and…

An ALB operates at layer 7 and terminates connections, so it cannot transparently pass arbitrary IP traffic to a stateful firewall appliance for inspection. It is tempting because ALBs distribute HTTP/HTTPS workloads, which would suit a web-tier scenario rather than subnet-to-subnet inspection.

Trap 2: Deploy the appliance behind a Network Load Balancer and configure…

An NLB forwards traffic to registered targets but does not make the appliance an inline next hop; route tables pointing at an NLB endpoint are not supported for general subnet-to-subnet inspection. It is tempting because NLBs preserve source IPs for TCP/UDP load balancing.

Trap 3: Use VPC Gateway Endpoints to route traffic through the appliance.

Gateway endpoints only route traffic privately to Amazon S3 and DynamoDB, so they cannot carry general inter-subnet traffic through a firewall appliance. They are tempting because they avoid NAT and internet gateways for those specific AWS service destinations.

Study all VPC Endpoint common traps →

A
Deploy the appliance behind an Application Load Balancer and configure the VPC route tables.
Why it fails: An ALB operates at layer 7 and terminates connections, so it cannot transparently pass arbitrary IP traffic to a stateful firewall appliance for inspection. It is tempting because ALBs distribute HTTP/HTTPS workloads, which would suit a web-tier scenario rather than subnet-to-subnet inspection.
B
Deploy the appliance behind a Gateway Load Balancer in an inspection VPC and use a Transit Gateway to route traffic through it.
Gateway Load Balancer uses GENEVE encapsulation to transparently redirect traffic to third-party appliances, while Transit Gateway routes inter-subnet and inter-VPC traffic through the inspection VPC. This combination satisfies the requirement to inspect all traffic between subnets without altering routing on each workload.
C
Deploy the appliance behind a Network Load Balancer and configure the VPC route tables to send traffic to the NLB.
Why it fails: An NLB forwards traffic to registered targets but does not make the appliance an inline next hop; route tables pointing at an NLB endpoint are not supported for general subnet-to-subnet inspection. It is tempting because NLBs preserve source IPs for TCP/UDP load balancing.
D
Use VPC Gateway Endpoints to route traffic through the appliance.
Why it fails: Gateway endpoints only route traffic privately to Amazon S3 and DynamoDB, so they cannot carry general inter-subnet traffic through a firewall appliance. They are tempting because they avoid NAT and internet gateways for those specific AWS service destinations.

Full breakdown with real-world context →

Question 4mediummultiple choice

Read the full VPC Endpoint explanation →

A company is designing a new microservices application using Amazon ECS with Fargate. The services need to communicate securely within the VPC. Which approach should be used for service discovery?

Trap 1: Amazon Route 53 private hosted zones with health checks

Route 53 private hosted zones resolve DNS names, but ECS task IP addresses change on every deployment, and health checks alone do not register those ephemeral addresses. It suits static-record private DNS, not dynamic Fargate task registration, which AWS Cloud Map handles.

Trap 2: VPC peering connections between services

VPC peering links two VPC networks at the routing layer; it does not register or resolve individual ECS task endpoints, and all services here already share one VPC. It is tempting because peering enables private cross-VPC connectivity, which is its actual purpose.

Trap 3: Application Load Balancer with path-based routing

An ALB distributes HTTP traffic by path or host; it provides no registry mapping logical service names to task IP addresses, so Fargate tasks cannot resolve peers. It is tempting because ALBs do front microservices, but that is ingress load balancing, not service discovery.

Study all VPC Endpoint common traps →

A
Amazon Route 53 private hosted zones with health checks
Why it fails: Route 53 private hosted zones resolve DNS names, but ECS task IP addresses change on every deployment, and health checks alone do not register those ephemeral addresses. It suits static-record private DNS, not dynamic Fargate task registration, which AWS Cloud Map handles.
B
AWS Cloud Map
AWS Cloud Map provides service discovery with health-checked registration of ECS tasks, returning IP addresses and ports through DNS or API calls. This suits Fargate tasks, whose addresses change, and keeps service-to-service traffic inside the VPC.
C
VPC peering connections between services
Why it fails: VPC peering links two VPC networks at the routing layer; it does not register or resolve individual ECS task endpoints, and all services here already share one VPC. It is tempting because peering enables private cross-VPC connectivity, which is its actual purpose.
D
Application Load Balancer with path-based routing
Why it fails: An ALB distributes HTTP traffic by path or host; it provides no registry mapping logical service names to task IP addresses, so Fargate tasks cannot resolve peers. It is tempting because ALBs do front microservices, but that is ingress load balancing, not service discovery.

Full breakdown with real-world context →

Question 5mediummultiple choice

Read the full VPC Endpoint explanation →

A company runs a containerized application on Amazon ECS with Fargate. The application needs to access an Amazon S3 bucket that contains sensitive data. The security team requires that all traffic between the ECS tasks and S3 remain within the AWS network and not traverse the internet. What is the MOST secure way to meet this requirement?

Trap 1: Use an internet gateway and route traffic through a NAT gateway.

Traffic would still leave the AWS network via the internet gateway.

Trap 2: Enable S3 Transfer Acceleration on the bucket.

Transfer Acceleration uses the internet.

Trap 3: Use a NAT gateway and update the route table to direct S3 traffic…

NAT gateway is for outbound internet, not private access.

Study all VPC Endpoint common traps →

A
Use an internet gateway and route traffic through a NAT gateway.
Why it fails: Traffic would still leave the AWS network via the internet gateway.
B
Enable S3 Transfer Acceleration on the bucket.
Why it fails: Transfer Acceleration uses the internet.
C
Create a VPC endpoint for S3 and attach it to the VPC.
VPC endpoint enables private connectivity to S3 without internet.
D
Use a NAT gateway and update the route table to direct S3 traffic to the NAT.
Why it fails: NAT gateway is for outbound internet, not private access.

Full breakdown with real-world context →

Question 6hardmulti select

Read the full VPC Endpoint explanation →

A company is using AWS Organizations with a centralized networking account that hosts a transit gateway. The company wants to ensure that all traffic between VPCs in different accounts flows through the transit gateway. Which THREE steps are required to implement this architecture?

Trap 1: Create VPC endpoints for the transit gateway in each VPC.

VPC endpoints expose AWS services privately within a VPC; they cannot attach a VPC to a transit gateway. Endpoints are correct for private access to services such as S3, whereas transit gateway attachments and route table entries are needed here.

Trap 2: Create VPC peering connections between each VPC and the networking…

VPC peering creates direct one-to-one routes between VPC pairs, bypassing the transit gateway entirely, so inter-VPC traffic would not traverse it. Peering suits simple, low-count, same-Region connectivity where centralised inspection or hub-and-spoke routing is not required.

Study all VPC Endpoint common traps →

A
Attach the VPCs in member accounts to the transit gateway.
Transit gateway attachments are the prerequisite for any VPC to send traffic through it. Each member-account VPC must be attached, either directly or via shared attachment, before route tables can reference the gateway as a target for inter-VPC traffic.
B
Update the route tables of the VPCs to point to the transit gateway for inter-VPC traffic.
Attachments alone do not steer traffic; each VPC's route table must contain routes whose target is the transit gateway for the peer VPC CIDR ranges. Without these routes, inter-VPC packets follow local or peering paths instead of the gateway.
C
Create VPC endpoints for the transit gateway in each VPC.
Why it fails: VPC endpoints expose AWS services privately within a VPC; they cannot attach a VPC to a transit gateway. Endpoints are correct for private access to services such as S3, whereas transit gateway attachments and route table entries are needed here.
D
Create VPC peering connections between each VPC and the networking VPC.
Why it fails: VPC peering creates direct one-to-one routes between VPC pairs, bypassing the transit gateway entirely, so inter-VPC traffic would not traverse it. Peering suits simple, low-count, same-Region connectivity where centralised inspection or hub-and-spoke routing is not required.
E
Share the transit gateway with the member accounts using AWS Resource Access Manager.
AWS Resource Access Manager shares the transit gateway from the networking account into member accounts, letting them create attachments and reference the gateway in their route tables. This satisfies the cross-account ownership constraint without duplicating the gateway.

Full breakdown with real-world context →

Question 7mediummultiple choice

Read the full VPC Endpoint explanation →

A company is building a serverless data processing pipeline. Data is uploaded to an S3 bucket, which triggers a Lambda function to transform the data and store the result in another S3 bucket. The Lambda function needs to access a VPC-hosted database for enrichment. What is the MOST secure way to allow the Lambda function to access the VPC resources?

Trap 1: Assign a public IP to the Lambda function and route through an…

Lambda functions in a VPC cannot receive public IPs, and an Internet Gateway provides no path to private VPC database subnets. It is tempting as a familiar EC2 connectivity pattern, and would be correct for public-facing instances needing outbound internet access, not private database enrichment.

Trap 2: Use Lambda@Edge to process data at the edge location.

Lambda@Edge runs in CloudFront edge locations and cannot join a VPC, so it cannot reach the VPC-hosted database. It is tempting because it processes data close to viewers with low latency, and would be correct for request or response manipulation at the edge, not private VPC access.

Trap 3: Place the Lambda function in a public subnet and use a NAT Gateway.

A public subnet still routes egress through an internet gateway, so the function reaches the database over the public path rather than privately; the database would also need public exposure. NAT Gateways exist to give private-subnet resources outbound internet access, which is the scenario where this design is right.

Study all VPC Endpoint common traps →

A
Assign a public IP to the Lambda function and route through an Internet Gateway.
Why it fails: Lambda functions in a VPC cannot receive public IPs, and an Internet Gateway provides no path to private VPC database subnets. It is tempting as a familiar EC2 connectivity pattern, and would be correct for public-facing instances needing outbound internet access, not private database enrichment.
B
Configure the Lambda function to access the VPC and use a VPC endpoint for S3.
Attaching the Lambda function to private subnets lets it reach the VPC-hosted database, while a gateway VPC endpoint for S3 keeps traffic to the bucket on the AWS network, avoiding NAT gateways and internet exposure.
C
Use Lambda@Edge to process data at the edge location.
Why it fails: Lambda@Edge runs in CloudFront edge locations and cannot join a VPC, so it cannot reach the VPC-hosted database. It is tempting because it processes data close to viewers with low latency, and would be correct for request or response manipulation at the edge, not private VPC access.
D
Place the Lambda function in a public subnet and use a NAT Gateway.
Why it fails: A public subnet still routes egress through an internet gateway, so the function reaches the database over the public path rather than privately; the database would also need public exposure. NAT Gateways exist to give private-subnet resources outbound internet access, which is the scenario where this design is right.

Full breakdown with real-world context →

Question 8hardmulti select

Read the full DNS explanation →

A company is migrating to a multi-account AWS environment. They want to centralize DNS management using Amazon Route 53 private hosted zones. The private zones must be accessible from all VPCs in the organization. Which THREE steps are required to achieve this?

Trap 1: Create a public hosted zone with the same name and configure DNSSEC.

A public hosted zone resolves internet-facing names and DNSSEC signs public answers; neither makes a private zone reachable from other VPCs. It is tempting because DNSSEC and public zones are legitimate Route 53 features, but cross-VPC access requires associating the private hosted zone with each VPC.

Trap 2: Create a Route 53 Resolver outbound endpoint in each account.

An outbound endpoint forwards queries from your VPC to external DNS servers; it does not share a private hosted zone across accounts. It is tempting because Resolver endpoints are used for hybrid DNS, but the required step is associating the private hosted zone with the VPCs.

Study all VPC Endpoint common traps →

A
Create a private hosted zone in the central networking account.
A Route 53 private hosted zone must exist before any cross-account association can occur, so creating it in the central networking account establishes the single authoritative record container that member VPCs will later resolve against.
B
Share the private hosted zone with other accounts using AWS Resource Access Manager.
AWS RAM shares the private hosted zone with member accounts, granting them permission to associate it with their own VPCs. Without this share, association attempts from other accounts fail, since the zone belongs to the central networking account.
C
Create a public hosted zone with the same name and configure DNSSEC.
Why it fails: A public hosted zone resolves internet-facing names and DNSSEC signs public answers; neither makes a private zone reachable from other VPCs. It is tempting because DNSSEC and public zones are legitimate Route 53 features, but cross-VPC access requires associating the private hosted zone with each VPC.
D
Associate the private hosted zone with the VPCs in the member accounts.
Associating the private hosted zone with each member-account VPC is required because a Route 53 private hosted zone only resolves for VPCs explicitly associated with it, unless centralised through RAM or a shared-services hub. This satisfies the stem's constraint that the zone be accessible from all VPCs across the organisation.
E
Create a Route 53 Resolver outbound endpoint in each account.
Why it fails: An outbound endpoint forwards queries from your VPC to external DNS servers; it does not share a private hosted zone across accounts. It is tempting because Resolver endpoints are used for hybrid DNS, but the required step is associating the private hosted zone with the VPCs.

Full breakdown with real-world context →

Continue with 20-question session →

Free account

Track your progress over time

Create a free account to save your results and see which topics improve across sessions.

Focused VPC Endpoint sessions

Start a VPC Endpoint only practice session

Every question in these sessions is drawn from the VPC Endpoint domain — nothing else.

10 questions 20 questions 30 questions 50 questions

Browse all VPC Endpoint questions →Mixed SAP-C02 session

Frequently asked questions

What does the SAP-C02 exam test about VPC Endpoint?: IPv6 questions usually test address types (link-local, global unicast, ULA), autoconfiguration (SLAAC), Neighbor Discovery Protocol and the differences from IPv4.
How should I use these practice questions?: Select your answer before revealing the explanation. Then read why each option is right or wrong — this active recall approach builds retention far faster than re-reading notes.
Can I practise just VPC Endpoint questions in a focused session?: Yes — the session launcher on this page draws every question from the VPC Endpoint domain. Use a 10-question session first to gauge your baseline, then move to 20 or 30 once the weak spots are clear.
Where can I practise other SAP-C02 topics?: Use the topic links above to move to related areas, or go back to the SAP-C02 question bank to see all topics.
Are these real exam questions or dumps?: These are original practice questions written to test the same concepts the SAP-C02 exam covers. They are not copied from any real exam or dump site.

VPC Endpoint only

10 questions 20 questions 30 questions 50 questions

Mixed SAP-C02 session

Track your progress

A free account saves results across sessions and highlights which topics need work.

Study resources

All SAP-C02 questions VPC Endpoint domain overview SAP-C02 exam guide

Exam traps to avoid

▸Link-local addresses are not routable beyond the local link.
▸SLAAC uses EUI-64 or random interface IDs — not a DHCP server.
▸NDP uses ICMPv6, not ARP.
▸An IPv6 prefix is /64 for most host subnets, not /24.

VPC Endpoint practice questions

What to know about VPC Endpoint

Common VPC Endpoint exam traps

VPC Endpoint questions

A company runs a production AWS Lambda function that processes orders. Recently, the function has been timing out occasionally. The function uses a VPC with a single private subnet and has a timeout of 30 seconds. What is the MOST likely cause of the timeout?

A company is designing a new microservices application using Amazon ECS with Fargate. The services need to communicate securely within the VPC. Which approach should be used for service discovery?

A company is using AWS Organizations with a centralized networking account that hosts a transit gateway. The company wants to ensure that all traffic between VPCs in different accounts flows through the transit gateway. Which THREE steps are required to implement this architecture?

A company is migrating to a multi-account AWS environment. They want to centralize DNS management using Amazon Route 53 private hosted zones. The private zones must be accessible from all VPCs in the organization. Which THREE steps are required to achieve this?

Track your progress over time

Start a VPC Endpoint only practice session

Related SAP-C02 topic practice pages

Design for New Solutions practice questions

Design Solutions for Organizational Complexity practice questions

Accelerate Workload Migration and Modernization practice questions

Continuous Improvement for Existing Solutions practice questions

SAA-C03 VPC practice questions

SAA-C03 S3 lifecycle policy questions

SAA-C03 RDS Multi-AZ questions

SAA-C03 IAM policy practice questions

SAA-C03 Route 53 failover questions

SAA-C03 CloudFront practice questions

SAA-C03 NAT gateway questions

SAA-C03 VPC endpoint questions

Frequently asked questions

Track your progress

Study resources

Exam traps to avoid