# Glossary — Infrastructure as Code

The canonical vocabulary for this course. Opinionated and repo-flavoured. Once a term is
defined here, every lesson uses it this way. Terms marked *(Part N)* are taught in that part.
Repo-specific values are confirmed in [repo-iac-map.md](./repo-iac-map.md).

---

### Infrastructure as Code (IaC)
Defining infrastructure (clusters, networks, buckets, IAM) as version-controlled code you can
review, diff, and apply — instead of clicking cloud consoles or running ad-hoc commands.
Reproducible, auditable, and reviewable.

### Terraform
HashiCorp's IaC tool. You write **declarative** config (HCL) describing desired infrastructure;
Terraform plans the diff against reality and applies it via cloud **providers**. *Repo: under
`deployments/terraform/`.*

### Declarative / desired state
You describe *what* you want (a cluster with these node pools), not *how* to build it. Terraform
figures out the create/update/delete actions to converge — the same idea as Kubernetes (Course 2),
applied to cloud resources.

### Provider *(Lesson 2)*
A plugin that lets Terraform talk to a platform's API (GCP, AWS, Kubernetes, Cloudflare, GitHub).
*Repo: primarily the `google`/`google-beta` provider, plus Cloudflare/GitHub.*

### Resource *(Lesson 2)*
The core building block — one piece of infrastructure (`google_container_cluster`,
`google_sql_database_instance`, `google_service_account`). A `resource` block declares its desired
config.

### HCL
HashiCorp Configuration Language — Terraform's syntax: `resource`, `variable`, `output`,
`module`, `provider` blocks; expressions and interpolation.

### Plan / apply *(Lessons 1, 12)*
`terraform plan` = preview the diff (what will be created/changed/destroyed) by comparing config
to state. `terraform apply` = make those changes. Plan-before-apply is the safety gate.

### State *(Lesson 3)*
Terraform's record of the real infrastructure it manages — the **source of truth** it diffs
against. Lives in a **state file** (JSON). Losing/corrupting it is a big deal.

### Remote state / backend *(Lesson 3)*
Storing state in a shared **backend** (here a **GCS** bucket) instead of a local file — so a team
(and Atlantis) share one state, with versioning and locking. *Repo: GCS backend, configured once
via Terragrunt.*

### State locking *(Lesson 3)*
A lock (the GCS backend takes one automatically) that stops two `apply`s running at once and
corrupting state.

### Drift *(Lessons 3, 12)*
When real infrastructure no longer matches state/config (someone clicked in the console).
`terraform plan` detects it; `apply` (or `import`) reconciles it.

### Module *(Lesson 4)*
A reusable, parameterized package of resources with **inputs** (variables) and **outputs** —
called with a `module` block. DRY infrastructure: write "a GKE cluster" once, instantiate it many
times. *Repo: ~34 under `modules/`.*

### Input variable / output *(Lesson 4)*
A module's parameters (`variable`) and return values (`output`). Outputs of one module feed inputs
of another (e.g. the VPC's subnet ID → the GKE cluster).

### Terragrunt *(Lessons 5–6)*
A thin wrapper over Terraform that keeps configs **DRY**: define the remote-state + provider once
in a root config, and each leaf `include`s it. *Repo: the `live/` dirs are Terragrunt; the root
config is named **`root.hcl`** (not the conventional `terragrunt.hcl`).*

### `remote_state` / `generate` / `include` *(Lessons 5–6)*
Terragrunt blocks: `remote_state` (the shared backend config), `generate` (write a provider/
backend file into each dir), `include` (pull in the parent root config). The mechanism that makes
one config serve every cell.

### live / modules split *(Lessons 5–6)*
The convention: `modules/` = reusable definitions (no state); `live/` = thin per-cell configs that
instantiate modules with real values. *Repo: `deployments/terraform/{modules,live}`.*

### env × org matrix (in TF) *(Lesson 6)*
This repo's organizing principle (Course 1) as a **directory tree**: `live/<env>-<org>/<component>/
terragrunt.hcl` — one directory per cell per component, each with its own state.

### GKE *(Lesson 8)*
Google Kubernetes Engine — the managed Kubernetes the clusters run on (Course 2). *Repo: a TF
module with spot node pools, Workload Identity, and `enable_binary_authorization`.*

### Node pool / spot *(Lesson 8)*
A group of GKE nodes with a shared config. *Repo: backend runs on **spot** (pre-emptible) nodes by
default (Course 2 L10) — provisioned here.*

### IAM (Identity & Access Management) *(Lesson 9)*
GCP's permissions model: who (a **member**: user/group/service account) may do what (a **role**) on
what (a resource). In TF: `google_project_iam_member`, `google_service_account`.

### Service Account (GCP / GSA) *(Lesson 9)*
A non-human identity for workloads/CI. *Repo: a per-service GSA + the CI bots (`prod-build-bot`,
…). Created in Terraform.*

### Workload Identity (binding) *(Lesson 9)*
The link that lets a Kubernetes ServiceAccount impersonate a GCP GSA with no static key —
`google_service_account_iam_member` with role `roles/iam.workloadIdentityUser`, member
`serviceAccount:PROJECT.svc.id.goog[<ns>/<ksa>]`. **This is the Terraform behind the
`iam.gke.io/gcp-service-account` annotation (Course 3) and keyless CI (Course 5).**

### Workload Identity Federation (WIF) *(Lesson 9)*
The external variant: a **pool + provider** that lets an outside identity (GitHub's OIDC token,
Course 5) assume a GCP SA. *Repo: `gh-action-pool`.*

### Cloud KMS *(Lesson 10)*
GCP's key-management service. *Repo: the keyrings/keys behind **SOPS** secret decryption (Course 3)
and the **`binauthz-attestors`** attestation keys (Course 5), created in Terraform.*

### VPC / subnet *(Lesson 11)*
The private network (and its regional subnets) the clusters live in. *Repo: a networking module.*

### Cloud SQL *(Lesson 11)*
GCP's managed relational database. *Repo: Postgres instances (service DBs; the Grafana OnCall DB,
Course 6).*

### Cloudflare (in TF) *(Lesson 11)*
DNS + edge certs, managed via the Cloudflare provider. *Repo: the DNS records + front-end certs
backing Istio's Cloudflare ingress gateway (Course 4).*

### Atlantis *(Lesson 12)*
Terraform **PR automation**: opening a PR runs `terraform plan` and posts it as a comment;
commenting `atlantis apply` runs the apply and locks state. *Repo: `platforms/atlantis` — the
apply path for infra (distinct from Course 5's push-based app deploys).*