An integration test for an S3 module has run blocks with no command attribute and real AWS credentials. A new engineer asks what happens to the buckets the test creates once terraform test finishes. Which answer is correct?
Select an answer to reveal the explanation.
Short Explanation
Here's the deal: a run block without a command is a full apply, so you're really building buckets. Terraform cleans up after the whole test file finishes, not after each run, and it tells you about anything it couldn't tear down.
Full Explanation
The command attribute of a run block defaults to apply, so a run with no command performs a complete apply against real providers and creates real infrastructure. Terraform keeps the state for each test file in memory, separate from any backend or workspace state for the configuration, and when the file completes it attempts to destroy every resource it created. When alternate modules are involved, it destroys state files in reverse run block order so that dependent objects, such as objects inside a bucket, are removed before the bucket itself. If cleanup fails, Terraform reports the resources it could not destroy along with diagnostics. Plan is not the default; it must be requested with command = plan, which is how authors write unit-style tests that create nothing. The configured backend is not used by terraform test at all, so the buckets never appear in workspace state waiting for a manual destroy. Cleanup is not per run block: later runs can build on earlier runs' resources, which is why destruction waits until the whole file has finished. Exam caveat: because cleanup can fail, HashiCorp recommends dedicated test accounts that can be routinely purged. Operational check: run the suite, read the end of the output for any could-not-destroy list, and confirm in the AWS console that no test buckets remain.