A parks department EC2 web server sits behind a security group. What is the foundational inbound behavior of that security group before any custom allow rules are added?
Select an answer to reveal the explanation.
Short Explanation
A security group is a locked front door until you add a key for a specific guest. Inbound starts denied; only the allow rules you write open the path. That default-deny inbound habit is the CLF idea to remember.
Full Explanation
For a parks department EC2 web server sitting behind a security group, the foundational inbound behavior is deny-by-default: no inbound traffic is allowed until an administrator adds explicit allow rules. Security groups are stateful virtual firewalls associated with elastic network interfaces. Outbound traffic is typically allowed by default (unless tightened), but inbound starts closed. That default protects a newly launched municipal web server from accidental internet exposure until the team intentionally opens ports such as 443 from a load balancer security group or approved CIDR.
The claim that security groups allow all inbound traffic by default until an explicit deny is written reverses the model. Security groups support allow rules only; they do not use deny rules the way network ACLs do. Network ACLs do not automatically replace security groups on every ENI—both controls can apply in a layered design, with security groups at the instance/ENI layer and NACLs at the subnet layer. Security groups evaluate inbound and outbound connection attempts for the associated ENIs; they are not limited to filtering outbound DNS replies while ignoring inbound connections.
Exam caveat: Memorize the pairing—security groups are stateful and deny inbound by default with allow-only rules; network ACLs are stateless and can include allow and deny rules at the subnet boundary. Questions that say “before any custom allow rules” are testing the inbound default deny for security groups.
Operational check for parks: inspect the instance’s security group in the console or CLI, confirm that only required inbound rules exist (for example, HTTPS from the ALB security group), remove 0.0.0.0/0 SSH if a bastion or SSM Session Manager is the approved path, and verify that health checks still succeed after tightening. Document the baseline security-group template so new trail-map or reservation servers inherit the same deny-by-default posture.