In Domain 4 of the TF-003 exam, you must master the core Terraform workflow: init, plan, apply, and destroy. This is the heartbeat of Terraform — the four commands you will use almost every time you manage infrastructure as code. Understanding this workflow isn’t just about passing the exam; it’s the foundation for safely creating, previewing, and removing cloud resources without accidentally causing downtime or incurring surprise bills.
Jump to a section
A simple way to picture Terraform Workflow Essentials: Init, Plan, Apply, Destroy
Have you ever planned a big transformation and then panicked because you weren’t sure the end result would match what you had in mind? That’s exactly what Terraform’s workflow solves — it lets you see the finished product before you commit. Imagine you’ve just bought a rundown house and you want to turn it into a cosy little café. You’ve got a blueprint (your Terraform configuration), but you wouldn’t just start knocking down walls with a sledgehammer. First, you need to get your tools ready: you buy the right ladder, check your toolbox, and make sure the power drill is charged. That’s the Init step — preparing your working environment.
Next, you walk through the house with your blueprint and mentally map out where each wall will go, where the kitchen will be, and where the coffee machine stands. You take notes: “If I move this wall, I’ll lose two metres of floor space, but I’ll gain a bigger counter.” That’s the Plan step — you see the exact changes without lifting a hammer.
Then comes the moment of truth: you actually start building. You knock down walls, install plumbing, and hang the café sign. Apply is the step where your blueprint becomes reality. But what if you change your mind later and decide the café should be a bookstore instead? You’d tear down the café interior and start fresh. That’s the Destroy step — cleaning up so you’re not left with a half-empty building you can’t reuse.
Terraform is a tool that lets you define your IT infrastructure — things like virtual machines, databases, and networks — in simple text files called configuration files. Instead of logging into a cloud console and clicking buttons to set up a server, you write down what you want in a file, and Terraform makes it happen. The workflow we’re about to explore is the standard sequence of commands you run to go from an empty folder to a fully built (and later fully destroyed) set of resources.
Let’s start with Init (short for ‘initialise’). When you first write your configuration files, Terraform doesn’t know anything about them. It needs to download the code that talks to your cloud provider (like AWS, Azure, or Google Cloud). Those code packages are called providers. For example, if you want to create a virtual machine in AWS, you need the AWS provider. The terraform init command looks at your configuration, figures out which providers you need, downloads them into a hidden folder called .terraform, and also sets up a state file — a record of everything Terraform is managing. You run init once at the beginning of a project, and again any time you add a new provider. Without init, none of the other commands will work.
Next is Plan. This is one of Terraform’s most powerful features because it lets you preview changes before making them. When you run terraform plan, Terraform reads your current configuration files, compares them with the state file (which knows what currently exists in the real world), and creates an action plan. It tells you exactly what will be created, modified, or deleted. For example, it might say: “This will create 1 AWS instance, update the security group, and delete an old load balancer.” This step is safe — it doesn’t actually change anything. It’s like a detailed receipt before you pay. The plan output even shows you a count of how many resources will be added, changed, or destroyed. If the plan looks wrong, you can stop and fix your configuration without harm.
After reviewing the plan, you run Apply. The terraform apply command takes the plan you approved and executes it. Terraform calls the cloud provider’s API (Application Programming Interface — a way for two software programs to talk to each other) and says: “Create this server, attach this disk, assign this IP address.” It then updates the state file to match what it just built. By default, Terraform will do a plan again before applying, and then ask for your confirmation with a prompt: “Do you want to perform these actions?” This double-check prevents accidents. However, if you already ran a plan separately and know the changes are safe, you can skip the confirmation by passing the --auto-approve flag. Apply is the moment of truth — your infrastructure is now live.
Finally, there is Destroy. When you no longer need your infrastructure — maybe you’re done testing, or you want to avoid cloud costs — you run terraform destroy. This command reads the state file, figures out what exists, and tears it all down in the correct order. If a virtual machine depends on a network, Terraform destroys the machine first, then the network. Destroy is the opposite of apply: it removes resources. Just like apply, it first shows you a plan (what will be deleted) and asks for confirmation. This prevents you from accidentally wiping out your production database.
Together, these four commands form a loop: init to set up, plan to preview, apply to build, destroy to clean up. Real teams use this loop repeatedly — they plan and apply small changes, test them, then destroy test environments to keep costs low. This workflow replaces the old way of manually configuring servers by hand, which was slow and error-prone. By codifying your infrastructure, you can rebuild identical environments in minutes and destroy them just as quickly.
Terraform Init
Run terraform init in your project directory. Terraform reads your .tf files, identifies the required providers (e.g., AWS, Azure), downloads them into the .terraform folder, and configures the backend for state storage. This is the setup step — without it, nothing else works.
Terraform Plan
Run terraform plan to generate an execution plan. Terraform compares your configuration with the current state file (if any) and outputs a summary of changes: additions, modifications, and destructions. This is a dry run — no resources are touched. Use it to catch mistakes before applying.
Terraform Apply
Run terraform apply to implement the plan. Terraform will display the plan again and prompt you to type 'yes' (unless you use --auto-approve). It then calls cloud provider APIs to create, update, or delete resources. After completion, the state file is updated to match the new infrastructure.
Terraform Destroy
Run terraform destroy when you want to remove all resources managed by the current configuration. It shows a destruction plan (like a reverse plan) and asks for confirmation. Once confirmed, Terraform tears down resources in dependency order. The state file is updated to reflect nothing exists.
Rerun Init for Changes
If you later add a new provider, change a provider version, or switch the state backend, you must rerun terraform init. This updates the .terraform folder. It is safe to rerun — it will not destroy any existing resources or undo previous work.
Imagine you work for a small e-commerce company called “ShopFast” that wants to launch a new feature: a product recommendation engine. The development team needs a temporary test environment — a virtual server with a database and a load balancer — to run experiments. They don’t want to use the production environment because mistakes there would lose orders. A year ago, you would have logged into the cloud console, clicked through wizard pages to create a server, configured a database manually, and prayed you didn’t miss a setting. If you made a mistake, you’d have to start over or spend hours debugging.
With Terraform, you write a configuration file that declares: “one AWS EC2 instance (virtual server), one RDS database (managed relational database), one ALB (load balancer).” You store these files in version control (like Git) so your whole team can see and review them. Here is how you use the workflow step by step.
- First, run terraform init. You or a colleague clones the repository for the first time. The init command installs the AWS provider and creates the initial state file.
- Next, run terraform plan. The output shows: “Plan: 3 to add, 0 to change, 0 to destroy.” This tells you that three new resources will be created. You review the plan with your team lead to confirm the instance type (t3.micro) is correct and the database password is set from a variable, not hardcoded.
- Then, run terraform apply. Terraform shows the same plan again and asks: “Do you want to perform these actions?” You type ‘yes’. Terraform calls AWS APIs, and within two minutes, the server, database, and load balancer are all running. The state file is updated with the resource IDs, IP addresses, and other metadata.
- The development team runs their tests for a week. Once they are done, you run terraform destroy. Terraform shows a plan: “Destroy: 3 to destroy.” You confirm, and all three resources are deleted. No dangling virtual machines, no forgotten database that costs £50/month.
In larger organisations, this workflow is automated. A CI/CD pipeline (a system that automatically runs tests and deployments) will run terraform plan on every code change, someone reviews the plan, and then terraform apply is triggered automatically for staging environments. The destroy step is often scheduled to clean up test environments every evening to save money. The core workflow remains the same whether you are managing one server or a thousand — init, plan, apply, destroy. For your TF-003 exam, you do not need to be an expert in any particular cloud — you just need to understand the purpose and order of these four commands and when each one is used.
TF-003 definitely tests your understanding of the order and purpose of the four workflow commands. You will see multiple-choice questions, scenario-based questions, and true/false questions. Do not let the simplicity of the concepts trick you — the exam loves to set traps around the details. Here is what you must know cold.
Order of commands: The exam expects you to know that init must be run before plan and apply. A common trap question is: “You just wrote a new configuration with a new provider. Which two commands must you run in sequence to deploy it?” The answer is init then apply (or init then plan then apply — both are valid sequences, but the first command is always init). They might give options like plan then init or apply then init — those are wrong because you cannot plan or apply before initialising.
Plan is not destructive: Many questions will try to confuse you into thinking terraform plan makes changes. Remember: plan is a read-only operation. It never touches your infrastructure. The only commands that change infrastructure are apply and destroy. If a question says “which command creates resources?”, the answer is apply. If it asks “which command deletes resources?”, the answer is destroy.
State file and init: The exam expects you to know that terraform init prepares the working directory — it downloads providers and sets up the state. It does NOT create or modify any real infrastructure. A typical trap question: “A team member just added a new module. Which command should they run first?” The answer is init (not plan or apply). Another trap: “You run terraform plan and get an error about a missing provider. What command did you forget?” Answer: terraform init.
Destroy confirmation: The exam tests that terraform destroy prompts for confirmation by default, just like apply. They might ask: “Which flag would you use to skip the confirmation prompt when destroying resources?” The answer is --auto-approve. They may also ask whether terraform destroy creates a plan first — yes, it does.
Comparison with plan and apply: Some questions ask you to identify the difference between terraform plan and terraform apply. The key distinction: plan shows you what will happen, apply makes it happen. A typical exam scenario: “You want to verify that adding a new security group rule won’t accidentally remove an existing rule. Which command do you run?” Answer: terraform plan.
State locking when running apply: While not central to the workflow, the exam sometimes asks about state locking during apply. The idea is that if two people run terraform apply at the same time, the state file could get corrupted. Terraform locks the state when applying, and terraform init can be used to configure backend locking (e.g., with S3 + DynamoDB). For single-workflow questions, know that apply (and destroy) are the commands that require state locking.
Key facts to memorise:
The four core commands in order: init, plan, apply, destroy.
terraform init is idempotent — running it multiple times is safe.
terraform plan outputs ‘to add’, ‘to change’, and ‘to destroy’ counts.
terraform apply will run a plan and ask for confirmation by default.
terraform destroy is equivalent to terraform apply -destroy.
Without init, no other command works.
Plan never modifies infrastructure.
Expect at least 3-5 questions on this topic in the exam. They will be straightforward if you memorise the roles of each command and the order. The trap questions often revolve around mis-ordering or confusing plan with apply.
The Terraform workflow is a four-step cycle: init, plan, apply, and destroy, executed in that order.
Terraform init is required before any other command — it downloads providers and sets up the state backend.
Terraform plan is a read-only preview that shows what resources will be added, changed, or destroyed without making any real modifications.
Terraform apply executes the changes described in the plan and updates the state file to reflect the new infrastructure.
Terraform destroy is the inverse of apply — it deletes all resources managed by the current configuration and requires confirmation by default.
All four commands are safe to run multiple times — init is idempotent, plan is read-only, and apply/destroy ask for confirmation.
Without an initialised working directory (via init), terraform plan and apply will fail with an error about missing providers.
The state file is Terraform’s record of real-world resources — it is updated during apply and destroy, and never modified during plan.
These come up on the exam all the time. Here's how to tell them apart.
terraform plan
Read-only operation that never modifies infrastructure
Outputs a summary of changes (add, change, destroy)
Does not update the state file
terraform apply
Modifies infrastructure by creating, updating, or deleting resources
Displays the plan and asks for confirmation before making changes
Updates the state file after execution
terraform init
Downloads providers and sets up the backend
Must be run before any other command in a new directory
Does not read or compare state to configuration
terraform plan
Reads configuration and state to generate an execution plan
Can only be run after init has been successful
Does not download anything
terraform apply
Creates or modifies resources to match the configuration
Can add new resources or update existing ones
Preserves infrastructure if you want to keep running it
terraform destroy
Removes all resources managed by the configuration
Does not create or update anything
Leaves no resources behind once complete
terraform apply (default behavior)
Runs a plan and shows it to the user
Prompts the user to type 'yes' before making changes
Safer for production environments because it adds manual approval
terraform apply --auto-approve
Skips the confirmation prompt entirely
Runs the plan and immediately makes changes
Useful for automation scripts and CI/CD pipelines
Mistake
You can skip terraform init if your configuration hasn't changed.
Correct
You must run terraform init at least once per new working directory. After that, you only need to rerun init if you add a new provider, change a provider version, or modify the backend configuration. It is safe to rerun it, but it is not required every time.
Beginners think providers are built into Terraform and do not need to be downloaded. They assume that because the terraform command exists, everything is ready to go. In reality, providers are plugins that must be installed separately.
Mistake
Terraform plan and terraform apply are interchangeable — apply just runs plan automatically.
Correct
Plan is a read-only preview that shows what will change. Apply actually makes those changes. They are distinct commands with different purposes and safety considerations.
Because apply runs a plan internally before asking for confirmation, beginners conclude that plan is redundant. But plan is essential for reviewing changes in CI/CD pipelines and for sharing with team members before deployment.
Mistake
Terraform destroy deletes all resources in your cloud account, not just the ones in your configuration.
Correct
Terraform destroy only removes resources that are tracked in the Terraform state file. If you have resources in your cloud account that were created manually or by another tool, terraform destroy will not touch them.
The word 'destroy' sounds absolute and scary. Beginners imagine it will wipe out everything. They do not understand that Terraform only manages what is in its state file — resources outside that file are invisible to Terraform.
Mistake
You must run terraform plan before every terraform apply.
Correct
You do not need to run plan separately. The apply command automatically runs a plan and prompts for confirmation. Running plan separately is optional and is used when you want to review the output before applying, especially in team reviews or automated pipelines.
Many tutorials show a pattern of plan then apply, so beginners think it is a strict requirement. They do not realise the plan step is built into apply for convenience.
Mistake
Terraform init also creates the infrastructure resources.
Correct
Init only prepares the working directory by downloading providers and setting up the state backend. It never creates, modifies, or destroys any real infrastructure.
The word 'initialise' sounds like 'start up', so beginners equate it with 'create'. They do not distinguish between preparing the tool and using the tool to build resources.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
No, you do not have to run plan separately. The apply command automatically runs a plan and asks for your confirmation. Running plan separately is optional and often done in team workflows to share the plan output for review.
It will fail with an error. Terraform requires the providers to be installed in the .terraform directory, and init is the only command that installs them. Always run init first in a new working directory.
No, it only deletes resources that Terraform is tracking in the state file. Resources created manually or by other tools are not affected — they are invisible to Terraform.
Yes, terraform plan is a read-only operation. You can run it as many times as you like. It never creates, modifies, or deletes any real infrastructure. It only reads your configuration and the current state file.
Apply creates or modifies resources to match your configuration. Destroy removes all resources managed by your configuration. Both commands require confirmation and both update the state file, but destroy removes everything while apply may add or change resources.
This usually happens if you added a new provider to your configuration after the initial init. You need to rerun terraform init whenever you add a new provider, change a provider version, or modify the backend configuration.
You've finished Terraform Workflow Essentials: Init, Plan, Apply, Destroy. Continue through the TF-003 study guide to build a complete picture of the exam.
Done with this chapter?