TL;DR: A security group is stateful, so return traffic for an allowed connection is automatically permitted. A NACL is stateless and evaluates every packet independently, which means an inbound allow rule without a matching outbound rule for the ephemeral port range silently breaks the response half of the connection.
How to approach it
Give the mechanism in one sentence each, then go straight to the failure mode. The interviewer already knows the definitions. Explain which packet is dropped and what the client observes.
A strong answer
A security group attaches to an ENI, allows only, and tracks connection state. If you allow inbound 443, the response leaving from source port 443 to the client’s ephemeral destination port is permitted automatically because the connection is in the state table. There is no need to write an outbound rule for it.
A NACL attaches to a subnet, supports both allow and deny, is evaluated in numbered rule order, and holds no state. Each packet is judged on its own. So an inbound allow on 443 permits the request, and the response, which leaves from port 443 to the client's ephemeral source port, is evaluated by the outbound rules as an entirely separate event. If the outbound rules do not permit that ephemeral range, the response never leaves.
| Security group | Network ACL | |
|---|---|---|
| Attaches to | ENI (instance level) | Subnet |
| State | Stateful | Stateless |
| Rules | Allow only | Allow and deny |
| Evaluation | All rules, any match permits | In rule-number order, first match wins |
| Return traffic | Automatic | Needs an explicit rule |
The case where it bites: someone locks down a subnet's NACL to inbound 443 and outbound 443, reasoning that the service only speaks HTTPS. The server receives the SYN, but its SYN-ACK is dropped: outbound destination 443 does not match the client’s ephemeral port. The TCP handshake times out. The required return-port range belongs to the client initiating the connection; inspect that client’s configuration and any load balancer in the path. AWS documents client-specific ephemeral ranges, including cases requiring 1024 through 65535.
The second case is a deny rule with a low number. NACL evaluation is first-match-wins in ascending order, so a deny at rule 50 makes an allow at rule 100 unreachable. Security groups have no such trap because they are allow-only and every rule is considered.
What interviewers probe next
"When would you actually use a NACL?" As a coarse subnet-level backstop, usually to deny a specific CIDR outright or to enforce a boundary that a team cannot accidentally undo with a security group change. It is a blunt instrument used deliberately, not a second firewall you configure by default.
"A team asks for a security group rule allowing 0.0.0.0/0 on 22. What do you do?" Refuse and offer the alternative: Session Manager or an equivalent identity-brokered path, so there is no open SSH port and there is an audit trail.
"How do you troubleshoot a connection that is blocked?" VPC Flow Logs, and read the ACCEPT and REJECT records in both directions. A REJECT can result from a security group or NACL; correlate the five-tuple with both rule sets and use Reachability Analyzer for the supported network path. Flow Logs alone do not identify the blocking rule.
Common mistakes
Reciting the comparison table and stopping. Every candidate has that table; almost none can name the ephemeral port failure.
Claiming security groups are attached to subnets. They attach to network interfaces, and getting this wrong signals console familiarity rather than working knowledge.
Saying NACLs are "for extra security" without a specific thing they enforce that a security group cannot. Defence in depth is only an argument if you can name the depth.