SCS-C02 Infrastructure Security Practice Question

A company has a security group that allows inbound SSH from 0.0.0.0/0. The security team wants to restrict access to only the company's public IP range 203.0.113.0/24. What change should be made?

⚠ Common exam trap

It's easy for candidates to confuse the stateless behavior of network ACLs with the stateful behavior of security groups, leading them to incorrectly believe that adding a deny rule in a network ACL can override a security group's allow rule for the same traffic.

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

✓

Modify the inbound SSH rule in the security group to source 203.0.113.0/24.

Security groups are stateful and act as a virtual firewall for instances. To restrict inbound SSH access from 0.0.0.0/0 to only the company's public IP range, you must modify the existing inbound rule's source CIDR from 0.0.0.0/0 to 203.0.113.0/24. This change directly updates the allowed source IP range, and since security groups evaluate all rules before making a decision, the more specific allowed range will take effect without needing additional rules.

Answer analysis

Option-by-option breakdown

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

✗
Add a network ACL rule to deny SSH from 0.0.0.0/0.
Why it's wrong here
A network ACL (NACL) is a stateless, subnet-level filter that is evaluated before the instance's security group. Adding a deny rule for SSH from 0.0.0.0/0 would drop all inbound SSH traffic at the subnet boundary, including from the company's 203.0.113.0/24 range, so it is over-broad rather than restrictive. Because the security group still has its original allow-all rule, you would only be layering a blanket block on top, not limiting access to the intended CIDR.
✓
Modify the inbound SSH rule in the security group to source 203.0.113.0/24.
Why this is correct
Modifying the inbound SSH rule's source from 0.0.0.0/0 to 203.0.113.0/24 is the precise fix because security groups are stateful and support only allow rules. Every IP outside that CIDR will be implicitly denied by the security group's default-deny behavior, while the company's addresses remain permitted. This change directly aligns the security group with the requirement and requires no extra outbound rule because stateful filtering automatically allows the return traffic.
✗
Add a network ACL rule to allow SSH from 203.0.113.0/24.
Why it's wrong here
Adding a NACL allow rule for 203.0.113.0/24 does not alter the security group, which still permits SSH from 0.0.0.0/0. In a default VPC, the existing NACL already has an allow-all rule, so the new rule is simply redundant and has no restrictive effect; in a custom NACL you would also need to remove broader allows. The security group remains the vulnerable, overly permissive control, so this is not a correct fix.
✗
Remove the inbound SSH rule from the security group.
Why it's wrong here
Removing the inbound SSH rule entirely would not restrict access; it would eliminate SSH for everyone, including the 203.0.113.0/24 administrators. Security groups have no explicit deny rules, and an absent inbound allow means no source can initiate SSH traffic. This would likely cause an administrative lockout and is a complete block rather than a targeted restriction to the company IP range.

Visual reference

Go deeper

SCS-C02 Infrastructure Security Practice Question

Why each option matters

Option-by-option breakdown

Related to this question