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.

• ✗

  Change the SSH port to a non-standard port to avoid automated attacks.

  Why it's wrong here

  Altering the SSH port to a non-standard value is security by obscurity, not a genuine security control. Automated scanners and attack tools routinely probe the entire TCP port range, so moving the listener does not stop automated discovery or brute-force attempts. More importantly, the instance still exposes a reachable TCP service, and any vulnerability in the SSH daemon remains exploitable regardless of the port. Operating on a non-standard port also typically violates change-management or compliance expectations without adding any real protection.

• ✗

  Restrict the inbound SSH rule to a single IP address from the corporate network.

  Why it's wrong here

  Restricting the SSH source to a single corporate IP narrows the exposure, but the security group still permits inbound TCP 22 from that address. If a user's workstation is compromised or an attacker obtains the private key, the instance is directly reachable, and you still have no centralized way to record or control individual sessions. Managing SSH keys, rotating them, and tracking session activity remains a manual burden. In contrast, eliminating the inbound rule entirely removes that attack surface and lets IAM govern access.

• ✗

  Replace the security group rule with a network ACL that allows SSH from 0.0.0.0/0.

  Why it's wrong here

  Replacing the security group with a network ACL that permits SSH from 0.0.0.0/0 merely changes the filtering layer from a stateful instance-level SG to a stateless subnet-level NACL. This actually makes configuration worse: the NACL must also allow ephemeral return traffic on high ports, and it still allows all inbound SSH from anywhere. Because NACLs are evaluated before security groups, an allow-all SSH rule here would override any tighter SG rule and grant broad network access rather than reducing it. It does not address the underlying issue of leaving an open port reachable from the internet.

• ✓

  Remove the inbound SSH rule and use AWS Systems Manager Session Manager to access the instance.

  Why this is correct

  Removing the inbound SSH rule and using AWS Systems Manager Session Manager closes the port 22 listener entirely, so the instance is not reachable over SSH from the network. Session Manager authenticates the user through IAM, authorizes actions with IAM policies, and sends the interactive shell session over an encrypted channel initiated by the SSM Agent. Sessions can be audited and recorded via S3 or CloudWatch Logs, and you can use a VPC endpoint so traffic never traverses an open internet-facing port. This avoids the need for SSH key management and eliminates brute-force exposure.

Go deeper

Related to this question