Terraform Output Complete Guide: Retrieving and Sharing Results (Associate Prep & Real-World)

Terraform outputs are the interface that exposes important identifiers and endpoints of the resources you build. Bad design leads to incidents: values you cannot fetch, leaks, or broken pipelines.

This article walks through defining outputs, retrieving them safely from the CLI, sharing them across modules and stacks, and handing them off to CI/CD — organized around the angles the Associate exam tests most often.

Output Basics: Role, Definition, and Caveats

An output is a value that a root module (or child module) exposes to the outside. After apply, it is written to the state file and can be referenced from the CLI or other code. Note that at plan time the value may still be undetermined (known after apply).

Adding sensitive = true masks the value in the standard CLI display. The raw value is still stored in state, however, so protecting the state (backend access control, encryption) is a prerequisite.

• Where to define: in outputs.tf or similar files in the root or child module
• Key arguments: value (required), description (optional), sensitive (optional)
• Dependencies: automatically depends on resources and modules referenced in value
• At plan time, it can appear as 'known after apply' — fetch after apply as a rule

Minimal outputs.tf (with a sensitive value)

output "bucket_name" {
  description = "S3 bucket name that stores app artifacts"
  value       = aws_s3_bucket.app_bucket.id
}

output "db_password" {
  description = "Initial DB user password (display is masked)"
  value       = random_password.db.result
  sensitive   = true
}

CLI Retrieval: Choosing the Right terraform output Mode

terraform output lists post-apply output values or fetches them individually. Use the bare form for humans, -json for machine-readable consumption, and -raw when you need a plain string.

Sensitive outputs are masked in the standard display. -json returns JSON that includes the value (with a sensitive flag), which is convenient for automation but risks leaks via logs. -raw is for strings only and may refuse or mask sensitive outputs.

• terraform output list of outputs (sensitive values masked)
• terraform output name a single value (sensitive values masked)
• terraform output -json machine-readable JSON (includes sensitive values, flagged with sensitive: true)
• terraform output -raw name raw string output (for non-sensitive strings)

Output flow (definition → state → retrieval & sharing)

Common retrieval commands

# List (sensitive values masked)
terraform output

# Fetch a single value (sensitive values masked)
terraform output bucket_name

# Machine-readable (includes sensitive values — handle logs with care)
terraform output -json | jq '.bucket_name.value'

# Plain string (for non-sensitive strings)
terraform output -raw bucket_name

# Parse the full state as JSON (when you want fields beyond outputs)
terraform show -json | jq '.values.outputs'

Module Outputs and Parent-Child Composition Design

A child module's output can be referenced from the parent as module.<name>.<output_name>. Re-exposing (wrapping) it from the parent stabilizes the external interface and makes it resilient to internal implementation changes.

When you want to return several things at once, using an object or map as value keeps consumption simple. Outputs do not carry explicit type declarations, but you can pass an object as the value.

• Design the interface in the order child → parent → external
• Values are finalized only after apply, so upstream dependencies must also respect apply order
• Avoid name collisions and bloat — keep outputs to a meaningful minimum

Example: re-exposing a child module's output from the parent

# child/outputs.tf
output "vpc" {
  description = "Key VPC attributes"
  value = {
    id     = aws_vpc.main.id
    cidr   = aws_vpc.main.cidr_block
    rt_ids = [for r in aws_route_table.this : r.id]
  }
}

# root/main.tf
module "network" {
  source = "./child"
  # ...
}

# root/outputs.tf
output "vpc_id" {
  value       = module.network.vpc.id
  description = "VPC ID consumed by the application"
}

Sharing Across Stacks: When and How to Use terraform_remote_state

When you need to reference outputs in a different state, data "terraform_remote_state" is the tool. It fits separated topologies — for example, the application layer reading a VPC ID from the network layer.

It creates an implicit cross-stack dependency, so you must manage apply order (run network → app in CI) and set access permissions on the referenced state. If the coupling becomes problematic, consider a single-repo root/child module layout instead.

• Specify backend and config correctly (S3, AzureRM, GCS, etc.)
• Read-only. Be aware that updates to the referenced state may not propagate immediately
• Control execution order in the pipeline to avoid concurrent-apply conflicts

Referencing another state's outputs via terraform_remote_state

data "terraform_remote_state" "network" {
  backend = "s3"
  config = {
    bucket = "tfstate-shared-bucket"
    key    = "envs/prod/network/terraform.tfstate"
    region = "ap-northeast-1"
  }
}

# Usage (consume the VPC ID)
resource "aws_subnet" "app" {
  vpc_id            = data.terraform_remote_state.network.outputs.vpc_id
  cidr_block        = "10.0.1.0/24"
  availability_zone = "ap-northeast-1a"
}

CI/CD Handoff: JSON Output and Safe Sharing Patterns

For automation, use terraform output -json, extract only the keys you need, and pass them as artifacts or environment variables. Use masking and permission separation to keep sensitive values out of logs.

Outputs cannot be fed back as resource inputs directly (they exist to expose values externally), so it is simplest to generate files via the CLI. When -raw is not applicable, fall back to -json with jq.

• Export only the keys you actually need (the necessary-and-sufficient principle)
• Prefer a secure secret store (Vault, etc.) for sensitive values
• Enable access control, encryption, and versioning on the state backend

Example CI steps (JSON → .env/file output)

# 1) Save to JSON
terraform output -json > outputs.json

# 2) Extract just the values you need into .env (mask/skip sensitive ones)
VPC_ID=$(jq -r '.vpc_id.value' outputs.json)
echo "VPC_ID=$VPC_ID" >> app.env

# 3) Convert to another format (for system configuration, etc.)
jq '{service_url: .service_endpoint.value, bucket: .bucket_name.value}' outputs.json > runtime_config.json

Associate Exam Hot Topics and Pitfalls

Outputs should be retrieved after apply as a rule — at plan time they can be unknown. sensitive=true masks CLI output; it does not encrypt state. -json includes sensitive values, so be careful with logs.

Cross-stack references are possible via data.terraform_remote_state, but the recommended approach is explicit dependency management through modularization. -raw is string-only and cannot be used with composite types.

• Retrieve with terraform output after apply (plan is not enough)
• sensitive only suppresses display — protecting state is the real job
• -json is for automation; -raw is for non-sensitive strings
• For cross-state references, mind permissions, ordering, and coupling

What known after apply looks like

# Plan display (conceptual)
# + output "bucket_name" {
#     value = (known after apply)
#   }
# -> After apply, retrieve the finalized value with terraform output

Check Your Understanding

Frequently Asked Questions