Multi-Environment IaC Promotion Pipeline Prompt
Design a dev → stage → prod promotion pipeline for infrastructure where the same code ships to every environment, differences live in config, and prod changes are reviewed, gated, and reversible.
- Target user
- Platform engineers designing IaC delivery pipelines
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT
The prompt
You are a platform engineer who has built IaC delivery pipelines where the same artifact flows from dev to prod and nobody hand-edits prod. I will provide: - IaC tool(s) and how environments are currently separated (dirs, workspaces, branches, accounts) - Number of environments and their blast-radius differences - CI/CD system and approval requirements - How config/secrets differ per environment Your job: 1. **One code, many configs** — the same modules/charts/stacks deploy everywhere; ONLY config differs (`*-prod.tfvars`, `values-prod.yaml`, stack config). Flag any environment-specific logic baked into the code itself. 2. **Environment isolation** — recommend separate accounts/subscriptions/projects per environment over shared-account-with-tags. Show how state/backends are isolated so a dev apply can never touch prod. 3. **Promotion model** — pick and justify: branch-per-env, directory-per-env, or (preferred) a single main with environment config + a pipeline that promotes the SAME commit forward. Avoid divergent long-lived branches. 4. **Gates** — dev auto-applies; stage applies on merge; prod requires a reviewed plan artifact + manual approval. The prod apply MUST use the exact plan that was reviewed (save and re-use the plan file), not re-plan at apply time. 5. **Pre-prod validation** — what must pass before promotion: lint, policy (OPA/Conftest), plan diff review, drift check, and (where possible) ephemeral-environment integration tests. 6. **Rollback** — infra rollback is rarely a clean revert. Define the strategy: forward-fix vs revert-the-commit-and-apply, plus how stateful resources complicate it. Tag releases so you can identify the last-good config. 7. **Auditability** — every prod change traces to a PR, a reviewed plan, and an approver. Output as: (a) the directory/state layout, (b) the pipeline stages with gates, (c) the "reviewed-plan = applied-plan" mechanism, (d) the rollback playbook, (e) the top 3 ways prod and lower environments silently diverge and how to prevent each. Bias toward: same artifact everywhere, account-level isolation, and applying the exact plan that was reviewed.