TF-Associate-004 - Terraform configuration (21% of the exam) - Section 4g

Validate configuration using custom conditions.

Variable validation blocks, preconditions and postconditions, and the check block assert assumptions and fail fast with a clear message. Candidates should place the right construct for a stated guarantee and understand when a precondition is evaluated relative to plan and apply.

variable validationprecondition and postconditioncheck blockcustom condition error message

Practice question for this objective

Free sampleTerraform configurationhard

In current Terraform, how does a variable validation block differ from a resource precondition in terms of when its check is evaluated?

variable "instance_count" {
  type = number
  validation {
    condition     = var.instance_count > 0
    error_message = "The instance_count must be greater than zero."
  }
}
  • ABoth are evaluated only during apply, so neither can stop an invalid input from reaching the plan phase.
  • BVariable validation is checked as the input value is assigned, before most other evaluation, whereas a precondition is checked during plan and apply once the resource it guards is being evaluated. Correct
  • CVariable validation runs after the resource is created so it can inspect computed attributes, while a precondition runs before any input is read.
  • DBoth run at exactly the same point, and the only difference is that validation can reference other resources while a precondition cannot.
Understand that variable validation is checked early on input assignment whereas preconditions are evaluated when the guarded object is processed during plan and apply. A validation block is scoped to the variable and evaluated as the value is bound, giving fast feedback, while a precondition attaches to a resource, data source, or output and is evaluated during plan and apply when that object is resolved, so the two conditions catch problems at different stages.

Why A is wrong: This is tempting because both are custom conditions, but validation runs early on the input and preconditions are checked during plan as well as apply, not apply alone.

Why B is correct: A validation block tests the input variable itself and fails early on assignment, while a precondition is tied to a resource or output and runs when that object is evaluated during plan and apply.

Why C is wrong: The ordering is reversed: validation cannot see computed attributes because it runs on the raw input, and a precondition does not run before inputs are read.

Why D is wrong: They do not run at the same point, and validation is actually the more restricted of the two because it may reference only the variable itself, not other resources.

See more TF-Associate-004 practice questions, answers explained.

Exam traps in Terraform configuration

Answers that look right on this material and are not. Each one is a distractor from a different question in the TF-Associate-004 bank for this domain.

  • Only during apply, once Terraform begins creating or updating the affected resources.

    Why it is wrong: This is tempting because apply is where changes happen, but variable validation is a plan-time check and does not wait for apply.

  • The error_message is optional metadata that Terraform logs only in debug mode and never shows to the operator.

    Why it is wrong: This is tempting because messages often feel like logging detail, but the argument is required and is shown to the operator when the condition fails, not hidden behind debug mode.

  • It halts the plan with an error and refuses to produce a plan until the endpoint returns 200.

    Why it is wrong: This is how a precondition behaves, but a check block does not block the plan, so treating it as a hard failure is wrong.

More in this domain

Back to all Terraform configuration objectives, or the TF-Associate-004 cert hub.

Examworthy is not affiliated with or endorsed by HashiCorp. Original, blueprint-aligned practice material only.