Interacting with Google Cloud programmatically

Ivybridge Fintech's developers build a Go service on Spanner. Each developer currently uses a shared Spanner instance for local testing, which costs money around the clock and causes tests to interfere with each other's data. The team wants a free, isolated database for local development and for integration tests in Cloud Build, without changing application code.

What should you recommend?

1. AGive each developer a separate Spanner instance with 100 processing unitsSeparate small instances isolate data but still cost money for every developer all the time.
2. BReplace Spanner with a local PostgreSQL database for testingA different database engine behaves differently from Spanner, so tests may pass locally and fail in production, and code changes may be needed.
3. CMock every Spanner call in the integration testsMocks suit unit tests but do not test real query behavior, which is the purpose of integration tests.
4. DRun the Spanner emulator locally and in Cloud Build, and set the SPANNER_EMULATOR_HOST environment variable so the client library connects to itThe Spanner emulator runs in memory at no cost, each developer or build gets its own copy, and the client libraries connect to it automatically when SPANNER_EMULATOR_HOST is set.

Elderglen Schools has a small IT team that has written Terraform configurations for its Google Cloud projects. The team does not want to run its own Terraform servers or CI runners, manage state buckets, or maintain Terraform binaries, but it wants deployments, state and run history managed by Google Cloud and controlled through IAM.

What should you recommend?

1. ARun Terraform from each engineer's laptop with local stateLocal runs leave state and history on laptops, which is unmanaged and unsafe for a team.
2. BConvert the configurations into a series of gcloud commands in a shell scriptScripts are not declarative, do not track state, and lose Terraform's planning and drift detection.
3. CDeploy the configurations with Infrastructure Manager, which runs Terraform on Google Cloud and stores the state and revision history for each deploymentInfrastructure Manager is the managed Terraform service: it runs Terraform through Cloud Build, keeps state and revisions for each deployment, and is controlled with IAM, so the team runs no infrastructure of its own.
4. DUse Cloud Deployment Manager templates instead of TerraformCloud Deployment Manager reached end of support on March 31, 2026, and Google directs its users to Infrastructure Manager. Choosing it would also mean rewriting the existing Terraform code.

Four platform engineers at Westmoor Utilities manage shared VPC networks with Terraform. Each engineer keeps a terraform.tfstate file on a laptop, and last week two engineers applied conflicting changes and one state file was lost. The team wants a shared, protected state with locking and history.

What should you recommend?

1. AConfigure the Terraform gcs backend with a Cloud Storage bucket that has Object Versioning enabled and access limited to the platform teamThe gcs backend stores state centrally, locks it during operations so that two applies cannot run at once, and Object Versioning keeps earlier versions for recovery.
2. BCommit the terraform.tfstate file to the Git repository after every applyState in Git has no locking, can expose secrets stored in state, and still allows conflicting applies between commits.
3. CHave only one engineer run Terraform and share the state file by emailThis creates a single point of failure and a manual process, and email is not a secure place for state that may contain sensitive values.
4. DStop using state and import all resources before every applyTerraform depends on state to map configuration to real resources, and repeated imports are slow and error-prone.

Thistlewood Labs runs a GKE Standard cluster where a pod named report-builder writes files to Cloud Storage. Today the pod mounts a service account key from a Kubernetes Secret, and the security team requires that no long-lived keys are used. Other pods on the same nodes must not be able to write to the bucket.

What should you do?

1. AGrant the node pool's service account the Storage Object Admin role on the bucketEvery pod on those nodes would inherit the node's permissions, so other pods could also write to the bucket.
2. BRotate the service account key every 30 days with a Cloud Scheduler jobRotation shortens the life of each key, but it still relies on keys, which the security team prohibits.
3. CStore the key in Secret Manager and read it at pod startupSecret Manager protects the key at rest, but the workload still uses a long-lived key.
4. DEnable Workload Identity Federation for GKE, give the report-builder Kubernetes service account access to the bucket through IAM, and remove the mounted keyWorkload Identity Federation for GKE gives each Kubernetes service account its own identity with short-lived credentials, so only report-builder gets access to the bucket and no key is stored anywhere.