How do you stop a team of engineers from accidentally overwriting each other's infrastructure changes? Terraform Cloud and Enterprise solve this by providing a central platform for managing Terraform runs, state, permissions, and collaboration. For the TF-003 exam, you need to know what features these platforms offer and why they matter for team workflows.
Jump to a section
A simple way to picture Terraform Cloud and Enterprise: Core Features and Setup
You and three friends decide to renovate a shared flat. Doing it alone means one person buys paint, another buys brushes, a third picks tiles, and the fourth chooses a sofa. Without a shared plan, you end up with three different shades of white, mismatched tiles, and a sofa that doesn't fit through the door. This chaos is what happens when a team manages infrastructure without a central system.
Now imagine you all agree on a shared app. First, you define a master blueprint for every room: exact paint codes, tile dimensions, and furniture specifications. Everyone submits change requests through the app, which automatically checks for conflicts. When Sarah wants to swap the sofa, the app verifies no one else changed the living-room layout at the same time, logs who approved it, and updates the central plan. If something breaks, you can roll back to yesterday's version because the app saved every snapshot.
This is exactly what Terraform Cloud and Enterprise do for infrastructure teams. Instead of individuals running Terraform on their laptops with separate state files — leading to conflicting changes — a shared platform manages the state, enforces permissions, runs checks before changes, and keeps a version history. The flat renovation succeeds because everyone works from the same trusted plan, with safety rails built in.
Terraform is a tool that lets you define infrastructure — things like servers, databases, and networks — as code. You write configuration files that describe what you want, and Terraform creates or changes those resources in your cloud provider (like AWS, Azure, or Google Cloud). But when multiple people work on the same infrastructure, problems arise. For example, two engineers might run Terraform at the same time, each thinking they have the correct current state. This causes conflicts and outages. Terraform Cloud and Terraform Enterprise are platforms built to solve these problems.
Terraform Cloud is a hosted service provided by HashiCorp. You do not need to install or maintain any software — you sign up, connect your version control system (like GitHub or GitLab), and it runs Terraform for you. Terraform Enterprise is the self-hosted version. You install it on your own servers, inside your own network. This is useful for organisations with strict security or compliance rules that prevent using a cloud service. Both offer the same core features.
The most important feature is remote state management. When you run Terraform, it creates a file called the state file, which maps your configuration to the real-world resources it manages. This state file is critical: if it is lost or corrupted, you lose the ability to manage your infrastructure. In a team, sharing one state file on a network drive leads to corruption. Terraform Cloud stores the state file securely on its servers, with locking. Locking means that only one run can modify the state at a time. If Alice runs a plan, the state is locked. Bob's run will wait until Alice finishes. This prevents conflicts.
Another key feature is the remote run environment. Instead of running Terraform on your laptop, you trigger runs from a web interface, API, or version control pull request. Terraform Cloud spins up a temporary, isolated environment to execute the plan and apply. This ensures consistency — the environment always has the right Terraform version and plugins — and secures sensitive variables like API keys, because they never touch your local machine.
Collaboration features include:
Run triggers: When one workspace (a collection of configurations managed together) completes, it can automatically trigger a run in another workspace. For example, after you update a network, a workspace for application servers can start.
Policy as code: Using a tool called Sentinel, you can write rules that enforce company policies. For instance, a rule might block any configuration that provisions a server in a non-approved region.
Cost estimation: Before applying changes, Terraform Cloud can estimate the cost of the proposed resources, helping teams manage budgets.
Private module registry: Teams can share reusable Terraform modules (like packaged configurations for an EC2 instance or a database) within their organisation, ensuring consistent patterns.
Version control integration is central. Instead of manually running terraform apply, you push a change to a branch in GitHub, open a pull request, and Terraform Cloud automatically runs a plan. The plan output appears in the pull request as a comment. Team members can review the proposed changes before approving. When the pull request is merged, Terraform Cloud automatically runs the apply. This makes infrastructure changes follow the same review process as application code.
Audit logging records every action: who triggered a run, what changed, and when. This satisfies compliance requirements. Workspaces allow you to organise infrastructure by environment (development, staging, production) or by team. Each workspace has its own state file, variables, and access controls.
Why does this exist? Before these platforms, teams shared state files via shared drives or manual processes, which was error-prone and insecure. Engineers ran Terraform locally, leading to version mismatches and unreviewed changes. Terraform Cloud and Enterprise standardise and secure the workflow, making it suitable for real-world production use by teams of any size.
Sign up and connect version control
Create a Terraform Cloud account and connect it to your Git provider (e.g., GitHub). This allows Terraform Cloud to detect changes in your repository and trigger runs automatically.
Create a workspace and configure variables
A workspace groups all settings for a set of infrastructure. You define variables (like cloud provider credentials or region) here. Sensitive variables are marked so they are never exposed in logs.
Push a change to a branch
Edit your Terraform configuration files locally, commit, and push to a branch in your repository. This simulates proposing a change. Terraform Cloud detects the new commit in the branch.
Review the plan in the pull request
Terraform Cloud automatically runs terraform plan and posts the result as a comment on the pull request. Team members review the proposed changes (additions, modifications, deletions) and estimated costs. They can discuss and request alterations.
Approve and merge to apply
After review, the pull request is merged into the main branch. Terraform Cloud detects the merge and automatically runs terraform apply. The state file is updated and locked during the apply. Notifications are sent to the team about the outcome.
Monitor and audit
After changes are applied, you can view the run history, state versions, and audit log in Terraform Cloud. These records show who made each change and when, which is valuable for troubleshooting and compliance.
A company called 'QuickCart' runs an e-commerce platform on AWS with 15 engineers. They started with one person running Terraform from a laptop, storing the state file on a shared network drive. Problems arose: two engineers ran apply at the same time, corrupting the state. A junior engineer accidentally deleted a production database. And they had no record of who changed what. The team decided to adopt Terraform Cloud.
Step by step, here is what happens in a typical day for a QuickCart engineer:
The engineer receives a ticket: 'Increase the number of application servers from 3 to 5 to handle holiday traffic.' They create a new branch in GitHub, edit the Terraform configuration to change the instance count from 3 to 5, and push the change.
They open a pull request. Automatically, Terraform Cloud detects the new branch and runs a plan. Within seconds, a comment appears on the pull request: 'Plan: 2 to add, 0 to change, 0 to destroy. Estimated cost increase: $87 per month.' The engineer and their teammates review this. A senior engineer spots that the plan proposes adding servers in the same availability zone, which is risky. They suggest editing the configuration to spread across zones. The engineer makes the change and pushes again. Terraform Cloud runs another plan — this time, it shows servers spread across two zones.
After approval, the pull request is merged into the main branch. Terraform Cloud automatically triggers an apply, which adds the two new servers. The state file is updated and locked during the process. A notification is sent to the team.
The team also uses Sentinel policies. One policy blocks any resource that is not tagged with a cost-centre tag. When an engineer tried to create a test server without a tag, the plan failed with a clear error message: 'Policy violation: all resources must have a tag specifying cost_centre.' This saved the company from incurring untracked costs.
For sensitive variables like database passwords, the team stores them as 'sensitive variables' in Terraform Cloud. These are never displayed in logs or plan output, and they are never sent to the engineers' local machines.
Through this workflow, QuickCart eliminated state corruption, reduced deployment errors, and gained full auditability. The platform handles the heavy lifting of coordination, so engineers focus on writing correct configuration.
The TF-003 exam tests your knowledge of Terraform Cloud and Enterprise features under objective 6.1. Expect questions that ask you to distinguish between core features, identify what improves team workflows, and understand the difference between the free, team, and enterprise tiers.
Common question patterns include: - 'Which feature allows a team to enforce a rule that prevents provisioning servers in a restricted region?' The answer is Sentinel (policy as code). - 'What is the primary benefit of remote state locking?' It prevents concurrent runs from corrupting the state file. - 'How does Terraform Cloud integrate with version control systems?' It runs plans on pull requests and applies on merges to the main branch. - 'What is the difference between Terraform Cloud and Terraform Enterprise?' Cloud is a hosted service; Enterprise is self-hosted on your own infrastructure. - 'Which feature provides a history of all changes and actions within the platform?' Audit logging.
Traps to watch for:
The exam might list 'state locking' as seperate from 'remote state' — they are related but distinct. Locking is the mechanism; remote state is where the state is stored.
Questions about 'run triggers' could be confused with 'notifications'. Run triggers are automated cross-workspace pipelines; notifications are alerts sent to Slack or email.
They may test that cost estimation is only available in certain tiers or requires a specific configuration.
Do not confuse the private module registry with the public Terraform Registry. The private registry is within your organisation; the public registry is for everyone.
Some questions describe features that exist in Terraform Cloud but not in the open-source version: remote runs, policy as code, cost estimation, and team management.
Key definitions to memorise:
Workspace: A container for managing a collection of infrastructure resources with its own state file and variables.
Sentinel: A policy-as-code framework for enforcing rules on Terraform runs.
Run: A single execution of terraform plan or apply, managed by the platform.
State locking: Mechanism that prevents concurrent modifications to a state file.
VCS integration: Connection to version control systems like GitHub, GitLab, or Bitbucket.
Remote backend: Configuration that tells Terraform to store state and run operations in Terraform Cloud.
Study tip: Create a table comparing open-source Terraform (local runs and state) vs Terraform Cloud (remote runs and state) vs Terraform Enterprise (same as Cloud but self-hosted). Focus on the safety and collaboration features of Cloud/Enterprise.
Terraform Cloud stores state remotely with locking, preventing data corruption when multiple team members run Terraform simultaneously.
Remote runs execute in consistent, isolated environments on Terraform Cloud, eliminating the 'works on my machine' problem.
Version control integration allows Terraform Cloud to automatically run plans on pull requests and apply on merges, making infrastructure changes follow code review workflows.
Sentinel enforces policy as code, enabling organisations to block non-compliant infrastructure changes before they are applied.
Terraform Enterprise is the self-hosted version of Terraform Cloud for organisations that require on-premises deployment due to compliance or security policies.
Workspaces isolate environments (like dev, staging, prod) and each has its own state file, variables, and access controls within Terraform Cloud.
Audit logging records every action in Terraform Cloud, providing a complete trail for compliance audits and incident investigation.
These come up on the exam all the time. Here's how to tell them apart.
Terraform Cloud
Hosted by HashiCorp on their infrastructure
No installation or maintenance required by the user
Data is stored in HashiCorp's cloud environment
Terraform Enterprise
Self-hosted on your own servers or cloud
Requires installation, configuration, and ongoing maintenance
Data remains within your own network and compliance boundary
Remote State Backend (e.g., S3)
Only stores state file
No built-in locking or version history
No run execution or collaboration features
Terraform Cloud
Stores state with automatic locking and versioning
Executes runs in isolated cloud environments
Provides VCS integration, policy, and audit logs
Free Tier of Terraform Cloud
Supports up to 5 users
Includes remote state and runs
No Sentinel policy as code or cost estimation
Team/Enterprise Tier
Unlimited users
Includes Sentinel policy enforcement and cost estimation
Offers team management, audit logs, and run triggers
Manual Terraform Workflow
Engineers run terraform plan/apply on their laptops
State file stored locally or on shared drive
No automatic plan output on pull requests
Terraform Cloud Workflow
Runs executed in consistent cloud environment
State stored centrally with locking
Automatic plan output on PRs; team reviews before apply
Mistake
Terraform Cloud and Terraform Enterprise are completely different products with different features.
Correct
They share the same core features (remote state, runs, policy, collaboration). The main difference is deployment model: Cloud is hosted by HashiCorp, Enterprise is self-hosted on your own infrastructure.
The names suggest a larger gap than reality. Beginners assume 'Enterprise' has more features, but functionally they are nearly identical.
Mistake
You must use Terraform Cloud to use remote state management.
Correct
Remote state can be stored in many backends: S3, Azure Storage, GCS, Consul, etc. Terraform Cloud is one option that adds locking, version history, and runs.
Because Terraform Cloud is heavily marketed, beginners think it is the only way to share state remotely. But open-source Terraform also supports remote backends.
Mistake
Sentinel is a free feature available in all Terraform Cloud tiers.
Correct
Sentinel is a paid feature available in the Team and Enterprise tiers. The free tier does not include policy as code.
The exam expects you to know pricing tier boundaries. Beginners often assume all features are in the free tier because HashiCorp promotes Sentinel heavily.
Mistake
Terraform Cloud automatically applies all changes as soon as a plan is generated.
Correct
Terraform Cloud runs a plan automatically for pull requests, but apply only happens when you manually approve it or configure auto-apply (which is optional and not recommended for production).
The automated plan generation gives the impression that apply is also automatic. Beginners miss the manual approval step that is critical for safety.
Mistake
The private module registry in Terraform Cloud is the same as the public Terraform Registry.
Correct
The private module registry stores modules you create within your organisation. The public Registry contains community and HashiCorp-maintained modules. They are separate.
Both are called 'registries' and appear in similar UI panels. Beginners confuse their purpose and content.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Yes, there is a free tier that supports up to 5 users and includes basic features like remote state and runs. Paid tiers add features like Sentinel policy as code, cost estimation, and team management.
No, you can use the web interface to create workspaces and trigger runs. However, you still write Terraform configuration locally in code files and push them to a Git repository.
An S3 backend only stores the state file. Terraform Cloud stores state, locks it, runs plans/applies in the cloud, integrates with version control, and provides collaboration features like policy and audit logs.
Yes, Terraform Cloud works with any provider that Terraform supports, including AWS, Azure, GCP, and many others. You configure the provider and credentials as variables.
State locking prevents conflicts. The first change locks the state, so the second change is queued and runs only after the first completes. This ensures no concurrent modifications.
You mark variables as 'sensitive' when creating them. They are encrypted at rest, never shown in plans or logs, and never sent to your local machine during runs.
You've finished Terraform Cloud and Enterprise: Core Features and Setup. Continue through the TF-003 study guide to build a complete picture of the exam.
Done with this chapter?