A test file has 30 run blocks. Each uses its own setup module or a distinct state_key, none references another run's outputs, and the whole file runs one run at a time and takes too long. The authors want the independent runs to execute concurrently without splitting the file. Which change does this?
Select an answer to reveal the explanation.
Short Explanation
Run blocks are polite by default: they wait in single file. Flip parallel = true in the test block and you'll see the independent ones go through together. The trap is sharing a state_key, which forces them back into line.
Full Explanation
Terraform executes run blocks sequentially unless parallel execution is enabled. The optional test block accepts parallel = true, which applies to every run block in the file, and an individual run can opt out with parallel = false. Two runs can execute together only if both have parallel enabled, neither references the other's outputs, and they do not share a state file, where the state file is chosen by state_key or, without one, by the module source. The scenario already satisfies the independence rules, so enabling parallel in the test block is the missing step. Assigning one shared state_key does the opposite: runs that share a state file must wait for each other, so the file stays serial. parallel is evaluated per run, so setting it only on the last run block does not make earlier runs eligible; worse, a run with parallel = false acts as a synchronisation point that splits the file into groups. command is a run block attribute, not something the file-level variables block can set, and plan-only runs are not inherently concurrent. Exam caveat: the separate -parallelism option of terraform test governs how many plan and apply operations run at once; it does not replace the parallel attribute. Operational check: rerun terraform test and compare wall-clock time, and confirm runs that depend on outputs still report after the runs they reference.