Google ACE Deploying and Implementing a Cloud Solution Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Cloud Storage

  Why this is correct

  Cloud Storage is a fully supported Terraform remote backend for Google Cloud. When you configure a GCS bucket as a backend, Terraform stores the state file in the bucket, which lets multiple team members access the same state. The backend automatically uses an object lock to prevent concurrent writes, and you can enable bucket versioning to keep a history of state changes, which is essential for rollback and recovery. Additionally, the bucket can be secured with IAM policies, encryption at rest, and access logging.

• ✗

  Cloud Source Repositories

  Why it's wrong here

  Cloud Source Repositories is a hosted Git repository service in Google Cloud, designed for storing and managing source code, configuration files, and documentation. It has no concept of Terraform state or state locking; it does not implement the Terraform backend interface. While you might commit a state file into a Git repository, this is an anti-pattern because Git lacks server-side locking for Terraform's concurrency safety and exposes sensitive state data. CSR cannot serve as a remote backend because it provides no API for Terraform to read and write a state object atomically.

• ✗

  Cloud Shell

  Why it's wrong here

  Cloud Shell is an interactive, browser-based terminal that provisions a temporary Compute Engine VM for each user. It includes the gcloud CLI and Terraform pre-installed, but it is not a state backend. The filesystem in Cloud Shell is ephemeral (persisted only for a limited time in a 5 GB home directory), and there is no shared locking or atomic write mechanism across multiple sessions. You could run Terraform commands from Cloud Shell, but the state would be stored locally on that ephemeral disk unless you explicitly configure a separate backend like Cloud Storage.

• ✗

  Cloud Bigtable

  Why it's wrong here

  Cloud Bigtable is a fully managed, scalable NoSQL database service optimized for large analytical and operational workloads with low-latency reads and writes. It exposes a wide-column data model, but it is not integrated with Terraform's backend system, and there is no official or communitysupported Terraform backend implementation for Bigtable. Even if you were to manually store a state file as a Bigtable cell, you would lose critical features such as optimistic locking, state versioning, and a simple consistent file read/write path. Therefore, Bigtable is not a viable or appropriate choice for Terraform state management.

Go deeper

Related to this question