Network Access Control Lists (NACLs) in AWS are stateless. What does this mean for the traffic flow?
Think about how a stateless firewall treats incoming and outgoing packets separately.
Because NACLs are stateless, they do not remember previous traffic. This means you must create rules for both inbound and outbound traffic explicitly to allow communication.
You have a NACL with an inbound rule allowing HTTP (port 80) traffic. There is no outbound rule allowing return traffic. What will happen when a client tries to access a web server behind this NACL?
Remember that NACLs are stateless and require explicit outbound rules.
Since there is no outbound rule allowing the return traffic, the response packets from the server are blocked, so the client will not receive any response.
You want to configure a NACL to allow SSH (port 22) access to an EC2 instance and allow the instance to respond back. Which set of rules correctly achieves this?
Think about how return traffic uses ephemeral ports.
Inbound SSH traffic arrives on port 22, but return traffic from the instance uses ephemeral ports. So inbound rules allow port 22, outbound rules allow ephemeral ports.
What is a key security implication of NACLs being stateless compared to security groups which are stateful?
Consider how statelessness affects rule management.
Because NACLs do not track connection state, you must create rules for both inbound and outbound traffic. This can increase complexity and risk of mistakes.
You need to design a highly available architecture using multiple subnets in different Availability Zones (AZs) with NACLs. Which statement about NACLs is true in this scenario?
Think about how NACLs associate with subnets and their scope.
A single NACL can be associated with multiple subnets, even across different AZs, which helps simplify rule management in multi-AZ architectures.