Infrastructure as Code, Terraform Plans, Policy Checks, and Deployment Workflows: Configuration, Design Patterns, and Trade-Offs

1. IaC workflow design is a set of boundary choices

There is no single correct Terraform workflow. A small team may manually dispatch an apply from a reviewed commit; a regulated platform may require a saved-plan digest, environment approval and short-lived cloud federation; a GitOps system may prohibit GitHub Actions from directly applying infrastructure at all. The design test is whether source, state, authority and evidence remain independently observable.

2. Plan on pull request; apply only from trusted revision

PR planning gives fast feedback on proposed infrastructure change, but fork or untrusted PR code must not receive privileged cloud credentials. For public contribution models, either use a no-credential validation path or a carefully designed read-only planning service. Mutation belongs after merge/approval from a trusted base-repository revision.

Do not assume “merged to main” proves that the exact reviewed plan is still current. Main may advance, state may change externally, or another deployment may win the race. Bind apply to one source SHA and one plan/state context.

3. Saved plan versus re-plan at apply time

4. One state boundary per environment/blast radius

State is an authority boundary because whoever can update it can often drive infrastructure mutation. Separate production from staging rather than selecting both through an unvalidated variable against one broad credential. Backend keys/workspaces can partition state, but naming alone is not enough: bind credentials, environment rules and concurrency to the same target identity.

State locking protects concurrent writers where the backend supports it. It is not a global deployment scheduler and it is not evidence that the human reviewed the current plan. Use GitHub concurrency to reduce overlapping workflow intent and backend locking to protect the state write itself.

5. OIDC versus static cloud secret

Static cloud access keys in repository secrets create long-lived credential rotation and exfiltration risk. OIDC lets the apply job request a short-lived token and lets the cloud provider decide whether repository/workflow/environment claims are trusted. Keep id-token: write only on the jobs that exchange it, and scope the provider role to the exact backend/resources required.

OIDC is an authentication mechanism, not a Terraform policy engine. A correctly federated role can still be over-privileged, and a least-privilege role can still apply a destructive plan if governance fails.

6. Direct apply versus downstream GitOps handoff

Direct push deployment means GitHub Actions authenticates to the backend/provider and performs apply. It gives immediate run-to-change linkage but places mutation credentials/identity at the CI boundary. A GitOps handoff instead updates an authorized desired-state repository or change record and lets a dedicated reconciler perform the mutation.

GitOps does not remove the need for plan evidence. It changes which system owns apply authority and target health. Record the handoff commit/change ID and the reconciler outcome separately from the GitHub Actions check.

7. Setup action versus preinstalled CLI

As verified September 10, 2026, hashicorp/setup-terraform v4.0.1 uses the Node 24 action runtime and can install an exact Terraform version. The mandatory lab pins the action by full commit SHA and requests Terraform 1.16.1. Relying on whichever Terraform binary happens to exist in a runner image makes evidence weaker and can produce incompatible plan behavior after image updates.

8. Plan portability cautions

A saved Terraform plan is designed for a later apply in the same configuration/state context, not as a vendor-neutral serialized change request. Record Terraform version and provider lock, and avoid moving binary plans across arbitrary operating systems, architectures or long version gaps. If a plan must cross a job boundary, keep runner/tooling assumptions explicit and verify the digest before apply.

OpenTofu can implement a similar operating model, but do not assume a Terraform plan binary is interchangeable with OpenTofu or vice versa. Pick one CLI for a workflow run, pin it, and generate/apply plans with that tool.

9. Decision table

10. Lesson summary

Architecture should make stale state, privilege boundaries and evidence ownership visible. Whether you save plans, re-plan, use OIDC or hand off to GitOps, never collapse review, authorization and mutation into one opaque job.

Knowledge check

Official references and version notes

• Terraform CLI plan — Saved plans, planning modes, detailed exit codes and the security warning for plan files.
• Terraform CLI apply — Applying a saved plan and automation semantics.
• Terraform dependency lock file — Provider selections/checksums and why the lock file belongs with source.
• Terraform state locking — State-lock behavior and the operational risk of force-unlock.
• Terraform local backend — Local state backend used only by the disposable no-cloud lab.
• HashiCorp setup-terraform — Official setup action; current v4 line uses Node 24.
• GitHub environments — Approval/protection boundary for a guarded apply job.
• GitHub OIDC overview — Preferred short-lived cloud federation boundary for optional real-provider adapters.
• Workflow artifacts — Plan/evidence transfer is GitHub artifact state, not infrastructure state.
• OpenTofu documentation — Open-source alternative CLI with a similar plan/apply operating boundary; verify syntax/version separately before substitution.