Professional Cloud Architect

Intrigued by the art of cloud architecture? Discover how to design, develop, and manage robust, secure, scalable, and dynamic solutions on Google Cloud as you prepare for the Professional Cloud Architect exam!

Intermediate

Prepare and test your skills

Intermediate

Prepare and test your skills

GCS Backend Locking and Versioning for Terraform State

Section: Infrastructure as Code (e.g., IaC and Terraform)

...

Explanations

...

View source documentation

Keep the momentum going with these hand-picked practice scenarios

IntermediateProfessional Cloud Architect

An enterprise analytics team is designing a BigQuery data architecture for high-volume streaming telemetry events. The design must meet the following technical and compliance requirements: Telemetry data must be retained for exactly 90 days, after which expired data must be automatically and permanently removed without incurring continuous query scanning costs. Frequent downstream dashboard queries aggregate telemetry metrics by event_type and filter on specific user_id values over varying daily date ranges. The team wants to use a materialized view to accelerate precomputed aggregations while avoiding expensive full cache invalidations when data reaches the retention limit. How should you configure the base table and materialized view architecture to meet these requirements?

Designing the project, dataset, and table architecture to ensure proper data governance

Want more questions like this?

Get a free certification question every week.

Last updated August 28, 2026

Professional Cloud Architect

Intrigued by the art of cloud architecture? Discover how to design, develop, and manage robust, secure, scalable, and dynamic solutions on Google Cloud as you prepare for the Professional Cloud Architect exam!

Intermediate

Prepare and test your skills

Intermediate

Prepare and test your skills

GCS Backend Locking and Versioning for Terraform State

Section: Infrastructure as Code (e.g., IaC and Terraform)

A distributed engineering team is collaborating on Google Cloud infrastructure provisioning using Terraform. The team is experiencing issues where concurrent execution of terraform apply causes state corruption and race conditions. In addition, the team needs to protect sensitive state data and ensure that previous versions of the state file can be restored if corrupted.

Which backend configuration should you implement to satisfy these requirements?

...

Configure the Terraform gcs backend pointing to a dedicated Cloud Storage bucket with Object Versioning enabled and IAM access restrictions

...

Store state files in a Cloud Storage bucket and configure Object Lifecycle Management rules to export state snapshots to BigQuery

...

Configure the Terraform gcs backend and provision a Cloud SQL instance to serve as an external distributed lock table

...

Configure the Terraform local backend and commit the terraform.tfstate file to a shared Git repository with branch protection rules

...

Explanations

What the GCS Remote Backend is

The Google Cloud Storage (GCS) backend for Terraform is a native remote backend mechanism designed to store Terraform state files (.tfstate) securely in a centralized Cloud Storage bucket. Storing state centrally allows distributed teams to share a single, authoritative representation of their managed infrastructure.

How it meets the requirements

State Locking and Consistency: The gcs backend natively provides state locking using Cloud Storage object preconditions and generations. Whenever an engineer or CI/CD pipeline runs terraform plan or terraform apply, Terraform acquires an exclusive lock on the remote state file. This prevents concurrent executions from running simultaneously and corrupting the state.
State Recovery via Object Versioning: Enabling Object Versioning on the Cloud Storage bucket preserves every previous iteration of the state file whenever updates are written. If a bad apply or accidental corruption occurs, administrators can easily roll back to a known healthy state generation.
Security and Access Control: Access to the state bucket can be strictly controlled using Google Cloud Identity and Access Management (IAM) roles (such as roles/storage.objectAdmin or roles/storage.objectViewer) and secured with customer-managed or Google-managed encryption keys.

Key advantages

Native Locking: Does not require any external database or lock table configuration.
High Availability: Backed by Google Cloud's highly resilient storage infrastructure.
Auditability and Compliance: Integrates seamlessly with Cloud Audit Logs to track who accessed or modified state files.
Automation Compatibility: Integrates directly with CI/CD platforms such as Cloud Build and GitHub Actions.

Why this is optimal

The gcs backend natively satisfies all enterprise requirements for state consistency, concurrency locking, disaster recovery, and fine-grained security without adding architectural complexity or third-party overhead.

...

View source documentation

Keep the momentum going with these hand-picked practice scenarios

IntermediateProfessional Cloud Architect

Terraform Workspaces vs Directory Separation

Infrastructure as Code (e.g., IaC and Terraform)

IntermediateProfessional Cloud Architect

IAP TCP Forwarding

Security protection (e.g. intrusion protection, access control, and firewalls)

IntermediateProfessional Cloud Architect

Compliance Reports Manager

Industry certifications (e.g., SOC 2)

