Security groups vs network ACLs: SAA-C03 scenarios

The two VPC firewalls and the line the exam draws between them — stateful allow-only groups at the instance, stateless numbered ACLs at the subnet. Seven scenarios, SAA-C03, 2026 edition.

Try 7 free security-group-vs-NACL scenarios in the exam's own style — every answer explained, no sign-up.

Straight to the 7 free questions ↓

Security groups and network ACLs are the two firewalls inside a VPC, and the SAA-C03 tests whether you can place a requirement on the right one. They are not interchangeable: one is stateful and allow-only at the instance, the other is stateless and can deny at the subnet. Almost every distractor on this topic comes from swapping a property between them.

Two firewalls, four properties

A security group is stateful, allow-only, and attached to an elastic network interface — so it wraps an individual instance and returns traffic automatically. A network ACL is stateless, carries both allow and deny rules, and guards a whole subnet. Hold those four properties side by side and most questions answer themselves. The diagram places the stateless numbered ACL at the subnet boundary and the stateful security groups around each instance inside it — the coarse edge and the fine filter.

Rule order is the whole mechanism

Network ACL rules are numbered and evaluated in ascending order, and evaluation stops at the first match. A deny at rule 90 beats an allow at rule 100 not because deny outranks allow, and not because one CIDR is narrower, but purely because 90 is reached first. There is no specificity contest and no allow-versus-deny precedence pass — only the number line. When a scenario hands you rule numbers, read them in order and stop at the first one that matches the packet.

Stateless means you own the return trip

Because an ACL is stateless, the response to a permitted flow is not allowed automatically. A request to a service arrives on its port; the reply goes back to the caller’s ephemeral port in the 1024–65535 range. So an instance making outbound HTTPS calls needs an inbound ACL rule for the ephemeral range, even though the outbound 443 rule looks complete. Connections that hang with the “right” rule in place are almost always a missing ephemeral-port rule. A security group never has this problem — its statefulness handles the return trip for you.

When you need which

The reflexes are short. Need to block a specific address or range at a subnet’s edge? Only the network ACL can deny. Need different rules for two instances in one subnet? Only the security group is per-instance. Governing routine tier-to-tier access? Use security groups that reference each other and leave the ACL at its default allow — pushing ordinary traffic into numbered ACL rules is stateless bookkeeping you do not need. And the stateful catch: emptying a security group’s outbound rules does not stop responses to allowed inbound requests, because return traffic is exempt from the outbound rule set entirely.

Layer them on purpose

The two are not rivals; they are layers. Put the coarse subnet-wide deny on the network ACL and the fine per-application allow on the security groups, and you have defence in depth where each control does what it is built for. Trying to force everything onto one layer — detailed per-app rules on an ACL, or a block guardrail on an allow-only security group — is the design mistake the exam plants.

How to use the seven scenarios below

Answer each before opening the explanation, and when you miss, name the property that decided it — “stateless”, “allow-only”, “subnet-level”, “rule order”, “ephemeral”. Every explanation states that property and dismantles the distractors, most of which are real controls with one property swapped. For the wider picture, see Design Secure Architectures.

A subnet boundary drawn as a dashed box. Guarding the boundary is a stateless network ACL shown as a numbered rule list, evaluated lowest number first, with both allow and deny rules and an explicit outbound ephemeral-port range for return traffic. Inside the subnet sit two EC2 instances, each wrapped by its own stateful security group that carries allow-only rules and returns traffic automatically. Labels mark the network ACL as stateless and subnet-level and the security groups as stateful and instance-level, illustrating layered defence where the ACL is the coarse subnet edge and each security group is the fine per-instance filter.

7 free SAA-C03 practice questions

Answers and explanations — no email wall

SAA-C03 Question 1 of 7

A network ACL guards a subnet. Rule 90 denies TCP 3306 from 10.0.5.0/24, and rule 100 allows all TCP from 10.0.0.0/16. A database instance in the subnet receives a connection from 10.0.5.20 on port 3306. What happens, and why?

Answer: A — The connection is denied, because network ACL rules are evaluated in ascending number order and the first match — rule 90 — wins.

A network ACL evaluates rules in ascending order by rule number and stops at the first match. Rule 90 is reached before rule 100, matches the source and port, and denies — later rules are never consulted. Why not the others: 'broader overrides narrower' is how you might reason about specificity, but ACLs care only about number order, not CIDR size. There is no allow-versus-deny precedence pass; type is irrelevant to ordering. And membership in 10.0.0.0/16 is exactly what rule 100 would have allowed had evaluation ever reached it. Rule numbering is the whole mechanism this question tests.

SAA-C03 Question 2 of 7

A partner's on-premises range 203.0.113.0/24 has been compromised, and all inbound traffic from that CIDR must be blocked at the edge of a subnet that hosts a dozen instances. The instances' security groups already allow the partner's application ports. What is the correct control?

Answer: A — Add an inbound deny rule for 203.0.113.0/24 on the subnet's network ACL at a low rule number.

Only a network ACL can express a deny, and it acts once at the subnet boundary — a single low-numbered deny rule blocks the compromised CIDR ahead of the allow rules, covering all twelve instances at once. Why not the others: security groups are allow-only, so there is no deny rule to add to them. Stripping the application ports would break legitimate partner traffic along with the bad, over-correcting the requirement. A security group cannot be 'attached to a subnet' at all — that is the network ACL's scope, and conflating the two is the trap.

SAA-C03 Question 3 of 7

Two instances share one subnet: a bastion host that should accept SSH only from the corporate office, and an application server that should accept HTTPS only from an internal load balancer. A solutions architect wants each instance governed by its own distinct rule set. Which control fits, and why?

Answer: A — A separate security group per instance, because security groups apply at the instance's elastic network interface.

