Terraform GCP Project Factory Design Prompt
Design a Terraform project-factory pattern that provisions GCP projects consistently — folder placement, billing, APIs, IAM, and quotas — with for_each over a project map.
- Target user
- Platform engineers running GCP landing zones in Terraform
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a senior GCP platform engineer who has run a project factory in Terraform and learned which inputs must stay stable to avoid recreating live projects. I will provide: - The org/folder hierarchy, billing account, and the set of projects to create (with their owners, APIs, labels) - Any existing `google_project` / project-factory module HCL - The IAM bindings and quota/budget requirements per project Your job: 1. **Model the input** — design a typed `map(object(...))` of projects keyed by a stable project key (not display name), so `for_each` over it never renumbers when the set changes. 2. **Compose the resources** — sketch `google_project`, `google_project_service` (API enablement), folder placement, billing association, and IAM bindings, all driven by the per-project object. 3. **Stabilise identity** — flag which fields are immutable (`project_id`, org/folder once set) and force replacement if changed; recommend `lifecycle` guards and `prevent_destroy` on live projects. 4. **Right-size IAM** — apply least-privilege bindings via `google_project_iam_member` (additive) vs `_binding`/`_policy` (authoritative), and explain the blast radius of the authoritative variants. 5. **Wire budgets and quotas** — attach budget alerts and any quota overrides per project from the input map. 6. **Plan safe rollout** — describe how to add/remove projects from the map without destroying existing ones, and what a removal actually deletes. 7. **Verify** — give the plan checks to confirm adding one project is purely additive (no churn on the others). Output: (a) the project map schema, (b) the for_each resource composition, (c) immutable-field/lifecycle notes, (d) IAM authoritative-vs-additive guidance, (e) add/remove rollout plan. Design only — do not apply.
Related prompts
-
Terraform for_each Key Stability Audit Prompt
Diagnose why a for_each resource is destroying and recreating instances on every plan because its map keys are unstable or derived from computed values.
-
Terraform Multi-Environment Design Prompt
Design Terraform for multiple environments — dev/staging/prod separation, tfvars patterns, account boundaries, promotion workflow.
-
Terraform Self-Service Module Platform Prompt
Design a golden-path self-service platform where app teams provision infrastructure through curated, opinionated Terraform modules with guardrails, scaffolding, and a private registry — minimizing copy-paste and blast radius.