7.3 Structuring infrastructure code
Your infrastructure repository stays readable at the tenth environment.
Before:06. Containers & KubernetesUnlocks:11. Projects, Certification & Portfolio
An infrastructure repository is judged at its tenth environment, not its first, and this topic is about structure that survives growth: modules without premature abstraction, remote state with locking for teams, and the workspaces-versus-directories decision for environments. Importing existing resources without breaking them earns its place because real work starts amid things that already exist. It follows the basics because structure problems only appear at scale. The common confusion is extracting a module the first time something repeats; the wrong abstraction costs more than the duplication did.
Work through these
Modules, composition and avoiding premature abstraction
Modules let you reuse a pattern, and abstracting too early produces a module with fifteen variables that nobody can read. The judgement about when to extract one is the content of this item.
Remote state, locking and team workflows
Shared state needs to live somewhere central and needs locking so two people cannot apply at once. Without the lock, simultaneous changes corrupt the record of what exists.
Workspaces vs directories per environment
Separating environments by workspace or by directory are two accepted approaches with different failure modes. Choosing one deliberately matters more than which one you choose.
Importing existing resources without breaking them
Resources created by hand can be brought under management without recreating them, and the process is finicky enough to be worth practising on something disposable.
Sign in to keep your progress.
Free resources
We haven't checked most of these for screen reader use yet.
Links last checked 29 Aug 2026.
Stuck here?
Ask a mentor. A real person answers, and they can see exactly which topic you're on. Usually within a couple of working days.
Checking your session…
Topics shown in module order.