Security groups attach to an elastic network interface, so each instance can carry its own set of allow rules — the natural fit when two workloads in one subnet need different access. Why not the others: a network ACL is scoped to the whole subnet, so you cannot give one instance its own ACL. Hand-keying per-IP rules into a subnet-wide ACL is brittle and misuses the layer — the ACL is a coarse subnet guardrail, not a per-host firewall. A single shared security group would force identical rules on both, the opposite of the requirement. Instance-level means security group; subnet-level means network ACL.

SAA-C03 Question 4 of 7

Instances in a subnet guarded by a custom network ACL make outbound HTTPS calls to a third-party API. The outbound ACL rule allowing TCP 443 is present, yet the calls hang with no response. What is the most likely fix?

Answer: A — Add an inbound network ACL rule allowing the ephemeral port range (1024–65535) so response traffic can return.

Network ACLs are stateless, so the response to an outbound request is not allowed automatically — it arrives on an ephemeral port the client chose, and the inbound ACL must permit the ephemeral range for the reply to land. Why not the others: the response does not come back on 443; it targets the caller's ephemeral port, so an inbound 443 rule misses it. There is no toggle to make an ACL stateful — statefulness is the security group's property, not a setting. Widening the outbound rule touches the wrong direction entirely. Stateless plus ephemeral ports is the classic ACL failure mode.

SAA-C03 Question 5 of 7

A security group on a web server allows inbound TCP 443. To stop the server from initiating any outbound connections, an engineer removes all outbound rules, expecting this to also block responses to inbound requests. Clients report the site still works normally. Why?

Answer: A — Security groups are stateful, so responses to allowed inbound requests are permitted automatically regardless of outbound rules.

Because a security group is stateful, traffic that returns in response to an allowed inbound flow is permitted automatically — outbound rules govern only connections the instance itself initiates. Removing them stops new outbound sessions but never touches replies to inbound requests, so the site keeps serving. Why not the others: the outbound rule set can be emptied; it simply does not affect return traffic. No protocol is exempt from evaluation — statefulness, not exemption, is what allows the reply. And a security group never defers its decisions to a network ACL; the two layers act independently. This stateful behaviour is exactly what distinguishes it from an ACL.

SAA-C03 Question 6 of 7

A compliance standard requires layered network controls: a coarse subnet-wide guardrail that can block known-bad ranges, plus fine-grained per-application access. A solutions architect wants defence in depth with the least brittle configuration. How should the layers be assigned?

Answer: A — Use the network ACL for the subnet-wide deny guardrail and security groups for per-application allow rules.

Each layer plays to its strength: the stateless subnet-level ACL carries the broad deny guardrail, and the stateful instance-level security groups carry the specific per-application allows — genuine defence in depth. Why not the others: security groups cannot deny, so they cannot serve as the block guardrail. Cramming detailed per-application rules into a single ACL ignores the security group layer built for exactly that and grows brittle as applications multiply. Leaning on the ACL alone throws away the automatic, stateful, instance-scoped filtering the security group provides for free. Coarse-deny at the subnet, fine-allow at the instance is the layering the exam rewards.

SAA-C03 Question 7 of 7

A team is designing routine access between an application tier and a caching tier in the same VPC and proposes writing detailed numbered allow and deny rules on the subnet network ACLs for every port pair. What should a solutions architect recommend for the least operational overhead?

Answer: A — Use security groups that reference each other for the tier-to-tier allows and leave the network ACLs at their default allow.

Normal instance-to-instance access is the security group's job: reference the caching tier's group as the source on the application tier's group and the allow follows the resource, stateful and self-maintaining, while the ACLs stay at their default allow. Why not the others: pushing every port pair into numbered ACL rules is stateless, duplicated across subnets, and demands ephemeral-port bookkeeping — high overhead for routine traffic. A single permissive ACL in place of security groups discards per-instance control. Denying every unused port on the ACL is a maintenance treadmill that security groups avoid by allowing only what you name. Reserve network ACLs for explicit subnet-wide denies; use security groups for ordinary access.

That is exactly how every question in the course works — answer, explanation, why-not. The real set continues in the practice player: 10 free questions, no sign-up.

Continue with the 10 free questions →

Those 7 questions were the start.

The exam does not test whether you recognise a term — it tests whether you can rule out three plausible answers under time pressure. That is what the explanations above are for, and there are 780 more questions built exactly like them.

Collecting questions yourself

Scattered across forums, of unknown age
Answer keys without reasoning
No idea which domain you are weak in

Practising with a system

780 questions in 12 full tests, SAA-C03 (2026)
Every option explained — including the wrong ones
Readiness per exam domain, and drills for your weakest

Start free — 10 questions

Straight into the player. No account, no email.

Frequently asked questions

Are security groups stateful?

Yes. A security group is stateful: if it allows an inbound request, the response is allowed out automatically, and if it allows an outbound request, the response is allowed back in — regardless of the rules in the other direction. A network ACL is the opposite, stateless, so each direction is evaluated on its own and return traffic needs its own rule on the ephemeral port range.

When do I actually need a network ACL?

When you must explicitly deny — block a compromised CIDR range at a subnet's edge across every instance at once — because security groups are allow-only and cannot express a block. For ordinary instance access you reach for security groups instead and leave the network ACL at its default allow. The exam tell is the word 'deny' or 'block' applied subnet-wide.

Are these real exam questions?

No. They are original scenarios written for this page in the exam's style and difficulty. Reproducing real exam items violates the AWS certification agreement and can cost a candidate their certification — ours come with the reasoning attached instead.

Updated for SAA-C03 (July 2026). The sample questions above are our own work in the style of the exam — not real exam items. The exam itself is set and marked by the certification body.