How do network ACLs differ from security groups at Cloud Practitioner depth?

Network ACLs are subnet-level stateless filters, while security groups are stateful controls typically associated with instances — the Cloud Practitioner distinction. Picture two checkpoints: the security group sits next to the instance and remembers conversations (stateful); the network ACL sits at the subnet gate and checks each direction separately (stateless). Network ACLs do not encrypt EBS volumes, and security groups do not encrypt S3 objects. Network ACLs do not replace IAM policies for API authorization. Security groups are not always stateless while network ACLs are always stateful — that pairing reverses the truth. Distractors fail by assigning encryption duties, by replacing IAM, or by swapping stateful/stateless labels. Exam caveat: many designs rely primarily on security groups; NACLs appear when subnet-wide explicit allow/deny sequencing is required. Operational check: document which subnets use custom NACLs, ensure ephemeral return ports are considered for stateless rules, keep security groups as the primary instance firewall, and test connectivity after rule changes in non-prod civic VPCs first. In practice, default to security groups for instance firewalling, add custom NACLs only with documented stateless allow pairs, and test both inbound and outbound paths in a staging VPC.