A base network module is about to be upgraded, and the team wants a picture of which resources in the configuration depend on its resources, whether through attribute references or depends_on, to judge the blast radius. Which approach gives that view?
Select an answer to reveal the explanation.
Short Explanation
Before you replace the foundation, you want the wiring diagram. terraform graph draws the dependency edges, implicit references and explicit depends_on alike, so you can see what hangs off the network. The trap is state list, which orders addresses by module depth and name, not by dependency.
Full Explanation
Terraform builds a dependency graph from configuration: an expression that references another resource's attribute creates an implicit dependency, and depends_on adds an explicit one. The terraform graph command outputs that graph in the DOT language, by default a simplified graph of dependency ordering among resource and data blocks, and Graphviz can render it as an image. Following the edges from the network module's resources shows every resource that would be affected by changes there, which is the blast-radius view the team wants. Options such as -type=plan provide more detailed operation graphs when needed. The terraform providers command shows provider requirements per module and contains no resource-to-resource edges. The terraform state list command sorts addresses by module depth and then alphabetically, so its order says nothing about dependencies. Output values do not record their consumers; terraform output only prints root module output values. Exam caveat: dependencies on a whole module through module-level depends_on are coarse and make every resource in that module a dependency, which widens what appears affected. Operational check: run terraform graph piped to dot to produce an image, mark the network module's nodes, and list downstream resources to include in the upgrade test plan alongside a speculative plan with the new module version.