Terraform in GitHub Actions - Time & Space Complexity

Time Complexity: Terraform in GitHub Actions

O(n)

Understanding Time Complexity

When using Terraform inside GitHub Actions, it's important to understand how the time to complete tasks grows as you add more resources.

We want to know how the number of Terraform operations affects the total execution time.

Scenario Under Consideration

Analyze the time complexity of running Terraform apply on multiple resources in a GitHub Actions workflow.

name: "Terraform Apply"
on:
  push:
jobs:
  terraform:
    runs-on: ubuntu-latest
    steps:
      - uses: "actions/checkout@v3"
      - uses: "hashicorp/setup-terraform@v3"
      - name: "Terraform Init"
        run: terraform init
      - name: "Terraform Apply"
        run: terraform apply -auto-approve
    

This workflow runs Terraform commands to initialize and apply infrastructure changes on each push.

Identify Repeating Operations

Look at what happens repeatedly during the Terraform apply step.

• Primary operation: Terraform API calls to create or update each resource.
• How many times: Once per resource defined in the Terraform configuration.

How Execution Grows With Input

As you add more resources, Terraform makes more API calls to create or update them.

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

Pattern observation: The number of API calls grows directly with the number of resources.

Final Time Complexity

Time Complexity: O(n)

This means the time to apply infrastructure changes grows in a straight line as you add more 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 work and longer time.

Interview Connect

Understanding how Terraform operations scale helps you design efficient workflows and manage infrastructure growth confidently.

Self-Check

"What if we split the Terraform apply into multiple smaller jobs in GitHub Actions? How would the time complexity change?"

Practice

1. What is the main purpose of using Terraform in GitHub Actions workflows?

easy

A. To store Terraform state files in GitHub issues

B. To manually edit cloud resources from GitHub

C. To automatically run Terraform commands when code changes

D. To replace Terraform CLI with GitHub commands

Solution

1. Step 1: Understand Terraform automation

   Terraform automates cloud resource management by running commands like plan and apply.

2. Step 2: Role of GitHub Actions

   GitHub Actions can trigger these Terraform commands automatically when code changes happen.

3. Final Answer:

   To automatically run Terraform commands when code changes -> Option C

4. Quick Check:

   Terraform automation = automatic runs [OK]

Hint: Terraform in GitHub Actions automates runs on code changes [OK]

Common Mistakes:

• Thinking GitHub Actions replaces Terraform CLI
• Believing Terraform state is stored in GitHub issues
• Assuming manual edits happen inside GitHub

2. Which syntax correctly defines a GitHub Actions step to run terraform init?

easy

A. - name: Terraform Init
command: terraform init

B. - run: terraform init
name: Terraform Init

C. - step: terraform init
run: true

D. - name: Terraform Init
run: terraform init

Solution

1. Step 1: Check GitHub Actions step syntax

   Steps use name and run keys to describe and execute commands.

2. Step 2: Validate correct order and keys

   - name: Terraform Init run: terraform init uses name then run with the correct command string.

3. Final Answer:

   - name: Terraform Init run: terraform init -> Option D

4. Quick Check:

   Step keys = name + run [OK]

Hint: GitHub Actions steps use 'name' then 'run' keys [OK]

Common Mistakes:

• Using 'command' instead of 'run'
• Swapping order of keys causing confusion
• Using invalid keys like 'step'

3. Given this GitHub Actions snippet, what will happen when a push occurs?

jobs:
  terraform:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Terraform Init
        run: terraform init
      - name: Terraform Plan
        run: terraform plan

medium

A. The workflow will fail due to missing apply step

B. Terraform will initialize and then create a plan for changes

C. Terraform will only checkout the code without running commands

D. Terraform will apply changes automatically

Solution

1. Step 1: Analyze the steps in the workflow

   The workflow checks out code, runs terraform init, then runs terraform plan.

2. Step 2: Understand Terraform commands effect

   terraform init prepares the environment; terraform plan shows what changes would happen but does not apply them.

3. Final Answer:

   Terraform will initialize and then create a plan for changes -> Option B

4. Quick Check:

   Init + Plan = prepare and preview [OK]

Hint: Init prepares, Plan previews changes, Apply makes changes [OK]

Common Mistakes:

• Confusing plan with apply
• Assuming apply runs automatically
• Ignoring checkout step importance

4. You wrote this GitHub Actions step but it fails:

- name: Terraform Apply
  run: terraform apply -auto-approve

What is a common reason for failure in this context?

medium

A. Missing terraform init before apply

B. Using -auto-approve flag incorrectly

C. GitHub Actions does not support terraform apply

D. The step name must be 'Apply Terraform' exactly

Solution

1. Step 1: Check Terraform command requirements

   Terraform requires terraform init to run first to set up backend and providers.

2. Step 2: Identify missing initialization

   If terraform init is missing, terraform apply will fail due to uninitialized state.

3. Final Answer:

   Missing terraform init before apply -> Option A

4. Quick Check:

   Init must run before apply [OK]

Hint: Always run 'terraform init' before 'terraform apply' [OK]

Common Mistakes:

• Thinking -auto-approve causes failure
• Believing GitHub Actions blocks apply commands
• Assuming step name affects execution

5. You want to securely store Terraform state remotely and run terraform apply only after manual approval in GitHub Actions. Which setup is best?

hard

A. Use a remote backend like AWS S3 for state and add a manual approval job before apply

B. Store state in GitHub repo and run apply automatically after plan

C. Keep state local and run apply in the same job as plan

D. Use GitHub Secrets to store state file content and apply immediately

Solution

1. Step 1: Secure state storage best practice

   Remote backends like AWS S3 keep Terraform state safe and shared among users.

2. Step 2: Implement manual approval in workflow

   GitHub Actions supports manual approval jobs to pause before applying changes.

3. Step 3: Combine both for safe, controlled deployment

   Using remote state plus manual approval ensures safety and control over apply.

4. Final Answer:

   Use a remote backend like AWS S3 for state and add a manual approval job before apply -> Option A

5. Quick Check:

   Remote state + manual approval = safe apply [OK]

Hint: Remote state + manual approval = secure, controlled apply [OK]

Common Mistakes:

• Storing state in repo risking conflicts
• Running apply automatically without checks
• Using secrets to store entire state file