Terraform Apply Basics

You've written a Terraform configuration, run terraform init and terraform plan, and seen a list of changes that would happen. But nothing actually exists in your cloud account yet. The gap between a great plan and real infrastructure is exactly where terraform apply lives—and this lesson closes that gap for good.

The problem this lesson solves

A configuration file is just text. Until you run terraform apply, your AWS instances, VPCs, or Kubernetes clusters are nothing more than declarations. Many beginners stop after plan because they're afraid apply might break something—or worse, they skip plan entirely and run apply blindly. Both approaches lead to confusion, wasted time, and occasionally expensive mistakes.

The real pain is uncertainty: What exactly will change? What if I make a typo? How do I undo it? terraform apply is the bridge between your intent and your actual infrastructure, and once you understand its workflow, you'll stop guessing and start shipping.

Core concept / mental model

Think of terraform apply as the execution engine of Terraform. If plan is the blueprint and validate is the lint check, apply is the construction crew that reads the blueprint and builds exactly what it says.

Here's a simple analogy: you're renovating your house. init downloads the tools and materials list. plan walks through the rooms and shows you which walls will be torn down and which will be added. apply signs off on the plan and the crew starts swinging hammers.

Technically, apply performs three actions: 1. Refresh: Reads the current state of your infrastructure (unless you disable it with -refresh=false). 2. Diff: Compares desired config vs. actual state and computes a delta. 3. Execute: Creates, updates, or destroys resources to match the desired state, then writes the new state to your state file.

The key idea: apply is deterministic and idempotent. Running it twice with no config changes results in no changes the second time. That's the superpower of infrastructure-as-code—your config is the single source of truth.

Pro tip: terraform apply will automatically run a plan first and ask for your confirmation. You can skip the separate plan step if you're confident, but always review the output before typing yes.

How it works step by step

When you run terraform apply in a directory with .tf files, this is what happens under the hood:

1. Initialize & read state — Terraform loads your state file (local terraform.tfstate or remote backend).
2. Refresh resources — It queries your providers (AWS, GCP, etc.) to get the actual current attributes of each managed resource. This may take a few seconds per resource.
3. Compute the diff — It compares the refreshed state against your configuration. Anything that differs becomes an action in the plan.
4. Show the plan — You see a human-readable summary with + (create), - (destroy), ~ (modify in-place), and -/+ (replace).
5. Wait for confirmation — Unless you pass -auto-approve, Terraform prompts Enter a value: and waits for yes.
6. Apply changes — Resources are created/updated/destroyed in dependency order. Each operation streams logs like aws_instance.web: Creating....
7. Write new state — After success, the state file is updated and saved.

If anything fails mid-apply, Terraform partially applies—resources that succeeded remain, but the state is not fully updated. That's why idempotency matters: re-running apply after a fix will complete the missing pieces.

Hands-on walkthrough

Let's make this concrete. Create a simple AWS EC2 instance (or just use a null_resource if you don't have cloud credentials—the flow is identical).

1. Write a minimal config

# main.tf
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = "us-east-1"
}

resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"

  tags = {
    Name = "terraform-apply-demo"
  }
}

2. Initialize and plan

terraform init
terraform plan

You'll see output like:

Terraform will perform the following actions:

  # aws_instance.web will be created
  + resource "aws_instance" "web" {
      + ami                          = "ami-0c55b159cbfafe1f0"
      + instance_type                = "t2.micro"
      + tags                         = {
          + "Name" = "terraform-apply-demo"
        }
    }

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

3. Apply it

terraform apply

Terraform will re-run the plan, then prompt:

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

Type yes and watch the magic:

aws_instance.web: Creating...
aws_instance.web: Still creating... [10s elapsed]
aws_instance.web: Creation complete after 12s [id=i-0a1b2c3d4e5f67890]

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

4. Verify and update

Now change the instance type to t3.micro and apply again:

terraform apply -auto-approve

This time you'll see ~ aws_instance.web (in-place update) and the config will be modified without destroying the instance.

Pro tip: Use -auto-approve in CI/CD pipelines or when you're running scripts, but never in interactive demos where you want a human checkpoint.

Compare options / when to choose what

terraform apply has several flags that change its behavior. Here's a quick comparison of the most common ones:

Choosing between apply and plan: Always run terraform plan first when you're in an unfamiliar codebase or when the change is large. Use apply directly when you're confident and want speed. In automated pipelines, apply -auto-approve after a review of the plan artifact is the standard pattern.

Variations to consider: - Remote backends (S3, Terraform Cloud): Your apply runs the same, but state is stored remotely, enabling team collaboration and locking. - terraform apply -replace=aws_instance.web: Forces replacement of a resource, useful when an in-place update isn't enough (e.g., corrupt AMI). - terraform apply -parallelism=N: Controls how many resources are created simultaneously. Lower it for rate-limit-sensitive APIs.

Troubleshooting & edge cases

Error: Error: Invalid legacy provider address

This happens when you've written provider = aws without the source in required_providers. Fix: re-run terraform init -upgrade after adding the source.

Error: Error: acquiring state lock

Someone else (or a previous process) is holding the state lock. This usually occurs with remote backends. Fix: wait a few seconds, or force unlock with terraform force-unlock <lock_id> (use only if you're sure the process is dead).

Wrong output: 0 added, 0 changed, 0 destroyed

This means your config matches the current state perfectly. If you expected changes, check that you didn't comment out a resource or change a variable input.

Partially applied state

If a apply fails midway (e.g., network timeout), resources that were created may remain but not be in the state. Re-run terraform apply; it should detect and adopt them. If not, you may need terraform import.

-auto-approve didn't skip the prompt

That's because you also need to pass -input=false if you have variable prompts that aren't set. Example: terraform apply -auto-approve -input=false.

What you learned & what's next

You now understand how to apply infrastructure with terraform apply—the command that turns your declarative configuration into real cloud resources. You learned the mental model of refresh→diff→execute, how to use flags like -auto-approve, what to do when things go wrong, and how to compare it with plan and other options.

You're ready to move to the next lesson in the track: Managing Terraform state. State files are the heart of reproducibility, and understanding how to store, inspect, and fix them will make you a truly confident Terraform practitioner.