Implementing resources through infrastructure as code

Study guide for Associate Cloud Engineer, Unit 3 · Topic 6. This is the topic's lecture in reading form — every slide's teaching, figures and worked examples, in order — followed by the official Google Cloud pages its claims rest on.

What the exam guide asks, quoted. Implementing resources through infrastructure as code. Considerations include:

1. Infrastructure as code tooling (e.g., Cloud Foundation Toolkit, Config Connector, Terraform, Helm)

Implementing resources through infrastructure as code

Four tools, one workflow, one state file

Which tool fits — Terraform, blueprints and modules, Config Connector, or Helm. How the Terraform workflow runs — init, plan, apply. What the state file remembers — and where a team must keep it.

This is the last deploying topic of Unit 3 and the only one with a single objective: infrastructure as code tooling, with four examples named — Cloud Foundation Toolkit, Config Connector, Terraform and Helm. The exam asks three kinds of question about it. Which tool fits a situation, because the four do different jobs and two of them only make sense if you already run Kubernetes. How the Terraform workflow runs, because each command does one thing and the distractors swap them. And what Terraform's state file is for, because the most common real-world failure in this topic is a team keeping it in the wrong place. We take the idea first, then each tool, then the workflow and its state.

Infrastructure as code: configuration you can version

Declare the end state in files; let the tool make it true

• Code instead of consoles or command-line scripts
• Declare the desired state, not the steps to reach it
• Version, reuse and share it like application code
• Google's default choice: the Terraform provider for Google Cloud

Worked example (synthetic). A team rebuilds its test environment by hand each quarter and it never matches production. Written as one configuration and applied twice, both environments come from the same files — and a change to either is a reviewed commit.

Start with the idea the tools share. Google defines infrastructure as code (IaC) as the process of provisioning and managing software application infrastructure using code instead of graphical user interfaces or command-line scripts. Two consequences follow. First, it is declarative: infrastructure as code lets you specify the desired state of your infrastructure, and the tool works out what to create, change or remove. Second, it is software: you can define resource configurations that you can version, reuse and share, and Google says it lets you treat infrastructure provisioning in the same manner as you handle application code — which is why it calls managing production environments through change-controlled processes using infrastructure as code a best practice. When the exam asks which tool, start from Google's default: in general, to configure and manage Google Cloud infrastructure using code, use the Terraform provider for Google Cloud. The other three named tools each answer a narrower need, and the next slide places them.

The four named tools, and what each is for

Two manage Google Cloud resources; one packages Kubernetes apps

Worked example (synthetic). Asked to "create a Cloud SQL instance from the same Git repository as our Kubernetes manifests", the graded answer is Config Connector — Helm would deploy the app, not the database.

Here the four tools stop being a list. Terraform is Google's general answer: the most commonly used tool to provision and automate Google Cloud infrastructure, with an execution plan and a state file. The guide's Cloud Foundation Toolkit needs a word of explanation. Its old address now redirects to Google's page on Terraform blueprints and modules, and that page is where the idea lives today: a module is a reusable set of Terraform configuration files that creates a logical abstraction of Terraform resources, and a blueprint is a package of deployable, reusable modules and policy that implements and documents a specific opinionated solution. So when the exam says Cloud Foundation Toolkit, think ready-made Terraform. Config Connector is for teams that live in Kubernetes: Google describes it as an open source Kubernetes add-on that lets you manage Google Cloud resources through Kubernetes, and says to use it with Config Controller to manage Google Cloud resources through Kubernetes. And Helm is different in kind: it is the package manager for Kubernetes, using charts that define a set of Kubernetes resources to deploy. Helm deploys an application onto a cluster; it is not how you create a bucket or a database.

The Terraform workflow

Each command does one job; the plan is the safety step

Figure: A flow chart of the Terraform workflow: write the configuration, run terraform init to prepare the directory, terraform plan to show the changes, then terraform apply to create or update infrastructure, which records every resource in the state file. The next change loops back to plan; terraform destroy removes what was created.

Worked example (synthetic). An engineer edits a machine type and runs apply without reading the plan. Nothing prevented it — but the plan was the step that would have shown the VM being replaced.

The workflow is four commands, and exam distractors work by swapping their jobs, so learn each one's single sentence from Google's quickstart. init prepares your working directory for other commands — it downloads the provider, and Google adds that to use the latest Google provider version you include the upgrade option. plan shows changes required by the current configuration; the overview puts it as generating an execution plan that shows what Terraform will do when you apply, so there are no surprises. apply creates or updates infrastructure, and you confirm by entering yes at the prompt. destroy destroys previously created infrastructure. Two details matter in practice. init writes a lock file recording the provider versions it chose, and Google says to include it in your version control repository so later runs make the same selections. And the arrow back from the state file to plan is the whole cycle: every later change is planned against what Terraform already recorded.

The state file: what Terraform remembers

Local by default; a team keeps it in Cloud Storage

Figure. Three cards showing how Terraform compares configuration with state: a resource missing from state is created, one whose configuration differs is updated, one that matches is left unchanged. Beneath them: state is a local terraform.tfstate file by default, which is hard for teams; a remote Cloud Storage backend with Object Versioning, migrated with terraform init -migrate-state and with admin access limited, is the team setup.

