CV0-004 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.

• ✓

  Create a security group with an inbound rule allowing TCP port 22 from 203.0.113.0/24

  Why this is correct

  Security groups are stateful, instance-level virtual firewalls whose inbound rules filter by protocol, port and source CIDR. Allowing TCP 22 solely from 203.0.113.0/24 restricts SSH to the corporate range, satisfying the stated access constraint without affecting other traffic.

• ✗

  Deploy a VPN and require all SSH traffic to go through it

  Why it's wrong here

  A VPN tunnels SSH traffic but does not itself restrict source addresses; instances would still accept SSH from anywhere unless a security group limits it. It is tempting because VPNs secure remote access, yet the requirement is source-IP filtering, which security group inbound rules on port 22 satisfy directly.

• ✗

  Configure a network ACL with an inbound allow rule for TCP port 22 from 203.0.113.0/24

  Why it's wrong here

  Network ACLs are stateless, requiring explicit inbound and outbound rules for all traffic, including the return SSH responses. While they filter by IP and port, their subnet-level operation means they apply to *all* instances within a subnet, not individual ones. This option is tempting because it filters by IP and port, but it is primarily used for broad, coarse-grained security at the subnet boundary, such as blocking an entire IP range from accessing any resources within a subnet.

• ✗

  Use AWS WAF to block SSH traffic except from 203.0.113.0/24

  Why it's wrong here

  AWS WAF filters HTTP and HTTPS web requests at layer 7, so it cannot inspect or block SSH traffic on port 22, leaving the instances reachable from any source. It is tempting because WAF does enforce IP-based allow lists for web applications, which would be the right tool if the requirement concerned HTTP access rather than SSH.

Go deeper

Related to this question