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.

• ✗

  Create a VPC peering connection between the subnets.

  Why it's wrong here

  VPC peering is a networking construct that connects entire VPCs, not individual subnets, and it does not filter or segment traffic between resources. Peering simply provides a routing path using private IPs, but security group rules and route tables still control what traffic flows; it introduces no granularity at the subnet level and cannot restrict communication between specific EC2 instances and an RDS database. Moreover, peering is not transitive and requires explicit route table entries, so it is not a substitute for security groups or NACLs, and it gives no stateful filtering or allow/deny policy capability.

• ✓

  Configure security groups for the EC2 instances that only allow outbound traffic to the RDS security group, and RDS security group allows inbound from the EC2 security group.

  Why this is correct

  Security groups act as stateful, instance-level firewalls, and AWS allows one security group to reference another as a source or destination in its rules. By configuring the EC2 security group's outbound rule to destination the RDS security group, and the RDS security group's inbound rule to source the EC2 security group, the two sets of instances can communicate only with each other, without hard-coding IP addresses. Because security groups default to deny-all and automatically allow return traffic, this pattern creates a minimal-privilege channel between the application tier and the database tier, and it self-maintains when instances are replaced or auto-scaled since the rule references the group, not individual instance IPs.

• ✗

  Assign the same security group to both the EC2 instances and the RDS database.

  Why it's wrong here

  Assigning the same security group to both EC2 and RDS might initially seem convenient, but a self-referencing rule in that group would allow all members — both the web servers and the database — to communicate with each other, and also with any other resource that joins the group. This approach provides no separation of roles: if the security group also contains rules for internet-facing traffic, those rules are applied to the RDS database as well, potentially exposing it unnecessarily. Even in a worst case, a compromised EC2 instance in the same group can connect to the database because the group-wide rule grants that access, violating the principle of least privilege and tightening the blast radius of any single vulnerability.

• ✗

  Use network ACLs with deny rules for all traffic except between the two subnets.

  Why it's wrong here

  Network ACLs are stateless and operate at the subnet level, not at the individual instance or ENI level, so they cannot distinguish between the EC2 instance and the RDS database in the same subnet. If the two subnets each have their own NACL, you would need to add both inbound and outbound allow rules for every ephemeral port and protocol, because stateless filtering requires explicit rules for each direction, and the default deny rule means any missed traffic is dropped. Additionally, NACLs apply equally to every resource in the subnet, making them too coarse for micro-segmentation between specific instances; security groups are the correct tool for this kind of instance-to-instance allow/deny policy.

Go deeper

Related to this question