For the TF-003 exam, you need to understand how Terraform handles infrastructure that spans multiple environments and teams. This chapter explains remote operations, workspaces, and version control integration — the three tools that allow you to manage infrastructure safely when you are not working alone on your personal laptop.
Jump to a section
A simple way to picture Remote Operations, Workspaces, and VCS Integration
A professional kitchen is not a single room with one chef. A busy restaurant chain has multiple kitchens across different cities, each serving the same menu to hundreds of customers every night. The chain's head chef at the central office does not fly to each kitchen to taste every sauce. Instead, each kitchen is a separate workspace with its own inventory and prep lists, but all kitchens follow the same master recipe book stored in a digital folder that everyone can see.
When the head chef wants to change the recipe for the house salad dressing, she does not rewrite the recipe on a napkin and fax it to every location. She edits the master recipe in the shared digital folder. Each local kitchen then pulls the latest version of that recipe before the dinner rush. If a kitchen tries to use an old version of the recipe, the salad dressing will taste wrong and customers will complain. The shared digital folder keeps a complete history of every change made to the recipe, so if a new dressing fails, the kitchen can instantly revert back to last week's successful version.
This system allows the chain to run remote operations — the head chef manages recipes from the central office while the local teams execute them. The multiple kitchens represent different workspaces, and the shared digital folder is version control. Without this system, every kitchen would be making its own version of the salad dressing, and the restaurant chain would lose its consistency.
When you start using Terraform on your own computer, everything is local. You write configuration files, you run terraform plan, and you run terraform apply. The state file — the record of what infrastructure exists — lives on your hard drive. This works fine for learning or tiny projects, but the moment you have a team, or you want to run Terraform automatically from a build server, or you need to manage multiple environments like development, staging, and production, the local setup breaks.
Remote operations solve the problem of running Terraform from a place that is not your laptop. Instead of executing terraform plan and terraform apply on your machine, you send those commands to a remote service — specifically, Terraform Cloud or Terraform Enterprise. The remote service runs the commands, stores the state file securely, and shows you the output in a web browser or through an API. This means you do not need to install Terraform on a central server, and you do not need to worry about who has the latest state file. The remote execution environment is consistent every time, so the same configuration produces the same plan regardless of who triggers it.
The key benefit of remote operations is safety. When Terraform runs on your laptop, if your internet disconnects halfway through an apply, the state file might become corrupt. If a teammate runs apply while you are running apply, both of you might try to create the same resource, causing a conflict. Remote operations solve this by queueing operations and locking the state file so only one run happens at a time. This is called state locking. Terraform Cloud handles all of this automatically.
Workspaces are a way to manage multiple environments using the same Terraform configuration. Imagine you have a configuration that creates a virtual network, a virtual machine, and a database. You need this same setup for development, staging, and production. Instead of copying the configuration folder three times, you create three workspaces within the same Terraform project. Each workspace has its own separate state file. When you run terraform workspace select dev, Terraform knows to use the dev state file and manage the dev infrastructure. When you switch to prod, Terraform uses the prod state file. Workspaces keep your code DRY — Don't Repeat Yourself — because you write the configuration once and reuse it across environments with different variable values.
Version control integration, or VCS integration, connects your Terraform configuration in a Git repository to Terraform Cloud. When you push a change to the main branch of your repository, Terraform Cloud automatically starts a new run. It performs a plan, and you or your team can review the plan before approving the apply. This creates a workflow exactly like code review. No one can make infrastructure changes without going through version control. Every change is logged with a commit message, an author, and a timestamp. If something breaks, you can look at the Git history to see exactly which change caused the problem, and you can revert the commit to roll back the infrastructure.
The combination of these three features creates a system called Infrastructure as Code in practice. You write your infrastructure in code, you store it in Git with your team, and you use Terraform Cloud to execute it safely with state locking and environment separation. This is the standard way organisations manage cloud infrastructure at scale.
For the exam, remember that remote operations are about where Terraform runs, workspaces are about separating environments without duplicating code, and VCS integration is about triggering Terraform automatically from Git changes. They are three separate concepts that work together.
Set up a Terraform Cloud account and organisation
You create a free account at app.terraform.io and create an organisation. The organisation is the container for all your workspaces and runs. This is the first step because every remote operation, workspace, and VCS integration ties back to this organisation.
Create a workspace in Terraform Cloud for each environment
You create one workspace for development, one for staging, and one for production. Each workspace has its own state file and variable set. This step is where you decide how many environments you need.
Connect your Git repository to Terraform Cloud via VCS integration
In the workspace settings, you link your GitHub, GitLab, or Bitbucket repository. Terraform Cloud will automatically detect pushes to the configured branch and start a new run. This step replaces the manual terraform plan and terraform apply commands.
Configure the remote backend in your Terraform code
You add a backend block to your main.tf file that tells Terraform to use Terraform Cloud as the backend. The block specifies the organisation and the workspace name patterns. Without this, Terraform will run locally.
Push your code to the main branch and trigger the first run
You commit and push your Terraform configuration to the Git repository. Terraform Cloud detects the push, starts a run, performs a plan, and waits for approval. You review the plan in the web UI and click Confirm & Apply.
Monitor state locking and run history
After the apply completes, Terraform Cloud unlocks the state file. You can view the run history, see who approved each change, and examine the plan output for every run. This is how teams audit infrastructure changes.
Consider a real company called FinSecure that provides financial analytics software. FinSecure has three environments: a development environment where developers test new features, a staging environment that mirrors production for final testing, and a production environment that serves paying customers. All three environments run on Amazon Web Services and use the same Terraform configuration.
FinSecure's platform team writes a Terraform configuration that creates an auto-scaling group of EC2 instances, an Application Load Balancer, an RDS database, and a Redis ElastiCache cluster. The configuration uses variables for environment-specific settings like instance size, database password, and subnet IDs.
The team stores this configuration in a GitHub repository. They have a branch protection rule that requires at least one approved review before merging into the main branch.
Here is what happens when a platform engineer named Maria needs to increase the database size in the staging environment. She creates a new Git branch from main, edits the Terraform variables file to change the staging database instance class from db.t3.medium to db.t3.large, and opens a pull request. Her teammate reviews the change and approves it. Maria merges the pull request into the main branch.
Terraform Cloud is connected to the GitHub repository via a VCS integration. As soon as Maria merges the commit to main, Terraform Cloud detects the change and starts a new run. It automatically checks out the latest code and runs terraform plan. The plan output shows that Terraform will modify the RDS instance class in the staging workspace — it will not touch development or production.
The platform team has configured Terraform Cloud to require manual approval for applies in the staging workspace. Maria receives a notification, logs into Terraform Cloud, reviews the plan, and clicks Confirm & Apply. Terraform Cloud runs terraform apply, executes the change against the staging AWS account, and updates the state file. The entire process is recorded: the Git commit SHA, the plan output, who approved it, and the timestamp.
Because FinSecure uses remote operations with state locking, no other team member can run a Terraform operation at the same time. Because they use workspaces, the development and production environments are completely isolated — changing staging has no risk of accidentally affecting production. Because they use VCS integration, every infrastructure change is tied to a code review and a commit message.
If the new database size causes performance issues in staging, Maria can revert the commit in Git. Terraform Cloud will pick up the revert, run a new plan that changes the database back to db.t3.medium, and Maria can approve the apply. The rollback is as simple as reverting a code change.
The TF-003 exam tests this objective with questions that probe your understanding of the differences between local and remote operations, the purpose of workspaces, and how VCS integration works. You will not be asked to configure these features from memory, but you must know what they do and why they exist.
Here are the specific concepts the exam targets:
Remote operations execute terraform plan and terraform apply on Terraform Cloud or Terraform Enterprise, not on your local machine. The exam will test whether you know that remote operations require a remote backend configuration that points to Terraform Cloud.
State locking is a feature of remote operations that prevents concurrent runs from corrupting the state file. The exam will ask which problem state locking solves. The trap answer is often something about encrypting the state file — encryption is separate.
Workspaces are named containers for multiple state files within the same Terraform configuration. The exam will test that each workspace has its own state file. A common trick question asks whether workspaces share a state file. The answer is no.
The default workspace is called "default" and is always present. The exam might ask what happens if you never create a workspace — you are using the default workspace.
Workspace names can be used in configurations via the terraform.workspace attribute. The exam will test that you can use this attribute to reference the current workspace name inside your code, for example to create environment-specific resource names.
VCS integration triggers Terraform runs automatically when changes are pushed to a configured branch in a Git repository. The exam will test that this is an optional feature and that you can still trigger runs manually via the Terraform Cloud API.
The exam loves to compare the Terraform Cloud VCS workflow with running Terraform locally. The key difference is that VCS integration enforces that all infrastructure changes go through version control and code review.
The exam may present a scenario where a team is having conflicts because multiple people run terraform apply at the same time. The correct answer is to use remote operations with a remote backend that supports state locking.
The exam may present a scenario where a team needs to manage separate environments like dev, test, and prod. The correct answer is to use workspaces, not to copy the configuration folder three times.
Do not confuse workspaces with modules. Modules are reusable pieces of configuration. Workspaces are separate instances of the same configuration. The exam will test this distinction.
The exam will not ask you to write the backend configuration block from memory, but you should recognise the required fields: hostname, organization, and workspaces.
For VCS integration, know that you can configure automatic speculative plans on pull requests. This means Terraform Cloud runs a plan when someone opens a pull request, but does not apply it. The exam tests that this is a feature, not a bug.
The exam may ask what happens if you run terraform apply locally while using a remote backend. The answer is that Terraform will run the command locally by default unless you use the remote execution mode.
Remote operations move Terraform execution from your local machine to Terraform Cloud, providing state locking and a consistent execution environment.
Workspaces allow you to manage multiple environments like dev, staging, and prod using a single Terraform configuration, each with its own separate state file.
VCS integration connects your Git repository to Terraform Cloud so that every push to the configured branch automatically triggers a Terraform run.
Never store Terraform state files in version control — state files contain sensitive information and must be stored securely in a remote backend.
The default workspace is always present and is named 'default' — if you never create a workspace, you are using the default workspace.
State locking prevents two team members from running terraform apply at the same time and corrupting the state file.
Terraform Cloud can run speculative plans on pull requests, showing you the impact of changes without applying them.
Workspaces are for state separation, not for code reuse — use modules for code reuse and workspaces for environment separation.
These come up on the exam all the time. Here's how to tell them apart.
Local Execution
Terraform runs on your laptop or local machine.
State file stored on your hard drive.
No built-in state locking; concurrent runs can corrupt state.
Remote Execution
Terraform runs on Terraform Cloud managed servers.
State file stored securely in Terraform Cloud backend.
Automatic state locking prevents concurrent corruption.
Workspaces
Separate state files for different environments.
One configuration, multiple state files.
Best for dev/staging/prod separation.
Modules
Reusable blocks of configuration code.
One state file can use multiple modules.
Best for packaging and sharing infrastructure patterns.
VCS Integration (Automatic)
Terraform starts automatically on Git push.
Plan and apply flow through code review.
Every change is tied to a commit and pull request.
CLI-Driven (Manual)
You run terraform plan and apply manually.
No automatic code review gate.
Changes are not automatically linked to version control.
Mistake
Workspaces are the same as Terraform modules — both let you reuse code.
Correct
Workspaces separate state files for different environments using the same configuration, while modules package reusable configuration blocks. You can use both together.
Beginners hear 'reuse' and lump all reuse mechanisms together. The exam deliberately tests the difference between state separation (workspaces) and code packaging (modules).
Mistake
Remote operations mean Terraform runs on a remote server that I have to set up and manage myself.
Correct
Remote operations in Terraform Cloud run on HashiCorp's managed infrastructure. You connect your Terraform Cloud account and specify the workspace, and HashiCorp handles the execution environment.
People with a sysadmin background assume 'remote' means self-managed servers. Terraform Cloud is a SaaS product, so no server management is needed.
Mistake
VCS integration means I have to store my Terraform state file in the Git repository.
Correct
VCS integration stores the Terraform configuration code in Git, but the state file is stored separately in Terraform Cloud. Never commit state files to Git.
New learners conflate 'code in Git' with 'state in Git'. The exam emphasises that state files contain sensitive data and must not be committed to version control.
Mistake
If I use workspaces, I need to create a separate Git branch for each workspace.
Correct
Workspaces are independent of Git branches. A single main branch can trigger runs in multiple workspaces. Git branches are for code changes, workspaces are for state separation.
Both concepts involve separation, so beginners map them one-to-one. The exam tests that they are orthogonal — you can have one branch and ten workspaces.
Mistake
State locking prevents anyone from reading the state file while a run is in progress.
Correct
State locking prevents concurrent writes to the state file, but the state file can still be read by other processes. Locks only block write operations.
The word 'lock' sounds like complete exclusion. The exam expects you to know that locks are write-exclusive, not read-exclusive.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
The exam focuses on Terraform Cloud as the remote operations platform, but technically any remote backend that supports state locking can be used. Terraform Cloud is the recommended solution because it also provides VCS integration and a web UI.
They are the same concept. The Terraform CLI has local workspaces, and Terraform Cloud has cloud workspaces. Both allow multiple state files per configuration, but cloud workspaces add features like remote execution and VCS integration.
Yes, that is the standard practice. You have one repository with your Terraform configuration, and you create multiple workspaces in Terraform Cloud — one for each environment. The repository does not need to change for different environments.
Deleting a workspace permanently deletes the associated state file. Terraform Cloud warns you before deletion. Always backup your state file before deleting a workspace, or use the Terraform Cloud API to export it.
You still need Terraform installed locally to write and validate your configuration files with terraform fmt and terraform validate. However, the actual terraform plan and terraform apply run on Terraform Cloud, not on your machine.
You set workspace-specific variables in the Terraform Cloud UI for each workspace. For example, you set the instance_type variable to 't2.micro' in the dev workspace and to 't2.large' in the prod workspace. You can also use the terraform.workspace attribute in your code.
Yes, by default Terraform runs commands locally unless you configure the remote execution mode in the backend block. You can choose to run local execution for development and remote execution for production environments.
You've finished Remote Operations, Workspaces, and VCS Integration. Continue through the TF-003 study guide to build a complete picture of the exam.
Done with this chapter?