SCS-C02 NAT Gateway Practice Question

Answer analysis

Option-by-option breakdown

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

• ✗

  Web servers in private subnets, database servers in public subnets, both behind an Application Load Balancer

  Why it's wrong here

  Placing the database tier in public subnets gives those instances a route to an internet gateway, making the database reachable from or able to connect out to the internet, which directly violates the requirement for no internet access to the database. An Application Load Balancer placed in front of web servers in private subnets can still route traffic to those web servers, but the ALB does not remove the database's public exposure because the database subnets' route table still permits internet traffic. A compliant design must put the database in subnets with no default route to an internet gateway or a NAT device.

• ✗

  Web servers in public subnets, database servers in private subnets with a route to a NAT Gateway in a public subnet

  Why it's wrong here

  This design exposes the web servers directly on the internet because they are in public subnets, so clients can bypass the Application Load Balancer and its security capabilities such as AWS WAF, TLS termination, and strict security group rules. More critically, the database private subnet includes a route to a NAT gateway, which provides outbound-only internet access; if the database is compromised, it can initiate outbound connections and exfiltrate data, which violates the requirement that the database have no internet access. The NAT route should be used only by the web tier, while the database subnets must have no route to any internet gateway or NAT gateway.

• ✓

  Web servers in private subnets with a route to a NAT Gateway, database servers in private subnets with no route to the NAT Gateway, both behind an Application Load Balancer in public subnets

  Why this is correct

  This architecture correctly places the web servers in private subnets with a 0.0.0.0/0 route to a NAT gateway in public subnets, so the web servers can download patches and updates but cannot be directly reached from the internet. The database servers are in separate private subnets with no route to the NAT gateway or to an internet gateway, giving them no internet path at all—protecting against both inbound attacks and outbound data exfiltration. The internet-facing Application Load Balancer resides in public subnets, accepts HTTPS traffic on port 443, terminates TLS, and forwards requests to the web servers over private IPs, while the web servers communicate with the database over the VPC internal network only.

• ✗

  Web servers in public subnets with Elastic IPs, database servers in private subnets with a route to an internet gateway

  Why it's wrong here

  Assigning Elastic IPs to web servers in public subnets makes each web instance directly reachable from the internet, creating an unnecessary exposure that bypasses the Application Load Balancer as the single public entry point and also ignores the ALB's advanced features like path-based routing and request-level security policies. Additionally, the database subnets are described as private yet are given a route to an internet gateway, which contradicts the definition of a private subnet; if the database instances ever have a public IPv4 address assigned, they would have a direct internet path enabling both inbound access and outbound communication. A correctly designed private subnet must have no internet gateway route at all, and the public web tier should sit behind the ALB rather than using individual Elastic IPs.

Go deeper

Related to this question