Task 2.4: Planning and implementing resources using tooling.

• AGive each engineer a separate Terraform workspace on their own laptop

  Incorrect

  Separate local workspaces keep separate states for the same resources, which makes the drift worse.

• BRun terraform refresh on each laptop before every apply to rebuild the local state

  Incorrect

  Refreshing updates each local copy from real resources but still leaves three separate state files that can disagree.

• CCommit terraform.tfstate to the Git repository and pull before each run

  Incorrect

  A state file in Git still diverges between pushes and can leak secrets; Terraform's remote backends exist for sharing state.

• DMove the state to a gcs backend in a Cloud Storage bucket with Object Versioning

  Correct

  A remote backend gives everyone one shared state, and versioning keeps earlier state versions for recovery.

Terraform's state records what it manages. A team must share one copy of it, and a Cloud Storage backend is the standard place to keep that copy on Google Cloud.

• ATo Terraform configurations deployed with Infrastructure Manager

  Correct

  Infrastructure Manager runs Terraform as a managed service, records deployments and revisions, and can create previews; it is the migration path Google names for Deployment Manager.

• BTo Cloud Deploy delivery pipelines that promote each environment

  Incorrect

  Cloud Deploy delivers applications to runtimes such as GKE and Cloud Run; it does not provision the underlying infrastructure.

• CTo new Deployment Manager templates written in Python instead of Jinja

  Incorrect

  Deployment Manager is no longer supported, whatever the template language, so new work should not go into it.

• DTo Cloud Build steps that run gcloud commands to create each resource

  Incorrect

  Imperative gcloud steps are not declarative infrastructure as code and keep no deployment revisions or previews.

Deployment Manager has reached end of support, and Google directs its users to Infrastructure Manager. Infra Manager uses standard Terraform, so the definitions become portable Terraform code.

• AHelm charts that create the resources as part of each release

  Incorrect

  Helm packages Kubernetes manifests; on its own it cannot create a Cloud SQL instance or a Pub/Sub topic.

• BCloud Build triggers that run gcloud commands for each resource when the repository changes

  Incorrect

  Build steps run imperative commands; the resources would not be Kubernetes objects that the team manages with kubectl and RBAC.

• CConfig Connector installed on the GKE cluster, with the resources declared as manifests

  Correct

  Config Connector is a Kubernetes add-on that represents Google Cloud resources as Kubernetes resources, so they are managed with kubectl and Kubernetes tooling.

• DInfrastructure Manager deployments triggered from the same Git repository

  Incorrect

  Infrastructure Manager runs Terraform; it does not let the team manage these resources as Kubernetes objects with kubectl and RBAC.

Config Connector extends the Kubernetes API with Google Cloud resource kinds, so infrastructure follows the same manifest, kubectl and RBAC workflow as the applications.

• AA separate root module for the instance, to keep its blast radius smaller

  Incorrect

  Fewer resources per root module limit the impact of a change, but a plan in that module could still destroy the instance.

• BAutomated backups on the instance, so it can be rebuilt after a deletion

  Incorrect

  Backups help recover after a loss, but Terraform would still go ahead and delete the instance.

• CThe Cloud SQL Viewer role for the pipeline's service account on the project

  Incorrect

  A read-only role would also block the updates the team still wants to make to the instance.

• DA lifecycle block with prevent_destroy set to true on the instance resource

  Correct

  Google's Terraform guidance protects stateful resources such as databases this way, so a plan that would destroy the instance is rejected.

Protect stateful resources in the configuration itself: prevent_destroy makes Terraform stop on any plan that would destroy the resource, while updates and the other resources work as usual.

• Aterraform state rm for each resource

  Incorrect

  This only forgets the resources in state and leaves them running.

• Bterraform refresh

  Incorrect

  refresh updates state from real resources; it deletes nothing.

• Cgcloud projects delete on the project

  Incorrect

  Deleting the project also removes everything else in it.

• Dterraform destroy

  Correct

  destroy removes the resources managed by the configuration's state.

Terraform tracks what it created, so it can remove exactly those resources and nothing else.

• ADelete the .terraform.lock.hcl file before runs so that init picks the newest release

  Incorrect

  Google recommends checking the lock file into source control so that provider selections are tracked and reviewed; deleting it invites the same surprise.

• BDeclare the provider in required_providers with a constraint pinned to a minor version

  Correct

  Pinning root modules to a minor provider version, for example ~> 6.10.0, allows automatic patch releases while keeping a stable target.

• CPin the provider to one exact release, such as = 6.10.2, in required_providers

  Incorrect

  An exact pin blocks the patch releases the team wants to receive automatically.

• DSet the constraint to >= 6.0 so that later provider releases are accepted

  Incorrect

  A lower bound alone still accepts the next major release and its breaking changes.

In root modules, declare each provider in versions.tf and pin it to a minor version: patch releases flow in, major and minor upgrades become deliberate changes.

• ARead the setting through a data source and pass the value to the resource

  Incorrect

  Data sources read information about existing objects; they cannot set an argument the provider does not support.

• BCreate the resource with a gcloud beta command and keep it out of Terraform

  Incorrect

  The resource would no longer be managed in Terraform, which the team requires.

• CDeclare the google-beta provider and set provider = google-beta on that resource

  Correct

  The google-beta provider exists to provision and manage Google Cloud beta APIs, and a single resource can use it while the rest keep the google provider.

• DApply the setting with a local-exec provisioner that runs a gcloud beta command

  Incorrect

  Google's guidance is to limit custom scripts in Terraform; a provisioner runs a command once and does not manage the setting as part of state.

Terraform on Google Cloud has two providers: google for generally available APIs and google-beta for beta APIs. Use google-beta only on the resources that need a beta feature.

• AMark the password output as sensitive so that Terraform hides its value

  Correct

  Sensitive values exported as outputs should be marked as sensitive, relying on Terraform's built-in handling instead of custom measures.

• BEncrypt the Terraform state with a customer-supplied encryption key

  Incorrect

  Encrypting state protects the state at rest; it does not stop the value from being printed as an output.

• CMove the password into a terraform.tfvars file next to the root module

  Incorrect

  A tfvars file sets input variables; the output that prints the password is unchanged.

• DRemove the output and have the job read the password from the state file

  Incorrect

  Values like this are stored in plain text in the state, so reading them from the state file spreads the secret further.

Treat secrets carefully at every step: mark sensitive outputs, keep secrets out of state where possible, and encrypt state as an extra layer.