Scalable Terraform configuration design practice questions

Input variable validation rules can reference other variables and objects in the same module (Terraform 1.9 and later).

The values are literals, so they are known before planning. Terraform 1.9 made validation conditions general expressions that may reference other input variables, so var.min_size is allowed and the comparison 2 >= 4 is false. Validation failure is an error that stops the run before a plan. The tempting distractor describes the pre-1.9 rule that a condition could reference only its own variable.

1. Check the Terraform version: 1.15 is well past 1.9.
2. Recall that validation may reference other variables since 1.9.
3. Evaluate the condition with the caller's values: 2 >= 4 is false.
4. Recall that a failed validation is an error raised before planning.

Exam tip: Since Terraform 1.9, a validation block can compare one input with another.

Preconditions express assumptions a specific resource makes; postconditions express guarantees an object provides to every consumer.

Only the DNS zone depends on DNS hostnames. A precondition in that resource's lifecycle block is checked while Terraform plans the zone, errors with a message about the zone, and documents the assumption next to the code that relies on it. A postcondition on the data source would claim the setting is guaranteed for every consumer, so configurations that only build subnets or route tables against VPCs without it would fail too. A check block never errors, and a variable validation describes the input rather than the resource that needs the setting.

1. Decide whether the rule is a guarantee for all consumers or an assumption of one consumer.
2. Here only the DNS zone relies on it, so it is an assumption.
3. Assumptions go in a precondition on the consuming resource.
4. Reject options that attach the rule to every consumer, to the input, or that only warn.

Exam tip: Put an assumption in a precondition on the resource that relies on it, not on the shared source.

Check blocks validate infrastructure behaviour without blocking operations, and HCP Terraform health assessments re-evaluate them continuously.

Two requirements decide: failures must not block, and the test must repeat between runs. Check blocks are the only custom condition whose failure is a warning, and a scoped data source inside the check keeps a failed HTTP read from erroring the run. Enabling health assessments on the workspace makes HCP Terraform re-run checks (with preconditions and postconditions) and alert. Postconditions and preconditions error; terraform validate never reaches the endpoint.

1. Pick the condition type whose failure is a warning: a check block.
2. Use a scoped data source inside the check so a failed read also stays a warning.
3. Add continuous re-evaluation: health assessments in HCP Terraform.
4. Reject options that error or that never contact the endpoint.

Exam tip: Check blocks warn instead of blocking, and health assessments re-run them between applies.

Sensitivity propagates to every value derived from a sensitive value, and an output exposing such a value must be declared sensitive.

The template includes var.db_password, so the whole string is sensitive. Terraform will not let an output expose a sensitive value unless the output is explicitly marked sensitive = true, so it raises an error during planning. It does not quietly redact the output or part of the string, and it never prints it in clear text.

1. Trace the output's value back to a sensitive input.
2. Recall that derived values inherit sensitivity.
3. Recall that an unmarked output exposing a sensitive value is an error.
4. Fix by adding sensitive = true to the output.

Exam tip: An output built from a sensitive value must be marked sensitive, or the plan fails.

sensitive = true controls display only; the value is still persisted in state and saved plans.

The sensitive argument redacts values in CLI output and carries the mark through every expression derived from them. It does not change what Terraform stores: a value used by a resource argument is written to state, and saved plan files also contain it. That is why state and plan artefacts must be protected by the backend and pipeline, and why ephemeral values and write-only arguments exist for secrets that must never be persisted.

1. Separate display from storage.
2. Sensitive changes display: redacted output, propagated marks.
3. Sensitive does not change storage: state and plan files keep the value.
4. Use ephemeral values or write-only arguments when storage itself is the risk.

Exam tip: Sensitive hides a value on screen; it does not keep it out of state or plan files.

Ephemeral resources produce values that are never persisted, and write-only arguments accept values without storing them in state or plan.

Both the generator and the consumer must avoid persistence. An ephemeral random_password exists only during the run, and password_wo is a write-only argument that Terraform never stores; because Terraform cannot detect changes to it, the provider pairs it with password_wo_version, which is stored and incremented to push a new value. A managed random_password leaks the secret into state on its own, and ordinary arguments cannot take ephemeral values.

1. List every place the secret could be persisted: the generator and the consumer.
2. Make the generator ephemeral so its result is never stored.
3. Make the consumer a write-only argument so the database resource does not store it.
4. Use the paired version argument to trigger rotation later.

Exam tip: To keep a secret out of state: ephemeral source plus write-only argument, rotated by its version argument.