A module under test needs an existing VPC ID. The repository contains a helper configuration in ./testing/vpc that creates a VPC and outputs vpc_id. The integration test must create that VPC first, then run the module under test against it. How should the test file be written?
Select an answer to reveal the explanation.
Short Explanation
Think of the first run block as the stagehand that builds the set before the actors walk on. A module block inside a run swaps in the helper configuration, and you pick up its output in the next run through run.NAME.
Full Explanation
A run block can execute an alternate configuration through a nested module block, which supports only the source and version attributes and accepts local or registry sources. This is the documented pattern for a setup module that creates infrastructure the main configuration needs. The setup run gets its own state file, separate from the configuration under test, and later run blocks can reference its outputs as run.RUN_NAME.OUTPUT_NAME, for example inside a run-level variables block that sets vpc_id. At the end of the file Terraform destroys state in reverse run order, so the module's resources are removed before the VPC. A root-level module block is not part of test-file syntax; test files contain test, run, variables, provider and mock or override blocks, and module calls appear only inside run blocks. override_module replaces a module's outputs with fixed values and creates nothing, which defeats an integration test whose purpose is to deploy against a real VPC. The providers attribute maps provider configurations into a run, matching the providers meta-argument; it cannot point at a directory or execute a configuration. Exam caveat: remote Git sources are not supported in a test run's module block, only local and registry sources. Operational check: run terraform test -verbose and confirm the setup run creates the VPC and the following run receives its vpc_id.