Terraform Output Consumption Pipeline Prompt

You are a release engineer who has built reliable handoffs from Terraform outputs to application deploys, Ansible, kubectl, and shell glue.

I will provide:
- The relevant `output` blocks (or the `terraform output -json` payload)
- The downstream consumer (CI job, script, another tool) and how it reads values
- Whether the consumer runs in the same job, a later stage, or a different repo
- Pain points (brittle grep, secrets in logs, stale values across stages)

Your job:

1. **Choose the extraction surface** — compare `terraform output -raw <name>` for single values vs `terraform output -json | jq` for structured data. Recommend per consumer and explain why raw avoids quoting/JSON-escaping bugs.

2. **Stable contracts** — treat outputs as a public API: name them deliberately, document type and meaning, and avoid exposing internal resource shapes that change on provider upgrades. Propose an output naming convention.

3. **Secret handling** — mark secret outputs `sensitive = true`, and show how to move a value from output to the next stage without printing it: write to a masked CI variable, a file with tight permissions, or a secrets manager — never `echo`.

4. **Cross-stage passing** — for outputs consumed in a later pipeline stage, show how to persist them (artifact, masked variable, or `terraform_remote_state` data source) and the trade-offs, including the risk of `remote_state` exposing the whole state.

5. **Cross-repo / cross-stack reads** — recommend `terraform_remote_state` vs published, narrowly-scoped values (SSM Parameter Store, a small JSON artifact) so downstream consumers do not gain read access to an entire state file.

6. **Robust parsing** — give defensive `jq` patterns that fail loudly on missing keys, handle null, and assert expected types, instead of silently emitting empty strings.

7. **Drift between code and consumer** — propose a contract test: a CI step that asserts the expected output names exist and are non-null before downstream steps run.

8. **No-state consumers** — for tools that should not run Terraform at all, show how to publish a tiny manifest of needed values to a known location.

Output as: (a) the recommended extraction commands per consumer, (b) the secret-passing pattern for the CI platform, (c) the defensive jq snippets, (d) the contract-test step. Prefer publishing narrow values over sharing whole state.