Terraform Cloud/Enterprise features - Commands & Configuration

Introduction

Terraform Cloud and Enterprise help teams work together on infrastructure safely and efficiently. They provide features like remote state storage, version control integration, and policy enforcement to avoid mistakes and improve collaboration.

When multiple people manage the same infrastructure and need to avoid conflicts.

When you want to keep your infrastructure state files safe and backed up remotely.

When you want to run Terraform plans and applies automatically after code changes.

When you want to enforce rules on infrastructure changes to meet company policies.

When you want to see detailed logs and history of all infrastructure changes.

Config File - main.tf

main.tf

terraform {
  required_version = ">= 1.3.0"
  backend "remote" {
    organization = "example-org"
    workspaces {
      name = "example-workspace"
    }
  }
}

provider "aws" {
  region = "us-east-1"
}

resource "aws_s3_bucket" "example" {
  bucket = "example-terraform-cloud-bucket"
  acl    = "private"
}

This Terraform configuration uses the remote backend to connect to Terraform Cloud under the organization example-org and workspace example-workspace. This setup enables remote state storage and runs in Terraform Cloud.

The AWS provider is configured for the us-east-1 region, and a simple S3 bucket resource is defined.

Commands

This command authenticates your local Terraform CLI with Terraform Cloud so you can securely connect and run commands remotely.

Terminal

terraform login

Expected Output

Terraform has been successfully configured to authenticate with Terraform Cloud.

You are now logged in.

Initializes the Terraform working directory and configures the remote backend to use Terraform Cloud for state management.

Terminal

terraform init

Expected Output

Initializing the backend...



Successfully configured the backend "remote"!



Terraform has been successfully initialized!



You may now begin working with Terraform. Try running "terraform plan" to see any changes.

Creates an execution plan showing what Terraform will do when applying the configuration. This runs locally but uses remote state from Terraform Cloud.

Terminal

terraform plan

Expected Output

Refreshing Terraform state in-memory prior to plan...



An execution plan has been generated and is shown below.

Resource actions are indicated with the following symbols:

  + create



Terraform will perform the following actions:



  # aws_s3_bucket.example will be created

  + resource "aws_s3_bucket" "example" {

      + acl    = "private"

      + bucket = "example-terraform-cloud-bucket"

      + id     = (known after apply)

    }



Plan: 1 to add, 0 to change, 0 to destroy.

Applies the planned changes to create the S3 bucket. The apply runs locally but updates state in Terraform Cloud.

Terminal

terraform apply -auto-approve

Expected Output

aws_s3_bucket.example: Creating...

aws_s3_bucket.example: Creation complete after 2s [id=example-terraform-cloud-bucket]



Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

→

-auto-approve - Skips interactive approval to apply changes immediately

Lists all resources tracked in the Terraform state stored remotely in Terraform Cloud, confirming the S3 bucket is managed.

Terminal

terraform state list

Expected Output

aws_s3_bucket.example

Key Concept

If you remember nothing else from this pattern, remember: Terraform Cloud stores your state remotely and runs plans and applies safely for teams.

Common Mistakes

Not running 'terraform login' before using Terraform Cloud backend

Terraform CLI cannot authenticate with Terraform Cloud, causing errors when initializing or applying.

Always run 'terraform login' once to authenticate your CLI with Terraform Cloud before other commands.

Using local backend instead of remote backend in team environments

State files are stored locally, risking conflicts and loss when multiple people work on the same infrastructure.

Configure the 'remote' backend in Terraform to store state in Terraform Cloud for safe team collaboration.

Running 'terraform apply' without reviewing the plan

You might apply unintended changes that could break infrastructure or cause downtime.

Always run 'terraform plan' first to review changes before applying.

Summary

Run 'terraform login' to authenticate your CLI with Terraform Cloud.

Configure the 'remote' backend in your Terraform file to store state in Terraform Cloud.

Use 'terraform init' to initialize the backend and working directory.

Run 'terraform plan' to preview changes and 'terraform apply' to make changes.

Use 'terraform state list' to verify resources tracked in remote state.

Practice

1. What is the main purpose of Terraform Cloud/Enterprise?

easy

A. To help teams manage infrastructure together safely

B. To replace Terraform CLI on local machines

C. To provide a graphical interface for writing Terraform code

D. To host websites built with Terraform

Solution

1. Step 1: Understand Terraform Cloud/Enterprise role

   Terraform Cloud/Enterprise is designed to help teams collaborate on infrastructure management safely.

2. Step 2: Eliminate incorrect options

   It does not replace the CLI, provide a GUI for coding, or host websites.

3. Final Answer:

   To help teams manage infrastructure together safely -> Option A

4. Quick Check:

   Collaboration and safety = B [OK]

