Structuring CI/CD Pipelines for IaC Validation

Infrastructure CI/CD pipelines and application CI/CD pipelines look similar at first glance—linting, tests, and deployment steps.

The difference is blast radius. A bad infrastructure apply can impact networks, IAM, and shared services across teams and environments.

This guide outlines a practical pipeline structure for safe validation.

Stage 1–3: verify what’s being planned

At minimum:

• Validate syntax and configuration.
• Check formatting.
• Run static analysis against the generated plan (when available).

These stages should fail fast for low-signal problems.

Stage 4–5: test and generate a plan artefact

Generate the plan once and treat it as the artefact that downstream stages evaluate.

Don’t regenerate the plan after policy checks; you want the plan you reviewed to be the plan you apply.

Stage 6: policy evaluation

Policy evaluation runs against the plan output:

• Blocking policies must fail the pipeline.
• Warning policies must be surfaced to reviewers.

Keep policy messages review-friendly: they should explain the risk and remediation.

Stage 7–8: human review, then apply

Reviewers need a summary that maps:

• what changed,
• what policies triggered,
• why it matters,
• what remediation is expected.

Then apply only after approval.

Stage 9: drift check after apply

After apply completes, verify the cluster/cloud state actually converged to the declared configuration.

Common pitfalls

1. Regenerating plans between stages.
2. Applying without state locking.
3. Applying stale plan artefacts.
4. Skipping a post-apply drift check.
5. Treating warnings as ignorable for risky resource types.

If you want a single governed workflow for plan generation, policy evaluation, and approval, start with repo-to-infrastructure.