Capstone — Provisioning a Real Multi-Resource Environment

Terraform / Infrastructure as Code

Chapter 11 · Capstone — Provisioning a Real Multi-Resource Environment

Ten chapters, one piece at a time. This closing chapter combines every one of them into a single, realistic three-tier environment — a VPC, a compute tier, and a database — built and deployed the way a real team actually would.

The Target Environment

A VPC with public and private subnets, a web tier running in the public subnets, and a database in the private subnets — a genuinely common shape, deliberately chosen so every chapter's own technique has a real place to be applied.

Step 1 — Remote Backend & Locking

Configured first, before anything else exists: Chapter 6's S3+DynamoDB backend, so state is safely shared and locked from the very first apply onward — never starting on local state and migrating later.

terraform { backend "s3" { bucket = "company-tfstate" key = "capstone/terraform.tfstate" dynamodb_table = "terraform-locks" encrypt = true } }

Step 2 — The VPC via a Registry Module

Chapter 7: the VPC itself is a vetted community module, not hand-written — its subnet layout, route tables, and NAT gateways already cover edge cases a first attempt wouldn't.

module "vpc" { source = "terraform-aws-modules/vpc/aws" version = "~> 5.0" cidr = "10.0.0.0/16" }

Step 3 — Variables & Environment-Specific Values

Chapter 4: instance_count, an environment variable with validation, and a sensitive db_password — with Chapter 5's own honest caveat still true: sensitive hides CLI output, the encrypted backend from Step 1 is what actually protects the value at rest.

Step 4 — The Compute Tier With for_each

Chapter 3: web servers created with for_each over a stable set of names, referencing the VPC module's own subnet-ID outputs — the dependency graph resolving automatically, exactly as Chapter 3 first demonstrated with a data source.

resource "aws_instance" "web" { for_each = toset(["a", "b"]) subnet_id = module.vpc.public_subnets[0] }

Step 5 — The Database Tier With lifecycle Protection

Chapter 3's own Exercise 3 scenario, applied for real: the database gets prevent_destroy = true — a deliberate safeguard against exactly the accidental-destroy risk that exercise walked through.

resource "aws_db_instance" "main" { lifecycle { prevent_destroy = true } }

Step 6 — Environments: Separate Directories, Not Workspaces

Chapter 8 concluded that workspaces alone aren't a strong enough boundary for a genuinely high-stakes production environment — this capstone deliberately follows that conclusion, using separate environments/dev/ and environments/prod/ directories, each with its own backend key and credentials, rather than terraform workspace select.

Step 7 — Handling a Pre-Existing Resource

The DNS record for this environment was created by hand, before this project existed. Chapter 9's two-step import workflow brings it under management: write the matching resource block, run terraform import, then iterate against plan until it reports no changes.

Step 8 — The CI/CD Gate

Chapter 10's full pipeline wraps the whole thing: fmt/validate → terraform test → plan posted as a PR comment, gated by a policy-as-code check → human review → merge → apply, running only from the reviewed main branch.

The Full Picture

StepChapter
1Ch.6 — Remote backend & locking
2Ch.7 — VPC via a registry module
3Ch.4 — Variables, validation, sensitive values
4Ch.3 — for_each and the dependency graph
5Ch.3 — lifecycle protection
6Ch.8 — Environment isolation strategy
7Ch.9 — Import
8Ch.10 — CI/CD gate

What's Still Out of Scope, Honestly

This capstone provisions infrastructure — it deliberately does not configure servers or install software, exactly the Terraform-vs-Ansible boundary Chapter 1 drew from the very first page; that's still a genuinely separate, still-outstanding piece of this site's own bucket list. Multi-region disaster recovery, cost optimization at real scale (cloud1-9/cloud2-7), and a dedicated secrets manager beyond an encrypted backend are all real next steps a production system would eventually need, named honestly rather than treated as solved here.

The through-line, restated
Every step in this capstone is a direct, concrete application of a chapter's own material — nothing new was introduced here. That's deliberate: production-readiness comes from combining well-understood, individually simple pieces correctly, not from any single advanced trick.
Terraform provisions; it doesn't configure
Nothing in this capstone installs or configures software on the web tier once it exists — that boundary, drawn all the way back in Chapter 1, holds even at capstone scale. A real deployment still needs Ansible (or an equivalent) for that half of the job.

Closing the Course

From Chapter 1's configuration-drift problem to a real, CI-gated, multi-resource environment — every chapter in between solved one specific, genuine piece of that original problem. State, locking, modules, environments, import, and automated review together are what actually make infrastructure reproducible, reviewable, and safe to change — not any single command on its own.

Hands-On Exercises

Exercise 1

Explain why Step 1 (the remote backend) had to be configured before any other resource in this capstone, rather than being added later once the environment already existed.

📄 View solution
Exercise 2

Explain why this capstone chose separate directories over Terraform workspaces for dev/prod isolation, tying your answer back to the specific reasoning Chapter 8 gave.

📄 View solution
Exercise 3

Across the entire course, name the single idea that recurs most often, and explain in your own words why understanding it matters more than memorizing any individual command.

📄 View solution

Chapter 11 Quick Reference — Course Complete

  • Every capstone step is a direct, unmodified application of an earlier chapter's own technique
  • Still out of scope: server configuration (Ansible's job), DR at scale, dedicated secrets management
  • Terraform provisions infrastructure; it never configures what runs on top of it
  • Course complete — Terraform / Infrastructure as Code, 11 chapters