How do you prevent chaos when multiple people are building and changing the same cloud infrastructure at the same time? That's the big problem that remote state and backends solve. For the TF-003 exam, you need to know how Terraform keeps a single, secure, shared record of everything you've built — and this chapter explains exactly how that works in plain English.
Jump to a section
A simple way to picture Remote State and Backends
An office filing cabinet is the single source of truth for the entire team's project documents.
Imagine you and three friends are writing a massive group report together in a physical office. Each of you has your own desk with a small drawer where you keep your current notes and drafts. This is your 'local state' — it's handy for your own quick work, but it's a disaster for teamwork. If you update the introduction on your computer while your friend edits the conclusion on theirs, you create two different versions of the report. Nobody knows which one is correct. To fix this, your team buys a single, shared filing cabinet that sits in the middle of the office. You all agree on one rule: the master copy of the report is always the one inside that cabinet. When you want to work, you take the folder out to your desk, make changes, and then put the updated folder back into the cabinet. The cabinet also keeps a history label showing who changed what and when. If someone accidentally spills coffee on their notes, the real document is still safe in the cabinet.
This filing cabinet is exactly what a Terraform backend does for your code. Your personal computer holds your local 'state file' — the map of the infrastructure you built. But if you're on a team, everyone's local map quickly goes out of sync. Terraform's remote backend is that shared, locked filing cabinet in the cloud. It stores the one true state file, logs who made changes, and lets only one person edit it at a time. Without it, your team would accidentally overwrite each other's work and break the infrastructure.
When you run 'terraform apply', Terraform creates a file called 'terraform.tfstate'. This state file is a map of everything you just built: every server, every database, every network setting. Think of it as Terraform's scorecard — it tells the tool what already exists, so the next time you run a command, it doesn't try to create the same server twice or accidentally delete something it should keep.
Without a shared state file, every person on your team would have their own copy of the map on their own laptop. If you add a server and your colleague adds a database around the same time, you'd have two different maps. When you both try to update the infrastructure, one of you would overwrite the other's changes, or Terraform would get confused and try to rebuild things that already exist. This is called 'state file drift' — when the local map no longer matches reality.
A 'backend' is simply where Terraform stores this state file. By default, Terraform saves the state file on your local hard drive (the 'local' backend). For a single person learning Terraform on their own machine, that's fine. But in a team environment, you need a 'remote backend' — a shared location that everyone on your team can access.
There are several common types of remote backends:
Amazon S3 (Simple Storage Service): a cloud storage bucket from Amazon Web Services. The state file is stored as a regular file in a bucket, and you can add 'dynamodb locking' to prevent two people from editing at the same time.
AzureRM (Azure Resource Manager): Microsoft Azure's version, where the state is stored in a 'storage account container' and locked with an 'Azure blob lease'.
Google Cloud Storage (GCS): similar to S3 but for Google Cloud. It stores the state file in a bucket and offers locking.
Terraform Cloud: HashiCorp's own managed service. It handles state storage, version history, and locking automatically without you having to set up any cloud storage yourself.
When you configure a remote backend, you write a block in your Terraform configuration that looks like this:
terraform { backend "s3" { bucket = "my-company-terraform-state" key = "prod/network/terraform.tfstate" region = "us-east-1" } }
This tells Terraform: 'Don't save the state on my laptop. Instead, go to this S3 bucket and fetch the shared state file from there.' Every time you run 'terraform plan' or 'terraform apply', Terraform automatically downloads the latest version of the state from the remote backend, compares it with your code, and then uploads any changes after the operation completes.
Why does this matter? Three reasons: consistency, locking, and history. Consistency means everyone always sees the same map. Locking is a mechanism that prevents two people from running 'apply' at the exact same moment — if you start an apply, the backend locks the state file, and your colleague's apply will wait until you're done. History means the remote backend can keep old versions of the state file, so if something goes wrong, you can roll back to the previous state.
For the TF-003 exam, you must know that the default backend is 'local', and that remote backends are essential for team environments. You also need to understand that the state file can contain sensitive information (like passwords or IP addresses), so remote backends should always be encrypted and access-controlled. Finally, remember that not all backends support state locking — for example, a simple S3 bucket without DynamoDB does not lock the state, which is risky. HashiCorp recommends always using a backend that supports both state storage and locking.
Decide Your Team's Backend Type
Before writing any Terraform code, decide where you will store the shared state file. For the exam, the main options are Amazon S3 (with DynamoDB for locking), AzureRM, Google Cloud Storage, or Terraform Cloud. Choose based on which cloud provider your organisation uses or whether you want a managed service.
Create the Backend Storage in Your Cloud Provider
You must manually create the storage location before Terraform can use it. For example, create an S3 bucket in AWS, or a storage container in Azure. This step is essential because Terraform cannot create the backend itself — it needs an existing place to store the very first state file.
Add a Backend Configuration Block to Your Terraform Code
Inside your Terraform configuration files (usually in a file called 'backend.tf' or 'main.tf'), you write a 'terraform' block with a nested 'backend' block that specifies the type and details. For example, you specify the bucket name, the file path (key), and the region. This tells Terraform where to find the remote state.
Run 'terraform init' to Initialise the Backend
When you run 'terraform init' for the first time, Terraform reads your backend configuration, connects to the remote location, and downloads the current state file (or creates an empty one if it doesn't exist yet). It also sets up the lock mechanism. You must run 'init' after adding or changing a backend configuration.
Run 'terraform plan' and 'terraform apply' Normally
From this point on, every time you run 'plan' or 'apply', Terraform automatically downloads the latest state from the remote backend, compares it with your code, and after an 'apply', uploads the updated state back to the backend. You don't need to manually copy or upload anything — Terraform handles it.
Enable Versioning and Encryption on the Backend Store
After the backend is working, enable bucket versioning (on S3 or GCS) or soft-delete (on Azure) to keep historical copies of the state file. Also enable encryption at rest to protect sensitive data. These are important security and recovery steps that the exam expects you to recognise as best practices.
Set Up Access Controls for the Backend
Use IAM policies (or Azure RBAC) to restrict who can read and write the state file. Only team members who need to modify infrastructure should have write access. Others might have read-only access for reference. This step prevents accidental or malicious corruption of the state file.
Let's walk through a realistic day for Priya, a DevOps engineer at a mid-sized e-commerce company. Priya's team of five people all manage the same cloud infrastructure for the company's main website. They use Terraform with an S3 backend and DynamoDB locking.
At 9:00 am, Priya opens her laptop and pulls the latest code from the team's Git repository. She runs 'terraform init' which tells Terraform to connect to the remote S3 bucket. Terraform downloads the current state file — it shows the company currently has 12 web servers, 3 databases, and 2 load balancers deployed in the 'us-east-1' region.
Priya sees a ticket to add one more web server because traffic has increased. She edits the Terraform configuration file to increase the server count from 12 to 13. Before she runs 'apply', she runs 'terraform plan' — Terraform fetches the state again (to make sure nobody else changed it in the last 10 minutes) and tells her: 'You want to add 1 server. No other changes detected.'
At 9:15 am, Priya runs 'terraform apply'. Terraform first contacts the DynamoDB table, which acts as a lock. It checks if any other team member is currently applying changes. Nobody is, so Terraform takes the lock (writes a record in the table saying 'Priya is editing now'). Then it creates the new server. During this process, Priya's colleague Marco tries to run his own 'terraform apply' to update a database password. His command detects the existing lock and waits — it shows a message: 'Acquiring state lock. This may take a few moments...' It will keep trying until Priya finishes.
At 9:20 am, Priya's apply completes. Terraform uploads the updated state file to the S3 bucket, which now reflects 13 servers. It releases the lock from DynamoDB. Marco's command immediately acquires the lock, downloads the new state, and proceeds with his database password change.
Later that day, another colleague accidentally submits a change that would delete the entire load balancer. They catch it during the plan step, but the state file in S3 has a versioning feature enabled. Even if they had applied the mistake, Priya could have rolled back the state file directly in S3 to the previous version and then run 'terraform apply' to restore the load balancer.
What does Priya actually do day-to-day regarding backends? She:
Checks that the team's backend configuration in the code always points to the correct S3 bucket and DynamoDB table.
Ensures that only appropriate team members have IAM (Identity and Access Management) permissions to read and write to that S3 bucket.
Occasionally reviews the state file history in S3 to see who changed what and when.
Sets up a separate state file for each environment — 'dev', 'staging', and 'production' — using different S3 bucket paths, so changes in development never accidentally affect the live website.
In this real-world scenario, the remote backend isn't an abstract concept — it's a practical tool that prevents Priya and Marco from breaking each other's work and keeps their production infrastructure stable.
The TF-003 exam tests your understanding of Remote State and Backends quite directly. You will see questions about backend types, state locking, and the practical reasons for using remote state. Here is exactly what you need to know.
First, memorise that the default backend is 'local'. Many questions assume you know this without being told. A typical question might be: 'You run terraform apply without configuring a backend. Where is the state stored?' The answer is always the current working directory on your local machine.
Second, you must be able to identify the three most common standard backends from the options: Amazon S3, AzureRM Storage Account, and Google Cloud Storage. The exam sometimes includes 'consul' (HashiCorp's own key-value store) as a backend option — know that it exists but is less common. Terraform Cloud is also a backend option and is HashiCorp's recommended choice for teams.
Third, understand state locking. The exam will ask: 'Why is state locking important?' The answer is to prevent concurrent modifications that could corrupt the state file. You also need to know which backends support locking (S3 requires DynamoDB for locking, AzureRM supports it natively, Terraform Cloud does it automatically).
Common trap patterns the exam uses:
They might describe a team scenario and give you options where one is 'use a local backend because it's simpler'. This is wrong — the local backend is not suitable for teams.
They might list a backend that doesn't exist, like 'GitHub Backend' or 'Git Backend'. Terraform does not have a native git backend. Do not fall for invented options.
They might ask about backing up state. The correct answer is to enable versioning on the backend storage (like S3 versioning) — not to manually copy state files.
They might ask about sensitive data in state. State files can contain secrets like database passwords or public IP addresses. The correct practice is to enable encryption at rest on the backend store and restrict access with IAM policies.
They might ask what happens if the backend is unavailable. Terraform will not run 'apply' or 'plan' because it cannot access the state. Some questions test that you cannot operate without a state file.
Key definitions to memorise for the exam:
'State file' — the JSON file that maps Terraform configuration to real-world infrastructure.
'Backend' — the location where Terraform stores the state file.
'Default backend' — local storage in the current directory.
'State locking' — a mechanism to prevent concurrent write operations on the state file.
'Remote state' — accessing a state file stored outside of your local machine, typically in cloud storage.
'State file versioning' — keeping previous copies of the state file for rollback purposes.
Finally, the exam sometimes tests 'remote state data sources'. This is a separate concept from backends: it allows one Terraform configuration to read the state file from another configuration. For example, your networking team's Terraform can store its state, and your application team's Terraform can read it to find the VPC ID. You don't need to write this code on the exam, but you need to recognise that 'terraform_remote_state' is a data source that reads state from a remote backend.
The default Terraform backend is 'local', which stores the state file in the current working directory on your own machine.
A remote backend stores the state file in a shared location (like S3 or Terraform Cloud) so multiple team members can access the same single source of truth.
State locking prevents two people from running 'terraform apply' at the same time, which avoids corrupting the state file and breaking the infrastructure.
The three most common standard backends for the exam are Amazon S3, AzureRM Storage Account, and Google Cloud Storage.
State files can contain sensitive information such as database passwords and IP addresses, so remote backends must be encrypted and access-controlled.
Using a local backend in a team environment will inevitably lead to state file drift, where each person's local map of infrastructure becomes outdated and conflicting.
Terraform Cloud is a managed backend offered by HashiCorp that handles state storage, locking, and version history automatically without you managing cloud storage.
You must configure a backend block inside a terraform block in your configuration file before running 'terraform init' for the first time with a remote backend.
These come up on the exam all the time. Here's how to tell them apart.
Local Backend
Stores state file on your local hard drive only
No state locking — two people cannot safely apply simultaneously
No version history or automatic backups of state
Remote Backend
Stores state file in shared cloud storage (S3, Azure, GCS)
Supports state locking via DynamoDB, blob leases, or Terraform Cloud
Provides version history and rollback through bucket versioning
State File (terraform.tfstate)
JSON file that records what infrastructure currently exists
Created and updated by Terraform automatically
Contains sensitive data like passwords and resource IDs
Configuration Files (.tf files)
Human-readable code written in HashiCorp Configuration Language
Written and version-controlled by the developer in Git
Should not contain raw secrets use variables instead
State Locking
Prevents simultaneous writes to the state file
Implemented via DynamoDB, blob leases, or Terraform Cloud APIs
Ensures state file integrity during concurrent operations
State Versioning
Keeps historical copies of previous state files
Implemented via cloud storage versioning (e.g., S3 versioning)
Allows rollback to a previous state if something goes wrong
Terraform Cloud Backend
Managed by HashiCorp — no cloud storage setup needed
Automatic state locking and version history included
Costs money based on number of resources managed
Self-Managed S3 Backend
You create and manage the S3 bucket and DynamoDB table yourself
Requires manual configuration of locking and versioning
Only costs cloud storage fees — no per-resource pricing
Mistake
The state file is the same as the Terraform configuration files (.tf files). If I delete my .tf files, the state file will also disappear.
Correct
The state file is a separate file (terraform.tfstate) that Terraform creates and updates. Deleting your .tf configuration files does not delete the state file, and deleting the state file does not delete your actual infrastructure.
Beginners often conflate configuration (what you want) with state (what exists). They think the .tf files are the single source of truth, but actually the state file is the record of deployed resources.
Mistake
Remote backends are only useful for huge teams with hundreds of engineers. If I work alone or in a small team of two, I don't need a remote backend.
Correct
Even a two-person team benefits from a remote backend. Without it, if you and your colleague make changes from different laptops, you'll create conflicting local state files. Remote backends also provide backups, version history, and locking regardless of team size.
This misconception comes from thinking that 'team' means 'large team'. TF-003 defines team environment as any scenario where more than one person might run Terraform against the same infrastructure, including small groups.
Mistake
If I use a remote backend, I don't need to store my Terraform code in version control (Git). The backend stores both my code and the state.
Correct
The backend only stores the state file, not your Terraform configuration code. You must still store your .tf files in version control (like Git) for code review, history, and collaboration. The backend is for state only.
The word 'backend' sounds like it stores everything, but its scope is specifically state management. Beginners confuse the concept of 'remote storage for state' with 'remote storage for code'.
Mistake
State locking is optional and only recommended for large teams. For small teams, it slows things down.
Correct
State locking is essential for any team environment, regardless of size. Without locking, two people running 'apply' simultaneously can corrupt the state file, leading to infrastructure drift and potentially breaking live services.
Beginners think locking is an optimisation, not a safety feature. They see it as a 'nice to have' rather than a 'must have', which the exam specifically tests as a requirement for team environments.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A backend is simply where Terraform stores its state file. By default it's on your local computer, but for teams you configure a remote backend like an S3 bucket so everyone shares the same file.
Not strictly for single-person projects, but it's still recommended because it gives you backups, version history, and the ability to run Terraform from different machines. For the exam, remember that local backends are the default but remote backends are best practice even for individuals.
You must run 'terraform init -migrate-state'. This command copies your existing state file from the old backend to the new one. Without the '-migrate-state' flag, Terraform will refuse to change backends.
Yes, the state file can contain sensitive data such as database passwords, access keys, or public IP addresses. You should always enable encryption on the backend storage and restrict access to only authorised users.
State locking prevents two people from running 'terraform apply' at the same time. Without it, simultaneous applies can corrupt the state file. Amazon S3 uses DynamoDB for locking, AzureRM has built-in blob leasing, and Terraform Cloud handles it automatically.
No, Terraform does not have a native Git backend. Storing state files in Git is dangerous because Git handles merge conflicts poorly with binary or JSON files, and state files can contain secrets that should not be in version control. Use a cloud storage backend instead.
It's a data source that lets one Terraform configuration read the state from another configuration. For example, your networking team's state can be read by your application team to get the VPC ID. It's different from a backend — it's a way to share outputs between configurations.
You've finished Remote State and Backends. Continue through the TF-003 study guide to build a complete picture of the exam.
Done with this chapter?