Terraform as Multi-Region, Multi-Vendor Provisioning Foundation

Week 4 reach-back synthesis of Vertex training pipelines, AWS edge resilience, Kubernetes network policy, and Bedrock knowledge bases.

§ IFrame

Week 3's Friday lesson tied four vendors together through the question of observing and enforcing: measure what the workload does, refuse what the operator forbade. Week 4 asks the question that comes after the workload is observed and guarded. The workload has to reach — across regions, across a continuous schedule, across a knowledge corpus, and across a segmented network — and the reach has to be the same on Monday as it was the Friday it was reviewed. This week's four cert lessons are four instances of reach at scale, and Terraform is the single tool that declares the whole reach as code and proves each morning that it still stands.

The theme reads the same on every vendor this week. Monday's Vertex lesson made training continuous, a pipeline that retrains and re-promotes on a schedule rather than once. Tuesday's AWS lesson made serving multi-region, a topology that survives a region's loss. Wednesday's Kubernetes lesson made the network default-deny, a segmentation that grows only by explicit allow. Thursday's agentic lesson made an agent's answers grounded, a retrieval pipeline that pulls from an enterprise knowledge base before the model speaks. Continuous, multi-region, segmented, grounded. Four kinds of reach, and every one of them a piece of configuration that a console makes fragile and Terraform makes durable.

§ IIWeek in Review

Monday's lesson studied Vertex AI continuous training across the Google GenAI Engineer and Pro ML Engineer tracks. The core was the training pipeline as a scheduled, versioned resource: a pipeline that ingests fresh data, trains a candidate, evaluates it against the incumbent, and promotes it through the model registry only if it clears a gate. Drift on the deployed model is the trigger; the registry is the record of what was promoted and when. None of the schedule, the gate threshold, the registry, or the trigger is model code. All four are configuration, and configuration that drifts in a console is a retraining job no one can prove still runs.

Tuesday's lesson studied AWS edge networking and multi-region resilience across the Solutions Architect Professional and DevOps Professional tracks. Route 53 health checks and failover routing moved traffic away from a sick region; CloudFront put content at the edge; Global Accelerator gave the application a stable anycast front door. The SAP flavor owned the topology choice — active-active versus active-passive, the recovery-time and recovery-point targets that decide it. The DOP flavor owned the failover automation — the health check, the alarm, the routing change that fires without a human. Each of the three is a configured resource: a hosted zone and record set, a distribution, an accelerator and its listener. The reach across regions is configuration.

Wednesday's lesson studied Kubernetes network policy across CKA and CKS. The default-deny posture starts from a policy that denies all ingress to a namespace, then grows the reachable surface one explicit allow at a time. CKA owned the pod-networking mechanics — how a policy selects pods, how ingress and egress rules read. CKS owned the security posture — default-deny as the starting point, layer-7 limits, identity-aware enforcement through a CNI like Cilium. The policy is a Kubernetes resource, which is to say configuration, and a segmentation that someone loosened by hand during an incident is exactly the silent regression segmentation exists to prevent.

Thursday's lesson studied grounding agents in enterprise knowledge across AWS AIP-C01 and GitHub GH-600. Amazon Bedrock Knowledge Bases ingested a corpus, embedded it, and stored the vectors; the RAG pipeline retrieved the relevant chunks at query time and handed them to the model so the answer was grounded in the corpus rather than in the model's parametric memory. GitHub Copilot context did the same for coding agents, grounding completions in the repository. The knowledge base, its data source, its embedding model, its vector store, and its retrieval configuration are all configured resources. The grounding is configuration.

Four lessons, twelve-plus surfaces, one fact repeated: the reach a workload needs is configuration, not code. Configuration in a console is configuration no one can review, diff, or recreate after an accident. Configuration in Terraform is reviewed in a pull request, diffed against the prior state, and recreated by a single apply. This week the difference is sharpest because reach spans regions and vendors at once.

§ IIITerraform as the Connective Tissue

Terraform's model has three moves that make it the right tool for multi-region, multi-vendor reach. The first is provider aliasing. The second is the module as a unit of reusable topology. The third is the remote state backend with locking. Each maps onto a discipline this week's four lessons named, and each is Professional-exam material.

Provider aliasing is the reach across regions and accounts. A single aws provider configuration is pinned to one region, but Tuesday's multi-region topology needs resources in two or three regions at once. Terraform answers with the provider alias: declare the aws provider once per region, give each an alias, and pass the chosen alias into each resource or module. The Route 53 hosted zone is global, but the regional load balancers it fails between live in distinct regional providers, and aliasing is how one configuration declares both. The same move spans vendors: google declares the Vertex pipeline, aws declares the edge and the knowledge base, kubernetes declares the network policy, and one configuration holds all of them in one dependency-ordered run.

The module is the reach across repetition. A multi-region topology is the same regional stack instantiated once per region, and Brikman's treatment of production-grade Terraform code makes the module the unit that keeps that repetition honest: a module declares a regional stack once, and each region is a module instance with its region-specific inputs (Terraform: Up and Running, 3rd ed., Ch 8, pp 428-429). The Professional discipline is to version those modules through a source reference so a fix to the regional stack rolls out region by region as a reviewed version bump rather than as three hand-edits that drift apart.

Remote state with locking is the reach across time and across the team. Brikman's state chapters make the remote backend the precondition for any infrastructure more than one engineer touches: the state lives in shared, locked storage so concurrent applies serialize rather than corrupt each other (index pp 659-660). For a multi-region, multi-vendor stack the state is the record of what reach was provisioned where, and a corrupted state leaves the actual topology ambiguous at exactly the moment a region failover needs it certain.

