Core Workflow

First PublishedFeb 16, 2026ByAtif Alam

The Terraform workflow is four commands: init, plan, apply, destroy. Every Terraform session follows this pattern.

terraform init

Initializes a working directory. Run this first (and whenever you add providers or modules):

terraform init

What it does:

• Downloads provider plugins (e.g. the AWS provider) to .terraform/.
• Downloads modules referenced in your config.
• Configures the backend (where state is stored).
• Creates .terraform.lock.hcl (dependency lock file — commit this to Git).

terraform init -upgrade    # upgrade providers/modules to latest allowed versions
terraform init -reconfigure  # reconfigure backend without migrating state

terraform plan

Shows what Terraform will do without making any changes:

terraform plan

Example output:

Terraform will perform the following actions:

  # aws_instance.web will be created
  + resource "aws_instance" "web" {
      + ami           = "ami-0c55b159cbfafe1f0"
      + instance_type = "t3.micro"
      + id            = (known after apply)
      + public_ip     = (known after apply)
      + tags          = {
          + "Name" = "web-server"
        }
    }

Plan: 1 to add, 0 to change, 0 to destroy.

Reading Plan Output

Symbol	Meaning
+	Resource will be created
-	Resource will be destroyed
~	Resource will be updated in-place
-/+	Resource will be destroyed and recreated (forced replacement)
<=	Data source will be read

The (known after apply) marker means the value is only available after the resource is created (e.g. generated IDs, assigned IPs).

Save a Plan

terraform plan -out=tfplan       # save plan to a file
terraform apply tfplan           # apply the saved plan (no re-prompt)

This is the recommended pattern in CI/CD: plan in the PR, save the plan file, apply the exact plan on merge.

Targeting

Plan or apply only specific resources:

terraform plan -target=aws_instance.web
terraform apply -target=aws_instance.web

Use sparingly — targeting skips dependency checks and can leave state inconsistent.

terraform apply

Executes the plan and makes real changes:

terraform apply

Terraform shows the plan and asks for confirmation (yes). To skip the prompt:

terraform apply -auto-approve

With Variables

terraform apply -var="instance_type=t3.large"
terraform apply -var-file="prod.tfvars"

Applying a Saved Plan

terraform apply tfplan

When applying a saved plan file, Terraform doesn’t re-prompt — it applies exactly what was planned.

terraform destroy

Destroys all resources managed by the current configuration:

terraform destroy

Shows a plan of what will be destroyed and asks for confirmation. To skip the prompt:

terraform destroy -auto-approve

Destroy specific resources:

terraform destroy -target=aws_instance.web

Other Useful Commands

terraform validate

Checks config syntax and internal consistency (no API calls):

terraform validate

terraform fmt

Formats .tf files to the canonical style:

terraform fmt          # format current directory
terraform fmt -recursive  # format all subdirectories too
terraform fmt -check   # check without modifying (useful in CI)

terraform output

Display outputs from the current state:

terraform output                # all outputs
terraform output instance_ip    # specific output
terraform output -json          # JSON format (for scripting)

terraform refresh

Updates state to match real infrastructure (deprecated in favor of terraform apply -refresh-only):

terraform apply -refresh-only

terraform console

Interactive REPL for testing expressions:

terraform console
> var.instance_type
"t3.micro"
> length(var.subnets)
3
> cidrsubnet("10.0.0.0/16", 8, 1)
"10.0.1.0/24"

Drift Detection

Drift happens when real infrastructure changes outside of Terraform — someone manually edits a security group in the AWS console, an auto-scaler changes instance counts, or another tool modifies a resource.

How Terraform Detects Drift

Every time you run terraform plan, Terraform:

1. Refreshes — Queries the cloud APIs to get the current state of every managed resource.
2. Compares — Checks current state against your config and the stored state.
3. Reports — Shows any differences as planned changes.

If someone manually added a tag to an instance, terraform plan would show:

  # aws_instance.web will be updated in-place
  ~ resource "aws_instance" "web" {
      ~ tags = {
          - "ManualTag" = "oops" -> null   # Terraform will remove the manual tag
            "Name"      = "web-server"
        }
    }

Refresh-Only Mode

To detect drift without applying any config changes:

terraform apply -refresh-only

This updates the state file to match reality without changing any infrastructure. Useful for:

• Auditing: “Has anything drifted since last apply?”
• Syncing state after expected external changes (e.g. auto-scaling).

You can also plan in refresh-only mode first:

terraform plan -refresh-only

Handling Drift

Situation	Action
Manual change was a mistake	Run terraform apply — Terraform reverts to your config
Manual change should be kept	Update your .tf files to match, then terraform plan (should show no changes)
External tool manages the field	Add ignore_changes in the resource’s lifecycle block
Resource was deleted externally	Terraform will plan to recreate it on next apply

Preventing Drift

• Restrict manual access — Use IAM policies to prevent console edits to Terraform-managed resources.
• Tag managed resources — Add a ManagedBy = "terraform" tag so people know not to edit manually.
• Run scheduled plans — Run terraform plan on a cron (e.g. nightly) to detect drift early.
• Use ignore_changes — For fields that are intentionally managed externally (e.g. auto-scaling desired count).

Scheduled Drift Detection (CI/CD)

# GitHub Actions — nightly drift check
name: Drift Detection
on:
  schedule:
    - cron: "0 6 * * *"    # daily at 6 AM UTC

jobs:
  detect:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: hashicorp/setup-terraform@v3
      - run: terraform init
      - run: terraform plan -detailed-exitcode
        # exit code 0 = no changes, 1 = error, 2 = drift detected

Exit code 2 from terraform plan -detailed-exitcode means drift was detected — you can trigger an alert or Slack notification.

---

The Typical Workflow

1. Write .tf files           (define resources)
2. terraform init            (download providers, modules)
3. terraform plan            (preview changes)
4. terraform apply           (make changes)
5. Iterate: edit → plan → apply
6. terraform destroy         (tear down when done)

In a team/CI setting:

1. Branch → edit .tf files
2. PR → terraform plan (posted as PR comment)
3. Review the plan
4. Merge → terraform apply (automated)

Key Takeaways

• Always plan before apply — review what will change.
• Use saved plans in CI/CD: plan -out=tfplan in PR, apply tfplan on merge.
• terraform fmt and terraform validate should run in CI on every PR.
• Avoid terraform apply -auto-approve outside of automated pipelines.
• Use -target sparingly and only for debugging — not as a regular workflow.
• Drift detection: terraform plan -refresh-only audits drift; plan -detailed-exitcode flags it in CI.
• Prevent drift with restricted access, tagging, ignore_changes, and scheduled plan runs.