A software architecture team at a media streaming organization is conducting a post-incident review of their continuous delivery pipeline. The current SDLC pipeline uses Cloud Build to execute Terraform manifests that provision Cloud Run microservices and manage IAM permissions across staging and production environments. The audit revealed that the Cloud Build trigger runs under a service account with the primitive Editor role (`roles/editor`), the Terraform state file is stored in a Cloud Storage bucket without versioning or state locking, and team members frequently perform manual Cloud Console adjustments when builds fail, creating significant configuration drift. Which set of architectural optimizations should the team implement to secure the pipeline and standardize their SDLC release process according to Google Cloud best practices?
- Configure Cloud Build to execute using a dedicated user-managed service account with fine-grained predefined roles, enable object versioning and state locking on the Terraform Cloud Storage backend, and restrict infrastructure mutations exclusively to automated CI/CD pipeline executions.Answer
- BMaintain the primitive Editor role on the Cloud Build service account to ensure deployment scripts never encounter permission failures, but move the Terraform state file into a shared code repository to track history.
- CGrant developers the Service Account Admin role (`roles/iam.serviceAccountAdmin`) so they can update service account permissions on demand, and disable state locking on the Cloud Storage backend to accelerate pipeline run times.
- DConfigure VPC Service Controls around the Cloud Run instances while keeping the Terraform state in an unversioned, public Cloud Storage bucket to streamline multi-project deployment access.