Terraform Cert Guide Chapter 10: Terraform Cloud and Enterprise Explained

Up to this point in the book, everything has been about running Terraform on your own machine. Local state files, local commands, you doing everything manually. That works fine when it’s just you. But the moment your team grows beyond a couple of people, things get messy fast. Chapter 10 introduces the solutions HashiCorp built for exactly that problem: Terraform Cloud and Terraform Enterprise.

Terraform Cloud: Terraform as a Service

Terraform Cloud is basically a SaaS version of Terraform. You access it at app.terraform.io, and it handles a lot of the stuff you used to manage yourself.

The big deal here is remote execution. Instead of running terraform plan and terraform apply on your laptop, Terraform Cloud spins up a temporary VM in their infrastructure, runs your code there, and tears down the VM when it’s done. No more “it works on my machine” problems. No more single point of failure because someone’s laptop died mid-apply.

Workspaces Replace Directories

In regular CLI Terraform, you work in directories. Each directory is basically its own little world with its own state. Terraform Cloud replaces that concept with workspaces. A workspace holds everything needed to provision infrastructure: your config, your variables, your state file, all of it.

The state file gets stored remotely, connected directly to the workspace. And here’s a nice touch: you can share outputs between workspaces using terraform_remote_state data sources without any extra authentication setup. If workspace A produces an output that workspace B needs, they can just talk to each other.

There’s also a feature called run triggers. If workspace A (upstream) changes, it can automatically kick off a run in workspace B (downstream). Handy when you have infrastructure that depends on other infrastructure.

Version Control Integration

You can hook your workspaces up to a VCS repo. Terraform Cloud supports GitHub, GitLab, Bitbucket, and Azure DevOps (both cloud and self-hosted versions for most of these).

Once connected, any commit to the linked branch triggers a terraform plan automatically. Pull requests also trigger plans, so reviewers can see exactly what infrastructure changes a PR would cause before approving. That’s genuinely useful for code review.

If your VCS tool isn’t on the supported list, you can still use the API or CLI to upload configs manually.

Free vs Paid

Terraform Cloud has a free tier that works for individuals or small teams. You get remote state storage, VCS integration, and remote runs. The paid plans add more features for bigger teams. We’ll see exactly what those features are in the comparison section below.

The Workflow in Practice

The book walks through a practical example of setting up Terraform Cloud with an Azure resource group. The steps are:

1. Sign up at app.terraform.io
2. Create an organization
3. Create a workspace inside that organization
4. Choose your workflow (VCS-driven, CLI-driven, or API-driven)
5. Link to your GitHub repo, specify the branch and working directory
6. Configure your variables (including secrets like ARM_CLIENT_SECRET)
7. Terraform Cloud auto-runs terraform plan
8. Review the plan output, then click Confirm & Apply or Discard Run

One important detail: when you set variable values in Terraform Cloud, you can mark them as sensitive. This encrypts the value so nobody can read it in the UI. Use this for API keys, client secrets, passwords, all the stuff you definitely don’t want sitting in plain text.

If you need to tear everything down later, there’s a Destruction and Deletion option under workspace settings. It can destroy both the infrastructure and the workspace itself.

Terraform Enterprise: Self-Hosted and Beefed Up

Terraform Enterprise is basically Terraform Cloud but you host it yourself. It’s a private instance that runs the same application, except with no resource limits and some extra enterprise features like audit logging and SAML single sign-on (SSO).

You need a license from HashiCorp, and it runs on RHEL or CentOS. HashiCorp publishes reference architectures for deployment, so you’re not guessing at how to set it up.

Why Would You Want This?

The book frames it around the problems that grow with your team:

• How do you manage provisioning workflows when dozens of people are involved?
• How do you handle collaboration across multiple teams?
• How do you manage state files without stepping on each other?
• How do developers get self-service infrastructure without chaos?
• How do you enforce rules and best practices?
• How do administrators control role-based access (RBAC) per team?
• How do you secure a multi-cloud environment?

