SCS-C02 Infrastructure Security Practice Question

A company is migrating a legacy application to AWS. The application requires two-way communication between the web servers and the database servers using TCP port 3306. The security team wants to follow the principle of least privilege. Which TWO actions should be taken to secure the traffic?

⚠ Common exam trap

Test-takers frequently confuse security groups (stateful, instance-level) with network ACLs (stateless, subnet-level) and incorrectly assume that a subnet CIDR-based rule in a security group is equivalent to using a security group ID, when in fact the latter provides stricter least-privilege control by limiting access to only the specific instances in the web security group.

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

✓

Create a security group for the web servers that allows outbound traffic on port 3306 to the database security group.

Security groups are stateful, so allowing outbound traffic on port 3306 from the web servers to the database security group automatically permits the corresponding return traffic. This adheres to the principle of least privilege by specifying the destination as the database security group ID rather than a broad CIDR range, ensuring only the intended web servers can initiate the connection.

Answer analysis

Option-by-option breakdown

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

✓
Create a security group for the web servers that allows outbound traffic on port 3306 to the database security group.
Why this is correct
This is correct because security groups are stateful: when the web server initiates a TCP connection to the database on port 3306, the corresponding return traffic is automatically allowed back into the web server without an explicit inbound rule. By setting the destination to the database security group ID rather than an IP range, the rule dynamically applies to every instance currently associated with that security group, which simplifies management if the database fleet scales or changes. This outbound rule scopes traffic to the specific database tier and avoids opening port 3306 to the whole VPC.
✗
Create a security group for the database servers that allows inbound traffic on port 3306 from the web subnet CIDR.
Why it's wrong here
Although this inbound rule would technically permit web servers on that subnet to reach port 3306, referencing the web subnet’s CIDR is far broader than necessary—it also allows any other instance placed in that subnet, such as a bastion host or a management server, to connect to the database. More importantly, the rule is static: if the web tier’s IP address space changes (e.g., new subnets are added or the subnet is replaced), the rule must be manually updated, whereas a security group reference automatically follows the members. Additionally, using a CIDR source does not leverage the stateful nature of security groups in the same clean way, and it is considered a less secure, less dynamic pattern than referencing the web security group’s ID.
✗
Place the database servers in a public subnet for easier connectivity.
Why it's wrong here
Placing the database servers in a public subnet would make them reachable from the internet, as public subnets route 0.0.0.0/0 through an Internet Gateway, exposing the database externally. This directly contradicts the security best practice of keeping database tiers in private subnets without internet routes, because a public subnet typically assigns public IP addresses and broadens the attack surface significantly. Even if the intention is 'easier connectivity' from the web servers, the web servers can reach private databases through private IP routing inside the VPC, so there is no technical benefit to making the database public.
✗
Configure the network ACL for the database subnet to allow inbound traffic on port 3306 from the web subnet CIDR.
Why it's wrong here
A network ACL is stateless, so allowing inbound traffic on port 3306 from the web subnet CIDR does not automatically permit the return traffic from the database servers to the web servers. The application requires two-way communication, and a stateless ACL would also need an outbound rule for ephemeral ports, which the security team would have to configure explicitly. This option is tempting because network ACLs provide subnet-level filtering and are often used to block traffic at the VPC boundary, but they lack the stateful tracking that security groups offer, making them unsuitable for this bidirectional requirement without additional rules.
✓
Create a security group for the database servers that allows inbound traffic on port 3306 from the web security group ID.
Why this is correct
This is the correct security group design: by specifying the web security group’s ID as the source for inbound port 3306, only instances that are members of that web security group can initiate connections to the database servers. The rule is dynamic—if new web servers are launched and added to that security group, they are instantly allowed, and if an instance is removed, its access is revoked automatically. Because security groups are stateful, the response traffic from the database back to the web server is automatically permitted, so no separate outbound rule is needed on the database security group.

Visual reference

Go deeper

SCS-C02 Infrastructure Security Practice Question

Why each option matters

Option-by-option breakdown

Related to this question