Terraform Variable Defaults Checker

Introduction

Terraform input variables define a module's public contract. A caller sees the variable name, type, description, default value, validation rules, and sensitivity flags before they see most of the module's internal choices. That contract decides which inputs are required, which values are optional, and which defaults may quietly shape a plan.

Defaults are useful when they describe a safe ordinary case, such as an empty tag map or a standard list of endpoint services. They become risky when they hide a password, depend on another expression, mismatch the declared type, or let an explicit null bypass the intended fallback. Missing defaults are not always wrong, because some module inputs should be required, but they should be deliberate rather than accidental.

The practical question is whether the module will behave predictably for callers. A required VPC ID can be a clean contract. A required region string without a description or validation block is harder to defend. A secret-like variable with a concrete default should usually stop release review until the value is removed or supplied through a safer runtime path.

A variable default audit is still a review aid. It can identify patterns that deserve attention, sort likely remediation work, and make the interface easier to discuss in a pull request. It cannot prove that provider behavior, workspace variables, policy rules, or a future plan will be correct.

Technical Details

Terraform treats an input variable without a default argument as required. When a default is present, callers may omit that input and Terraform uses the declared fallback. If a type constraint is also present, the default must be compatible with that type. Terraform also requires variable defaults to be literal values rather than references to other objects or computed expressions.

Sensitive variables need a different review path. Marking a variable sensitive redacts values in Terraform output, but ordinary sensitive values can still be present in state and plan data. Terraform 1.10 and later adds ephemeral variables for temporary values that should be available during a run without being written to state or plan files, subject to Terraform's allowed ephemeral contexts.

Null behavior is another common source of surprises. With Terraform's default nullable behavior, a caller can pass null to a variable, and when a default is also declared that explicit null can override the fallback. Setting nullable = false makes that variable require a non-null value, which is often clearer when a concrete default is meant to stand in for omitted input.

Rule Core

Severity And Decision Logic

The scanner is intentionally textual. It reads variable blocks, top-level arguments, and validation block counts from submitted Terraform-style text. It does not evaluate provider schemas, workspace variable precedence, module calls, policy engines, or real plans, so follow the audit with Terraform's own validation and planning workflow when the change matters.

Everyday Use & Decision Guide

Start with the module or stack label, then paste the variable declarations or load a Terraform-related text file. Use the module contract profile when required inputs are normal for the module. Switch to default hygiene when most non-sensitive inputs should have safe fallbacks. Use strict release when a public or reusable module should expose very few required non-sensitive values.

Read the top summary before the tables. Blocked means at least one critical finding exists. High-impact review means the first pass should focus on high rows. A clear or polish-level status can still contain useful cleanup work, especially for missing descriptions, nullable defaults, or validation hints.

• Use Default Audit Snapshot to brief a pull request or release ticket.
• Use Variable Ledger to inspect every variable's default posture, type, sensitivity, nullable setting, validation count, and top signal.
• Use Remediation Queue when you need the sorted list of concrete fixes.
• Use Default Exposure Chart to see whether risk is concentrated in required inputs, null defaults, sensitive defaults, empty defaults, or concrete defaults.
• Raise the row limit when a large module hides lower-priority findings from the visible remediation table.

If the source contains secret-like sample values, treat the editor content as sensitive even when the result tables mask default expressions. The analysis runs in the browser after the page loads, and selected files are read locally by the page, but copied source text and downloaded review artifacts can still carry variable names, module labels, and finding details.

A good first pass is to clear critical and high findings, then rerun with the same profile. After the headline no longer shows high-impact work, review the low findings for contract clarity before handing the module to callers.

Step-by-Step Guide

1. Enter a meaningful Module or stack label, such as modules/vpc-endpoints, so snapshot rows and exported evidence stay tied to the right review.
2. Choose Default policy. Keep Module contract for ordinary module reviews, use Default hygiene when safe fallbacks are expected, or use Strict release for a hardened release surface.
3. Paste Terraform variable blocks into Variables source, browse a file, drop a supported text file onto the editor, or load one of the samples to understand the output shape.
4. Open Advanced if the module targets Terraform before 1.10 or if the visible remediation list needs a different row limit.
5. Check the warning panel before trusting the tables. Empty input, text with no variable blocks, or an unmatched brace means the current source needs attention.
6. Read Default Audit Snapshot for the headline decision, then inspect Remediation Queue from top to bottom.
7. Use Variable Ledger to confirm whether individual rows have the expected type, default expression label, sensitivity label, nullable setting, and validation count.
8. After edits in the real module source, paste the revised variable blocks and confirm the high-impact count, sensitive defaults count, and remediation rows changed as expected.

Interpreting Results

The high-impact number counts critical and high findings, not total findings. One sensitive default can matter more than many missing descriptions. When the headline shows high-impact work, use the remediation table before spending time on polish rows.

Default coverage is descriptive rather than a pass/fail grade. A module with required subnet IDs can be healthy with low default coverage. A module with required region, environment, size, or mode strings may need better defaults, stronger descriptions, or validation blocks depending on the selected profile.

Sensitive defaults should be read conservatively. The result can flag explicit sensitive = true variables and secret-like names, and it masks sensitive default labels in outputs, but the original source area still contains whatever was pasted. If a real credential appeared in code, handle rotation and state review outside the checker.

A clear result does not validate Terraform syntax end to end. It means the scanner did not find the supported default, sensitivity, type, nullable, validation, or deprecation signals in the submitted variable blocks. Run Terraform validation and planning before treating the module contract as ready.

Worked Examples

Module contract with a required VPC ID

A module declares variable "vpc_id" with type = string, a clear description, and no default. Under Module contract, that can remain a required input without creating a missing-default finding. The Variable Ledger should show Required input, and the result is strongest when the signal is clear or limited to other low-priority contract notes.

Strict release finds a missing fallback

A reusable module declares variable "region" with type = string and no default. Under Strict release, the missing non-sensitive default becomes a high finding. The Remediation Queue should tell the owner to add a safe literal default or move the variable out of the strict release surface.

Secret-like sample value blocks release review

A variable named admin_password has sensitive = true and default = "demo-password". The ledger classifies the posture as Sensitive default, while the remediation row asks for the concrete default to be removed and supplied through a secure variable path. If the value resembles a known token or private key pattern, the severity becomes critical and the risk decision becomes Blocked.

Computed default needs a redesign

A variable declares default = var.default_region. Terraform variable defaults must be literal, so the checker reports a high non-literal default finding. The next change belongs in module design: keep the variable required, use a literal fallback, or move computed behavior into locals or caller input.

Broken paste stops the review

A copied variable block is missing its closing brace. The warning panel reports the unmatched block, and the parsed variable count may be lower than expected. Fix the source before reading the snapshot or exporting rows, because a partial scan can make the module look cleaner than it is.

FAQ:

Glossary:

Input variable

A Terraform module parameter declared with a variable block and supplied by a caller or default.

Default posture

The checker's classification of a variable as required, null default, empty default, concrete default, or sensitive default.

Sensitive variable

A variable marked or inferred as containing protected data that should not appear plainly in routine output.

Ephemeral variable

A Terraform 1.10+ variable intended for temporary values that should be available during a run without being stored in state or plan files.

Nullable

A Terraform variable setting that controls whether a caller may pass null for the variable itself.

Validation block

A nested rule that checks whether a variable value meets module-specific requirements beyond the basic type constraint.

References:

• Terraform variable block reference, HashiCorp.
• Manage sensitive data in your configuration, HashiCorp.
• Terraform validate command reference, HashiCorp.