An enterprise architecture team is designing an automated CI/CD pipeline using Cloud Build to provision infrastructure resources via Terraform across multiple environments. The pipeline must execute automatically upon code commits, maintain security compliance under the principle of least privilege, and prevent state corruption during concurrent executions. Which design strategy should the team implement?
- Store the Terraform state file in a remote Cloud Storage bucket with object versioning and state locking enabled, and assign fine-grained predefined roles to a custom service account assigned to the Cloud Build trigger.Answer
- BStore the Terraform state file in the source code repository alongside the configuration files, and execute Cloud Build builds using the default service account.
- CStore the Terraform state file in a remote Cloud Storage bucket, and grant the primitive Owner role to the Cloud Build service account to ensure automated pipeline steps do not fail from missing permissions.
- DStore the Terraform state file in a remote Cloud Storage bucket and rely exclusively on IAM role bindings to prevent pipeline service accounts from copying infrastructure artifacts outside the project environment.
Answer
The team should store the Terraform state in a remote Cloud Storage bucket configured with state locking and object versioning, while executing Cloud Build triggers under a custom service account bound to fine-grained predefined IAM roles.
Centralizing Terraform state management within a Cloud Storage bucket that supports state locking and versioning protects against concurrency errors and state corruption. Pairing this backend with custom Cloud Build service accounts that use specific predefined IAM roles ensures that automated deployments operate with minimal required privileges.
Step-by-Step Solution
Key Concept
CI/CD Pipeline Design for IaC Automation with Secure State Management and Least Privilege