Terraform in GitHub Actions - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ service_behavior

intermediate

Terraform GitHub Action Workflow Behavior

Consider this GitHub Actions workflow snippet that runs Terraform commands:

name: Terraform Apply
on: [push]
jobs:
  terraform:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v2
        with:
          terraform_version: 1.5.0
      - name: Terraform Init
        run: terraform init
      - name: Terraform Apply
        run: terraform apply -auto-approve

What will happen if the Terraform configuration has syntax errors?

A The workflow will fail at the 'Terraform Init' step with an error.

B The workflow will skip the 'Terraform Apply' step automatically.

C The workflow will succeed but no changes will be applied.

D The workflow will fail at the 'Terraform Apply' step with an error.

💡 Hint

Think about when Terraform validates the configuration syntax.

Terraform 'init' only initializes the backend and downloads providers. Syntax errors are detected during 'terraform apply' or 'terraform plan'. Therefore, the workflow fails at the 'Terraform Apply' step.

❓ Configuration

intermediate

Correct Terraform GitHub Action Step for State Storage

You want to configure your GitHub Actions workflow to use an AWS S3 bucket as the Terraform remote backend for state storage. Which step correctly initializes Terraform with this backend?

A run: terraform init -backend-config="bucket=mybucket" -backend-config="region=us-east-1"

B run: terraform apply -backend-config="bucket=mybucket" -backend-config="region=us-east-1"

C run: terraform plan -backend-config="bucket=mybucket" -backend-config="region=us-east-1"

D run: terraform validate -backend-config="bucket=mybucket" -backend-config="region=us-east-1"

💡 Hint

Which Terraform command sets up the backend configuration?

The 'terraform init' command initializes the working directory and configures the backend. The other commands do not configure the backend.

❓ security

advanced

Securely Managing AWS Credentials in GitHub Actions for Terraform

You want to run Terraform in GitHub Actions to deploy AWS resources. What is the best practice to provide AWS credentials securely to the workflow?

A Use GitHub Secrets to store AWS credentials and reference them in the workflow environment variables.

B Hardcode AWS credentials in Terraform configuration files checked into the repository.

C Use public AWS credentials with limited permissions in the workflow.

D Store AWS access key and secret key directly in the workflow YAML file.

💡 Hint

Think about how to keep secrets safe in GitHub repositories.

GitHub Secrets securely store sensitive data and can be injected as environment variables during workflow runs. Hardcoding or storing credentials in plain text is insecure.

❓ Architecture

advanced

Handling Terraform State Locking in Concurrent GitHub Actions Runs

Your team runs Terraform apply in GitHub Actions on multiple branches simultaneously. What mechanism prevents state corruption when multiple runs try to modify the Terraform state at the same time?

A GitHub Actions disables parallel runs by default for workflows using Terraform.

B Terraform automatically queues runs in GitHub Actions to avoid conflicts.

C Terraform state locking via the configured backend (e.g., DynamoDB for S3 backend) prevents concurrent modifications.

D Terraform uses local state files to avoid conflicts in GitHub Actions.

💡 Hint

Think about how Terraform backends handle concurrency.

Terraform uses state locking supported by backends like S3 with DynamoDB to prevent concurrent state modifications. GitHub Actions or Terraform CLI do not queue runs automatically.

✅ Best Practice

expert

Optimizing Terraform Runs in GitHub Actions for Cost and Speed

You want to optimize your Terraform GitHub Actions workflow to reduce cloud costs and speed up runs. Which approach is the best practice?

A Run 'terraform apply' on every push to any branch without filtering.

B Use 'terraform plan' on pull requests and only run 'terraform apply' on merges to the main branch.

C Run 'terraform apply' manually only, never automate in GitHub Actions.

D Run 'terraform destroy' after every successful apply to clean resources.

💡 Hint

Consider when to apply changes to avoid unnecessary resource creation.

Running 'terraform plan' on pull requests helps review changes without applying them. Applying only on main branch merges reduces unnecessary resource changes and costs.