SCS-C02 Infrastructure Security Practice Question

Network Topology

Refer to the exhibit. A security engineer runs the describe-instances command for an EC2 instance. The instance has a public IP address. The security group "allow-ssh-http" has inbound rules that allow SSH from 0.0.0.0/0 and HTTP from 0.0.0.0/0. The engineer wants to block SSH access from the internet while keeping HTTP access. Which change should be made?

⚠ Common exam trap

Candidates may incorrectly think security groups support deny rules (like network ACLs) or that adding a network ACL deny rule is the best solution. While a NACL deny rule can block SSH at the subnet level, it affects all instances in the subnet. Security groups are allow-only and provide instance-level control, so the correct action is to remove the SSH allow rule from the 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

✓

Remove the inbound rule that allows SSH from 0.0.0.0/0 from the security group.

Security groups are stateful and support only allow rules; removing the inbound SSH rule from the security group effectively blocks SSH access from the internet (0.0.0.0/0) while the HTTP rule remains, allowing HTTP traffic. Since the instance already has a public IP address, removing the SSH rule is the simplest and most direct way to achieve the goal without affecting other traffic.

Answer analysis

Option-by-option breakdown

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

✓
Remove the inbound rule that allows SSH from 0.0.0.0/0 from the security group.
Why this is correct
The security group acts as a stateful, allow-only firewall at the instance level. Removing the inbound SSH rule for 0.0.0.0/0 immediately denies all internet SSH traffic while leaving the HTTP rule intact. Since security groups contain no explicit deny rules, the absence of an allow rule is what blocks the connection. This is the precise, least-disruptive change because it only restricts SSH and does not affect HTTP reachability.
✗
Add a network ACL rule to deny SSH inbound from 0.0.0.0/0.
Why it's wrong here
Network ACLs are applied at the subnet boundary, not to a single instance. Adding a deny rule for inbound SSH from 0.0.0.0/0 would block SSH for every resource in that subnet, including other instances that may need legitimate SSH access. Additionally, network ACLs are stateless, so this approach is broader than necessary and could also require careful return-traffic rule management. The security engineer should remediate at the instance level instead of impacting the whole subnet.
✗
Disassociate the public IP address from the instance.
Why it's wrong here
Disassociating the public IP address from the instance eliminates all direct internet access to that instance, not just SSH. If the instance is hosting a web server, inbound HTTP traffic destined for that public IP would also fail. This approach breaks legitimate HTTP services and may not even resolve SSH exposure if an Elastic IP or other routing still provides access. The correct objective is to selectively close the SSH port while preserving HTTP, so removing the public IP is an overly broad action.
✗
Modify the security group to add a deny rule for SSH from 0.0.0.0/0.
Why it's wrong here
Security groups do not support deny rules; they are exclusively allow-list filters. Attempting to add a deny rule for SSH from 0.0.0.0/0 is invalid and cannot be implemented in the AWS console or API. To stop SSH access, you must remove the allow rule, because security groups implicitly deny all traffic that does not match an explicit allow rule. Therefore, the only valid security group change is deletion of the permissive SSH rule, never the addition of a deny statement.

Go deeper

SCS-C02 Infrastructure Security Practice Question

Why each option matters

Option-by-option breakdown

Related to this question