Your organization is designing an Infrastructure as Code (IaC) strategy using Terraform to deploy workloads across multiple Google Cloud environments (dev, qa, and prod). You need to design a scalable and maintainable architecture that adheres to Google Cloud best practices. Your design must meet the following requirements: Standardize infrastructure components while allowing environment-specific configurations. Ensure clear state isolation between environments to prevent blast radius issues. Allow downstream configurations and dependent applications to reference output attributes. Avoid anti-patterns such as brittle workspace logic or oversized state files. How should you structure your Terraform configuration?

Create a shared module under a `modules/` directory that defines variables and outputs without backend or provider blocks, and instantiate it within separate `environments/` subdirectories (`dev`, `qa`, `prod`) that each define their own `backend.tf` and `terraform.tfvars`.: ### What the Recommended Architecture Is This architecture uses a standard directory separation model that decouples **reusable child modules** from **environment-specific root modules**. Common infrastructure resources are defined inside a dedicated `modules/` directory, while distinct environment folders (`dev`, `qa`, `prod`) act as independent root execution directories that instantiate the child modules. ### How It Meets the Requirements - **Standardization & Customization**: The shared service module encapsulates baseline resource definitions while exposing input **variables** (such as machine types, project IDs, and labels) and **outputs** for referenced resources. Environment-specific values are cleanly supplied via each environment's `terraform.tfvars`. - **State Isolation**: Each environment directory contains its own `backend.tf` targeting dedicated Google Cloud Storage (GCS) state prefixes or buckets. This eliminates shared state file risks and reduces the blast radius of changes. - **Downstream Integration**: By defining comprehensive outputs in the child module and re-exporting them in the environment's root module, external applications or other Terraform configurations can consume these values via `terraform_remote_state`. - **Avoiding Anti-Patterns**: It avoids configuring provider or backend blocks inside reusable modules and keeps root modules compact (avoiding large state files exceeding 100 resources). ### Key Advantages - **Independent Lifecycle Management**: Environments can be planned, tested, and applied independently without locking state across the entire organization. - **No Provider Duplication**: Shared modules declare version constraints in `required_providers` without hardcoding credentials or backend configurations. - **Simplified CI/CD**: Pipelines can target specific environment folders during branch promotion workflows. - **Readability**: Eliminates complex inline ternary operators that attempt to branch on workspace names. ### Why This Is Optimal Separating reusable modules from distinct environment directories is the official standard for enterprise cloud infrastructure. It provides optimal modularity, reliable testing boundaries, and predictable execution plans.

StudyCerts

Terraform Modular Structure Multi Environment Gcp | 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! | StudyCerts

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

Track Readiness

Set Exam Goal

Intermediate

Prepare and test your skills

Track Readiness

Set Exam Goal

Terraform Modular Structure Multi Environment Gcp

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

Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.

Your organization is designing an Infrastructure as Code (IaC) strategy using Terraform to deploy workloads across multiple Google Cloud environments (dev, qa, and prod). You need to design a scalable and maintainable architecture that adheres to Google Cloud best practices.

Your design must meet the following requirements:

Standardize infrastructure components while allowing environment-specific configurations.
Ensure clear state isolation between environments to prevent blast radius issues.
Allow downstream configurations and dependent applications to reference output attributes.
Avoid anti-patterns such as brittle workspace logic or oversized state files.

How should you structure your Terraform configuration?

Embed dedicated provider and backend blocks directly inside each reusable child module, and pass runtime configurations dynamically using CLI command-line parameters (-var='env=prod').

Consolidate all environment resources and service logic into a single monolithic root module containing hundreds of resources, maintaining local state files checked into Git.

Create a single root configuration defining all environments together, and manage environment separation using Terraform CLI workspaces (terraform workspace new) combined with ternary expressions checking terraform.workspace against a single backend.

Create a shared module under a modules/ directory that defines variables and outputs without backend or provider blocks, and instantiate it within separate environments/ subdirectories (dev, qa, prod) that each define their own backend.tf and terraform.tfvars.

Professional Cloud Architect

Terraform Modular Structure Multi Environment Gcp

Related questions