Terraform Enterprise answers most of these. The key benefits Mishra highlights:

• Operational efficiency from centralized management
• Risk reduction through governance and policy
• Collaboration capabilities for cross-team work
• Cloud cost control with visibility into what’s being provisioned
• Governance and policy enforcement at scale

Sentinel: Policy as Code

This is one of the coolest features in the paid Terraform products. Sentinel is a policy-as-code framework available in Terraform Cloud (paid) and Terraform Enterprise. It’s also used in other HashiCorp products like Vault, Nomad, and Consul Enterprise editions.

The idea is simple: you write rules that define what infrastructure is and isn’t allowed. Sentinel checks these rules automatically between the terraform plan and terraform apply phases. If the plan violates a policy, the apply gets blocked.

Sentinel has its own language, and the book says you can pick it up in about an hour. No prior programming experience needed.

Enforcement Levels

Sentinel policies have enforcement levels that determine what happens when a check fails:

• Hard-mandatory: The policy must pass. Nobody can override it. If it fails, the run stops. Period.
• Soft-mandatory: The policy should pass, but authorized users can override it if needed.
• Advisory: The policy is informational only. Failures are logged but don’t block anything.

A Practical Example

The book demonstrates Sentinel with a policy that checks whether Azure resource groups have tags. Tags are important for cost tracking, environment identification, and general organization.

The setup:

1. Create a policy set in Terraform Cloud, pointing to your VCS repo where Sentinel policies live
2. Write a sentinel.hcl config file that defines which policies to apply and their enforcement level
3. The policy itself checks whether resources have tags defined

Here’s what the sentinel.hcl looks like:

policy "azure_tags" {
  source            = "./azure_tags.sentinel"
  enforcement_level = "hard-mandatory"
}

When the resource group has tags defined, the Sentinel check passes and the run continues to “Confirm & Apply.” When the tags are commented out, the check fails with “Policy check hard failed” and the terraform apply phase never runs.

That’s the power of it. You define rules once, and they automatically prevent anyone from deploying infrastructure that doesn’t meet your standards. No more relying on code reviews to catch missing tags or wrong regions.

Feature Comparison: CLI vs Cloud vs Enterprise

The book includes a comparison table showing what’s available in each Terraform product. Here’s the summary:

The pattern is clear: CLI is for solo work, Cloud free tier adds remote state and collaboration basics, Cloud paid adds governance and policy, Enterprise adds everything plus self-hosting and enterprise auth.

Key Takeaways for the Cert Exam

A few things from this chapter that are likely to show up on the certification exam:

1. Sentinel runs between plan and apply, not before plan or after apply
2. Terraform Cloud state is stored remotely in Terraform Cloud itself, not locally or in GitHub
3. Sentinel is available in both Terraform Cloud (paid) and Terraform Enterprise
4. Run triggers allow upstream workspace changes to automatically trigger downstream workspace runs
5. Workspaces in Terraform Cloud are not the same as local CLI workspaces. Cloud workspaces contain everything (config, state, variables), while CLI workspaces are just different state files in the same directory

The book includes some practice questions, and the Sentinel ones are straightforward if you remember where it sits in the workflow (between plan and apply) and what it’s used for (restricting infrastructure before provisioning).

Bottom Line

Chapter 10 is shorter than most chapters in the book, but the concepts are important for the exam and for real-world Terraform usage. Once your team grows past a few people, you need something beyond the CLI. Terraform Cloud and Enterprise solve the collaboration, governance, and security challenges that come with scale. And Sentinel gives you a clean way to enforce policies without relying on manual reviews. If you’re taking the cert exam, make sure you know the feature differences between the three products and exactly where Sentinel fits in the Terraform workflow.

Previous: Chapter 9: Terraform Stacks | Next: Chapter 11: Terraform Glossary

This is part of a series retelling “HashiCorp Infrastructure Automation Certification Guide” by Ravi Mishra (Packt, 2021). For the full text, grab the book - ISBN: 978-1-80056-597-5.