What does the `terraform graph` command produce, and how do you actually make use of its output?

## What the command does `terraform graph` asks Terraform to build its dependency graph and then serialise it in the DOT language, the plain-text format Graphviz reads. It prints that text to stdout and stops. There is no window, no image, no interactive viewer — rendering is your job: ``` terraform graph | dot -Tsvg > graph.svg ``` That requires Graphviz installed locally (`dot` is its command-line renderer). Without it you just get several hundred lines of `"node_a" -> "node_b"` on your terminal, which is occasionally enough: grepping the DOT text for a resource address shows every edge it participates in, without rendering anything. ## The options worth knowing `-type=plan` selects which of Terraform's internal graphs to emit; the plan graph is the one that matches what you are usually reasoning about. `-plan=path` builds the graph from a saved plan file instead of from the configuration. And `-draw-cycles` colours the edges that form a loop, which turns a wall of nodes into a picture with an obvious red ring: ``` terraform graph -draw-cycles | dot -Tpng > cycles.png ``` That last one is the reason most engineers ever run the command. When `Error: Cycle:` lists a dozen members and the mutual reference is buried inside a `for` expression or a generated module, the drawing finds it faster than reading code. ## Why the output is harder to use than people expect The graph Terraform walks is not the tidy diagram of your resources. It contains nodes for provider configurations, variables, locals, outputs, module expansion and internal bookkeeping, and it does not collapse them for presentation. A root module with sixty resources produces a picture with several hundred nodes and no useful layout — technically correct, humanly unreadable. So the honest framing is: `terraform graph` answers a question you already have. "Why does this instance wait for that policy?" or "where does this loop close?" are answerable. "Show me how my infrastructure fits together" is not — for that, a hand-drawn architecture diagram or the module structure itself communicates far better. It is also worth saying plainly that the output format is an implementation detail. As of Terraform 1.x the command remains available, but the node naming and structure have changed across versions and are not a stable contract. Parsing it in CI to enforce a rule is a fragile idea; the plan file (via `terraform show -json`) is the machine-readable surface, not this. ## Alternatives people reach for When the goal is understanding rather than debugging, most teams get further with cheaper tools: reading the plan output, which already lists what will change and in what shape; grepping for a resource address to find every reference to it; or keeping a diagram of modules and their inputs and outputs, which is the level a human actually reasons at. Third-party visualisers exist and consume the JSON plan rather than DOT, which is the more durable input. ## In an interview This is a small question, and the strong answer is small and honest: DOT to stdout, pipe to Graphviz, `-draw-cycles` for loops, unreadable at scale, do not depend on the format. Candidates who oversell it — claiming they generate architecture diagrams from it for stakeholders — usually have not run it on anything large.