Lesson 13 · Senior IaC judgment
IaC truthfulness: what Terraform owns here, and what it does not
How to explain what this Terraform tree really provisions, what it only influences indirectly, and why “everything is in IaC” is often too sloppy to be useful.
Your win: explain what Terraform truly owns in this repo, what adjacent systems still own, and why strong senior IaC answers sound more precise than “the infrastructure is all in Terraform.”
Why this page matters more than it first looks
A lot of weak infrastructure explanations fail for the same reason: they are too broad to be useful. People say “everything is Infrastructure as Code” or “Terraform creates the whole platform.” Those sentences sound mature. But they stop being helpful the moment you need to debug, review, or explain a real system with real boundaries.
This repo is a good place to learn the better habit because Terraform genuinely matters a lot here. It provisions major shared foundations: clusters, networking, IAM, KMS, Cloud SQL, state buckets, and trust links. But some important resources are still outside this tree, and many other layers — Helm, Kubernetes, Atlantis, app code, runtime operations — still own meaningful parts of the system.
That is why this page matters. It teaches a more senior kind of honesty: the ability to say what the Terraform tree really owns, where that ownership stops, and why that boundary changes how you reason about the platform.
Start with the whole system, not just the Terraform directory
The easiest mistake is to talk as if deployments/terraform/ were the whole platform. It is not. Terraform provisions foundational resources. But Helm still turns chart logic into runtime objects. Kubernetes still schedules and reconciles workloads. Atlantis still governs the plan/apply control path. Application code still owns business behavior. And a few notable resources are explicitly not managed here at all.
Once you zoom out and see the whole system, the Terraform boundary becomes easier to explain. Terraform creates a lot of the substrate other layers rely on. It does not automatically absorb every operational concern into itself.
deployments/terraform/.What Terraform truly owns here
Terraform really does own a lot. It owns the reusable infrastructure definitions under modules/ and the live instantiations under live/. It owns foundational cloud resources, identity bindings, KMS-backed trust paths, and the pieces that later courses quietly assumed were already present. That is why this course functions like a capstone for the deployment and platform track.
But Terraform still does not own everything around those resources. Runtime deploy behavior still belongs to CI/CD, Helm, and Kubernetes. Secret-consumption behavior still belongs partly to applications and deploy tooling. Observability still depends on systems operating above what Terraform created. And some resources are intentionally managed elsewhere.
What stronger answers sound like
The strongest answers here sound like: “Terraform is the foundational provisioning layer for this platform — clusters, IAM, KMS, networking, Cloud SQL, state/storage, and trust paths — but it is not the whole operational system, and some important resources are intentionally outside this tree, so strong IaC answers name both the owned surface and the boundary.”
That answer is better because it is more accurate, more local, and more operationally honest than a generic “everything is managed as code” slogan.
Re-read the repo IaC map with an ownership lens
Use the repo map to separate Terraform-managed foundations from neighboring runtime, delivery, and externally managed systems.
Check yourself (from memory)
Q1. What is the most truthful short summary of Terraform’s role in this repo?
Sources. Repo IaC map; official Terraform overview docs.