Plan/Apply Workflow & CI
Run Terraform safely in a team via pull requests, plan review, and automated apply.
In a team, you don’t run apply from your laptop. Infrastructure changes flow
through pull requests, just like application code:
- Open a PR with the Terraform change
- CI runs
fmt,validate, andplan, posting the plan to the PR - A human reviews the plan — especially destroy actions
- On merge, CI runs
apply(often with a manual approval gate)
This gives review, an audit trail, and consistent automated runs. Use remote
state with locking, a -out plan file so apply matches the reviewed plan, and
OIDC for keyless cloud auth in CI.
graph LR PR["Pull request"] --> CI["fmt + validate + plan"] CI --> REV["Human reviews plan"] REV --> M["Merge"] M --> AP["apply (gated)"]
- Describe how a Terraform change should flow from PR to production.
- Explain why CI posts the plan to the pull request.
- Why save a plan file and apply exactly that file?
- How should CI authenticate to the cloud without storing static keys?
Cheat Sheet▾
| Step | Command |
|---|---|
| Format | terraform fmt -check |
| Validate | terraform validate |
| Plan to file | terraform plan -out=tfplan |
| Apply that plan | terraform apply tfplan |
| Review | Human reads plan in PR |
| Auth in CI | OIDC (no static keys) |
| State | Remote + locking |
Common Interview Questions▾
How do you run Terraform safely in a team?
Through pull requests: CI runs fmt/validate/plan and posts the plan for human review, then applies on merge (often with an approval gate), using remote state with locking and keyless OIDC auth.
Why save and apply a plan file rather than re-planning at apply time?
So apply executes exactly what was reviewed. A fresh plan at apply could pick up new drift or changes and do something different from what the reviewer approved.