Lesson 7 · This repo's IaC: Terragrunt & the env×org matrix
The module inventory
The 34 building blocks — a tour of what Terraform actually provisions for the whole track.
Your win: know the repo's key modules and what each provisions — so you can point at the Terraform behind any piece of infrastructure from Courses 2–6.
34 modules, grouped by what they build
You don't need all 34 memorized, but knowing the important ones means you can trace any part of the stack to its source. Grouped:
| Group | Module(s) | Provisions (and where you met it) |
|---|---|---|
| The platform | platforms | the big one — GKE cluster, Cloud SQL, GCS buckets, KMS, BigQuery, PubSub, Artifact Registry (Courses 2, 6) |
| Identity | apps/{stag,uat,prod}, github-oidc, deploy-bot | per-service GSAs + Workload Identity (C3/C6); the GitHub WIF pool + CI bots (C5) |
| Network | vpc, cloudflare-dns, psc-endpoint | VPC/subnets/NAT; DNS + edge certs for Istio's gateway (C4) |
| Data | postgresql, postgresql-roles, postgresql-grant | DBs/users/RBAC inside the Cloud SQL instances (C-Postgres) |
| Security | kms-key, binary-authorization-attestor, security | SOPS keys (C3), binauthz attestors + policy (C5) |
| Access | project-roles, project-grant, project-services | custom IAM roles, grants, enabled GCP APIs |
| Observability | oncall, dashboard-monitoring, uptime-checks, notification-channel | Grafana OnCall API objects, monitoring config (C6) |
| Buckets/misc | simple-bucket, kubeip, lib/* | the TF state + CI cache buckets; egress IP; helpers |
The mental index: "which module made X?"
The payoff of this inventory is being able to answer, for any infra you've seen: where's
the Terraform? The cluster →
platforms. The
iam.gke.io annotation's backing → apps. The SOPS key → kms-key.
The binauthz policy → binary-authorization-attestor. The CI bots →
github-oidc. Istio's DNS certs → cloudflare-dns. That index turns
"magic infrastructure" into "a module I can go read."
Anchor — modules wrap community modules
A recurring pattern: the repo's modules often wrap well-tested community modules
rather than hand-writing raw resources — e.g. modules/platforms/gke.tf
wraps
terraform-google-modules/kubernetes-engine (Lesson 8),
modules/vpc wraps terraform-google-modules/network,
modules/simple-bucket wraps the cloud-storage
simple_bucket. So a "module" here is often a thin, opinionated layer over an
upstream module — the repo's conventions + the community's battle-testing.
A note on generated inputs
Some modules are driven by declarative data, not hand-listed resources: the
apps and kms-key modules read the service list from
deployments/decl/<env>-defs.yaml and generate a GSA + KMS
key per service. So adding a service to a YAML file provisions its identity + key — a nice
"data-driven infrastructure" touch you'll see in Lesson 9.
Read this next
Terraform Registry (community modules) + the repo modules dir
How registry modules are sourced, and this repo's modules/ tree.
→ registry.terraform.io — Google modules
→ In-repo: deployments/terraform/modules/
Check yourself (from memory)
Q1. The GKE cluster + Cloud SQL + GCS + KMS are provisioned by which module?
platforms is the big env module (GKE/Cloud SQL/
GCS/KMS/BQ/PubSub/AR). apps does identity.
Q2. The Terraform behind the iam.gke.io/gcp-service-account annotation is in…
apps creates the per-service GSA + Workload
Identity binding (Lesson 9). SOPS keys are kms-key.
Q3. A recurring pattern in these modules is that they…
e.g.
platforms/gke.tf wraps
terraform-google-modules/kubernetes-engine — opinionated layer over upstream.
The key modules and "which module made X?"
recall, then click to reveal
34 modules, grouped: PLATFORM =
platforms (GKE, Cloud SQL,
GCS, KMS, BQ, PubSub, AR); IDENTITY = apps (GSAs + Workload Identity, C3/C6),
github-oidc (WIF pool + CI bots, C5); NETWORK = vpc,
cloudflare-dns (DNS + Istio edge certs, C4); DATA = postgresql* (DBs/
users in Cloud SQL); SECURITY = kms-key (SOPS keys, C3),
binary-authorization-attestor (binauthz, C5); ACCESS = project-roles/grant/
services; OBS = oncall etc. (C6). "Which module made X?": cluster→platforms,
annotation→apps, SOPS key→kms-key, binauthz→binary-authorization-attestor, CI bots→github-oidc,
Istio certs→cloudflare-dns. Modules often WRAP community modules; some are DATA-DRIVEN (read
decl/<env>-defs.yaml).
Want a deeper tour of any module (e.g.
vpc or kms-key), or how
decl/*-defs.yaml drives the apps module? Ask me.
1. In-repo: deployments/terraform/modules/ (34 modules).