Terraform in GitLab CI - Time & Space Complexity

Time Complexity: Terraform in GitLab CI

O(n)

Understanding Time Complexity

When using Terraform in GitLab CI, it's important to understand how the time to run your infrastructure changes as you add more resources.

We want to know how the number of Terraform operations grows when the infrastructure size grows.

Scenario Under Consideration

Analyze the time complexity of this Terraform job in GitLab CI pipeline.

terraform init
terraform plan -out=plan.out
terraform apply plan.out
    

This sequence initializes Terraform, creates a plan for changes, and applies those changes to the cloud.

Identify Repeating Operations

Look at what happens repeatedly during the pipeline run.

• Primary operation: Terraform API calls to create, update, or delete resources.
• How many times: Once per resource in the plan during apply.

How Execution Grows With Input

As you add more resources, Terraform makes more API calls to manage them.

Input Size (n)	Approx. API Calls/Operations
10	About 10 calls
100	About 100 calls
1000	About 1000 calls

Pattern observation: The number of operations grows roughly in direct proportion to the number of resources.

Final Time Complexity

Time Complexity: O(n)

This means the time to run the Terraform apply step grows linearly with the number of resources.

Common Mistake

[X] Wrong: "Terraform apply time stays the same no matter how many resources I have."

[OK] Correct: Each resource needs its own API call, so more resources mean more time.

Interview Connect

Understanding how Terraform scales in CI pipelines helps you design efficient infrastructure and pipelines, a useful skill in cloud roles.

Self-Check

"What if we used Terraform workspaces to split resources? How would that affect the time complexity?"

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