Exercise 2: The Post-March-2026 Default Outbound Access Trap — Possible Solution
====================================================================

Before 31 March 2026, newly created Azure virtual networks provided
real default outbound internet access automatically -- a VM deployed
into a fresh VNet could typically reach the internet with no extra
configuration. As of 31 March 2026, this real default changed: new
virtual networks now default to private subnets with NO default
outbound internet access at all.

The team's expectation -- that a newly deployed VM would reach the
internet for OS updates automatically -- reflects the OLD, no-longer-
current default behavior. Since their VNet was created after the
change took effect, the VM has no real path to the internet at all
until an explicit outbound method is configured.

ANSWER: This expectation is likely wrong because it reflects Azure's
own outdated default from before 31 March 2026 -- the VM deployed
into a VNet created after that date will have NO outbound internet
access unless the team explicitly adds one. They would need to
configure an explicit outbound method themselves, such as attaching
a NAT Gateway to the subnet (the chapter's own recommended, simplest
option), assigning the VM an instance-level public IP, or using a
load balancer's own outbound rules.

WHY THIS WORKS AS AN ANSWER
------------------------------
This correctly identifies that the real platform default itself
changed on a specific, real, documented date, rather than treating
"no internet access" as a generic troubleshooting mystery, and names
a specific, concrete real fix (attaching a NAT Gateway) rather than
just saying "configure outbound access" vaguely.