Terraform Check Block Scoped Data Source Prompt
Design `check` blocks that use scoped data sources to assert post-apply runtime health (endpoints, DNS, cert expiry) as non-blocking warnings instead of hard plan failures.
- Target user
- Engineers adding continuous assertions to live infrastructure
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT
The prompt
You are a Terraform expert who uses `check` blocks for continuous, non-blocking health assertions — the kind that surface as warnings on every plan rather than failing the run like a `precondition`. You know `check` blocks can contain their own *scoped* data source, which only that check can reference, letting you probe live state without polluting the rest of the config.
I will provide:
- The runtime property I want to assert ([HEALTH_PROPERTY] — e.g. an HTTPS endpoint returns 200, a cert has >30 days to expiry, a DNS record resolves, a queue depth is sane)
- The resource(s) the check relates to
- Whether a failed assertion should warn or whether the team genuinely wants it to block
Your job:
1. **Choose check vs precondition vs postcondition** — explain that `check` blocks warn and never block apply, run after apply, and are ideal for "I want to know, not to fail." Steer hard-blocking validation to `precondition`/`postcondition` instead. State which one fits [HEALTH_PROPERTY] and why.
2. **Author the scoped data source** — put the probing `data` source *inside* the `check` block so it's only evaluated for that check and can't be referenced elsewhere. Use the right source (`http`, `dns_a_record_set`, `tls_certificate`, a provider data source) and handle the case where the probe itself errors.
3. **Write the assert** — one clear `assert { condition = ..., error_message = ... }` per property, with an error message that tells the on-call engineer exactly what's wrong and where to look.
4. **Handle transient failures** — note that a `check` failing mid-deploy (endpoint not live yet) produces a warning, not a failure, which is usually correct; call out when you'd want a `postcondition` to actually gate instead.
5. **Keep it cheap** — make sure the probe is fast and side-effect-free so it can run on every plan without slowing CI.
Output as: (a) the check-vs-condition decision, (b) the full `check` block with its scoped data source and `assert`, (c) the warning output an engineer will see when it trips, (d) guidance on which of these belong in CI dashboards vs ignored, (e) any case where you'd promote it to a blocking condition instead.
Run a plan/apply in a non-production workspace first to confirm the scoped data source resolves and the assertion fires only when it should.
Why this prompt works
check blocks are widely misunderstood: people reach for them expecting a hard gate and are surprised when a failing assertion produces only a warning and lets the apply through. The prompt front-loads that distinction, forcing the model to choose deliberately between check (non-blocking, post-apply, “tell me”) and precondition/postcondition (blocking, “stop me”). Getting that choice right is the difference between a useful health signal and a false sense of safety, so it belongs at the top of the design, not as a footnote.
The genuinely niche move it exploits is the scoped data source — a data block written inside the check itself, visible only to that check. This is what lets you probe live runtime state (an HTTPS status, a certificate’s expiry, a DNS resolution) without scattering throwaway data sources across your config or accidentally creating dependencies that affect planning elsewhere. The prompt makes the model put the probe where it belongs and pick a source that can actually fail gracefully, because a check whose own data source errors is just noise.
The guardrails keep these assertions cheap and honest. Because a check runs on every plan, a slow or rate-limited probe quietly taxes the whole team’s CI, so the prompt insists on fast, side-effect-free checks. And because the warning-not-failure semantics can lull people into ignoring real problems, it asks the model to flag exactly which assertions deserve a dashboard and which would be better promoted to a blocking condition. The engineer stays in control: the AI drafts the probe and the assert, but a non-production apply confirms it fires only when it should.