Terraform Tutorial — Introduction Practice Exercises

4 minute read

Test your understanding of Terraform’s purpose, ecosystem, and place in the DevOps world. These are conceptual exercises — no code or installation required yet.

Exercise 1: IaC Benefits

Question: Your manager asks why the team should spend time writing Terraform files instead of just clicking through the AWS console. List five benefits of Infrastructure as Code that you would present.

Answer
  1. Reproducibility — The same config creates the exact same infrastructure every time. No “it works on my environment” problems.
  2. Version control — .tf files live in Git. Every change is tracked with a commit message, author, and timestamp.
  3. Code review — Infrastructure changes can be reviewed in pull requests, just like application code.
  4. Disaster recovery — If a region goes down, you can recreate the entire infrastructure in a different region by running the same config.
  5. Automation — Terraform integrates into CI/CD pipelines. Changes can be applied automatically when a PR is merged.

Other valid answers: collaboration, documentation (the code IS the documentation), speed, consistency, auditability.

Exercise 2: Tool Selection

Question: For each scenario below, which tool would you primarily use — Terraform, Ansible, or both?

  1. Create a VPC with public and private subnets on AWS
  2. Install Nginx and deploy a web application on 20 existing EC2 instances
  3. Set up an EKS cluster and then install monitoring agents on the worker nodes
  4. Manage DNS records on Cloudflare
Answer
  1. Terraform — VPC creation is infrastructure provisioning, which is Terraform’s primary purpose.
  2. Ansible — Installing packages and deploying applications on existing servers is configuration management.
  3. Both — Terraform creates the EKS cluster (provisioning), then Ansible configures the worker nodes (configuration management).
  4. Terraform — DNS records are infrastructure resources. The Cloudflare provider manages them declaratively.

Exercise 3: Terraform Ecosystem

Question: Match each component of the Terraform ecosystem with its description:

Component Options
Terraform CLI a. A public library of providers and reusable modules
Terraform Registry b. A plugin that connects Terraform to a specific platform
Terraform Cloud c. The open-source binary you run on your machine
Provider d. A SaaS platform with remote state, team access, and policy enforcement
Answer
  • Terraform CLI → c. The open-source binary you run on your machine
  • Terraform Registry → a. A public library of providers and reusable modules
  • Terraform Cloud → d. A SaaS platform with remote state, team access, and policy enforcement
  • Provider → b. A plugin that connects Terraform to a specific platform

Exercise 4: Declarative vs Imperative

Question: Explain the difference between declarative and imperative approaches using a real-world analogy. Then explain which approach Terraform uses and why it matters.

Answer

Analogy: Ordering food at a restaurant.

  • Declarative: “I’d like a margherita pizza.” You describe WHAT you want. The kitchen figures out HOW.
  • Imperative: “Take 200g of dough, knead for 5 minutes, roll into a circle, add 100ml of sauce, add 150g of mozzarella, bake at 220°C for 12 minutes.” You describe every step.

Terraform is declarative. You write a configuration that describes the desired end state (“I want an S3 bucket with these tags”). Terraform figures out the steps needed to reach that state.

Why it matters:

  • You don’t need to know the exact API calls to create each resource
  • Running the same config twice is safe (idempotent) — Terraform only makes changes if the current state differs from the desired state
  • Terraform handles the correct order of operations (create VPC before subnets)

Exercise 5: CI/CD Integration

Question: Describe a Terraform CI/CD workflow for a team of five engineers. Include: when terraform plan runs, when terraform apply runs, and how the team reviews changes before they’re applied.

Answer

Workflow:

  1. Developer creates a feature branch and edits .tf files (e.g., adds a new S3 bucket).
  2. Developer pushes the branch and opens a pull request.
  3. CI pipeline runs terraform plan automatically and posts the plan output as a comment on the PR. The plan shows: “1 resource to add, 0 to change, 0 to destroy.”
  4. Team members review the PR — they check both the code changes and the plan output. They verify that the plan only changes what’s intended.
  5. A senior engineer approves the PR.
  6. The PR is merged to main.
  7. CI pipeline runs terraform apply on the main branch, creating the S3 bucket.
  8. The team is notified of the successful apply (Slack, email, or PR comment).

Key principles:

  • terraform plan runs on every PR (safe, read-only)
  • terraform apply runs only on merge to main (changes real infrastructure)
  • No one applies changes from their laptop — all changes go through the pipeline
  • The plan output is the review artifact — the team verifies it before approving

Chapter Summary

In this chapter, you learned:

  • Terraform is an open-source IaC tool that lets you manage cloud infrastructure through configuration files
  • Terraform is declarative and idempotent — you describe what you want, and running it twice is safe
  • Terraform complements Ansible (provisioning vs. configuration) and competes with CloudFormation and Pulumi
  • The ecosystem includes the CLI, Registry, Cloud, Enterprise, and 3,000+ providers
  • Terraform fits into CI/CD pipelines with plan-on-PR, apply-on-merge workflows
  • Real-world use cases include multi-region DR, self-service environments, and network-as-code

Next up: Installing Terraform — let’s get Terraform running on your machine.

← Real-World Use Cases Installing Terraform →

You may also enjoy