Exercise 3: Why "Two Constructs" Doesn't Carry Over From AWS to Azure — Possible Solution
====================================================================

AWS genuinely does split network filtering across two separate real
constructs: security groups (stateful, applied at the instance/network
interface level) and NACLs (stateless, applied at the subnet level).
A team with AWS experience might reasonably expect Azure to mirror
this same two-construct division.

Azure's real model is structured differently. Rather than two
separate constructs each tied to one specific level, Azure uses a
SINGLE construct -- the Network Security Group (NSG) -- that is
itself stateful, and that can be applied at the subnet level, the
individual network interface level, or both at the same time. There
is no separate, stateless equivalent to AWS's own NACLs anywhere in
Azure's real model.

ANSWER: This assumption doesn't carry over because Azure doesn't
split filtering by level into two different construct types the way
AWS does -- it uses one real construct (the NSG) that can itself be
applied at either level, or both simultaneously. A team expecting to
configure "an instance-level thing" and "a separate subnet-level
thing" in Azure would be looking for a second construct that simply
doesn't exist in Azure's own real model; the same NSG type handles
both roles.

WHY THIS WORKS AS AN ANSWER
------------------------------
This correctly identifies the specific structural mismatch (two
constructs vs. one construct usable at multiple levels) rather than
vaguely saying "Azure networking works differently," and matches the
chapter's own explicit warn-box framing of this as a genuine
structural difference worth understanding directly, not just a
naming difference.