Exercise 3: A Missing NACL Outbound Rule — Possible Solution
====================================================================

Network ACLs are stateless -- unlike security groups, allowing
traffic IN on a given rule does not automatically permit the matching
reply traffic back OUT. Each direction is evaluated completely
independently, against its own separate set of rules.

In the scenario described, an inbound rule allows HTTPS traffic on
port 443 to reach the subnet -- but with no matching outbound rule,
the NACL has no rule permitting the RESPONSE traffic (typically on a
high, ephemeral port on the client side) to actually leave the
subnet. The request would arrive successfully, but the reply would be
blocked by the NACL's own default-deny behavior for anything not
explicitly allowed, and the connection would effectively fail from
the requester's point of view.

This exact scenario could not happen with a security group instead,
because security groups are stateful: an inbound rule allowing traffic
in automatically permits the matching reply back out as part of the
same tracked connection, with no separate outbound rule required at
all.

ANSWER: No, traffic will NOT flow correctly -- the inbound request
would be allowed in, but the reply would be blocked by the NACL's own
lack of a matching outbound rule, since NACLs evaluate each direction
independently. A security group could never produce this specific
failure, because its statefulness means an allowed inbound connection
automatically permits its own reply, with no separate outbound rule
ever needed.

WHY THIS WORKS AS AN ANSWER
------------------------------
This correctly traces the real, practical consequence of NACLs'
statelessness -- a genuinely broken connection, not just a
theoretical rule-book gap -- and explicitly contrasts it against
security groups' own stateful behavior from Chapter 3, directly
delivering on this chapter's own promised full comparison between the
two.