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.

• ✗

  Disable SSH and use AWS Systems Manager Session Manager to connect to instances.

  Why it's wrong here

  Replacing SSH with AWS Systems Manager Session Manager does not close the existing inbound port 22 rule; the security group still contains the 0.0.0.0/0 source, leaving SSH exposed to the internet. Session Manager instead relies on the SSM agent initiating an outbound HTTPS connection to AWS and IAM permissions, and it does not satisfy a requirement to restrict SSH access at the security group layer. Therefore, this option changes the access method but leaves the original vulnerability in place.

• ✗

  Create a network ACL with an inbound rule allowing SSH from 203.0.113.0/24 and deny all other traffic.

  Why it's wrong here

  Creating a network ACL to deny all other traffic would impact every instance within the subnet, overriding their existing security group rules and failing to maintain them as required. Network ACLs are stateless, subnet-level firewalls, whereas security groups are stateful and operate at the instance level. While network ACLs can filter traffic by IP, they are typically used for broad, coarse-grained subnet isolation or as a second layer of defence, not for granular instance-specific rule modifications.

• ✓

  Modify the existing security group rule to change the source from 0.0.0.0/0 to 203.0.113.0/24.

  Why this is correct

  Modifying the existing rule is the correct action because security group inbound rules are evaluated as an allow list, and changing the source to 203.0.113.0/24 removes the wildcard entry while authorizing only the specified IP range. The update is an in-place edit, so no duplicate rule remains and the stateful security group automatically permits the return traffic for established SSH sessions. The existing rule should be changed rather than appended because any remaining 0.0.0.0/0 rule would continue to allow all source IPs.

• ✗

  Create a new security group rule allowing SSH from 203.0.113.0/24 and keep the existing rule.

  Why it's wrong here

  Adding a new security group rule that permits SSH from 203.0.113.0/24 while retaining the original 0.0.0.0/0 rule is ineffective because security group rules are additive and there is no precedence or deny rule to exclude other sources. Every matching inbound rule is applied, so the original rule still allows SSH from any IP address on the internet, including unauthorized attackers. The only way to restrict access is to remove or modify the permissive rule, not to supplement it with a narrower allow rule.

Go deeper

Related to this question