terraform apply

What Is terraform apply?

terraform apply is the command that actually makes changes to your infrastructure. It calculates a fresh execution plan (or uses a saved one), shows you that plan, waits for your approval, then provisions your infrastructure.

terraform apply

Unlike terraform plan, which is always safe, apply has real side effects. It calls cloud APIs to create, update, or delete resources. Run plan and review the output carefully before every apply.

The Apply Flow

When you run terraform apply without a saved plan file:

1. Terraform calculates a fresh execution plan (same as running terraform plan)
2. Displays the plan with all changes
3. Asks for confirmation: 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
4. Applies the changes: creates, updates, or destroys resources
5. Updates the state file with the new infrastructure state
6. Prints outputs if you have output blocks defined

You must type exactly yes to proceed. Typing y, Y, or anything else cancels the apply.

Real-Time Apply Output

As Terraform applies changes, it prints real-time status:

Notice how Terraform creates resources in dependency order, the VPC first, then subnets, then the internet gateway, then the security group, then the instance.

Parallel Execution

Terraform does not apply changes sequentially. It builds a dependency graph from your configuration and runs independent resources in parallel: up to 10 at a time by default:

To change the parallelism limit:

terraform apply -parallelism=5

You can also disable parallelism completely (rarely needed):

terraform apply -parallelism=1

Applying a Saved Plan

When you saved a plan with terraform plan -out=tfplan, apply it directly:

terraform apply tfplan

When applying a saved plan:

• No confirmation prompt is shown, the plan was already reviewed
• No fresh calculation: Terraform uses exactly the plan that was saved
• If infrastructure changed between plan and apply, Terraform will error and ask you to re-plan

This is the recommended production workflow and the standard CI/CD pattern.

Auto-Approve for CI/CD

In automated pipelines, you cannot have an interactive approval prompt. Skip it with -auto-approve:

terraform apply -auto-approve

Important: Only use -auto-approve in CI/CD pipelines with proper code review and branch protection. Never use it interactively on production infrastructure, you lose the safety check.

A complete GitLab CI apply stage:

apply:
  stage: apply
  script:
    - terraform init -input=false
    - terraform apply -input=false -auto-approve
  when: manual         # Requires a human to click "Play" in GitLab
  environment: production

Note the when: manual, even with -auto-approve, the CI job itself requires a human to trigger it. This gives you both automation and a human gate.

Accessing Outputs After Apply

After apply completes, view your declared outputs:

# Show all outputs
terraform output

# Show a specific output
terraform output instance_public_ip

# Get output as JSON (useful in scripts)
terraform output -json

Example output block in your Terraform config:

output "instance_public_ip" {
  description = "Public IP of the web server"
  value       = aws_instance.web.public_ip
}

Targeting a Specific Resource

Just like plan, you can apply to a specific resource only:

terraform apply -target=aws_instance.web

Warning: Using -target can leave your state inconsistent. Dependencies of the targeted resource will not be created/updated. Use only for emergencies or debugging.

What Happens to State During Apply

Every time apply succeeds, Terraform updates the state file (terraform.tfstate) to record what it built. The state file contains:

• Resource IDs from the cloud provider (e.g., i-0abc123 for an EC2 instance)
• All attribute values Terraform tracks
• Dependencies between resources

This is why apply is idempotent, if you run it again without changing your config, plan will show no changes and apply will do nothing.

Handling Apply Errors

If an error occurs mid-apply, Terraform:

1. Stops the apply for the failed resource
2. Continues applying resources that don't depend on the failed one
3. Updates state with what was successfully created

You will see something like:

After fixing the error, run terraform plan again to see the remaining changes, then terraform apply again. Terraform won't try to recreate resources that were already successfully created.

Knowledge Check

<MCQExercise exercise={{ id: 'tf-apply-q1', title: 'Question 1: Apply Confirmation', description: 'You run terraform apply. Terraform shows the execution plan and asks: "Enter a value:". You type "y" and press Enter. What happens?', options: [ { id: 'a', text: 'Terraform accepts "y" as a shorthand for "yes" and proceeds' }, { id: 'b', text: 'Terraform cancels the apply, only the exact word "yes" is accepted' }, { id: 'c', text: 'Terraform asks you to confirm again with a full "yes"' }, { id: 'd', text: 'Terraform applies but with a warning about the invalid input' }, ], correctId: 'b', explanation: 'Terraform requires the exact text "yes" to proceed. Typing "y", "Y", "Yes", or anything else cancels the apply. This is intentional, it prevents accidental applies from muscle memory (e.g., someone used to typing "y" for every prompt). You must type "yes" in full.', wrongExplanations: { a: 'Terraform does not accept shorthands. Only the exact text "yes" works.', c: 'Terraform does not re-prompt. Anything other than "yes" cancels the operation immediately.', d: 'There is no partial apply with warnings. Non-"yes" input cancels cleanly.', }, }} />

<MCQExercise exercise={{ id: 'tf-apply-q2', title: 'Question 2: Parallel Execution', description: 'You have 10 independent S3 buckets to create (no dependencies between them). How does terraform apply handle this by default?', options: [ { id: 'a', text: 'Creates them one at a time in the order they appear in the config file' }, { id: 'b', text: 'Creates them all simultaneously in parallel (up to 10 at a time by default)' }, { id: 'c', text: 'Asks which buckets to create first' }, { id: 'd', text: 'Batches them into groups of 5' }, ], correctId: 'b', explanation: 'Terraform builds a resource dependency graph and executes independent resources in parallel. The default parallelism limit is 10. Since your 10 S3 buckets have no dependencies on each other, Terraform will start creating all 10 simultaneously. Resources that depend on others (e.g., an EC2 instance in a subnet) wait for their dependencies to be created first.', wrongExplanations: { a: 'Terraform does not process resources in file order. It uses a dependency graph for optimal parallel execution.', c: 'Terraform never asks about ordering. It determines the optimal execution order automatically.', d: 'The default parallelism is 10 (not 5) and is not batched, all 10 independent resources start at once.', }, }} />

<MCQExercise exercise={{ id: 'tf-apply-q3', title: 'Question 3: -auto-approve', description: 'When is it safe to use terraform apply -auto-approve?', options: [ { id: 'a', text: 'Always, it just skips a redundant confirmation prompt' }, { id: 'b', text: 'Never, Terraform recommends against it' }, { id: 'c', text: 'In CI/CD pipelines with proper code review and branch protection in place' }, { id: 'd', text: 'Only for dev environments, never for staging or production' }, ], correctId: 'c', explanation: '-auto-approve is appropriate in CI/CD pipelines where the human approval gate is the code review / PR process and pipeline trigger (e.g., when: manual in GitLab). The key is that there IS still a human gate, it is just earlier in the process. What you must never do is use -auto-approve interactively on production infrastructure, where the plan review step is your last safety check before real changes happen.', wrongExplanations: { a: 'The confirmation prompt is a critical safety check, not redundant. Skipping it without proper controls is dangerous.', b: 'Terraform does not recommend against -auto-approve, it is explicitly designed for CI/CD use. The key is to have other safety gates in place.', d: 'The environment (dev vs prod) is less relevant than whether proper review processes are in place. Many teams use -auto-approve in all environments with proper PR workflows.', }, }} />