IntermediateProfessional Cloud Architect

Instance Template and Regional Managed Instance Group

Infrastructure orchestration, resource configuration, and patch management

IntermediateProfessional Cloud Architect

Cloud Run Serverless Containers

Cloud-first design approach

AdvancedProfessional Cloud Data Engineer

An enterprise analytics team is designing a BigQuery data architecture for high-volume streaming telemetry events. The design must meet the following technical and compliance requirements: Telemetry data must be retained for exactly 90 days, after which expired data must be automatically and permanently removed without incurring continuous query scanning costs. Frequent downstream dashboard queries aggregate telemetry metrics by event_type and filter on specific user_id values over varying daily date ranges. The team wants to use a materialized view to accelerate precomputed aggregations while avoiding expensive full cache invalidations when data reaches the retention limit. How should you configure the base table and materialized view architecture to meet these requirements?

Designing the project, dataset, and table architecture to ensure proper data governance

Want more questions like this?

Get a free certification question every week.

Last updated August 28, 2026

A distributed engineering team is collaborating on Google Cloud infrastructure provisioning using Terraform. The team is experiencing issues where concurrent execution of terraform apply causes state corruption and race conditions. In addition, the team needs to protect sensitive state data and ensure that previous versions of the state file can be restored if corrupted.

Which backend configuration should you implement to satisfy these requirements?

Configure the Terraform gcs backend pointing to a dedicated Cloud Storage bucket with Object Versioning enabled and IAM access restrictions

Store state files in a Cloud Storage bucket and configure Object Lifecycle Management rules to export state snapshots to BigQuery

Configure the Terraform gcs backend and provision a Cloud SQL instance to serve as an external distributed lock table

Configure the Terraform local backend and commit the terraform.tfstate file to a shared Git repository with branch protection rules

Configure the Terraform gcs backend pointing to a dedicated Cloud Storage bucket with Object Versioning enabled and IAM access restrictions

What the GCS Remote Backend is

The Google Cloud Storage (GCS) backend for Terraform is a native remote backend mechanism designed to store Terraform state files (.tfstate) securely in a centralized Cloud Storage bucket. Storing state centrally allows distributed teams to share a single, authoritative representation of their managed infrastructure.

How it meets the requirements

State Locking and Consistency: The gcs backend natively provides state locking using Cloud Storage object preconditions and generations. Whenever an engineer or CI/CD pipeline runs terraform plan or terraform apply, Terraform acquires an exclusive lock on the remote state file. This prevents concurrent executions from running simultaneously and corrupting the state.
State Recovery via Object Versioning: Enabling Object Versioning on the Cloud Storage bucket preserves every previous iteration of the state file whenever updates are written. If a bad apply or accidental corruption occurs, administrators can easily roll back to a known healthy state generation.
Security and Access Control: Access to the state bucket can be strictly controlled using Google Cloud Identity and Access Management (IAM) roles (such as roles/storage.objectAdmin or roles/storage.objectViewer) and secured with customer-managed or Google-managed encryption keys.

Key advantages

Native Locking: Does not require any external database or lock table configuration.
High Availability: Backed by Google Cloud's highly resilient storage infrastructure.
Auditability and Compliance: Integrates seamlessly with Cloud Audit Logs to track who accessed or modified state files.
Automation Compatibility: Integrates directly with CI/CD platforms such as Cloud Build and GitHub Actions.

Why this is optimal

The gcs backend natively satisfies all enterprise requirements for state consistency, concurrency locking, disaster recovery, and fine-grained security without adding architectural complexity or third-party overhead.

Store state files in a Cloud Storage bucket and configure Object Lifecycle Management rules to export state snapshots to BigQuery

Configure the Terraform gcs backend and provision a Cloud SQL instance to serve as an external distributed lock table

Configure the Terraform local backend and commit the terraform.tfstate file to a shared Git repository with branch protection rules

Professional Cloud Architect

GCS Backend Locking and Versioning for Terraform State

Related questions

Terraform Workspaces vs Directory Separation

IAP TCP Forwarding

Compliance Reports Manager

Instance Template and Regional Managed Instance Group

Cloud Run Serverless Containers

Professional Cloud Architect

GCS Backend Locking and Versioning for Terraform State

What the GCS Remote Backend is

How it meets the requirements

Key advantages

Why this is optimal

Related questions

Terraform Workspaces vs Directory Separation

IAP TCP Forwarding

Compliance Reports Manager

Instance Template and Regional Managed Instance Group

Cloud Run Serverless Containers

What the GCS Remote Backend is

How it meets the requirements

Key advantages

Why this is optimal