Most Terraform users begin with a simple workflow:

terraform init
terraform plan
terraform apply

Everything runs locally, credentials come from the local machine, and the state file is stored either locally or in a configured backend.

However, real-world teams rarely run Terraform from developer laptops.
Infrastructure provisioning is executed from a controlled environment — this is where HCP Terraform (Terraform Cloud) comes in.

This article explains how Terraform Cloud works, what actually changes compared to local execution, and how to correctly authenticate and run Terraform remotely.

Table of Contents

1. What Terraform Cloud Actually Changes
2. Key Architectural Difference
3. Creating the Organization and Workspace
4. Connecting Local Terraform to Terraform Cloud
5. First Remote Plan and Why It Fails
6. Why Local Credentials Stop Working
7. Azure Authentication in Terraform Cloud
8. Adding Credentials to the Workspace
9. Running Terraform Remotely
10. Verifying Remote State
11. Understanding Workspaces
12. What Terraform Cloud Provides Beyond CLI
13. Practical Takeaway

---

What Terraform Cloud Actually Changes

Terraform Cloud does not replace the Terraform CLI — it replaces the execution environment.

Instead of:

Local CLI → Cloud Provider API

the architecture becomes:

Local CLI → Terraform Cloud → Cloud Provider API

Your machine only submits configuration and receives logs.
The actual Terraform runtime, state, and authentication live in Terraform Cloud.

---

Key Architectural Difference

Component	Local Terraform	Terraform Cloud
Execution	Runs on developer machine	Runs on HashiCorp infrastructure
State	Local or backend-configured	Always remote
Authentication	Local credentials	Workspace credentials
Audit History	Limited	Built-in
Collaboration	Manual	Native support

Understanding this distinction is essential — most confusion with Terraform Cloud comes from assuming it behaves like a remote backend only.
It is actually remote execution, not just remote storage.

---

Creating the Organization and Workspace

After signing into:

https://app.terraform.io

Create an organization and then create a workspace using:

CLI-Driven Workflow

This workspace acts as an isolated remote Terraform runtime.

Each workspace has:

• Its own state file
• Its own variables
• Its own credentials
• Its own run history

Think of it as a remote Terraform working directory.

---

Connecting Local Terraform to Terraform Cloud

Create a minimal configuration:

terraform {
  cloud {
    organization = "my-organization"

    workspaces {
      name = "cli-lab"
    }
  }
}

provider "azurerm" {
  features {}
}

resource "azurerm_resource_group" "example" {
  name     = "rg-hcp-demo"
  location = "eastus"
}

Initialize:

terraform init

Terraform will request authentication with Terraform Cloud.

Run:

terraform login

This generates an API token and stores it locally in:

~/.terraform.d/credentials.tfrc.json

At this point, your CLI is authenticated with Terraform Cloud — not with Azure.

---

First Remote Plan and Why It Fails

Running:

terraform plan

will fail with an authentication error for Azure.

This often surprises users who already have working local credentials such as:

$env:ARM_CLIENT_ID="..."
$env:ARM_CLIENT_SECRET="..."
$env:ARM_SUBSCRIPTION_ID="..."
$env:ARM_TENANT_ID="..."

These variables work locally because Terraform executes on your machine.

Terraform Cloud cannot access them.

---

Why Local Credentials Stop Working

In local execution:

Terraform (local process) reads environment variables → authenticates to Azure

In Terraform Cloud:

Terraform Cloud runtime reads workspace variables → authenticates to Azure

The execution environment changed, therefore the authentication location must also change.

---

Azure Authentication in Terraform Cloud

Terraform Cloud must authenticate independently using a Service Principal.

Create one if necessary:

az ad sp create-for-rbac --role Contributor --scopes /subscriptions/<SUBSCRIPTION_ID>

Azure returns:

appId        → Client ID
password     → Client Secret
tenant       → Tenant ID
subscription → Subscription ID

---

Adding Credentials to the Workspace

In the workspace → Variables → Environment Variables

Add:

Variable	Description
ARM_CLIENT_ID	Service Principal App ID
ARM_CLIENT_SECRET	Service Principal Secret
ARM_TENANT_ID	Azure Tenant
ARM_SUBSCRIPTION_ID	Azure Subscription

Mark secrets as sensitive.

These variables now exist inside the remote execution environment.

---

Running Terraform Remotely

Run:

terraform plan

You will notice:

• The command returns output locally
• Execution logs appear in the Terraform Cloud UI
• The plan runs remotely

Then apply:

terraform apply

The resource is created in Azure by Terraform Cloud — not by your machine.

---

Verifying Remote State

Delete local Terraform metadata:

rm -r .terraform

Run again:

terraform plan

It still works.

This confirms:

State is stored in Terraform Cloud, not locally.

---

Understanding Workspaces

A workspace represents an isolated Terraform environment.

Each workspace maintains:

• Independent state
• Independent credentials
• Independent variables
• Independent run history

This enables environment separation:

Workspace	Purpose
dev	Development infrastructure
test	Validation environment
prod	Production infrastructure

No duplication of directories or backend configuration required.

---

What Terraform Cloud Provides Beyond CLI

Terraform Cloud effectively acts as Terraform’s native CI/CD system.

It adds:

• Remote execution
• State management
• Secrets management
• Run history
• Access control
• Collaboration
• Policy enforcement (in higher tiers)

Without external pipelines.

---

Practical Takeaway

Terraform Cloud is not just a UI layer or remote backend.

It changes the operational model:

From:

Developers provisioning infrastructure

To:

Controlled platform provisioning infrastructure

The CLI becomes a client — not the executor.

Understanding this distinction is fundamental before using VCS-driven workflows, automated applies, or multi-environment deployments.