terraform applyCreate, change or destroy real infrastructure
terraform apply carries out a plan: it calls the cloud APIs to create, update, replace and delete resources, in dependency order and in parallel, then saves the result to state. Without a plan file it plans first and asks you to type yes.
terraform apply [PLANFILE] | terraform apply [-auto-approve] [-var-file=F] [-replace=ADDR] [-target=ADDR] [-parallelism=N] · terraform destroyCreate the dev environment for the first time: a random suffix, the logs bucket and the web instance.
terraformThe Terraform CLI.
apply takes the state lock and either loads the saved plan (checking that the state hasn't changed since; a stale plan is rejected) or computes a fresh plan and asks for 'yes'. Then Terraform walks the resource graph: anything without unfinished dependencies runs concurrently, up to -parallelism (10). For each action it calls the provider's ApplyResourceChange over gRPC; the AWS provider makes the real API calls (RunInstances, then polls DescribeInstances until 'running'; CreateBucket; and so on) and returns the new attributes, which fill in the (known after apply) values that dependants need. After each resource finishes, Terraform persists the updated state (to S3 for a remote backend), so a crash mid-apply loses little. If an operation fails, the other independent operations finish, the error is printed, and state records what really happened; a half-created resource can end up 'tainted' and replaced next time. There is no rollback: you fix and apply again. Finally the lock is released and outputs are printed.
PLANFILEApply a saved plan exactly; no prompt-auto-approveSkip the yes prompt (only for automation you trust)-var / -var-fileVariables, when not applying a saved plan-replace=ADDRForce-recreate one resource (replaces old taint)-target=ADDROnly this resource and its dependencies (exceptional)-parallelism=NConcurrent operations (default 10)-lock-timeout=5mWait for a busy lock instead of failing-refresh-onlyAccept drift into state; change no resourcesdestroyterraform destroy = apply -destroy: remove everything in stateterraform apply -auto-approve from a laptop against prodNo review, and whatever is on your branch and in your shell variables gets applied.
Plan in CI with -out, review, then apply the saved plan from the pipelineUsing -lock=false because 'the lock is stuck'If another apply is running, both write state and one set of changes is lost or corrupted.
Find who holds it (Lock Info); terraform force-unlock ID only when that run is really deadExpecting a failed apply to roll backTerraform has no transactions; what succeeded stays and is in state.
Read the error, fix the code, apply again; it converges from where it stoppedFixing a broken resource by deleting it in the consoleState still has it; the next plan shows it must be created, but other resources may reference a now-missing ID.
terraform apply -replace=ADDR to recreate it through TerraformTry these on a Linux machine of your own. Each task has a hint and a solution.
In ~/infra (after apply), recreate only aws_instance.web without touching anything else, with an approval prompt. Compare the instance ID before and after.
Read this lock message and decide what to do: 'Who: priya@ci-runner-7 Created: 2026-10-29 10:42:33' and it's now 10:44.
Write the commands a pipeline's apply stage should run, given that the plan stage uploaded tfplan.
terraform applyCreate, change or destroy real infrastructure
terraform apply carries out a plan: it calls the cloud APIs to create, update, replace and delete resources, in dependency order and in parallel, then saves the result to state. Without a plan file it plans first and asks you to type yes.
terraform apply [PLANFILE] | terraform apply [-auto-approve] [-var-file=F] [-replace=ADDR] [-target=ADDR] [-parallelism=N] · terraform destroyCreate the dev environment for the first time: a random suffix, the logs bucket and the web instance.
terraformThe Terraform CLI.
apply takes the state lock and either loads the saved plan (checking that the state hasn't changed since; a stale plan is rejected) or computes a fresh plan and asks for 'yes'. Then Terraform walks the resource graph: anything without unfinished dependencies runs concurrently, up to -parallelism (10). For each action it calls the provider's ApplyResourceChange over gRPC; the AWS provider makes the real API calls (RunInstances, then polls DescribeInstances until 'running'; CreateBucket; and so on) and returns the new attributes, which fill in the (known after apply) values that dependants need. After each resource finishes, Terraform persists the updated state (to S3 for a remote backend), so a crash mid-apply loses little. If an operation fails, the other independent operations finish, the error is printed, and state records what really happened; a half-created resource can end up 'tainted' and replaced next time. There is no rollback: you fix and apply again. Finally the lock is released and outputs are printed.
PLANFILEApply a saved plan exactly; no prompt-auto-approveSkip the yes prompt (only for automation you trust)-var / -var-fileVariables, when not applying a saved plan-replace=ADDRForce-recreate one resource (replaces old taint)-target=ADDROnly this resource and its dependencies (exceptional)-parallelism=NConcurrent operations (default 10)-lock-timeout=5mWait for a busy lock instead of failing-refresh-onlyAccept drift into state; change no resourcesdestroyterraform destroy = apply -destroy: remove everything in stateterraform apply -auto-approve from a laptop against prodNo review, and whatever is on your branch and in your shell variables gets applied.
Plan in CI with -out, review, then apply the saved plan from the pipelineUsing -lock=false because 'the lock is stuck'If another apply is running, both write state and one set of changes is lost or corrupted.
Find who holds it (Lock Info); terraform force-unlock ID only when that run is really deadExpecting a failed apply to roll backTerraform has no transactions; what succeeded stays and is in state.
Read the error, fix the code, apply again; it converges from where it stoppedFixing a broken resource by deleting it in the consoleState still has it; the next plan shows it must be created, but other resources may reference a now-missing ID.
terraform apply -replace=ADDR to recreate it through TerraformTry these on a Linux machine of your own. Each task has a hint and a solution.
In ~/infra (after apply), recreate only aws_instance.web without touching anything else, with an approval prompt. Compare the instance ID before and after.
Read this lock message and decide what to do: 'Who: priya@ci-runner-7 Created: 2026-10-29 10:42:33' and it's now 10:44.
Write the commands a pipeline's apply stage should run, given that the plan stage uploaded tfplan.