DECLARATIVE INFRASTRUCTURE
Where infrastructure becomes a software-defined system of record.
MATURITY POSITION — STAGE 1 OF 6
- Current Stage: Declarative Infrastructure
- Primary Architectural Concern: Whether a given piece of infrastructure deserves to become code, and what breaks when that decision is forced
- Primary Failure Mode: Configuration-as-Code Theater — declarative syntax has been adopted, but infrastructure decisions remain imperative, undocumented, and manually governed
- Stage Outcome: Reader can distinguish declarative infrastructure from infrastructure automation, and judge where each earns its cost
- Next Stage: MI2 — Control Plane Boundaries — Who owns the control plane?
Declarative infrastructure is the point at which infrastructure becomes a versioned system of record rather than operational memory. Most Infrastructure as Code (IaC) initiatives fail not because the tools are wrong, but because organizations adopt declarative syntax before they adopt declarative thinking — and this stage exists to teach the difference before it costs you a Level 3 stall.
That distinction is the whole job of MI1. This stage doesn’t argue that everyone should adopt IaC. It teaches architects what qualifies for declarative treatment, what doesn’t, and what breaks when you force it — a distinction that becomes the load-bearing foundation for everything MI2 through MI6 build on top of it.
The Modern Infrastructure & IaC Path Is an Intent-Governance Progression
| Stage | Architectural Question |
|---|---|
| MI1 — Declarative Infrastructure | When does infrastructure deserve to become code? |
| MI2 — Control Plane Boundaries | Who owns the control plane? |
| MI3 — State & Dependency Architecture | How does infrastructure become a platform product? |
| MI4 — Governance & Drift | How is infrastructure governed? |
| MI5 — Economics of Automation | How does infrastructure survive change? |
| MI6 — Infrastructure Survivability | How is infrastructure continuously proven? |
MI1 asks whether infrastructure should be declared at all. MI2 through MI6 all assume that question has already been answered correctly — each inherits whichever intent MI1 taught you to capture (or deliberately leave alone).
WHY THIS STAGE EXISTS — CONFIGURATION-AS-CODE THEATER
Most organizations believe adopting Terraform or OpenTofu solves the infrastructure-as-code problem. In practice, most stall two levels up the ladder — declarative syntax without declarative thinking.
Stage Anchor Question
Does this infrastructure deserve to become code?
Not: is Terraform installed? Not: what percentage of resources are under management? MI1 answers whether the underlying decision — to capture infrastructure intent as versioned specification rather than operational memory — was the right one for this specific piece of infrastructure, independent of which tool executes it.
Configuration-as-Code Theater is the named failure state for this stage: declarative syntax has been adopted, but infrastructure decisions remain imperative, undocumented, and manually governed. Terraform manifests exist. They describe a state nobody trusts, because changes still land through the console, module intent is never documented, and the code is a snapshot of what happened to be true on the day it was written — not a system of record anyone updates when the underlying decision changes.
This maps directly onto Framework #138’s core finding: most organizations reach Level 2 (Declarative Provisioning) on the Infrastructure Automation Ladder and stall there indefinitely, because declarative tooling was adopted without the governance architecture required to enforce intent at scale. The syntax changed. The thinking didn’t.
Stage Anchor Framework — Infrastructure Automation Ladder
Declarative Infrastructure Boundary (#138)
The Declarative Infrastructure Boundary is the point at which infrastructure intent becomes the authoritative system of record rather than operational memory. Below the boundary, infrastructure exists primarily as operational knowledge — execution depends on people. Above the boundary, infrastructure intent exists as versioned specification — execution depends on declared state.
Named Failure State: Configuration-as-Code Theater — declarative syntax adopted, infrastructure decisions still imperative, undocumented, and manually governed · Indicators: changes routinely applied outside the pipeline (“ClickOps drift”) · state file treated as sole source of truth with no review gate before apply · modules copy-pasted per environment rather than parameterized · version-controlled config exists but no one can explain why a resource is configured the way it is · IaC adoption measured by % of resources under management, not whether intent is captured and enforced
Why Architects Misjudge Declarative Infrastructure
IaC is treated as a tooling initiative instead of an intent-management discipline. Rolling out Terraform is a procurement and training exercise. Capturing why infrastructure is configured the way it is — and keeping that reasoning current — is an entirely different, and much harder, organizational commitment.
Automation is mistaken for declarative design. Scripts automate actions — they execute a sequence of imperative steps faster than a human could. Declarative systems describe outcomes — they state a desired end state and delegate the sequencing to a reconciliation loop. A well-automated imperative script is still imperative. Conflating the two is how organizations believe they’ve adopted IaC when they’ve only adopted faster scripting.
Code adoption is assumed to equal operational maturity. Many organizations reach Level 2 (Declarative Provisioning) on the Infrastructure Automation Ladder and never progress. They stop investing precisely because the dashboard says “90% of infrastructure is under Terraform management” — a metric that says nothing about whether the declared state reflects governed intent or just accumulated syntax.
What This Stage Is Not
Not a Terraform, OpenTofu, or Pulumi tutorial. Tool syntax is out of scope. MI1 evaluates whether the underlying decision to declare a given piece of infrastructure as code was correct — independent of which tool executes it.
Not a certification-track curriculum or vendor training. No badges, no vendor-specific best-practice checklists.
Not an argument that automation and IaC are the same thing. Automation is frequently a side effect of declarative adoption, not the goal of it — treating them as synonyms is exactly the misjudgment Section “Why Architects Misjudge” above names.
Not a mandate to convert everything to code. Includes the case for staying imperative — forcing declarative treatment onto low-value or highly volatile infrastructure often creates more governance debt than it removes.
>_ Estimated Reading Depth
| Format | Count | Estimated Time | Notes |
|---|---|---|---|
| Architecture articles — Cluster 01 | 2 | ~24 min | Why declarative matters — the automation ladder and the CI/CD-for-infrastructure argument |
| Configuration-as-Code Theater Failure Patterns Grid | 1 | ~8 min | Five failure patterns — read immediately after Cluster 01 |
| Architecture articles — Cluster 02 | 2 | ~22 min | Practicing the discipline — restraint, and the mechanical vocabulary of living in code day-to-day |
| Architecture articles — Cluster 03 | 2 | ~24 min | Adoption patterns — extending declarative practice past the cloud, and the tool-selection decision point |
| Architecture articles — Cluster 04 | 1 | ~10 min | Bridge to MI2 — where declared intent meets control-plane ownership |
| Total stage depth | 7 | ~88 min | Foundation stage — complete before entering MI2 Control Plane Boundaries |
>_ Where To Enter This Stage
Enter here if you’re evaluating whether to adopt declarative infrastructure practices at all — or if you’ve already adopted Terraform or OpenTofu syntax but suspect the underlying decisions are still imperative underneath it (Configuration-as-Code Theater). If you already know where your organization sits on the control-plane ownership debate — Terraform vs. GitOps vs. Kubernetes operators vs. platform APIs — skip to MI2.
Skip-ahead criteria: Architects who can already name where their organization sits on the Infrastructure Automation Ladder (#138), who can point to specific infrastructure that intentionally remains imperative and explain why, and who aren’t seeing Configuration-as-Code Theater symptoms in their own environment, may consider entering at MI2 — Control Plane Boundaries.
>_ Architecture Maturity Position
| Stage | Name | Maturity Level | Stage Question |
|---|---|---|---|
| MI1 ← YOU ARE HERE | Declarative Infrastructure | Foundation | When does infrastructure deserve to become code? |
| MI2 | Control Plane Boundaries | Operational | Who owns the control plane? |
| MI3 | State & Dependency Architecture | Operational | How does infrastructure become a platform product? |
| MI4 | Governance & Drift | Strategic | How is infrastructure governed? |
| MI5 | Economics of Automation | Strategic | How does infrastructure survive change? |
| MI6 | Infrastructure Survivability | Resilient | How is infrastructure continuously proven? |
>_ Stage Reading Sequence
DECLARATIVE INFRASTRUCTURE BEGINS HERE
The sequence below moves through four architectural questions in order. Cluster 01 establishes why declarative infrastructure matters — the automation ladder and the case for treating infrastructure as a software asset. The failure patterns grid sits immediately after, because it names what breaks when the doctrine in Cluster 01 is adopted as syntax without discipline. Cluster 02 is the antidote — restraint, and the mechanical vocabulary of what living in code actually looks like day to day. Cluster 03 covers adoption patterns beyond the cloud and the concrete tool-decision point. Cluster 04 closes the stage by bridging directly into MI2’s control-plane question.
Reading out of sequence is possible. The failure patterns grid gives the architectural reason to read Cluster 01 before the discipline, adoption, and bridge content that follows it.
Architectural question: Why does declarative infrastructure matter in the first place?
Why does declarative infrastructure matter in the first place?
The Infrastructure Automation Ladder names the six-level progression this whole stage is built around, and the CI/CD-for-infrastructure argument makes the core case for treating infrastructure as a software asset rather than an operational artifact.
>_ Common Configuration-as-Code Theater Failure States
Architectural question: How do disciplined practitioners avoid the theater?
How do disciplined practitioners avoid the theater?
Restraint first, mechanics second. One article argues for less code, not more; the other grounds the stage in the mechanical vocabulary of what living in code actually looks like on an ordinary Tuesday.
Architectural question: How does declarative practice extend past the cloud, and how do you choose a tool without choosing theater?
How does declarative practice extend past the cloud, and how do you choose a tool without choosing theater?
GitOps for Bare Metal tests whether the declarative model holds up on physical hardware. The Terraform vs. OpenTofu decision is where the qualifying test this stage teaches gets applied to an actual tool-adoption choice — cost, control, and licensing, not brand loyalty.
Architectural question: Once infrastructure is declared, who controls the system that interprets the declaration?
Once infrastructure is declared, who controls the system that interprets the declaration?
Closes the stage by reframing an OpenTofu adoption decision as what it actually is — not a license question, but the first concrete instance of MI2’s control-plane ownership question.
>_ Stage Graduates Can Now
Declarative Infrastructure (MI1) asks whether infrastructure decisions deserve to be captured as code — and names the failure state, Configuration-as-Code Theater, that occurs when the syntax is adopted without the underlying discipline. The capabilities below make that distinction operational, not just definitional. MI1 graduates can operate at Foundation maturity. What changes at MI2 is that the question of whether to declare infrastructure is settled — the question becomes who controls the system that interprets those declarations.
- Distinguish declarative infrastructure from infrastructure automation
- Identify when infrastructure should remain imperative
- Evaluate whether IaC adoption is solving an architectural problem or a tooling problem
- Recognize Configuration-as-Code Theater before it becomes operational debt
- Place infrastructure on the Infrastructure Automation Ladder (#138)
>_ Where Do You Go From Here
ARCHITECTURE REVIEW
Infrastructure Architecture Review
A structured review of where your infrastructure sits on the automation ladder, and whether your declarative adoption is capturing real intent or running Configuration-as-Code Theater.
[+] Request Assessment →WEEKLY DISPATCH
Weekly Dispatch
Architecture signals, framework updates, and new content from across the five pillars — delivered weekly for senior infrastructure architects.
[+] Subscribe →>_ Frequently Asked Questions
Q1: What’s the difference between imperative and declarative infrastructure?
A: Imperative infrastructure is defined by the sequence of steps used to build it — a script that runs commands in order. Declarative infrastructure is defined by the desired end state — a specification that a reconciliation system interprets and enforces, regardless of the current state it starts from. The distinction matters because imperative automation can be fast and still leave no durable record of intent, while declarative infrastructure captures that intent as a versioned artifact — provided the organization actually treats it as one rather than as syntax wrapped around imperative habits.
Q2: What is the Infrastructure Automation Ladder (Framework #138)?
A: A six-level progression model describing the maturity states infrastructure automation moves through: Level 0 Manual Infrastructure → Level 1 Scripted Operations → Level 2 Declarative Provisioning → Level 3 Policy-Driven Infrastructure → Level 4 Platform Automation → Level 5 Autonomous Infrastructure Governance. Most organizations stall between Level 2 and Level 3, because declarative tooling gets adopted without the governance architecture required to enforce intent at scale — the exact condition this stage names as Configuration-as-Code Theater.
Q3: What is Configuration-as-Code Theater?
A: The named failure state for this stage — declarative syntax has been adopted, but infrastructure decisions remain imperative, undocumented, and manually governed. Terraform or OpenTofu manifests exist. Changes still land through the console outside the pipeline. Modules are copy-pasted per environment instead of parameterized. Nobody can explain why a resource is configured the way it is. The code looks declarative. The organization’s thinking still isn’t.
Q4: When should infrastructure NOT become code?
A: When the cost of maintaining a declarative specification — module design, state management, review gates, drift detection — exceeds the volatility and blast-radius risk of the infrastructure it governs. One-off, low-change, low-consequence resources often don’t clear that bar. Forcing declarative treatment onto them adds governance overhead without adding governance value — which is its own quiet path into Configuration-as-Code Theater, just with better intentions.
Q5: Is GitOps the same as declarative infrastructure?
A: No. Declarative infrastructure describes what the desired state is. GitOps describes how that state gets reconciled — using Git as the source of truth and an automated control loop to converge production toward it. You can have declarative infrastructure without GitOps (declarative manifests applied manually or via CI without a reconciliation loop), and the reverse pairing is rare but conceptually possible. MI2 — Control Plane Boundaries — is where the ownership question underneath GitOps, Terraform, and Kubernetes operators actually gets resolved.
Q6: When should you skip ahead to MI2?
A: When you can already name where your infrastructure sits on the Infrastructure Automation Ladder, point to specific infrastructure you’ve deliberately kept imperative and explain why, and aren’t seeing Configuration-as-Code Theater symptoms — ClickOps drift, copy-pasted modules, undocumented intent — in your own environment. If any of those is untested or unclear, complete this stage first. MI2 assumes the declarative/imperative qualifying test this stage teaches has already been applied.
>_ Related Systems
The Infrastructure Automation Ladder — anchor article for Cluster 01; introduces Framework #138’s six-level model and the Level 2 stall this stage exists to prevent.
Open Post →Infrastructure as a Software Asset — the core CI/CD-for-infrastructure thesis this stage’s doctrine is built on.
Open Post →MI2 — Control Plane Boundaries. The next stage — which system owns the change once infrastructure is declared.
Open Stage →CS3 — Economic Architecture. Cross-domain: the economic-gravity question (#131) that governs when automation stops paying for itself.
Open Stage →D1 — Recovery Architecture Foundations. Cross-domain: recoverability and reproducibility are among the strongest architectural arguments for declaring infrastructure as code.
Open Stage →HashiCorp — Infrastructure as Code documentation. Vendor-neutral primer on declarative provisioning concepts underlying Terraform and OpenTofu alike.
Open Reference →CNCF — GitOps Principles. Foundational reference for the reconciliation-loop model underlying Cluster 03 and Cluster 04’s control-plane bridge.
Open Reference →