Terraform in GitLab CI - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to initialize Terraform in the GitLab CI job.

Terraform

terraform init [1]

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

A-refresh=false

B-auto-approve

C-input=false

D-lock=false

Attempts:

3 left

💡 Hint

Common Mistakes

Using -auto-approve with terraform init (it's for apply)

Omitting flags causing the job to hang waiting for input

The -input=false flag disables interactive input, which is necessary for automated CI runs.

2fill in blank

medium

Complete the code to plan Terraform changes in GitLab CI.

Terraform

terraform plan [1]

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

A-auto-approve

B-out=plan.tfplan

C-refresh=false

D-input=true

Attempts:

3 left

💡 Hint

Common Mistakes

Using -auto-approve with plan (it's for apply)

Not saving the plan file, so apply cannot use it

The -out=plan.tfplan option saves the plan to a file for later use in apply.

3fill in blank

hard

Fix the error in the apply command to run non-interactively in GitLab CI.

Terraform

terraform apply [1] plan.tfplan

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

A-auto-approve

B-input=true

C-refresh=false

D-lock=false

Attempts:

3 left

💡 Hint

Common Mistakes

Using -input=true causes the job to wait for input

Omitting -auto-approve causes the job to hang

The -auto-approve flag skips the approval prompt, allowing the apply to run automatically in CI.

4fill in blank

hard

Fill both blanks to configure the GitLab CI job to use Terraform with a backend and environment variables.

Terraform

variables:
  TF_VAR_region: [1]
  TF_VAR_env: [2]

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

A"us-east-1"

B"production"

C"dev"

D"eu-west-2"

Attempts:

3 left

💡 Hint

Common Mistakes

Using inconsistent environment names

Not quoting string values

Setting TF_VAR_region to "us-east-1" and TF_VAR_env to "production" passes these values as variables to Terraform.

5fill in blank

hard

Fill all three blanks to complete the GitLab CI job stages for Terraform init, plan, and apply.

Terraform

stages:
  - [1]
  - [2]
  - [3]

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

Adeploy

Bplan

Capply

Dinit

Attempts:

3 left

💡 Hint

Common Mistakes

Putting apply before plan

Using unrelated stage names

The stages should be init, then plan, then apply to follow Terraform workflow.

Practice

1. What is the main purpose of using Terraform in a GitLab CI pipeline?

easy

A. To write application code

B. To automate the creation and management of cloud resources

C. To monitor server performance

D. To manage user access permissions

Solution

1. Step 1: Understand Terraform's role

   Terraform is a tool designed to automate cloud infrastructure setup and changes.

2. Step 2: Understand GitLab CI's role

   GitLab CI automates running tasks like Terraform commands in a pipeline.

3. Final Answer:

   To automate the creation and management of cloud resources -> Option B

4. Quick Check:

   Terraform automates cloud resource management = B [OK]

Hint: Terraform manages infrastructure automatically in CI pipelines [OK]

Common Mistakes:

• Confusing Terraform with application code tools
• Thinking GitLab CI monitors servers directly
• Mixing user access management with infrastructure automation

2. Which GitLab CI stage is typically used to check Terraform configuration syntax before planning?

easy

A. deploy

B. apply

C. validate

D. build

Solution

1. Step 1: Identify Terraform stages in GitLab CI

   Common stages are validate, plan, and apply.

2. Step 2: Match stage to syntax check

   The validate stage checks Terraform files for syntax errors before any changes.

3. Final Answer:

   validate -> Option C

4. Quick Check:

   Syntax check stage = validate [OK]

Hint: Validate stage checks syntax before planning [OK]

Common Mistakes:

• Confusing apply with validation
• Using deploy which is not a Terraform stage
• Thinking build is related to Terraform syntax

3. Given this GitLab CI snippet:

stages:
  - validate
  - plan
  - apply

validate:
  script:
    - terraform validate

plan:
  script:
    - terraform plan -out=tfplan

apply:
  script:
    - terraform apply tfplan
  when: manual

What happens when the pipeline reaches the apply stage?

medium

A. Terraform waits for manual approval before applying changes

B. Terraform apply is skipped because of manual trigger

C. Terraform plan is rerun before applying

D. Terraform applies changes automatically without user input

Solution

1. Step 1: Understand the 'when: manual' keyword

   This setting means the apply job waits for a user to start it manually.

2. Step 2: Check apply stage behavior

   Apply will not run automatically; it requires manual approval to proceed.

3. Final Answer:

   Terraform waits for manual approval before applying changes -> Option A

4. Quick Check:

   Manual apply means wait for approval = D [OK]

Hint: 'when: manual' means manual approval needed [OK]

Common Mistakes:

• Assuming apply runs automatically
• Thinking manual means skip permanently
• Confusing plan rerun with apply stage

4. You have this GitLab CI job:

apply:
  script:
    - terraform apply tfplan
  when: manual
  only:
    - main

But the apply job runs on every branch, not just main. What is the likely cause?

medium

A. The 'only' keyword is deprecated and ignored; use 'rules' instead

B. The 'when: manual' overrides branch filtering

C. The job name 'apply' is reserved and runs always

D. The pipeline is misconfigured and needs a restart

Solution

1. Step 1: Recognize GitLab CI syntax changes

   GitLab deprecated 'only' in favor of 'rules' for better control.

2. Step 2: Understand effect on job filtering

   Using 'only' may not filter branches correctly, causing job to run everywhere.

3. Final Answer:

   The 'only' keyword is deprecated and ignored; use 'rules' instead -> Option A

4. Quick Check:

   Use 'rules' not 'only' for branch filters [OK]

Hint: 'only' is deprecated; use 'rules' for branch filters [OK]

Common Mistakes:

• Thinking 'when: manual' affects branch filtering
• Believing job names control execution
• Restarting pipeline without fixing config

5. You want to ensure Terraform plans only run on merge requests and applies only happen after manual approval on the main branch. Which GitLab CI configuration snippet achieves this?

hard

A. plan:
script:
- terraform plan
only:
- merge_requests

apply:
script:
- terraform apply
only:
- main
when: manual

B. plan:
script:
- terraform plan
only:
- main

apply:
script:
- terraform apply
when: manual

C. plan:
script:
- terraform plan
rules:
- if: '$CI_COMMIT_BRANCH == "main"'
when: always

apply:
script:
- terraform apply
rules:
- if: '$CI_MERGE_REQUEST_ID'
when: manual

D. plan:
script:
- terraform plan
rules:
- if: '$CI_MERGE_REQUEST_ID'
when: always
- when: never

apply:
script:
- terraform apply
rules:
- if: '$CI_COMMIT_BRANCH == "main"'
when: manual
- when: never

Solution

1. Step 1: Configure plan job for merge requests only

   Using rules with '$CI_MERGE_REQUEST_ID' ensures plan runs only on MRs.

2. Step 2: Configure apply job for manual approval on main branch

   Rules with branch check and 'when: manual' ensure manual apply on main only.

3. Step 3: Confirm why other configurations fail

   Other configurations either use the deprecated 'only' keyword or reverse the conditions (plan on main and apply on merge requests).

4. Final Answer:

   The configuration using rules with $CI_MERGE_REQUEST_ID for plan and $CI_COMMIT_BRANCH == "main" for manual apply -> Option D

5. Quick Check:

   Use 'rules' with MR and branch checks for plan/apply [OK]

Hint: Use 'rules' with MR and branch checks for plan/apply [OK]

Common Mistakes:

• Using deprecated 'only' keyword
• Mixing up branch and merge request conditions
• Forgetting 'when: manual' for apply