Courseiva
Design Secure ArchitecturesmediumMultiple ChoiceObjective-mapped

SAA-C03 Design Secure Architectures Practice Question

A company hosts an internal HTTP API on an internal Network Load Balancer (NLB) in VPC A. A partner team in a separate AWS account needs access, but their VPC CIDR overlaps with VPC A, so VPC peering is not feasible.

Security requirements state the API must remain non-public (no internet-facing ALB/NLB) and access must use AWS private networking.

Which architecture best meets these requirements?

⚠ Common exam trap

Candidates often think VPC peering is always the simplest solution, but they overlook the CIDR overlap restriction, or they assume a NAT gateway can provide inbound private connectivity, which it cannot.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

Use AWS PrivateLink by creating a VPC endpoint service backed by the NLB in VPC A, then create an interface VPC endpoint in the partner VPC with appropriate endpoint access controls.

AWS PrivateLink allows you to expose an internal NLB as a VPC endpoint service in VPC A, and the partner team can create an interface VPC endpoint in their own VPC to connect privately. This works even with overlapping CIDR blocks because PrivateLink uses ENIs with private IPs from the endpoint subnet, not routing based on CIDR. The traffic stays within the AWS network and never traverses the internet, meeting the non-public requirement.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • Use AWS PrivateLink by creating a VPC endpoint service backed by the NLB in VPC A, then create an interface VPC endpoint in the partner VPC with appropriate endpoint access controls.

    Why this is correct

    AWS PrivateLink establishes private, secure connectivity between VPCs without requiring VPC peering, VPN connections, or exposing services to the public internet. By creating a VPC endpoint service backed by the internal Network Load Balancer in VPC A, the internal HTTP API becomes available to the partner VPC via an interface VPC endpoint. This solution inherently avoids CIDR overlap issues and provides granular access control through endpoint policies and service permissions, ensuring the NLB remains non-public.

  • Expose the NLB to the internet with an Elastic IP and restrict access using the NLB’s security group only.

    Why it's wrong here

    Exposing the internal Network Load Balancer to the internet with an Elastic IP immediately violates the requirement for an 'internal' HTTP API, regardless of security group restrictions. While security groups can filter source IP addresses, the service's public exposure inherently increases its attack surface and introduces unnecessary risk. This approach fundamentally contradicts the need for a non-public, internal service and is not a secure method for partner integration.

  • Use VPC peering between VPC A and the partner VPC and update route tables to resolve the overlap.

    Why it's wrong here

    VPC peering fundamentally requires non-overlapping CIDR blocks between the peered VPCs to establish proper routing and avoid IP address conflicts. Attempting to update route tables to 'resolve' an overlap is not feasible, as the underlying network architecture cannot distinguish between identical IP addresses in different VPCs. This method would lead to routing failures and is an architectural limitation that VPC peering cannot overcome.

  • Deploy a NAT gateway in VPC A and route the partner’s traffic to the NLB through the NAT gateway.

    Why it's wrong here

    A NAT Gateway is designed primarily to enable instances in private subnets to initiate outbound connections to the internet or other AWS services, translating private IP addresses to public ones. It does not facilitate inbound private access from another VPC or account to an internal service like an NLB. Routing partner traffic through a NAT Gateway for inbound access is an incorrect application of its purpose and would not establish the required private connectivity.

Visual reference

192.168.1.0 /24 256 addresses (254 usable) 192.168.1.0 /25 Subnet A 128 addr (126 usable) 192.168.1.128 /25 Subnet B 128 addr (126 usable) Borrowing 1 bit from host portion creates 2 subnets (/25)

About these practice questions

One of 302 original SAA-C03 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

This SAA-C03 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SAA-C03 exam.