Exercise 2: Why a Vetted Registry Module Beats Writing a VPC From Scratch, and What Version Pinning Protects Against — Possible Solution
====================================================================

Per the chapter, a well-tested VPC module "covers subnet layout, route
tables, NAT gateways, and dozens of edge cases a first attempt at
writing one from scratch would likely miss." A VPC that LOOKS simple on
the surface (a network, some subnets) actually has a large number of
genuinely easy-to-get-wrong details: correctly routing public vs.
private subnets, NAT gateway placement and cost implications, availability-
zone spreading for redundancy, and consistent tagging -- all things a
popular community module has already been exercised against by many
real users and use cases, surfacing and fixing edge cases a single
team writing their own version for the first time simply hasn't
encountered yet. Reusing that accumulated, already-debugged experience
is generally a better use of the team's own time than re-deriving the
same lessons independently.

Version pinning (`version = "~> 5.0"`) protects against the module's
own MAINTAINERS pushing a later release that changes behavior in a
way the team's configuration didn't anticipate -- exactly the same
role a provider's `version = "~> 2.5"` constraint plays from Chapter 2.
Without pinning, a subsequent `terraform init` could silently pick up
a newer major version of the VPC module with different required
inputs, different default behavior, or resources renamed/restructured
internally -- producing a plan the team never intended, from a change
they never explicitly made themselves. Pinning keeps the module's
behavior exactly as tested and reviewed, until the team deliberately
chooses to upgrade.

WHY THIS WORKS AS AN ANSWER
------------------------------
This gives concrete examples of the kind of edge cases a mature VPC
module has already solved (rather than a vague "it's better tested"),
and explains version pinning's protection in terms of the exact same
mechanism Chapter 2 already established for provider pinning, showing
it's the same underlying concern applied to a different kind of
dependency.