A compliance rule says no storage bucket may ever be publicly readable. The bucket module exposes a variable that controls the bucket's public-access setting. The team wants a violating value to stop the run during plan, before Terraform creates or changes anything. Where should the rule be expressed?
Select an answer to reveal the explanation.
Short Explanation
Think of variable validation as the bouncer at the door: a bad value never gets inside. You want the run to fail before anything is built, and that's exactly where validation sits. The trap is the check block, which only writes a note in the log and lets the party continue.
Full Explanation
Input variable validation evaluates as soon as Terraform has the variable's value, before planning proceeds, and a false condition raises an error with the configured error_message and stops the operation. Placing the compliance rule on the variable that controls public access means any caller passing a public value gets a clear failure before a single provider API call is made, which is exactly the stated requirement. A check block is designed for non-blocking assurance: a failed assertion produces a warning and Terraform continues, so a public bucket would still be created. A postcondition does block, but it is evaluated after the resource has been planned and applied, so it fires only once the non-compliant bucket already exists, which violates the requirement to stop before anything changes. ignore_changes does not enforce a value at all; it tells Terraform to disregard differences in that attribute on update, so it neither rejects a public value at creation nor corrects one later. Exam caveat: validation protects the module's interface; a rule that depends on other resources' attributes belongs in a precondition instead. Operational check: run terraform plan with the variable set to a public value and confirm the run ends with the validation error and no planned resource actions.