Variables, Local Values, and Outputs

What you will be able to do

• Distinguish input variable from type constraint in a realistic variables, local values, and outputs case.
• Interpret the delivery evidence and boundary associated with local value.
• Choose an appropriate action involving output value without exceeding the named operational scope.
• Verify sensitive value through an observable service result and reproducible handoff.

01

Frame Variables, Local Values, and Outputs

Use input variables, type constraints, local values, outputs, and sensitive-value boundaries to create clear and reusable OpenTofu module interfaces.

One service module must accept an environment name and instance count, derive a naming prefix, and publish the service address without exposing an access token.

Keep the delivery target, declared intent, execution evidence, reliability boundary, and recovery choice separate. Start with observable state and preserve enough context for another operator to reproduce the decision.

02

Input variable

An input variable is a module parameter supplied by its caller or root configuration. Within variables, local values, and outputs, this role answers a separate delivery or reliability question and keeps its own evidence.

Declare environment and instance count with descriptions. Apply that action to the named service case before widening the rollout, infrastructure scope, or incident response.

Respect this boundary: do not edit module source for each environment value. The observable result is specific: each invocation supplies explicit environment inputs.

03

Type constraint

A type constraint limits accepted variable shapes and improves early error messages. Within variables, local values, and outputs, this role answers a separate delivery or reliability question and keeps its own evidence.

Require a string environment and a numeric instance count. Apply that action to the named service case before widening the rollout, infrastructure scope, or incident response.

Respect this boundary: do not leave structured operational inputs completely unconstrained. The observable result is specific: invalid input types fail before resource changes begin.

04

Local value

A local value gives a readable name to an expression used inside its module. Within variables, local values, and outputs, this role answers a separate delivery or reliability question and keeps its own evidence.

Derive the service prefix once from the environment input. Apply that action to the named service case before widening the rollout, infrastructure scope, or incident response.

Respect this boundary: do not expose a local as part of the public module interface. The observable result is specific: all resource names use the same derived prefix.

05

Output value

An output publishes selected information from a module to callers or CLI users. Within variables, local values, and outputs, this role answers a separate delivery or reliability question and keeps its own evidence.

Return the service address with a clear description. Apply that action to the named service case before widening the rollout, infrastructure scope, or incident response.

Respect this boundary: do not expose internal objects that callers do not need. The observable result is specific: the caller receives the intended service address.

06

Sensitive value

Sensitive markings reduce accidental display but do not remove values from all state storage. Within variables, local values, and outputs, this role answers a separate delivery or reliability question and keeps its own evidence.

Mark the token input sensitive and protect the state that may contain it. Apply that action to the named service case before widening the rollout, infrastructure scope, or incident response.

Respect this boundary: do not treat a sensitive flag as encryption or secret storage. The observable result is specific: normal plan output omits the token and state access remains restricted.

07

Apply Variables, Local Values, and Outputs to One Service Change

Use one bounded delivery decision: One service module must accept an environment name and instance count, derive a naming prefix, and publish the service address without exposing an access token.

First, declare environment and instance count with descriptions. Then, require a string environment and a numeric instance count. Keep both observations attached to the exact revision, environment, or service window.

Next, derive the service prefix once from the environment input. After that, return the service address with a clear description. Close the work only after you mark the token input sensitive and protect the state that may contain it.

08

Recap Before Practice and Prove

Input variable: An input variable is a module parameter supplied by its caller or root configuration. In this service case, declare environment and instance count with descriptions. Preserve the boundary: do not edit module source for each environment value.

Type constraint: A type constraint limits accepted variable shapes and improves early error messages. In this service case, require a string environment and a numeric instance count. Preserve the boundary: do not leave structured operational inputs completely unconstrained.

Local value: A local value gives a readable name to an expression used inside its module. In this service case, derive the service prefix once from the environment input. Preserve the boundary: do not expose a local as part of the public module interface.

Output value: An output publishes selected information from a module to callers or CLI users. In this service case, return the service address with a clear description. Preserve the boundary: do not expose internal objects that callers do not need.

Sensitive value: Sensitive markings reduce accidental display but do not remove values from all state storage. In this service case, mark the token input sensitive and protect the state that may contain it. Preserve the boundary: do not treat a sensitive flag as encryption or secret storage.