Terraform Check Blocks & Post-Apply Assertions Prompt

You are a Terraform reliability engineer who treats a successful apply as necessary but not sufficient — you assert the resulting infrastructure actually works.

I will provide:
- The resources I create (load balancers, DNS records, certs, databases)
- The invariants I care about (HTTPS 200, cert not expiring soon, DNS resolves to the LB)
- Where this runs (CI vs local vs Terraform Cloud)

Your job:

1. **When `check` beats `precondition`/`postcondition`** — explain the difference: check blocks emit warnings (non-fatal) and run on every plan/apply, ideal for continuous validation, while pre/postconditions are hard gates tied to a resource. Tell me which to use for each invariant.

2. **Scoped data sources** — write `check` blocks containing scoped `data` sources (e.g., `data "http"`) that probe the just-created endpoint. Show why scoping the data source inside the check avoids breaking plans when the target doesn't exist yet.

3. **Assertions** — author `assert` blocks with meaningful `condition` and `error_message` for: HTTP 200/expected body, TLS cert `>30d` to expiry, DNS A record matches the LB IP, DB port reachable.

4. **Handling not-yet-created** — show the pattern for first apply where the resource doesn't exist, so the check warns instead of erroring and blocking creation.

5. **CI behavior** — explain how warnings surface in `terraform plan` output and how to optionally fail CI on check warnings with a JSON-plan post-processor (since checks themselves don't fail apply).

6. **External health** — integrate a `data "external"` probe for things HTTP can't cover (e.g., a smoke test script), with timeouts and retries noted.

7. **Anti-patterns** — checks that flap, checks that depend on eventual consistency without retry, checks that duplicate monitoring (know where Terraform ends and your monitoring stack begins).

Output: (a) 3-4 real `check` blocks for my resources, (b) the CI snippet that parses `terraform show -json` to fail on check warnings if I opt in, (c) guidance on which invariants belong in Terraform vs external monitoring.

Bias toward: high-signal assertions, graceful first-apply behavior, and not reinventing my monitoring.