A test file uses mock_provider "aws" {} plus override_resource { target = aws_s3_bucket.logs, values = { arn = "arn:aws:s3:::logs" } }. A run block with command = plan asserts that output.bucket_arn equals that ARN, but the assertion fails because the value is unknown. The run must remain a plan-only run. Which change fixes it?
Select an answer to reveal the explanation.
Short Explanation
Here's the catch: mocked and overridden values show up at apply time by default, so a plan-only run just sees (known after apply). You don't switch to apply to fix it; you tell Terraform to generate the values during plan with override_during = plan.
Full Explanation
By default a mocked provider, and any override_resource, override_data or override_module block, supplies its values during the apply operation; during plan the affected computed attributes remain unknown. That is why an assertion in a command = plan run block cannot compare the ARN: the output still reads as known after apply. The override_during attribute accepts plan or apply. Set on the override_resource block it changes timing for that one target; set on mock_provider it changes the default for everything that provider mocks, and a block-level setting overrides the provider-level one. With plan, Terraform generates the values at plan time and reuses them during apply. Disabling refresh in plan_options changes whether existing objects are re-read, not when override values are produced, so the value stays unknown. Moving the value into mock_resource defaults does not help, because those defaults follow the same apply-time rule unless override_during is set. expect_failures applies only to custom conditions on checkable objects; an unknown value is not a custom-condition failure, so the run would still fail. Exam caveat: switching to command = apply would also make the value known, but the stated constraint keeps the run plan-only. Operational check: rerun terraform test and confirm the plan-mode run reports the ARN as a known value and the assertion passes.