10.3 Infrastructure as Code: Terraform, Config Connector, Cloud Foundation Toolkit & Helm

Why This Matters on the ACE Exam

The exam guide's Domain 3 closes with a short but sharply-defined bullet: "infrastructure as code tooling (e.g., Cloud Foundation Toolkit, Config Connector, Terraform, Helm)." Unlike most ACE content, which tests doing a task in the Console or with gcloud, this sub-topic tests recognition — can you correctly identify which of these four named tools solves a given infrastructure-as-code problem, and how they relate to each other. Confusing the four with each other (or with Cloud Deployment Manager, which is not in this official bullet) is the most common way candidates lose points here.

The Four Named Tools

Terraform is an open-source, cloud-agnostic declarative infrastructure-as-code tool built by HashiCorp. You write infrastructure definitions in HashiCorp Configuration Language (HCL), and Terraform maintains a state file that tracks what it believes exists in the real world. The core workflow is three commands:

terraform init    # download providers (google, google-beta), initialize backend
terraform plan     # show what would change
terraform apply     # create/update/destroy resources to match the config

Terraform is not GCP-specific — the same tool provisions AWS, Azure, and on-premises resources through different provider plugins — which is exactly why it is listed separately from the next tool.

Cloud Foundation Toolkit (CFT) is not a different engine from Terraform — it is Google's own curated library of reusable, opinionated Terraform modules (with some legacy Cloud Deployment Manager templates) that encode Google-recommended patterns: a project-factory module that stamps out new projects with standard IAM bindings and APIs already enabled, a network module that builds a Shared VPC the "right" way, an IAM module, and more. Think of CFT as "pre-built, Google-reviewed Terraform building blocks," not a separate product installed instead of Terraform. A scenario that says "quickly stand up a new project following Google's recommended landing-zone pattern" points to CFT modules; one that says "we need custom, from-scratch infrastructure logic" points to raw Terraform.

Config Connector (Kubernetes Config Connector, or KCC) takes a fundamentally different approach: it is a GKE add-on that lets you manage Google Cloud resources — a Cloud SQL instance, a Cloud Storage bucket, a Pub/Sub topic, even an IAM policy — as native Kubernetes Custom Resources, applied with plain kubectl apply -f against YAML manifests. A controller running in the cluster continuously reconciles the live GCP resource against the desired-state YAML, correcting drift automatically and on an ongoing basis. This is the key architectural distinction from Terraform: Terraform's reconciliation is a point-in-time action (drift is only corrected the next time someone runs terraform apply), while Config Connector's controller watches and corrects continuously, the same way Kubernetes reconciles a Deployment's replica count. Config Connector is the natural choice for a team that already runs GitOps against a Kubernetes cluster and wants their cloud infrastructure reviewed and managed by the same pipeline and the same kubectl-based tooling as their application manifests.

Helm is the package manager for Kubernetes — conceptually closer to apt or npm than to Terraform or Config Connector. A Helm chart bundles a set of Kubernetes manifests (Deployments, Services, ConfigMaps) together with a values.yaml file of overridable parameters, so the same chart can deploy a "small" version of an app to a dev cluster and a "large, highly-available" version to production by swapping values, not manifests. Helm's job is templating and versioning application deployments onto a cluster that already exists — it does not provision the GCP infrastructure (the VPC, the GKE cluster itself, the IAM roles) around that cluster. That job belongs to Terraform/CFT or Config Connector. The core commands are helm install, helm upgrade, and helm rollback (to a previous release revision).

Comparison Table

Exam Scenario

A platform team already runs a GitOps pipeline where every change to their GKE cluster's applications flows through pull requests merged into a Git repo, applied by an in-cluster controller. They now want a new Cloud SQL database and a new Pub/Sub topic to be requested and reviewed the exact same way, using the same kubectl-style YAML review process — not a separate Terraform repository. The answer is Config Connector: it lets the Cloud SQL instance and Pub/Sub topic be defined as Kubernetes-native YAML resources, reviewed in the same pull requests, and reconciled by the same in-cluster tooling the team already trusts. A second team that needs to roll out 30 nearly-identical new projects, each with the same IAM bindings, enabled APIs, and Shared VPC attachment, is a Cloud Foundation Toolkit scenario — reusing Google's project-factory Terraform module instead of writing that logic from scratch. A third team deploying the same microservice to five environments with different replica counts and resource limits per environment is a Helm scenario — one chart, five values.yaml overrides.

Key Takeaways

• All four tools named on the exam guide — Cloud Foundation Toolkit, Config Connector, Terraform, Helm — are infrastructure-as-code tooling, but each solves a different layer of the problem.
• Cloud Foundation Toolkit is a library of Google-curated Terraform modules, not a separate engine from Terraform.
• Config Connector manages GCP resources as Kubernetes CRDs with continuous, controller-based drift reconciliation — unlike Terraform's point-in-time apply model.
• Helm packages and versions Kubernetes application manifests inside an existing cluster; it does not provision the surrounding GCP infrastructure.
• A scenario describing GitOps/kubectl-driven infrastructure review points to Config Connector; a scenario describing a repeatable multi-project landing zone points to Terraform plus Cloud Foundation Toolkit; a scenario about templated app releases across environments points to Helm.