Infrastructure as Code: Desired State and Evidence

Enterprise problem: Ziba’s GKE environment can be recreated manually, but undocumented console choices and one-off commands make the next recovery slow, unauditable, and likely to produce different networking or memory capacity. Whole-course context: The previous cloud slice traced Ziba from Google Cloud networking to a running pod; today consumes that resource inventory and turns its important decisions into Infrastructure as Code (IaC), a delivery discipline for managing infrastructure through versioned machine-readable definitions. Today’s slice: We define the IaC loop—declare, review, execute, observe, and reconcile—without treating any one tool as the discipline itself. End-of-day evidence: A reviewer can connect a versioned change to an approved diff, immutable run, observed cloud and cluster effects, and a negative policy result. Still unsolved: Terraform’s state mechanics, Argo CD’s Kubernetes reconciliation, secrets implementation, and production approval remain separate slices.

Code alone does not make infrastructure reproducible, so Ziba needs a lifecycle that controls who can propose, approve, execute, and verify a change. These use cases cover normal evolution and recovery from drift.

IaC can automate mistakes faster unless the customer outcome and failure evidence are explicit. These stories make review, execution authority, and post-change measurement independently observable.

An infrastructure definition is inert until an authorised engine translates it into provider API calls, so the execution boundary must be visible. Both flows end with observed infrastructure and customer evidence rather than “pipeline passed.”

IaC is a discipline, not a single product: Terraform, OpenTofu, cloud-native deployment services, Pulumi, and configuration tools can implement portions of the loop with different state and execution models. Google describes IaC as defining cloud resources in human-readable files that can be versioned, reused, and shared; Terraform is one supported implementation, not the definition of IaC (Google Cloud IaC overview).

Desired state, execution metadata, and live provider state answer different questions, so none should silently overwrite the others. This ownership model preserves a reviewable chain from proposal to physical effect.

Generated-application database: Not created in this slice — durable Git revisions, approvals, execution records, provider resources, audit logs, and probes are sufficient for infrastructure delivery evidence.

Calling configuration “the source of truth” hides the fact that hardware and cloud APIs can diverge, so a complete loop needs both desired and observed state. Expand the smallest model into five independently reviewable stages.

Teams often frame declarative files and imperative commands as enemies, which obscures that a safe system uses both at different layers. Desired state describes the target; an engine still performs ordered imperative API operations, and diagnostics remain intentionally read-only commands.

environment: production
gke:
  region: europe-west2
  mode: standard
  node_pool:
    machine_type: e2-standard-4
    min_nodes: 1
    max_nodes: 4
policy:
  public_control_plane: false
  workload_identity: required

The example is a conceptual contract, not a Terraform schema. A Terraform module, Pulumi program, Google Cloud Infrastructure Manager deployment, or other reviewed engine could consume an equivalent intent. Tool choice changes syntax, state, providers, and operations; it does not remove the need for review, authority, evidence, drift decisions, and deletion ownership.

A diff that says “update in place” may still restart software or replace a VM, so review must map abstract declarations to actual effects. The same IaC discipline applies whether the executor targets GCP, AWS, an on-premises API, or Kubernetes.

Choosing a fashionable tool before naming the ownership and failure model creates avoidable lock-in. Select an implementation by the APIs it controls, how it represents state, how it previews change, and how the team operates failures.

IaC cannot be proven safely by reading code alone, so rehearse a bounded non-production change and its failure path. The following pseudocode expresses the workflow independently of a particular engine.

iac fmt --check
iac validate
iac policy-check --environment=staging
iac plan --out=change.plan
iac show change.plan
iac apply change.plan
iac observe --environment=staging
curl --fail --show-error "${ZIBA_STAGING_URL}/healthz"

Replace iac with the chosen implementation and its exact commands. Save the proposed diff before apply, bind approval to its checksum, reject changed inputs, and archive both provider observations and the customer probe.

After the chosen engine executes, these concrete read-only commands are runnable against the Ziba GKE environment and capture the provider, Kubernetes, and customer views independently:

gcloud container clusters describe ziba-prod \
  --region=europe-west2 \
  --format='json(name,location,currentMasterVersion,nodePools)'
kubectl get nodes -o custom-columns=NAME:.metadata.name,MEMORY:.status.allocatable.memory
kubectl -n blog get deployment ziba -o jsonpath='{.metadata.generation}{" "}{.status.observedGeneration}{"\n"}'
curl --fail --show-error "${ZIBA_URL}/healthz"

Infrastructure as Code is an operating discipline that connects versioned intent to controlled execution and falsifiable evidence. A configuration file or successful provider response covers only part of that loop.

• IaC is broader than Terraform; Terraform is one implementation with a particular language, provider, plan, and state model.
• Desired state, execution metadata, and live reality have separate owners.
• Declarative intent still causes imperative provider operations and physical allocation.
• Drift is a decision input: revert it, adopt it in reviewed intent, or explicitly defer it.
• Infrastructure success must be paired with Ziba’s customer-visible health.

An IaC change is complete only when its proposed and actual effects can be reconstructed. Use this checklist before granting any production executor authority.

• [ ] Versioned desired state contains no plaintext secrets and pins material dependencies
• [ ] Diff is generated from fresh live observations and the exact reviewed commit
• [ ] Policy and human approval are bound to immutable inputs
• [ ] Executor uses short-lived, least-privilege authority
• [ ] Evidence includes provider IDs, Kubernetes observations, customer probe, negative path, time, and run ID
• [ ] Drift, rollback, import/adoption, and retirement owners are documented