Terraform Cloud/Enterprise features - Step-by-Step Execution

Process Flow - Terraform Cloud/Enterprise features

Start Terraform Cloud/Enterprise

↓

User Pushes Code to VCS

↓

Terraform Cloud Detects Change

↓

Run Plan Automatically

↓

User Reviews Plan

↓

Apply Approved Plan

↓

State Stored Securely

↓

Collaboration & Policy Checks

↓

End

This flow shows how Terraform Cloud/Enterprise automates infrastructure changes from code push to secure state storage with collaboration and policy enforcement.

Execution Sample

Terraform

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

This code configures Terraform to use Terraform Cloud with a specific organization and workspace.

Process Table

Step	Action	Result	Notes
1	User pushes Terraform code to version control	Terraform Cloud detects new code	Triggers run automatically
2	Terraform Cloud starts plan phase	Plan created showing proposed changes	User can review plan
3	User approves plan	Terraform Cloud applies changes	Infrastructure updated
4	Terraform Cloud stores state securely	State file saved in cloud backend	Enables collaboration
5	Policy checks run during plan/apply	Runs Sentinel policies	Blocks changes if policy fails
6	Team members collaborate	Shared workspace and notifications	Improves teamwork
7	Run completes	Outputs available	Infrastructure ready
8	No new code changes	No new runs triggered	Idle state

💡 No new code changes detected, so no further runs triggered.

Status Tracker

Variable	Start	After Step 1	After Step 3	Final
Terraform Code	Not present	Pushed to VCS	Used for apply	Stored in VCS
Run Status	Idle	Planning	Applied	Idle
State File	Local or none	Not updated	Updated in cloud	Stored securely
Policy Status	Not checked	Checked during plan	Checked during apply	Passed or blocked

Key Moments - 3 Insights

Why does Terraform Cloud run a plan automatically after code is pushed?

Terraform Cloud detects the code change (see execution_table step 1) and runs a plan to show proposed changes before applying, ensuring safety.

How does Terraform Cloud ensure team collaboration?

By storing state securely in the cloud backend and sharing workspace runs and notifications (execution_table steps 4 and 6), team members can work together safely.

What happens if a policy check fails during apply?

The apply is blocked by Terraform Cloud's Sentinel policy enforcement (execution_table step 5), preventing unsafe changes.

Visual Quiz - 3 Questions

Look at the execution_table, what is the run status after step 3?

A Idle

B Planning

C Applied

D Failed

💡 Hint

Check the 'Run Status' variable in variable_tracker after Step 3.

At which step does Terraform Cloud store the state file securely?

A Step 2

B Step 4

C Step 6

D Step 8

💡 Hint

Look at the 'State File' variable changes and execution_table step descriptions.

If no new code is pushed, what happens according to the execution_table?

A No new runs are triggered

B Terraform Cloud runs a plan anyway

C Terraform Cloud applies previous plan

D Policy checks run repeatedly

💡 Hint

See the exit_note and step 8 in execution_table.

Concept Snapshot

Terraform Cloud/Enterprise automates infrastructure changes by detecting code pushes,
running plans for review, applying approved changes, and storing state securely.
It supports team collaboration and enforces policies to keep infrastructure safe.
Use cloud backend configuration to connect Terraform to Terraform Cloud.
Policy checks run automatically during plan and apply phases.
No runs happen without new code changes.

Full Transcript

Terraform Cloud and Enterprise provide a way to automate and manage infrastructure changes safely. When a user pushes Terraform code to version control, Terraform Cloud detects the change and automatically runs a plan. This plan shows what changes will happen, allowing the user to review before applying. Once approved, Terraform Cloud applies the changes and securely stores the state file in the cloud backend. This setup enables team collaboration by sharing state and run information. Additionally, policy checks run during plan and apply phases to enforce rules and prevent unsafe changes. If no new code is pushed, Terraform Cloud does not trigger new runs, keeping the system idle until changes occur.

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