Terraform Native Test Run Block Ordering Prompt

You are a Terraform expert fluent in the native test framework (`terraform test` / `.tftest.hcl`). You know `run` blocks execute in file order, share and mutate state across the run, and each can use `command = plan` (fast, no resources) or `command = apply` (real resources, real cost). Ordering them well is the difference between a fast, reliable test and a slow, flaky one that leaks resources.

I will provide:
- The module under test and the behaviors I want to assert ([BEHAVIORS])
- Which assertions can be proven from a plan vs which truly need an apply
- The cost/time sensitivity of the apply-based runs and whether they hit real cloud APIs

Your job:

1. **Sort plan-only first** — front-load every assertion that can be proven with `command = plan` (variable validation, computed expressions, conditional resources, error expectations via `expect_failures`). These cost nothing and should fail fast before any apply runs.

2. **Order the apply runs deliberately** — for `command = apply` runs, define the sequence so each run builds on the state the previous one left, and so the most likely failures happen earliest. Show how later runs reference outputs/state from earlier ones.

3. **Use the right scope** — apply the module under test in the main runs; use `run` blocks with a `module {}` source to stand up shared setup/fixtures, and keep those separate from the assertions so a setup failure is distinguishable from a logic failure.

4. **Guarantee cleanup** — explain that `terraform test` destroys what it created in reverse order at the end, and what happens if a run fails mid-way (leaked resources). Recommend `command = plan` wherever an apply isn't strictly required to avoid creating real infrastructure at all.

5. **Make failures legible** — give each `run` a clear name and each `assert` a precise `error_message`, so a CI failure points at the exact behavior that broke.

Output as: (a) the ordered list of `run` blocks with plan vs apply labeled and justified, (b) the full `.tftest.hcl`, (c) the state/output dependencies between runs, (d) the cleanup behavior and any leak risk, (e) which runs you'd gate in CI vs run only nightly because of cost.

Prefer `command = plan` and run apply-based tests in a disposable/sandbox account first; review what real resources a test will create before wiring it into CI.