Terraform Infrastructure as Code Workflow: Plan, Review, Apply, and Manage Drift

Overview

Terraform is most useful when it is treated as a software delivery process rather than a command run from an engineer’s laptop. The desired workflow is straightforward: define infrastructure as code, validate the change, create a plan, review the plan, apply an approved change through a controlled identity, and verify the result.

This process depends on clear ownership of three related but different artifacts. The configuration describes the intended infrastructure. The state records the relationship between that configuration and real resources. The plan shows the proposed transition from the current state to the desired state. Confusing these roles can lead to risky changes, stale plans, or state conflicts.

A team can adapt the exact tools to its environment, but the controls should remain recognizable. Source control should be the authoritative home for Terraform configuration. State should be stored remotely in a system that supports access control and, where available, locking. Pull requests should provide the main review boundary. Continuous integration should run formatting, validation, security checks, and plan generation. Apply permissions should be narrower than plan permissions.

Step-by-step workflow

1. Define a clear repository and module structure

Start by separating reusable building blocks from environment-specific composition. A module might define a network, database, or compute service. A root configuration should combine those modules for a particular environment or account. Avoid creating a single directory that contains every environment and every resource unless the scope is genuinely small; large undifferentiated configurations make ownership, review, and state boundaries harder to understand.

Keep environment inputs explicit. Variables, provider configuration, naming rules, and outputs should make it possible to identify what differs between development, staging, and production. Use consistent naming and tagging conventions so that an operator can connect a resource in the cloud console to the code and state that manage it.

2. Store state remotely and define ownership

Local state is easy to create but difficult to govern across a team. Use a remote backend appropriate for the platform and security requirements. Restrict who can read or modify state because it can contain resource metadata and, depending on configuration, sensitive values. Enable state locking when the backend supports it so that concurrent operations do not overwrite one another.

Separate state by a meaningful boundary, such as an environment, application, or platform component. Smaller state scopes can reduce the impact of a change and make ownership clearer, but excessive fragmentation creates more dependencies and operational overhead. Document the reason for each boundary and how related stacks exchange outputs.

3. Make changes in a branch and run local checks

For each change, create a branch and keep the scope narrow. Run formatting and configuration validation before opening a pull request. Review variable changes, provider changes, resource replacement behavior, and dependency updates with particular care. A change that appears to update one attribute may recreate a resource or affect dependent services.

Do not place credentials directly in configuration files or commit them to source control. Use the secret-management and identity features available in your execution environment. Mark sensitive inputs and outputs where appropriate, while remembering that a sensitive label controls display behavior; it does not replace secure storage or access control.

4. Generate a plan in continuous integration

The pull request pipeline should run the same initialization and validation steps used by the team’s supported Terraform version. It should generate a plan against the correct workspace, account, or state location and make the result available to reviewers. A plan is useful only when its inputs are controlled: provider versions, variables, credentials, and the target state must be unambiguous.

Review the plan for additions, updates, and destructions. Pay special attention to replacements, changes to access policies, network boundaries, data stores, and resources with external dependencies. If a plan contains an unexpected action, stop and investigate rather than approving it because the final count looks small.

5. Separate approval from apply

Applying from a developer workstation makes it difficult to prove which code was used, who approved it, and which identity changed the infrastructure. A safer pattern is to apply from a controlled CI or deployment environment after the pull request has been approved. The apply job should use a narrowly scoped identity and should target the same state boundary reviewed in the plan.

Where the platform supports it, require an explicit approval before production applies. Avoid treating an old plan as permanently valid: if state, variables, provider versions, or surrounding resources change, regenerate the plan before applying. After the apply completes, record the result and link it to the change that authorized it.

6. Verify and document the result

Terraform confirms that its resource operations completed; it does not prove that an application is healthy. Follow an infrastructure change with targeted checks: service reachability, permissions, routing, health checks, logs, and relevant metrics. For application-facing changes, pair this workflow with a deployment and post-deployment verification process, such as the post-deployment verification checklist for websites and APIs.

If the change affects a production service, make rollback or recovery steps visible before applying. A failed infrastructure operation may require both Terraform remediation and operational incident handling. The incident response checklist for failed deployments and production rollbacks provides a useful companion process.

Tools and handoffs

The workflow works best when every handoff has a clear input and output:

• Source control: stores modules, root configurations, version constraints, documentation, and pull-request history.
• Terraform CLI: performs formatting, initialization, validation, planning, and application using a version the team has chosen to support.
• Remote backend: stores state and coordinates access, with locking and recovery features configured where available.
• CI/CD pipeline: runs repeatable checks and creates plans without depending on a personal workstation.
• Identity and secret systems: provide short-lived or tightly scoped access without exposing credentials in code.
• Policy and security checks: detect risky configurations, prohibited resource settings, and accidental exposure before apply.
• Monitoring and service checks: confirm that the infrastructure change produced the intended operational result.

Teams using a GitOps workflow may commit the approved infrastructure change and let a reconciler perform the apply. Teams using a more traditional CI/CD pipeline may keep the apply job in the same system that generated the plan. The important distinction is not the product category; it is whether the process preserves review, identity control, auditability, and a reliable connection between code and deployed infrastructure. For broader delivery context, compare this workflow with GitOps and traditional CI/CD deployment approaches.

Quality checks

Use a consistent checklist before approving a Terraform change:

• Is the change in the correct module, environment, and state boundary?
• Are provider, module, and Terraform version constraints intentional and reproducible?
• Does the plan show only the expected additions, updates, and deletions?
• Could any resource be replaced, interrupted, or made unreachable?
• Are identity, network, storage, and encryption settings consistent with the team’s requirements?
• Are secrets supplied through an approved mechanism rather than committed to the repository?
• Can the apply run with a limited identity and without manual edits to the plan?
• Are outputs and documentation sufficient for the next operator?

Drift detection should be a scheduled activity, not only a reaction to an incident. Run plans at a suitable interval without automatically applying them, then review unexpected differences. Drift can result from a console edit, another automation system, a provider-side change, or an incomplete import. Decide deliberately whether to restore the configuration, update the code to match an approved change, or import and manage the resource properly.

When bringing existing infrastructure under Terraform, inventory the resource first, confirm its ownership and dependencies, then import it using the supported process. Follow the import with a plan and adjust the configuration until the plan reflects the intended steady state. Avoid importing resources into a shared state boundary without agreeing who will maintain them afterward.

When to revisit

Review this Terraform workflow whenever the team changes its cloud accounts, deployment platform, CI/CD system, state backend, identity model, or provider set. A change in any of these inputs can alter how plans are generated, where credentials come from, or who can apply infrastructure.

Schedule regular maintenance even when the platform appears stable. Revisit provider and module constraints, remove obsolete resources and variables, test recovery of remote state, inspect state access, and review drift reports. Check that new team members can understand the repository, identify the correct state boundary, and find the apply and incident procedures without relying on tribal knowledge.

A practical next step is to document one complete path from pull request to verified infrastructure change. Include the commands or pipeline stages, required approvals, state location, identity used for apply, expected review points, and recovery contacts. Then run the path with a low-risk change. The resulting record becomes a working baseline that can be refined as the tools and infrastructure evolve.