Terraform in GitLab CI - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is the purpose of using Terraform in GitLab CI?

Terraform in GitLab CI automates the process of creating, changing, and managing infrastructure as code during the software development lifecycle.

beginner

Which GitLab CI file defines the Terraform pipeline stages?

The .gitlab-ci.yml file defines the pipeline stages, including Terraform commands like init, plan, and apply.

intermediate

Why should Terraform state files be stored remotely in GitLab CI pipelines?

Storing Terraform state files remotely ensures team collaboration, prevents state conflicts, and keeps state data safe and consistent across pipeline runs.

beginner

What is the role of the terraform plan command in GitLab CI?

terraform plan shows the changes Terraform will make to the infrastructure without applying them, helping to review before deployment.

intermediate

How do you securely provide Terraform variables and credentials in GitLab CI?

Use GitLab CI environment variables or GitLab's secret management to securely pass sensitive data to Terraform during pipeline execution.

Which file is essential to configure Terraform jobs in GitLab CI?

A variables.tf

B terraform.tfstate

C main.tf

D .gitlab-ci.yml

The .gitlab-ci.yml file defines the CI/CD pipeline including Terraform jobs.

What does the terraform init command do in a GitLab CI pipeline?

A Deletes existing infrastructure

B Applies infrastructure changes

C Initializes Terraform and downloads required providers

D Shows planned changes without applying

terraform init prepares the working directory by downloading providers and setting up backend.

Why is remote state storage recommended in GitLab CI pipelines using Terraform?

A To allow multiple users to share the state safely

B To speed up pipeline execution

C To avoid writing any state files

D To store pipeline logs

Remote state storage prevents conflicts and allows team collaboration.

How can sensitive Terraform variables be securely passed in GitLab CI?

A Using GitLab CI environment variables marked as protected

B Hardcoding in .gitlab-ci.yml

C Storing in public Git repository

D Passing as plain text in pipeline logs

Protected environment variables keep sensitive data secure during pipeline runs.

What is the main benefit of running terraform plan before terraform apply in GitLab CI?

A To delete old infrastructure

B To preview infrastructure changes before applying

C To initialize Terraform

D To store state remotely

terraform plan helps review changes to avoid mistakes.

Explain how Terraform integrates with GitLab CI to automate infrastructure deployment.

Think about the pipeline steps and how Terraform commands fit in.

Describe best practices for managing Terraform state and secrets in GitLab CI pipelines.

Focus on security and collaboration aspects.

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