Detail page available

Infrastructure as code

Terraform plans that make infrastructure changes reviewable

Treat configuration, state, and apply approvals as a controlled workflow—automation still needs cloud judgment.

Terraform · Technology detail

Primary intent: Declarative infrastructure as code and environment reproducibility

DeclareConfig
ReviewPlan
RecordState
ChangeApply

Capability system

Desired state

Declarative infrastructure.

  • Plan review

    Diff before mutate.

  • Modules

    Shared landing-zone patterns.

  • Remote state

    Team-safe concurrency.

  • Policy as code

    Guardrails on plans.

  • Multi-cloud

    Provider-backed targets.

Illustrative flow

Plan-and-apply workflow

Stage 1 / 4

Write

Declare infrastructure as code.

Illustrative resource blockhcl
resource "aws_s3_bucket" "assets" {  bucket = var.assets_bucket_name  # tags and encryption omitted for brevity}

Illustrative HCL — not a live cloud resource.

Plan, State and Drift Workflow

Choose new environment, controlled change, or drift review scenarios.

Choose new environment, controlled change, or drift review scenarios.

Static view: configuration, plan, review, state, apply, cloud resources, and drift detection form the workflow.

Controlled change

Modify existing infrastructure with review.

  1. Config diff
  2. Plan
  3. Approval
  4. Apply
  5. Verify

Responsibilities

  • Blast-radius notes
  • Rollback idea
  • Change window

Tradeoff: Applying unreviewed plans invites surprises.

Controlled change layer flowConfig diffPlanApprovalApplyVerify

Problems this stack addresses

Terraform provisions and updates infrastructure declaratively. It is not GitHub Actions CI, not a cloud provider, and not Kubernetes manifests. It does not eliminate cloud expertise or make all drift safe to auto-fix.

  • Reproducible environments across stages
  • Reviewable infrastructure changes
  • Reduced configuration drift through intentional workflows

What we build with Terraform

Illustrative delivery shapes—not a guaranteed catalog.

  • Environment modules

    Reusable modules with clear input contracts.

  • Remote state backends

    Locked state with access controls.

  • Change pipelines

    Plan-in-PR, apply-with-approval patterns.

Architecture and deployment model

Platform role

  • Declarative provisioning across cloud providers
  • Change control companion to CI/CD
  • Not a substitute for cloud platform design skill

Architecture layers

  • Configuration and modules
  • Providers and resources
  • State and locking
  • Plan/apply and drift detection

Plan, state and drift workflow

Configuration → plan → review → state → apply → cloud resources → drift detection.

State honesty

Corrupted or shared state without locking creates dangerous applies.

CI relationship

GitHub Actions can run plan/apply; Terraform remains the IaC engine and state owner.

Security and shared responsibility

Shared responsibility

  • State may contain sensitive attributes—protect it
  • Provider credentials least-privilege
  • Module sources reviewed like dependencies

Identity and access

  • Separate plan and apply identities when useful
  • Human break-glass documented
  • No long-lived keys in repositories

Networking

  • Provision network resources intentionally
  • Avoid accidental public exposure in modules
  • Document peering and DNS ownership

Reliability, scaling and operations

Observability

  • Track apply history and authors
  • Alert on failed applies
  • Correlate infra changes with incidents

Reliability / recovery

  • State backup/versioning strategy
  • Rollback is not always trivial—design escape hatches
  • Drift review before blind applies

Scaling

  • Large states slow plans—modularize
  • Workspace/environment strategy prevents collisions
  • Parallelism tuned carefully

Delivery, automation and cost governance

Delivery workflow

  • PR plan → review → merge → apply
  • Environment promotion via workspaces or separate states
  • Manual approval for production applies

Automation / IaC

  • This page is the IaC authority among EXP-B3 tools
  • Still requires cloud provider expertise
  • Not all drift should be auto-applied

Cost / governance

  • Plans reveal costly resources before apply
  • Tagging enforced in modules
  • No automatic cost-optimization guarantee

Integration patterns

  • AWS / Azure / Google Cloud providers
  • GitHub Actions plan/apply
  • Kubernetes cluster provisioning
  • Docker registries as resources

When to choose / when not to choose

Choose when

  • You need reproducible multi-environment infrastructure
  • Changes must be reviewable before apply
  • Multiple clouds or many resources benefit from modules

Reconsider when

  • A single click-ops resource with no repeat need
  • Team cannot protect state backends
  • Another org-standard IaC tool is mandated

Tradeoffs

  • Declarative clarity vs state management burden
  • Module reuse vs abstraction opacity
  • Automation speed vs review quality

Migration / modernization notes

  • Import existing resources carefully with state reviews
  • Do not rewrite all cloud console history in one apply
  • Establish tagging and naming before mass adoption

Proof and capability boundary

Capability-level IaC guidance. No claim Terraform removes cloud expertise or safely auto-resolves all drift.

No claim IaC removes expertise; no safe auto-fix-all-drift promise.

Does Terraform eliminate the need for cloud expertise?

No. Providers encode APIs, but sound architecture, IAM, networking, and cost judgment remain human responsibilities.

Can all drift be auto-fixed safely?

No. Some drift is emergency hotfix. Triage before apply; blind auto-remediation can be harmful.

Discuss Terraform workflows

Share providers and environments—we will outline module and state/change-control practices.

Begin stack consultation