Terraform Cloud/Enterprise features - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to specify the Terraform Cloud workspace name.

Terraform

terraform {
  cloud {
    organization = "my-org"
    workspaces {
      name = "[1]"
    }
  }
}

Drag options to blanks, or click blank then click option'

Amy-workspace

Bworkspace_id

Cdefault

Dterraform-cloud

Attempts:

3 left

💡 Hint

Common Mistakes

Using workspace_id instead of the workspace name string.

Leaving the name field empty.

Using an invalid workspace name.

The name field specifies the workspace name in Terraform Cloud.

2fill in blank

medium

Complete the code to enable remote state storage in Terraform Cloud.

Terraform

terraform {
  backend "remote" {
    organization = "my-org"
    workspaces {
      name = "my-workspace"
    }
    [1] = true
  }
}

Drag options to blanks, or click blank then click option'

Askip_remote_apply

Bremote_state_enabled

Cskip_credentials_validation

Dauto_init

Attempts:

3 left

💡 Hint

Common Mistakes

Confusing option names related to remote state.

Using options that do not exist in the backend block.

The skip_credentials_validation option controls whether to skip validating credentials during terraform init.

3fill in blank

hard

Fix the error in the policy set block to attach a policy to a workspace.

Terraform

resource "tfe_policy_set" "example" {
  name         = "example-policy-set"
  organization = "my-org"
  [1] = [tfe_workspace.example.id]
}

Drag options to blanks, or click blank then click option'

Aworkspace_id

Bworkspace_ids

Cworkspaces

Dworkspace

Attempts:

3 left

💡 Hint

Common Mistakes

Using singular attribute names instead of plural.

Passing a single ID instead of a list.

The workspace_ids attribute expects a list of workspace IDs to attach the policy set.

4fill in blank

hard

Fill both blanks to configure a VCS repository for Terraform Cloud workspace.

Terraform

resource "tfe_workspace" "example" {
  name         = "example-workspace"
  organization = "my-org"
  vcs_repo {
    identifier     = "[1]"
    branch         = "[2]"
  }
}

Drag options to blanks, or click blank then click option'

Amy-org/my-repo

Bmain

Cdevelop

Dmy-repo

Attempts:

3 left

💡 Hint

Common Mistakes

Using only the repo name without organization in identifier.

Using an invalid branch name.

The identifier is the full repo path, and branch is the branch name to track.

5fill in blank

hard

Fill all three blanks to define a Sentinel policy resource with enforcement level and source.

Terraform

resource "tfe_policy" "example" {
  name             = "example-policy"
  organization     = "my-org"
  enforcement_level = "[1]"
  policy           = "[2]"
  description      = "[3]"
}

Drag options to blanks, or click blank then click option'

Ahard-mandatory

Bsoft-mandatory

Csentinel/policy.sentinel

DPolicy to enforce security rules

Attempts:

3 left

💡 Hint

Common Mistakes

Using invalid enforcement levels.

Incorrect policy code format.

Leaving description empty.

enforcement_level sets how strictly the policy is enforced.

policy is the Sentinel policy code as a raw string.

description explains the policy purpose.

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