Terraform as Multi-Vendor Trust Substrate

Week 2 reach-back synthesis of Vertex, IAM, Admission, and Bedrock-Audit.

§ IFrame

Friday is reach-back day. The week's four cert lessons covered four vendor surfaces: Google's Vertex AI (Monday), AWS's IAM + Secrets Manager + KMS (Tuesday), Kubernetes admission control and the External Secrets Operator (Wednesday), and the AWS Bedrock + GitHub Copilot agent-audit surfaces (Thursday). Each was studied in its native vendor idiom. Today's lesson takes the four and shows them as one operator competence — provisioned, audited, and reconciled through Terraform.

Terraform's pedagogical role is not a fifth vendor. It is the connective tissue that turns four-vendor knowledge into one-stack execution. The Terraform Professional exam is the credential layer that codifies this competence — testing module composition, workspace strategy, state management, drift detection, policy-as-code (Sentinel and OPA), and the operational patterns for running Terraform at multi-vendor scale.

§ IIWeek in Review

§ IIITerraform as Connective Tissue

§ III.A — One Repository, Many Providers

A multi-vendor Terraform repository for the Week 2 stack carries four providers in its versions.tf:

terraform {
  required_version = ">= 1.7"
  required_providers {
    google     = { source = "hashicorp/google",     version = "~> 6.0"  }
    aws        = { source = "hashicorp/aws",        version = "~> 5.0"  }
    kubernetes = { source = "hashicorp/kubernetes", version = "~> 2.30" }
    github     = { source = "integrations/github",  version = "~> 6.0"  }
  }
}

The state backend lives in a fifth vendor (typically AWS S3 with DynamoDB locking) regardless of which provider the resource belongs to. The state file is the single shared mutable artifact the operator protects with KMS encryption at rest, IAM-gated read/write, and an immutable bucket policy that prevents object-version deletion.

The Terraform Professional exam tests two patterns here: the workspace-per-environment pattern (dev / staging / prod each own a separate state) and the root-module-per-domain pattern (split into gcp-vertex/, aws-trust/, k8s-admission/, github-audit/ each with its own state, joined by remote-state references when one needs another's output).

§ III.B — Modules as Vendor Compression

A module is Terraform's pedagogical unit. A well-authored module compresses an entire vendor sub-concept into one composable resource the consumer instantiates with a small variable set.

For Monday's Vertex stack, a vertex-bindings module accepts project ID + service-account email + model resources. It emits the 14 IAM bindings the GenAI Engineer + ML Pro tracks combined name. Consumer writes 10 lines; module emits 90 resources.

For Tuesday's AWS Trust stack, a rotation-lambda module accepts secret ARN + rotation function ARN + schedule. It emits the IAM role, the KMS grant, the Secrets Manager configuration, and the CloudWatch alarm. Consumer writes 6 lines; module emits 45 resources.

For Wednesday's K8s Admission stack, an admission-baseline module accepts the namespace label set. It emits the namespace labels, the ValidatingAdmissionPolicy resources, the External Secrets Operator namespace and CRDs, and the KMS-backed Secrets Encryption Configuration. Consumer writes 5 lines; module emits the 8 CKS-policy baseline.

For Thursday's Agent Audit stack, an agent-audit-streaming module accepts the GitHub org + S3 bucket + KMS key. It emits the GitHub audit-log streaming configuration, the S3 bucket policy, the KMS key policy, and the CloudWatch metric filter for Bedrock trace volume. Consumer writes 4 lines; module emits 20 resources.

§ III.C — Policy-as-Code Across the Four Stacks

Terraform Professional tests Sentinel and OPA-via-conftest. Both express the same Terraform plan must satisfy this policy before apply. Four policies the operator writes once and applies to every plan:

1. Every IAM binding must reference a service account, not a user account.
2. Every KMS key used by the four stacks must have key rotation enabled and a minimum 365-day deletion window.
3. Every secret managed in Secrets Manager must have a rotation schedule attached.
4. Every K8s namespace must carry the Pod Security Standard label restricting it to restricted or baseline.

The four policies live in one file. The CI pipeline runs terraform plan, exports the plan as JSON, and runs the policy engine against the JSON. The pipeline gates the apply step on the policy result. This is the single discipline the Terraform Professional exam expects the candidate to be able to describe and implement.

§ III.D — Drift Detection and Reconciliation

The Terraform state is what the operator believes the world looks like. The world is what the providers report. Drift is the difference. The Week 2 stack drifts four ways: Vertex model versions land underneath the state when a training pipeline ships; AWS Secrets Manager rotates secrets such that version_stage drifts from initial provisioning; K8s admission policies can be mutated through the cluster API outside Terraform; GitHub repository settings drift when org admins make UI changes. Each has its own discipline — Terraform must own the configuration; the runtime state may have its own legitimate sources of truth; the operator's job is to declare the boundary.

§ IVWorked Example — One Terraform Apply That Lands a Vertex-Triggered Bedrock Pipeline With End-to-End Audit

A concrete cross-vendor worked example. The pipeline: a Vertex AI model emits predictions to a Cloud Storage bucket; a Cloud Function calls an AWS API Gateway endpoint; the endpoint invokes a Bedrock Agent that takes an action on a GitHub repository through a Copilot Workflow; every step emits to the audit streaming pipeline.

The Terraform repository has four root modules: gcp-vertex/, aws-trust/, k8s-admission/, github-audit/. The cross-vendor wiring lives in remote state references — aws-trust/ reads gcp-vertex/'s Cloud Function outbound IP range; github-audit/ reads aws-trust/'s S3 bucket ARN; k8s-admission/ reads aws-trust/'s KMS key.

The single apply that lands the pipeline runs through four terraform apply calls in dependency order, each gated by the four policy-as-code gates from §III.C, each emitting its own audit log entry through the Terraform Cloud run log. The full set of operator changes is recoverable from four state files plus four run logs.

When the pipeline produces a production incident, the operator's investigation path is Thursday's three-log integration: GitHub Audit Log → workflow_run_id → Bedrock trace → operator's KMS-signed log of the Lambda forward. The Terraform state confirms what should exist; the audit streams reconstruct what did happen. The IaC layer and the audit layer are complementary, not redundant.

§ VPractice Questions

§ VIClosing

Friday's lesson is the operator's compression layer. Four vendor surfaces became one Terraform-provisioned stack with four modules, four policy gates, four drift disciplines, and one CI pipeline. The Terraform Professional candidate who understands this compression passes the exam's plan-policy-state-drift sections and answers the how would you deploy what you learned this week question with a repository diagram rather than a vendor checklist.

The week's four lessons gave the candidate vendor knowledge. Today's lesson gave the candidate the substrate that makes vendor knowledge composable. Both are necessary; neither is sufficient alone. The substrate is the operator's quiet superpower; the vendor knowledge is what makes the substrate worth using.