CDK for Terraform (CDKTF) Program Design Prompt
Architect a CDK for Terraform codebase in TypeScript or Python — stacks, constructs, provider/module bindings, state, and synth-to-Terraform CI — so you get real programming languages without losing Terraform's plan/apply guarantees.
- Target user
- Engineers building IaC in TypeScript/Python who want Terraform underneath
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT
The prompt
You are a senior infrastructure engineer who has shipped large CDK for Terraform (CDKTF) codebases and understands where it shines and where it bites. I will provide: - Preferred language (TypeScript or Python) - Cloud(s) and the providers/modules I need - How many environments and accounts/subscriptions - Backend for Terraform state - Team's CDK/AWS-CDK familiarity Your job: 1. **When CDKTF is the right call** — honestly compare CDKTF vs plain HCL vs Pulumi for my case. Name the failure modes (provider binding churn, synth debugging, smaller community) up front. 2. **Project structure** — propose a layout: app entrypoint, one stack per env/region, shared constructs library, generated provider bindings location, and `cdktf.json` config. 3. **Stacks and cross-stack refs** — how to split stacks for blast-radius control and pass outputs between them via `TerraformOutput` and remote state data sources. 4. **Constructs** — design L2/L3 constructs that encapsulate opinionated defaults (tagging, naming, encryption), with typed props and validation. Show one example construct. 5. **Provider and module bindings** — `cdktf get`, pinning provider versions, and wrapping existing Terraform modules so you reuse the ecosystem. 6. **State and backends** — configure the remote backend in code, and explain how synth produces standard Terraform JSON that `terraform plan/apply` consumes. 7. **CI/CD** — the pipeline: `cdktf synth` to produce JSON, run `terraform plan` against it, gate on the plan, then apply. Show how to keep synth output deterministic and reviewable. 8. **Testing** — unit tests with the testing matchers (assert a resource exists with given props) and snapshot tests on synthesized output. 9. **Escape hatches** — `addOverride`/`escapeHatch` for attributes the bindings don't expose, used sparingly. Output as: (a) annotated project tree, (b) one example stack + one construct in my language, (c) the synth-plan-apply CI snippet, (d) a unit + snapshot test example, (e) a list of risks to revisit in 3 months. Prefer typed, tested constructs over clever metaprogramming; keep the synthesized Terraform readable.