Bird
Raised Fist0
Terraformcloud~30 mins

Terraform Cloud/Enterprise features - Mini Project: Build & Apply

Choose your learning style10 modes available

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Terraform Cloud/Enterprise Features Setup
📖 Scenario: You are working as a cloud engineer for a company that wants to manage infrastructure using Terraform Cloud. Your task is to create a Terraform configuration that sets up a workspace with specific features enabled in Terraform Cloud.
🎯 Goal: Build a Terraform configuration that defines a Terraform Cloud workspace with version control integration, automatic runs enabled, and workspace variables configured.
📋 What You'll Learn
Create a Terraform Cloud workspace resource named example_workspace.
Set the workspace to use the main branch from a GitHub repository.
Enable automatic runs on changes.
Add a workspace variable named environment with the value production.
Configure the workspace to use Terraform version 1.5.0.
💡 Why This Matters
🌍 Real World
Terraform Cloud workspaces help teams manage infrastructure as code with collaboration, version control, and automation.
💼 Career
Knowing how to configure Terraform Cloud workspaces is essential for cloud engineers and DevOps professionals managing infrastructure deployments.
Progress0 / 4 steps
1
Create Terraform Cloud workspace resource
Write a Terraform resource block named terraform_cloud_workspace with the resource name example_workspace. Set the name attribute to example-workspace.
Terraform
Hint

Use the resource keyword to define a Terraform Cloud workspace resource with the exact name and resource identifier.

2
Configure version control and automatic runs
Add the vcs_repo block inside the terraform_cloud_workspace.example_workspace resource. Set identifier to github-user/repo-name and branch to main. Also, set auto_apply to true to enable automatic runs.
Terraform
Hint

Use the vcs_repo block to connect the workspace to a GitHub repo and set auto_apply to true to enable automatic runs.

3
Add workspace variable
Inside the terraform_cloud_workspace.example_workspace resource, add a variable block. Set key to environment, value to production, and category to terraform.
Terraform
Hint

Add a variable block with the exact key, value, and category to set workspace variables.

4
Set Terraform version for the workspace
Add the terraform_version attribute to the terraform_cloud_workspace.example_workspace resource and set it to "1.5.0".
Terraform
Hint

Set the terraform_version attribute to specify the Terraform version used by the workspace.

Practice

(1/5)
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