§ IVWorked Example — One Configuration That Provisions the Week

Consider a single Terraform configuration that stands up a slice of each of the week's four surfaces for one production service. The service is a model-backed agent that answers from an enterprise corpus: it retrains on a schedule, serves from two regions, runs on a segmented Kubernetes cluster, and grounds its answers in a knowledge base. Each of the week's four lessons provisions one face of its reach.

The configuration opens by declaring its providers and their aliases. The google provider is pinned to a project and region. The aws provider is declared twice with aliases aws.us_east and aws.us_west, one per serving region. The kubernetes provider points at the cluster. The Terraform block pins each provider to a version range and configures a remote backend with state locking. Version pinning and the locked remote backend are both Professional-level exam material and both the difference between a reproducible apply and a surprise.

The Vertex face comes first. A google_vertex_ai_pipeline_job driven by a scheduler resource declares the continuous training pipeline: its schedule, the data source it ingests, the evaluation gate it must clear, and the model-registry destination it promotes into. This is Monday's lesson as HCL: the retraining job that runs on a cadence, declared once and recreatable by apply, with the promotion gate's threshold visible in configuration rather than buried in a console form.

The AWS multi-region edge face comes next. A aws_route53_health_check and a aws_route53_record with a failover routing policy declare the DNS failover between the two regional providers. A aws_cloudfront_distribution puts the service at the edge, and a aws_globalaccelerator_accelerator gives it a stable anycast front door. The regional load balancers behind the failover record are declared once in a region module instantiated under each provider alias. This is Tuesday's lesson as resources spanning two regional providers.

The Kubernetes segmentation face comes third. A kubernetes_network_policy resource declares the default-deny baseline for the service's namespace, and a second policy declares the one explicit allow the service needs, ingress from the gateway namespace on the service port. This is Wednesday's lesson: the default-deny posture and the single reviewed exception, declared as the two policy resources the CNI enforces. The exception is visible in the configuration, so the reviewable question — what is allowed to reach this service — has a reviewable answer in the pull request.

The Bedrock knowledge-base face comes last. A aws_bedrockagent_knowledge_base resource declares the embedding model and the vector store, a aws_bedrockagent_data_source declares the corpus location, and the agent's configuration references the knowledge base by its identifier. This is Thursday's lesson: the grounding pipeline that retrieves from the corpus before the model speaks, declared as resources rather than clicked into a console.

The four faces apply in one terraform apply. The operator runs one command and the agent gets a retraining pipeline, a two-region failover topology, a default-deny network with one reviewed allow, and a grounded knowledge base. More to the point, the operator runs terraform plan the next morning and sees, in one diff, whether any of the four drifted overnight: a paused retraining schedule, a deleted health check, a loosened network policy, a knowledge base pointed at the wrong corpus. Each shows as a line in the plan, and the apply that follows restores the reviewed reach.

§ VPractice Scenarios

The first scenario tests provider aliasing. A team needs the same regional serving stack in us-east-1 and us-west-2, fronted by one Route 53 failover record. The exam point: how one configuration declares resources in two regions. The answer is two aliased aws provider configurations and a region module instantiated twice, once per alias, with the failover record in the global hosted zone referencing both regional load balancers.

The second scenario tests module versioning. A fix to the regional stack must reach three regions without three divergent edits. The answer is to bump the region module's version, correct the value in the module source, and let each region instance adopt the new version through its pinned source reference, so the rollout is a reviewed version bump per region rather than three hand-edits with no audit trail.

The third scenario tests state hygiene under a failover. A region fails at 3 a.m., an on-call engineer applies a traffic shift, and a second engineer applies a conflicting change a minute later. The answer is the remote backend's state lock: the second apply blocks on the lock the first holds, so neither overwrites the other's state, and the topology the failover depends on stays certain.

The fourth scenario tests the default-deny seam. A new service needs to reach the grounded agent, and a developer's first instinct is to widen the agent's network policy. The answer is a new explicit-allow rule in the agent namespace's kubernetes_network_policy, declared in Terraform and reviewed in a pull request, so the reachable surface grows by one reviewed line rather than by a console edit no one sees.

The fifth scenario ties the week to today's Ops lesson. The trading book's attribution pass retires a strategy and frees its capital; the strategy's serving infrastructure should be torn down with it. The answer is that the strategy's infrastructure is a module instance keyed by the strategy name, and retiring the strategy removes the instance from the configuration, so the next apply tears down exactly that strategy's endpoint, monitoring, and compute and leaves every other strategy's reach untouched. The retirement gate decides; the apply executes.

§ VIPractice Questions

§ VIIClosing

The week studied four vendors and found one kind of work: reach, provisioned. Vertex reaches across time with a continuous pipeline; AWS reaches across regions with a failover topology; Kubernetes reaches by explicit allow from a default-deny floor; Bedrock reaches into a corpus to ground an answer. Four kinds of reach, every one of them configuration, and Terraform is where that configuration lives as reviewed, versioned, drift-checked declaration across every region and vendor it touches.

Reach clicked into a console is reach no one can prove is still there. Reach declared in Terraform is reach whose absence is a line in tomorrow's plan. Provision the reach as code, plan it on a schedule, and read the diff. The diff is the week's reach reporting for duty.

Examine well. Reflect on this.