Worked example (synthetic). Two engineers apply from their own laptops, each with its own terraform.tfstate. The second apply plans against a picture of the infrastructure that is already out of date — a shared Cloud Storage backend removes the second picture.

The state file is why Terraform can be declarative. Google describes it as keeping track of all resources in a deployment, and says Terraform uses it to know the latest state of your infrastructure and to determine when to create, update and destroy resources. The three top cards are the rule, quoted: if a resource in the configuration does not exist in the state file, Terraform creates it; if it exists but has a different configuration, Terraform updates it to match; if it matches, Terraform leaves it unchanged. The bottom card is the operational half. By default Terraform stores state locally in a file named terraform.tfstate, and Google says that default can make Terraform usage difficult for teams when multiple users run Terraform at the same time and each machine has its own understanding of the current infrastructure. The fix is remote state, which is a feature of Terraform backends: Google's tutorial keeps it in a Cloud Storage bucket with Object Versioning enabled to keep the history of your deployments, migrates it there with init and the migrate-state option, and recommends that only a small set of users have admin permissions for the bucket.

Config Connector: cloud resources as Kubernetes objects

The controller acts with its own identity, not yours

Figure: A flow chart: resource manifests in a trusted Git repository are applied to a Kubernetes cluster with Config Connector's custom resource definitions; Config Connector's controllers reconcile them against Google Cloud APIs using the Config Connector IAM service account, creating resources such as buckets, databases and topics.

Worked example (synthetic). A developer with no Identity and Access Management role on the project applies a bucket manifest and the bucket appears. That is not a bug: the controller created it with its own service account, which is why who may apply manifests must be controlled.

Config Connector is worth drawing because its security model surprises people. It provides a collection of Kubernetes custom resource definitions (CRDs) and controllers, so a Cloud Storage bucket or a Pub/Sub topic becomes a Kubernetes object in a manifest, and Google's pitch is that you can manage Google Cloud infrastructure the same way you manage your Kubernetes applications. When objects are applied, Config Connector reconciles the configured state against Google Cloud APIs asynchronously. The arrow label is the part the exam tests: reconciliation executes using the identity of the Config Connector identity and access management (IAM) service account, not the identity of the human user or service account that submitted the manifest. So the ability to create those objects in the cluster is effectively the ability to change cloud resources, and Google says the security of the system depends on tightly controlling who can create them — for example, by having a Kubernetes controller apply Config Connector resources from a trusted code repository. That is why the diagram starts in Git.

Where charts live, and which service runs Terraform

Helm charts in Artifact Registry; Terraform in Infrastructure Manager

Worked example (synthetic). A practice question offers Deployment Manager as the way to template a new project's resources. In 2026 that is the one answer Google no longer supports for anyone new.

Three practical questions round the objective off. Where do Helm charts go on Google Cloud? Google says you can store Helm 3 charts saved as Open Container Initiative (OCI) container images in Artifact Registry Docker repositories, and that Artifact Registry only supports OCI-packaged Helm charts. What runs Terraform for you, if you do not want to maintain your own toolchain? Infrastructure Manager, which Google describes as a managed service that simplifies and automates the deployment and management of your Google Cloud infrastructure resources. It deploys Terraform configurations stored in Cloud Storage buckets, Git repositories or local directories, creates preview deployments so you can see how changes affect your infrastructure before applying them, and updates a deployment with revisions — and Google's infrastructure-as-code guide says to use it if you are looking to automate the deployment of your Terraform configuration. The last row is the trap. Deployment Manager was Google's older service; support for it was discontinued on 1 April 2026, and after 30 June 2027 it will be turned down. Existing resources created with it will continue to function, and Google asks current users to migrate to Infrastructure Manager or another deployment technology.

What this topic actually tests

Three discriminations, one objective

Which tool? Terraform by default; blueprints for a ready-made start; Config Connector if you live in Kubernetes; Helm to package apps, not cloud resources. Which command? init prepares, plan shows, apply changes, destroy removes. Where is the state? In a shared Cloud Storage backend — never one file per laptop.

Close on the three discriminations. Which tool: Terraform is Google's general default; what the guide calls Cloud Foundation Toolkit is ready-made Terraform, published today as blueprints and modules; Config Connector is for teams that already manage everything through Kubernetes; and Helm packages Kubernetes applications rather than creating cloud resources. Which command: init prepares the directory, plan shows what will change, apply creates or updates, destroy removes. Where the state lives: a team keeps it in a Cloud Storage backend with versioning and tight admin access, because Terraform decides what to create, update or leave alone by comparing configuration with state. And one date to carry into Unit 4: Deployment Manager is no longer supported, and Infrastructure Manager is its successor.

Official sources for this topic

• Associate Cloud Engineer exam guide — Section 3
• Infrastructure as Code on Google Cloud
• Overview of Terraform on Google Cloud
• Terraform blueprints and modules for Google Cloud
• Config Connector overview
• Store Helm charts in Artifact Registry
• Quickstart: Create a VM instance using Terraform
• Basic Terraform commands — Google Cloud
• Store Terraform state in a Cloud Storage bucket
• Work with Helm charts — Artifact Registry
• Infrastructure Manager overview
• Deployment Manager deprecation