Hands-On Practice Set 2

Let's think about this for a second

This round steps things up from round 1 — instead of practicing each skill in isolation, you'll combine them all at once. That includes deciding how to split modules into layers, choosing between `count` and `for_each` depending on the scenario, and writing up a production remote backend setup as a document. Budget about 10 minutes per task.

Let's connect this to a real scenario

Task 1: Design how you'd split a web app project (network, compute, database, monitoring) into 4 modules, and write down what each module's inputs/outputs should be. Task 2: If you need to create 5 servers with fixed names 'server-1' through 'server-5' (and want deleting/modifying one to not affect the others), would you use `count` or `for_each`, and why? Task 3: Write a step-by-step plan for migrating from local state to an S3 remote backend (include a backup, migrate, and verify sequence). Task 4: For the requirement 'the CI pipeline should auto-apply to the dev environment, but require manual approval for production', sketch out the rough pipeline steps.

Wrote down the criteria for deciding how to split modules into layers
Can correctly choose between count/for_each depending on the scenario
Wrote a remote backend migration plan and an environment-scoped CI/CD flow

Let's look at an example

text

# Task 2 - count vs for_each
Requirement: named servers, safe to remove one without
affecting the others -> use for_each (key-based), NOT count
(index-based) — removing an item from a list with count
shifts every subsequent index and can force unwanted recreates.

# Task 3 - local -> S3 backend migration
1. terraform state pull > backup.tfstate   (manual backup first)
2. Add the backend "s3" { ... } block to the config
3. terraform init                          (Terraform detects
   the backend change and offers to migrate state)
4. Confirm the migration prompt
5. terraform plan                          (should show 0 changes
   if migration succeeded — same resources, new state location)

You should see

You'll come away with a module layer design, a count/for_each decision, a remote backend migration plan, and an environment-scoped CI/CD flow.

Try it in 5 minutes

Actually run the migration plan from Task 3 against a local `local_file` resource (from the Basic chapter) — simulating a migration from local state to a simple file-based backend — and take notes on what happens at each step.

A quick word of caution

Before running a backend migration against production state, set a maintenance window (a time the whole team agrees not to run apply) — if someone applies at the same time as the migration, you could end up with a state conflict.