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.

• ✗

  Configure a network ACL on the subnet to allow inbound SSH from the corporate range and deny all other inbound traffic.

  Why it's wrong here

  A network ACL is stateless, meaning it evaluates inbound and outbound traffic independently; even if inbound SSH from 203.0.113.0/24 is allowed, the corresponding outbound response traffic must also be explicitly permitted, which the option does not specify. This option is tempting because network ACLs are commonly used for subnet-level IP-based filtering, and in a scenario where the application does not require stateful tracking of return traffic—such as blocking specific inbound ports without needing to manage ephemeral outbound replies—a network ACL would be the correct choice.

• ✗

  Use AWS Systems Manager Session Manager to connect to instances instead of SSH.

  Why it's wrong here

  AWS Systems Manager Session Manager is a valid way to avoid opening port 22 entirely, but the question asks to restrict SSH access specifically. Session Manager establishes a connection through the SSM agent without requiring inbound network rules, yet it does not modify or override the existing security group that still allows SSH from non-corporate IPs. Because the security group rule permitting SSH from all IP ranges remains unchanged, simply adopting Session Manager does not enforce the stated restriction, and the SSH service could still be reachable by unauthorized sources.

• ✗

  Add an IAM policy that allows `ec2:RunInstances` only if the request includes the corporate IP.

  Why it's wrong here

  An IAM policy with ec2:RunInstances and a condition on the corporate IP governs the API call that launches the instance, not the network traffic to a running instance. The aws:SourceIp condition key evaluates the IP address of the caller making the RunInstances request, but after the instance is running, that policy has no effect on the security group rules or NACL rules that determine whether an SSH connection is allowed. Since IAM does not mediate host-level network connections, this approach fails to restrict inbound SSH traffic and is therefore incorrect.

• ✓

  Add a security group rule that allows inbound SSH (port 22) from the corporate IP range.

  Why this is correct

  Adding a security group rule to allow inbound SSH (port 22) only from the corporate IP range is the correct solution because security groups are stateful and act at the instance's network interface level. This rule denies all other inbound SSH traffic by default, since security groups have an implicit deny-all inbound rule, and because it is stateful, return traffic for allowed connections (e.g., ephemeral ports) is automatically permitted. This directly restricts SSH to the corporate range without requiring separate outbound rules, making it the appropriate mechanism for this use case.

Go deeper

Related to this question