Terraform in GitHub Actions - Mini Project: Build & Apply

Terraform in GitHub Actions

📖 Scenario: You are working on a cloud infrastructure project. You want to automate the process of applying Terraform configurations using GitHub Actions. This will help you deploy infrastructure changes automatically when you push code to your repository.

🎯 Goal: Build a GitHub Actions workflow file that initializes Terraform, plans the changes, and applies them automatically on the main branch.

📋 What You'll Learn

Create a GitHub Actions workflow YAML file named terraform.yml in the .github/workflows directory.

Set the workflow to trigger on pushes to the main branch.

Add a job named terraform that runs on ubuntu-latest.

Configure steps to checkout the repository, setup Terraform, initialize Terraform, run terraform plan, and run terraform apply with auto-approve.

💡 Why This Matters

🌍 Real World

Automating Terraform deployments with GitHub Actions helps teams deploy infrastructure safely and consistently whenever code changes.

💼 Career

DevOps engineers and cloud architects often use CI/CD pipelines like GitHub Actions to manage infrastructure as code with Terraform.

1

Create the workflow file and trigger

Create a file named terraform.yml inside the .github/workflows folder. Add the workflow name Terraform CI and set it to trigger on push events to the main branch. Write the YAML lines for name and on with push and branches: [main].

Terraform

name: Terraform CI
on:
  push:
    branches: [main]
# Your code here

Hint

Start by defining the workflow name and the event trigger for the main branch.

2

Add the job and runner

Add a job named terraform under jobs. Set the runner to ubuntu-latest. Write the YAML lines for jobs:, terraform:, and runs-on: ubuntu-latest.

Terraform

name: Terraform CI
on:
  push:
    branches: [main]
jobs:
  terraform:
    runs-on: ubuntu-latest
    # Your code here

Hint

Define the job and specify the operating system runner.

3

Add steps to checkout and setup Terraform

Under the terraform job, add a steps section. Add a step named Checkout repository that uses actions/checkout@v3. Then add a step named Setup Terraform that uses hashicorp/setup-terraform@v2 with terraform_version: 1.5.7.

Terraform

name: Terraform CI
on:
  push:
    branches: [main]
jobs:
  terraform:
    runs-on: ubuntu-latest
    steps:
      # Your code here

Hint

Use the official GitHub Action to checkout code and the HashiCorp action to install Terraform.

4

Add Terraform init, plan, and apply steps

Add three steps under steps: Terraform Init running terraform init, Terraform Plan running terraform plan, and Terraform Apply running terraform apply -auto-approve. Use run to execute these commands.

Terraform

name: Terraform CI
on:
  push:
    branches: [main]
jobs:
  terraform:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v3
      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v2
        with:
          terraform_version: 1.5.7
      # Add Terraform commands below
      # Your code here

Hint

Run the Terraform commands in order to initialize, plan, and apply the infrastructure changes.

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