Exercise 1: Why References (Not File Order) Build the Dependency Graph — Possible Solution
====================================================================

When a resource argument reads `data.aws_ami.ubuntu.id`, that value
literally doesn't EXIST until the `aws_ami` data source has actually
been read. Terraform parses every resource and data block's arguments
looking for exactly this kind of reference -- one block's output being
consumed as another block's input -- and from the full set of these
references across the whole configuration, it constructs a directed
graph: "aws_instance.web depends on data.aws_ami.ubuntu," and so on for
every other reference found anywhere in the files.

This is why file order is irrelevant: Terraform never reads the
configuration top-to-bottom and executes blocks in the order they
appear. It first builds the COMPLETE dependency graph from every
reference in every file (regardless of which file or what position),
THEN walks that graph, executing blocks with no unresolved dependencies
first, and resources that only depend on already-completed ones next --
running anything with no dependency relationship between them in
PARALLEL, since nothing requires one to finish before the other starts.
Two engineers could write `aws_instance.web` before `data.aws_ami.ubuntu`
in a file, or the reverse, and Terraform's actual execution order would
be identical either way, driven entirely by the reference, not the
text position.

WHY THIS WORKS AS AN ANSWER
------------------------------
This explains the actual mechanism (a value literally doesn't exist
until its source resolves, so the reference itself IS the dependency
Terraform detects) and correctly states the consequence for parallel
execution, not just "order doesn't matter" as an assertion.