Security groups vs NACLs decision in AWS - Practice Questions

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding Security Groups and NACLs

Which statement correctly describes the main difference between Security Groups and Network ACLs (NACLs) in AWS?

A NACLs are stateful and control traffic for individual instances, while Security Groups are stateless and control traffic at the subnet level.

B Security Groups act as virtual firewalls for instances and are stateful, while NACLs are stateless and operate at the subnet level.

C Both Security Groups and NACLs are stateful and operate at the instance level.

D Security Groups and NACLs both operate at the subnet level and are stateless.

💡 Hint

Think about where each one applies and whether they remember previous traffic.

Security Groups are stateful and attached to instances, meaning they remember traffic and automatically allow return traffic. NACLs are stateless and apply to subnets, so return traffic must be explicitly allowed.

❓ Architecture

intermediate

Choosing Between Security Groups and NACLs

You want to protect a public subnet in your VPC from unwanted inbound traffic but allow all outbound traffic. Which AWS feature should you configure primarily to block unwanted inbound traffic efficiently?

A Configure only Security Groups to deny unwanted inbound traffic; NACLs are not needed.

B Configure a Security Group with rules to deny unwanted inbound traffic and allow all outbound traffic.

C Configure both Security Groups and NACLs to deny unwanted inbound traffic and allow all outbound traffic.

D Configure a Network ACL with rules to deny unwanted inbound traffic and allow all outbound traffic.

💡 Hint

Consider which feature applies at the subnet level and can block traffic before it reaches instances.

NACLs operate at the subnet level and can block unwanted inbound traffic before it reaches instances. Security Groups control traffic at the instance level but cannot block traffic before it reaches the subnet.

❓ security

advanced

Impact of Stateless NACLs on Return Traffic

You have a NACL that allows inbound HTTP (port 80) traffic but does not explicitly allow outbound HTTP traffic. What will happen when a client tries to access a web server in the subnet?

A The client will connect, but responses will be delayed due to NACL processing.

B The client connection will fail because Security Groups block inbound HTTP traffic by default.

C The client will not receive responses because NACLs are stateless and outbound HTTP traffic is blocked by default.

D The client will successfully connect and receive responses because Security Groups allow return traffic automatically.

💡 Hint

Remember that NACLs are stateless and require explicit rules for both inbound and outbound traffic.

NACLs do not remember traffic state, so if outbound HTTP traffic is not allowed explicitly, the return traffic will be blocked, causing the client to not receive responses.

✅ Best Practice

advanced

Best Practice for Layered Security in AWS Networking

Which approach best follows AWS security best practices for controlling traffic to instances in a public subnet?

A Use NACLs to block unwanted inbound traffic and Security Groups to allow only necessary inbound traffic to instances.

B Use only Security Groups to control all inbound and outbound traffic to instances.

C Use Security Groups to block all inbound traffic and NACLs to allow only necessary inbound traffic to instances.

D Use only NACLs to control all inbound and outbound traffic at the subnet level.

💡 Hint

Think about defense in depth and where each control is applied.

Best practice is to use NACLs as a coarse filter at the subnet level and Security Groups as fine-grained controls at the instance level, providing layered security.

❓ service_behavior

expert

Effect of Overlapping Rules in Security Groups and NACLs

You have a Security Group that allows inbound SSH (port 22) from anywhere and a NACL that denies inbound SSH from all IPs. What will be the result when you try to SSH into an instance in that subnet?

A SSH connections will be blocked because NACLs deny traffic before Security Groups allow it.

B SSH connections will succeed because Security Groups allow the traffic and are stateful.

C SSH connections will be allowed only if the instance is in a private subnet.

D SSH connections will fail due to conflicting rules causing a timeout.

💡 Hint

Consider the order in which AWS processes NACLs and Security Groups.

NACLs are evaluated before Security Groups. If a NACL denies traffic, it is blocked before reaching the instance, regardless of Security Group rules.