Most GCP environments I inherit have the same infrastructure problem — not that Terraform isn’t being used, but that it was never structured. A flat directory of .tf files, a single state bucket, no module boundaries, no CI/CD enforcement, and a growing list of resources that were clicked into existence in the console and never imported. The platform works, but it can’t be reviewed, it can’t be reproduced, and it can’t be trusted.
Fixing that is one of the most high-leverage things I do in an enterprise engagement. A well-structured IaC foundation changes how fast a team can move, how confidently they can change things, and how cleanly they pass security audits.
Getting to Terraform is the easy part. Most teams are already there. The harder problem is building an IaC architecture that holds up as the platform grows — one where adding a new service doesn’t require understanding the entire state, where a CI pipeline enforces policy before anything touches production, and where a new engineer can onboard without breaking something.
The difference between IaC that works and IaC that scales is structure. Module boundaries, state segmentation, pipeline design, and policy scanning are the decisions that determine whether your Terraform is an asset or a liability three years from now.
This is the foundation I build. It follows the SCALE Framework — specifically the Automation/IaC pillar — and integrates with the Security by Design and Lifecycle Ops dimensions that make the platform maintainable over time.
Module architecture. Every reusable pattern gets a module — GKE cluster, VPC, IAM binding sets, GCS buckets with standard controls, Cloud Run services. Modules are versioned and referenced by version tag, not by local path. This means changes to a module are deliberate and reviewable, not implicit.
State segmentation. I split state by lifecycle and blast radius — org-level resources (folders, org policies, billing) in their own state, network hub in its own state, per-environment workload state separate from platform state. A change to a workload Terraform run cannot accidentally touch the network layer. This also aligns with least-privilege — each pipeline service account only has permissions over its own state and resource scope.
Remote state in GCS. State is stored in GCS with versioning enabled, uniform bucket-level access, and CMEK encryption via Cloud KMS. State locking prevents concurrent apply conflicts.
CI/CD pipeline integration. Every Terraform change goes through a pipeline — fmt and validate on PR open, plan output posted as a PR comment for review, apply only on merge to main, and only via a dedicated CI service account with scoped permissions. I use GitHub Actions with Workload Identity Federation to eliminate static service account keys in the pipeline entirely. Full detail on the WIF approach at Workload Identity Federation Migration.
Policy scanning with Checkov. IaC policy scanning runs in the pipeline before plan. Checkov catches misconfigured GCS buckets, overpermissioned IAM bindings, missing encryption settings, and other findings before they reach a production environment. This is the IaC layer of the DevSecOps pipeline — security controls enforced at the point of change, not discovered in a post-deployment audit.
No console click-ops in production. This is a hard rule I establish in every engagement. Any resource created outside of Terraform is an audit finding and a drift risk. Where resources were previously provisioned manually, I import them into state and bring them under IaC control as part of the engagement.
A well-structured Terraform foundation is what makes everything downstream reliable. The GCP Landing Zone Blueprint is fully Terraform-managed — org hierarchy, network topology, IAM boundaries, and org policy constraints all in version control from day one. The GCP Platform Migration Playbook treats IaC build-out as a Phase 2 prerequisite before any workload migration begins. GKE clusters are provisioned via Terraform with node pool configuration, security settings, and Workload Identity all managed as code — not configured post-deployment.
When your infrastructure is fully described in version-controlled Terraform, you get reproducible environments, clean DR runbooks, audit-ready change history, and an onboarding experience for new engineers that doesn’t require tribal knowledge.
I work directly with your engineering or platform team to design and deliver the Terraform architecture — module structure, state design, CI/CD pipeline, and policy scanning — and leave your team with a foundation they can operate and extend independently.
Engagements run as a scoped project or as part of a broader platform build. For teams that want ongoing architectural oversight as the platform evolves, I also work fractionally — part-time Principal Architect embedded into your team.
No account managers, no juniors, no handoffs. More about my background and approach →
