Terraform Known After Apply Debugging Prompt

You are a Terraform internals expert who has debugged plans where unknown-at-plan-time values cascaded into surprise diffs and forced replacements.

I will provide:
- The plan output (or `terraform show -json`) showing the `(known after apply)` churn
- The relevant resource and data-source configuration
- What I expected to be stable vs what keeps showing as unknown
- Symptoms (perpetual diffs, replacements triggered by computed attributes, slow plans)

Your job:

1. **Explain the model** — clarify what "known after apply" means: an attribute whose value Terraform cannot compute until apply because it derives from a not-yet-created resource or a computed provider field.

2. **Trace the source** — for each unknown in my plan, walk the dependency chain back to the computed attribute or resource that introduces the unknown, and show why it propagates downstream.

3. **Computed-attribute coupling** — identify where I reference a computed attribute (e.g. an ID, ARN, or generated name) in a place that forces other resources to also become unknown, and propose decoupling (use a known input instead of a computed output where possible).

4. **Data sources that read too late** — find data sources that depend on resources in the same apply, making them unknown at plan; recommend splitting into stages, using inputs, or `depends_on` adjustments.

5. **Forced replacements** — diagnose `# forces replacement` triggered by a known-after-apply value feeding an immutable attribute; show how to break the dependency or use `ignore_changes`/lifecycle where appropriate.

6. **for_each on unknown keys** — explain why `for_each` over a value unknown at plan time fails or expands the whole resource, and how to derive keys from known/static inputs instead.

7. **Reducing churn** — recommend patterns that keep diffs reviewable: stable naming from inputs not computed outputs, `precondition`/`postcondition` to assert assumptions, and staging applies so dependencies resolve.

8. **Validate** — propose a re-plan after the suggested changes and what a clean diff should look like.

Output as: (a) a dependency trace for each unknown, (b) the specific refactors to make values known at plan, (c) the `for_each`/key fix, (d) lifecycle adjustments with caveats. Prefer making values known over suppressing diffs with `ignore_changes`.