terraform apply: apply a plan to a real cloud

What apply does

terraform apply runs three steps in sequence:

1. Generates a plan (the same as terraform plan).
2. Shows the plan and asks for confirmation: "Here are the changes. Apply them? Type yes."
3. After you confirm, it calls the cloud API and actually creates, changes, or deletes resources.
4. Updates the state file (terraform.tfstate): it records what happened.

This is the first command that actually does something in the cloud. Before it, everything is just talk.

Two ways to run it

Way 1: with interactive confirmation (recommended)

terraform apply

Terraform shows the plan and, at the end, asks:

Do you want to perform these actions?

  Terraform will perform the actions described above.

  Only 'yes' will be accepted to approve.

  Enter a value:

Type yes (exactly three letters, not y, not Y, not Yes) and apply starts. Any other input cancels it.

Way 2: apply a plan you saved earlier

terraform plan -out=tfplan.bin

# ... you review the plan, a reviewer signs off ...

terraform apply tfplan.bin

When you run apply with a plan file, Terraform does not ask for confirmation. The assumption is that approval already happened during the plan review.

This is the standard approach in CI/CD. One pipeline step builds the plan in a PR, and a second step applies it after the merge.

-auto-approve: when it is fine, when it is not

The -auto-approve flag skips the interactive question:

terraform apply -auto-approve

When it is fine:

• Practice and demo tasks (like in this course with LocalStack).
• CI/CD pipelines where the plan was already saved and reviewed.
• Local ephemeral environments that you tear down regularly.

When it is dangerous:

• Production. Never run apply -auto-approve against a production environment from a local terminal. One mistyped character in HCL and you recreate the production database.
• Someone else's code. You cloned a repository from GitHub, did not read the HCL carefully, and apply -auto-approve deletes your resources.

The rule: -auto-approve is acceptable only when you are sure the plan has already been checked, whether by you, by a reviewer, or by tests.

What apply shows while it runs

aws_s3_bucket.demo: Creating...

aws_s3_bucket.demo: Still creating... [10s elapsed]

aws_s3_bucket.demo: Creation complete after 12s [id=my-bucket-12345]

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

Reading it:

• Creating... means Terraform sent the request to the API and is waiting.
• Still creating... [10s elapsed] means the operation is taking a while, and Terraform reminds you periodically that it is still waiting.
• Creation complete after 12s [id=my-bucket-12345] means the resource is created and its ID is known.
• Apply complete! Resources: 1 added, 0 changed, 0 destroyed is the final summary.

Parallelism, and why apply is sometimes slow

By default, Terraform applies up to 10 resources in parallel. If you have 100 independent buckets, apply creates them across 10 parallel workers.

Dependencies are computed automatically. If one resource contains ${aws_s3_bucket.demo.id}, Terraform creates the bucket first, then the resource that references it. This is called the dependency graph.

You can tune parallelism:

terraform apply -parallelism=20    # more workers

terraform apply -parallelism=1     # one at a time (for debugging)

If apply fails partway through

It happens: half the resources got created, half did not. The cloud API returned an error (quota exceeded, name conflict).

What happened:

• The resources that were already created are recorded in state. They exist.
• The resources that were not created are absent from both the state and the cloud.
• The state is valid and not corrupted.

What to do:

• Fix the cause (raise the quota, change the name).
• Run apply again. Terraform sees the resources already in state and skips them, then tries to finish the rest. This is called idempotency.

Pitfalls

• Something can change between plan and apply. If someone deleted a resource by hand in the AWS console, apply fails. The fix is either to apply a saved plan with apply tfplan.bin, or to accept it and run plan again.

• yes is lowercase. Yes, YES, and y all cancel the operation. This is deliberate: the confirmation has to be a conscious choice.

• Apply does not roll back changes. If 5 of 10 resources were created and the sixth failed, Terraform will NOT delete the five it already made. The state is updated and those resources exist. You can only undo them with a new apply (using correct HCL) or with destroy.

• Run time depends on the cloud. An AWS S3 bucket takes seconds. An AWS RDS instance takes 10 to 20 minutes. That is normal, and Terraform is not at fault.

• Do not run two applies at once. The state file is locked for the duration of an apply. If you start a second one, it either waits or fails with a locking error.