Lesson 4 · Terraform fundamentals

Modules

Write infrastructure once, instantiate it everywhere — the DRY unit that makes an env×org matrix possible.

Your win: explain what a Terraform module is, how inputs/outputs parameterize it, and why this repo's 34 modules are the reusable building blocks behind ~180 per-cell configs.

Don't write the cluster config 30 times

You need a GKE cluster in stag-manabie, prod-tokyo, prod-jprep, … Copy-pasting the same 200 lines of cluster resources into each cell is the env×org problem all over again (Course 1). A module is the fix: a reusable, parameterized package of resources you write once and instantiate with different inputs.¹ It's the same "define once, stamp out many" idea as a Helm library chart (Course 3), but for cloud resources.

Inputs and outputs — the module's interface

Input variables (variable) — the module's parameters (project, region, node-pool sizes). The caller passes values.
Outputs (output) — values the module returns (the cluster's name, a bucket's URL, a service account's email). Callers read them, and one module's output feeds another's input.

# calling a module
module "platforms" {
  source     = "../../..//modules/platforms"
  project_id = var.project_id
  gke        = local.gke_config        # the input
}
# … later, another component reads its output
namespace = module.platforms.gke_identity_namespace

Outputs wiring modules together — the dependency graph Modules aren't islands. The VPC module outputs a subnet ID; the GKE module takes it as an input. That input→output link is a dependency — Terraform builds a graph and creates things in the right order (VPC before the cluster that needs it). In this repo, cross-component wiring is explicit via Terragrunt dependency blocks (Lesson 5).

Anchor — the 34 modules vs the 180 leaves deployments/terraform/modules/ holds 34 reusable modules — platforms (GKE + Cloud SQL + KMS + GCS), apps (service accounts + Workload Identity), vpc, kms-key, github-oidc, cloudflare-dns, … (Lesson 7). None of them create anything on their own — they're definitions. The ~180 terragrunt.hcl leaves under live/ are thin: each just points at a module and passes that cell's values (terraform { source = "…/modules/platforms" }). One module definition; many instantiations across the env×org matrix. That ratio — 34 defs → 180 instances — is exactly why modules matter.

Modules can wrap modules This repo's modules often wrap community modules (e.g. modules/platforms/gke.tf wraps terraform-google-modules/kubernetes-engine). You rarely write raw resources for a GKE cluster — you configure a well-tested module. Standing on others' modules is normal and good; know where the registry ones end and yours begin.

Terraform — Modules

Authoring and calling modules, input variables, outputs, and composition.

→ hashicorp — Modules

Check yourself (from memory)

Q1. A Terraform module is…

Write it once with inputs/outputs; instantiate with different values — the DRY unit (like a Helm library chart, for cloud infra).

Q2. One module's output feeding another's variable creates…

Input→output links form the dependency graph; Terraform creates VPC before the cluster that needs its subnet.

Q3. In this repo, the live/ leaves are thin because…

34 module defs → ~180 leaf instantiations; each leaf points at a module and passes its env×org values.

Modules — what, inputs/outputs, and this repo's def-to-instance ratio.

recall, then click to reveal

A MODULE = a reusable, PARAMETERIZED package of resources — write once, instantiate many (the DRY unit; like a Helm library chart, for cloud infra). INTERFACE: variable INPUTS (caller passes values) + output RETURNS (caller reads; one module's output → another's input = a DEPENDENCY Terraform orders, e.g. VPC before GKE). Call with module "x" { source = "…/modules/x"; ... }. Modules often WRAP community modules (repo GKE wraps terraform-google-modules). REPO: 34 module defs under modules/ (platforms/apps/vpc/kms-key/github-oidc/…) → ~180 thin terragrunt.hcl LEAVES under live/, each pointing at a module with that cell's values. That 34→180 ratio is why modules matter.

✅ Part 1 complete You've got the Terraform fundamentals: what IaC is + plan/apply (L1), providers & resources (L2), state (L3), and modules (L4). Part 2 is this repo's IaC: Terragrunt & DRY, the env×org matrix as a directory tree, the module inventory, and the GKE cluster the whole track runs on.

Ready for Part 2 (Terragrunt & the env×org matrix)? Or a mock interview on Part 1 — state and "why modules" are guaranteed Terraform-Associate questions. Ask me.

1. Terraform — Modules.