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.

• ✗

  Allow inbound HTTP/HTTPS from the internet gateway.

  Why it's wrong here

  The internet gateway (IGW) is a horizontally scaled, redundant VPC component that provides a target in the route table for internet-bound traffic, but it is not a source IP or a security group. Security group rules must reference a CIDR block, a security group ID, or a prefix list; an IGW has no such identifier. Moreover, even if you attempted to allow traffic 'from' the IGW, packets arriving at an instance still carry the public IP of the client, not the IGW's address, so this rule would never match. The correct pattern is to allow traffic from the ALB's security group, which acts as a logical source that preserves the client's original IP while constraining access to only the load balancer.

• ✓

  Allow inbound HTTP/HTTPS from the security group of the ALB.

  Why this is correct

  Referencing the ALB's security group as the source in the EC2 instance's security group inbound rule is the recommended, least-privilege approach for a private-subnet web tier. This creates a security-group-to-security-group dependency: the rule dynamically allows traffic from any network interface that is associated with the ALB's security group, regardless of the ALB's IP addresses or how they change over time. Because the ALB terminates the client connection and opens a new connection to the instance, the source IP of those connections is the ALB's private IP (or its ENI), which is covered by the ALB's security group association. This rule also ensures that no other resource in the VPC or on-premises can reach the instances directly, preserving the private subnet's isolation and forcing all traffic through the ALB.

• ✗

  Allow inbound HTTP/HTTPS from 0.0.0.0/0.

  Why it's wrong here

  Allowing inbound HTTP/HTTPS from 0.0.0.0/0 would permit any source on the internet to reach the EC2 instances directly, completely bypassing the Application Load Balancer. This defeats the entire purpose of placing the web instances in a private subnet, as they would no longer be isolated from direct inbound internet traffic — they would effectively behave as if they were in a public subnet. Even if the instances were in a private subnet with no public IP, a rule from 0.0.0.0/0 would still not be the right control, because the intended architecture is to accept traffic only through the ALB, and 0.0.0.0/0 is far broader than the ALB's security group. It also introduces significant security risk, since any security group rule with 0.0.0.0/0 for HTTP/HTTPS exposes the instances to any internet client, including malicious scanners.

• ✗

  Allow inbound HTTP/HTTPS from the VPC CIDR.

  Why it's wrong here

  Using the VPC CIDR as the source for HTTP/HTTPS would allow any resource within the VPC's IP range — including other EC2 instances, containers, or network interfaces — to reach the web instances directly, not just the ALB. The ALB is not identified by the VPC CIDR; it is identified by its own security group or its specific ENI IPs, which may fall within the VPC CIDR but are not equivalent to the entire range. This rule does not force traffic through the ALB, and it violates least privilege by granting broad internal network access to the web tier. Additionally, if the VPC CIDR is also used for on-premises connectivity via VPC peering or a transit gateway, this rule could inadvertently allow traffic from those connected networks as well, further expanding the attack surface.

Go deeper

Related to this question