What this prompt does
This prompt specifies a complete Terraform CI/CD pipeline on [ci_platform] so infrastructure changes become routine and reviewable. You give it [infrastructure_scope], [team_size], and your [workflow_type], and it designs two pipelines: a PR pipeline running fmt, validate, tflint with [tflint_rules], [security_scanner], and a plan posted as a comment; and an apply pipeline that runs on merge to [main_branch] using the exact saved plan.
The structure works because safe IaC delivery is a sequence of gates. The plan you review is the plan that applies, drift is caught on a schedule via [drift_schedule], and promotion from [first_env] to [next_env] waits on [approval_mechanism]. By also specifying [state_locking_strategy] to prevent concurrent applies, secret handling through [secret_source], a [rollback_approach], and an [iam_strategy] using short-lived OIDC credentials, the prompt covers the failure modes that make naive pipelines dangerous. The [team_size] and [workflow_type] inputs tune how strict the gating should be, since a small trunk-based team needs less ceremony than a large org with formal change control.
When to use it
- You are moving from local
terraform applyto a reviewed, automated pipeline - You want plan-on-PR and apply-on-merge so every change is seen before it lands
- You need policy and security scanning wired in via
[security_scanner] - You want environment promotion gated by
[approval_mechanism]per stage - You need short-lived credentials instead of long-lived AWS keys in CI
- You want scheduled drift detection reporting to
[drift_report_destination] - You need a clear rollback path when an apply goes wrong
Example output
Expect two pipeline definitions for [ci_platform]: a PR workflow with each check (fmt, validate, tflint with [tflint_rules], [security_scanner]) as a step and the plan formatted as a comment, and an apply workflow that retrieves the saved plan and applies it with notifications via [apply_notification]. You also get a promotion configuration implementing [promotion_workflow], a [state_locking_strategy] setup, a secrets section using [secret_source] with sensitive-value masking, a scheduled drift job reporting to [drift_report_destination], and an [iam_strategy] defining separate read-only plan and write apply roles. The rollback section spells out the [rollback_approach] so reverting is a known procedure, not an improvisation.
Pro tips
- Use
[secret_source]with OIDC federation rather than stored static keys — short-lived role assumption is the single biggest security win here - Split
[iam_strategy]into a read-only plan role and a write apply role so a compromised PR pipeline cannot mutate infrastructure - Make
[promotion_workflow]match reality: auto-apply dev, but require the real number of approvals for production - Save the plan as an artifact and apply that exact plan on merge — applying a freshly generated plan defeats the review
- Set
[state_locking_strategy]with both CI concurrency groups and a backend lock so two applies cannot race - Run
[security_scanner]as a blocking check, not an advisory one, or insecure config will sail through under deadline pressure - Tune
[drift_schedule]to your needs and route results to[drift_report_destination]somewhere people actually look, or the detection is wasted
