Terraform in GitLab CI - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Configuration

intermediate

Terraform GitLab CI Pipeline Stage Order

Given the following GitLab CI stages for Terraform, what is the correct order to ensure safe infrastructure deployment?

A 1,2,3,4

B 2,1,3,4

C 3,1,2,4

D 1,3,2,4

💡 Hint

Initialization must happen before validation and planning.

Terraform requires initialization first to set up backend and providers, then validation to check syntax, planning to preview changes, and finally apply to execute changes.

❓ security

intermediate

Protecting Terraform State in GitLab CI

Which option best secures Terraform state files when running Terraform in GitLab CI pipelines?

A Disable state locking to speed up pipeline execution.

B Store state files locally on the GitLab runner disk.

C Commit state files to the Git repository for versioning.

D Use a remote backend like AWS S3 with encryption and access control.

💡 Hint

State files contain sensitive info and must be protected and shared safely.

Using a remote backend with encryption and access control ensures state files are secure and consistent across pipeline runs.

❓ service_behavior

advanced

Terraform Apply Behavior in GitLab CI with Auto-Approve

What is the effect of adding the '-auto-approve' flag to 'terraform apply' in a GitLab CI pipeline?

A It automatically applies changes without waiting for user confirmation.

B It requires manual approval before applying changes.

C It only plans changes but does not apply them.

D It disables state locking during apply.

💡 Hint

Think about automation and manual steps in CI pipelines.

The '-auto-approve' flag skips the interactive approval prompt, allowing automated pipelines to apply changes without manual intervention.

❓ Architecture

advanced

Managing Multiple Environments with Terraform in GitLab CI

Which approach best isolates Terraform state and variables for multiple environments (e.g., dev, staging, prod) in GitLab CI?

A Use a single state file and switch variables inside the pipeline script.

B Run all environments in parallel using the same state and variables.

C Use separate Terraform workspaces or backend state files per environment.

D Store all environment states in one backend bucket without prefixes.

💡 Hint

Isolation prevents accidental cross-environment changes.

Separate workspaces or backend state files per environment keep state isolated and reduce risk of conflicts or accidental changes.

✅ Best Practice

expert

Handling Sensitive Variables in GitLab CI for Terraform

What is the best practice to securely provide sensitive variables (like AWS credentials) to Terraform in GitLab CI pipelines?

A Hardcode sensitive variables directly in the .gitlab-ci.yml file.

B Store sensitive variables in GitLab CI protected variables and reference them in the pipeline.

C Commit sensitive variables in a separate encrypted file in the repository.

D Pass sensitive variables as plain text environment variables in pipeline scripts.

💡 Hint

Think about GitLab features designed for secrets management.

GitLab CI protected variables securely store secrets and inject them into pipelines without exposing them in code or logs.

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