Hint: Think teamwork and safety in infrastructure management [OK]

Common Mistakes:

• Confusing Terraform Cloud with a code editor
• Thinking it replaces local Terraform CLI
• Assuming it hosts applications

2. Which of the following is the correct way to configure a Terraform Cloud workspace in terraform block?

easy

A. terraform { cloud { organization = "my-org" workspaces { name = "my-workspace" } } }

B. terraform { cloud_backend { org_name = "my-org" ws_name = "my-workspace" } }

C. terraform { backend "cloud" { organization = "my-org" workspaces { name = "my-workspace" } } }

D. terraform { backend "remote" { org = "my-org" workspace_name = "my-workspace" } }

Solution

1. Step 1: Recall Terraform Cloud backend syntax

   The correct syntax uses backend "cloud" with organization and workspaces { name = "my-workspace" } block.

2. Step 2: Compare options to syntax

   terraform { backend "cloud" { organization = "my-org" workspaces { name = "my-workspace" } } } matches the official syntax exactly; others have incorrect keys or structure.

3. Final Answer:

   terraform { backend "cloud" { organization = "my-org" workspaces { name = "my-workspace" } } } -> Option C

4. Quick Check:

   Backend "cloud" with organization and workspaces block = D [OK]

Hint: Remember backend "cloud" block with organization and workspaces { name } [OK]

Common Mistakes:

• Using incorrect block names like cloud_backend
• Mixing keys like org vs organization
• Wrong nesting of workspace inside cloud block

3. Given this Terraform Cloud workspace configuration snippet, what will happen when you run terraform apply?

terraform {
  backend "cloud" {
    organization = "example-org"
    workspaces {
      name = "prod"
    }
  }
}

medium

A. Terraform will run the apply remotely in Terraform Cloud and update the remote state

B. Terraform will run the apply locally and update remote state in Terraform Cloud

C. Terraform will fail because workspace name should be outside workspaces block

D. Terraform will ignore the backend and run locally without remote state

Solution

1. Step 1: Understand backend cloud with workspaces block

   The workspaces { name = "prod" } syntax is valid and specifies the workspace in Terraform Cloud.

2. Step 2: Know Terraform Cloud apply behavior

   When using Terraform Cloud backend, terraform apply runs locally but updates the remote state.

3. Final Answer:

   Terraform will run the apply locally and update remote state in Terraform Cloud -> Option B

4. Quick Check:

   Local execution, remote state = B [OK]

Hint: Cloud backend: local execution, remote state [OK]

Common Mistakes:

• Thinking apply runs remotely with cloud backend
• Confusing workspace block syntax
• Assuming backend config is ignored

4. You configured a Terraform Cloud workspace with the following backend block but get an error: Invalid backend configuration. What is wrong?

terraform {
  backend "cloud" {
    organization = "my-org"
    workspace = "dev"
  }
}

medium

A. The organization name is missing

B. Backend "cloud" does not support workspace configuration

C. The key extra_key is not valid in backend configuration

D. The workspace name must be inside a workspaces block, not as workspace key

Solution

1. Step 1: Check valid keys for backend "cloud" block

   Valid keys include organization and workspaces { name = "dev" } block. Direct workspace key is invalid.

2. Step 2: Identify invalid key causing error

   The workspace = "dev" key is not valid; it must be inside a workspaces block.

3. Final Answer:

   The workspace name must be inside a workspaces block, not as workspace key -> Option D

4. Quick Check:

   workspace requires workspaces block = B [OK]

Hint: Only use documented keys in backend block [OK]

Common Mistakes:

• Using direct workspace= instead of workspaces block
• Adding unsupported keys in backend config
• Misplacing workspace inside or outside workspaces block
• Assuming organization can be omitted

5. Your team wants to enforce that all Terraform runs in Terraform Cloud must pass a policy check before applying changes. Which Terraform Cloud/Enterprise feature should you use to achieve this?

hard

A. Sentinel policies integrated with Terraform Cloud runs

B. Terraform CLI hooks on local machines

C. Manual approval outside Terraform Cloud

D. Terraform Cloud workspace tags

Solution

1. Step 1: Identify feature for policy enforcement in Terraform Cloud

   Sentinel is Terraform Cloud's policy as code framework that integrates with runs to enforce rules.

2. Step 2: Eliminate other options

   CLI hooks are local and not enforced centrally; manual approval is not automated; tags do not enforce policies.

3. Final Answer:

   Sentinel policies integrated with Terraform Cloud runs -> Option A

4. Quick Check:

   Policy enforcement = Sentinel = A [OK]

Hint: Use Sentinel for policy checks in Terraform Cloud [OK]

Common Mistakes:

• Confusing local CLI hooks with centralized policy enforcement
• Thinking tags enforce policies
• Relying on manual approval only