SCS-C02 Infrastructure Security 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.

• ✗

  Use network ACLs to block all inbound traffic to the private subnets.

  Why it's wrong here

  Network ACLs are stateless and block traffic at the subnet boundary, but they cannot prevent the database servers from initiating outbound connections to the internet if a NAT gateway or egress-only internet gateway is present in the route table; the requirement to deny direct internet access is enforced by omitting an internet gateway from the private subnet’s route table, not by ACLs. This option is tempting because network ACLs are commonly used to filter inbound traffic to subnets for security hardening, and in a scenario where the goal is simply to restrict inbound access to a subnet from specific source IP ranges, a network ACL would be the correct stateless filter.

• ✓

  Configure security group rules to allow inbound traffic from the web server security group to the database security group.

  Why this is correct

  The database security group should have an inbound rule that references the web server security group as its source rather than a CIDR block. This allows the web tier to reach the database service on the required port, such as 3306 or 5432, while keeping the database isolated from all other sources. Because security group references are stateful and evaluated dynamically, this rule continues to work as web instances scale or are replaced, and it does not require the database to have a public IP or an internet gateway route.

• ✓

  Do not add a route to an internet gateway in the route table for the private subnets.

  Why this is correct

  A private subnet is defined by its route table, which typically contains only the local VPC route and has no 0.0.0.0/0 target such as an internet gateway or virtual private gateway. Simply attaching an internet gateway to the VPC is not enough to grant internet access; the route table for the private subnet must not include a route to it. Omitting the internet gateway route is the essential control that prevents instances with private IP addresses from directly reaching the internet. If outbound egress is ever required, it must be introduced deliberately through a NAT gateway or proxy rather than by default.

• ✗

  Attach an internet gateway to the VPC and route the private subnets to it.

  Why it's wrong here

  Adding a 0.0.0.0/0 route pointing to an internet gateway in the private subnet route table would effectively turn those subnets into public subnets and permit two-way communication with the internet. Any instance in those subnets that has a public IPv4 address would become reachable from the internet, and all outbound traffic would bypass the restricted network path expected for private resources. This directly violates the requirement to deny direct internet access to the database and application tiers. The correct design is to attach the internet gateway to the VPC only for public subnet route tables and leave the private subnet routes without that target.

• ✗

  Add a NAT gateway in the public subnet and route the private subnets to it.

  Why it's wrong here

  A NAT gateway provides outbound-only internet access for instances in private subnets; it does not accept unsolicited inbound connections from the internet. Although a NAT gateway would preserve the ability to initiate outbound connections, that egress capability is not required by the stated design and adds an unnecessary network path, ongoing cost, and dependency for the private tier. Routing private subnets to a NAT gateway therefore creates internet egress where none is needed, even though it would not expose services to inbound internet traffic. If no internet access is required, the private subnets should simply keep only the local route and no NAT route.

Go deeper

Related to this question