When Terraform Apply Actually Runs: What Happens After You Approve the Plan

You have reviewed the plan output. You have confirmed that Terraform will create two EC2 instances, not delete the existing database, and attach the correct security group. Now you type terraform apply and press Enter. The terminal scrolls with messages like aws_instance.app_server: Creating... and you wait.

This moment is where infrastructure-as-code stops being a configuration file and becomes real infrastructure. Servers spin up. Networks get configured. DNS records get created. But what exactly happens during terraform apply, and how do you make sure this step does not cause problems?

Why You Should Use a Saved Plan File

The safest way to run terraform apply is to feed it a plan file that you generated earlier. After running terraform plan -out=plan.tfplan, you can execute terraform apply plan.tfplan. This guarantees that Terraform applies exactly what you reviewed, nothing more, nothing less.

Here is the exact command sequence to generate and apply a saved plan file:

terraform plan -out=plan.tfplan
terraform apply plan.tfplan

The risk of running terraform apply without a plan file is subtle but real. Between the time you run terraform plan and terraform apply, someone else on your team could merge a change to the same configuration. Or you might modify a variable file without realizing it. When you run terraform apply without a saved plan, Terraform re-runs the plan using whatever configuration exists at that moment. The output might differ from what you reviewed ten minutes ago.

For production environments, always use a saved plan file. It creates an audit trail: you can point to plan.tfplan and say "this is exactly what was approved." For staging or development environments where changes are small and frequent, the convenience of running terraform apply without a plan file might be acceptable. Just know the trade-off.

What Happens During the Apply Process

When terraform apply executes, it does not simply "apply the config." It communicates with the provider's API for every resource that needs to change. If you are creating an aws_instance, Terraform calls the AWS EC2 API to launch an instance. If you are updating a google_storage_bucket, it calls the Google Cloud Storage API.

Each API call can take anywhere from milliseconds to several minutes. Creating a virtual machine typically takes 30 seconds to a few minutes. Provisioning a managed Kubernetes cluster can take 10-15 minutes. Terraform shows progress in the terminal, but it does not give you a progress bar for individual resources. You see messages like:

The following flowchart summarizes the apply flow and the branching outcomes on success or failure:

flowchart TD A[Start terraform apply] --> B[Read plan file or re-plan] B --> C[Acquire state lock] C --> D[For each resource: call provider API] D --> E{All resources created/updated?} E -- Yes --> F[Write full state to state file] F --> G[Release state lock] G --> H[Apply succeeded] E -- No --> I[Partial state saved for created resources] I --> J[Release state lock] J --> K[Manual intervention needed] K --> L[Fix issue and re-apply] K --> M[Manually destroy or use terraform destroy] 
aws_instance.app_server: Still creating... [10s elapsed]
aws_instance.app_server: Still creating... [20s elapsed]

During this time, Terraform holds the state lock. No one else on your team can run terraform apply or terraform plan until the current operation finishes or times out. This is intentional: it prevents two people from modifying the same infrastructure simultaneously.

What Happens When Apply Succeeds

After all resources are created or updated successfully, Terraform writes the current state to the state file. This state file records every resource with its unique ID, all attributes, and the relationships between resources. For example, if you created an EC2 instance and attached a security group, the state file knows that aws_instance.app_server is associated with aws_security_group.web_sg.

This state file becomes the single source of truth for your infrastructure. The next time you run terraform plan, Terraform compares your configuration against the state file, not against the live cloud resources. This is why corrupt or missing state files cause so many problems: Terraform loses its reference point.

What Happens When Apply Fails

Apply failures are common enough that you should know how to handle them. A resource creation might fail because:

  • You hit a quota limit (e.g., too many EC2 instances in a region)
  • The provider credentials expired or are invalid
  • There is a conflict with an existing resource (e.g., trying to create a DNS record that already exists)
  • The cloud provider has an outage or throttling

When a failure happens, Terraform does not roll back everything. It marks the resources that failed and saves the state for whatever was successfully created. This means you end up in a partial state: some resources exist, some do not. Terraform does not automatically clean up the resources that were created before the failure.

For example, if you are creating five resources and the fourth one fails, the first three resources still exist in your cloud account. The state file records those three as created. You need to decide what to do next:

  • Fix the issue (e.g., request a quota increase) and run terraform apply again. Terraform will attempt to create the remaining resources.
  • Manually destroy the resources that were created and start over.
  • Use terraform destroy to clean up everything, but only if you are sure you want to remove all resources.

This partial-state behavior is one reason why you should test infrastructure changes in a non-production environment first. A failed apply in production can leave your infrastructure in an inconsistent state that requires manual intervention.

Practical Checklist Before Running Apply

Before you type terraform apply on any environment that matters, run through these checks:

  • Did you review the plan output for unexpected changes, especially deletions?
  • Is the state file backed up or stored in a remote backend with versioning?
  • Do you have the credentials to roll back if something goes wrong?
  • Is there a maintenance window or notification for the team?
  • For production: did you use a saved plan file (terraform apply plan.tfplan)?
  • For database changes: do you have a migration rollback plan separate from Terraform?

The Concrete Takeaway

Running terraform apply is the moment your configuration becomes real infrastructure. Use a saved plan file for production to ensure you apply exactly what was reviewed. Understand that failures leave partial state, not automatic rollbacks. And always know where your state file lives and how to recover it, because without it, Terraform cannot manage your infrastructure at all.