An enterprise organization is evaluating the security and governance of its automated CI/CD pipeline. The current pipeline uses Cloud Build to run integration tests for incoming pull requests (PRs) against a Cloud Spanner database situated inside a VPC Service Controls (VPC-SC) perimeter. An architecture audit revealed two critical issues: pull requests submitted by external contributors can execute arbitrary build scripts using the default Cloud Build service account, creating data exfiltration risks, and developers frequently execute ad-hoc infrastructure updates from local workstations, leading to state corruption and configuration drift. Which architecture and pipeline control strategy should a Principal Cloud Architect implement to address these security and operational risks?
- AGrant the default Cloud Build service account the primitive Owner role across the project to bypass VPC Service Controls perimeter checks, and configure pull request triggers to execute automatically on default shared worker pools.
- BRely exclusively on Cloud IAM role bindings to prevent data exfiltration during pull request builds on default public Cloud Build pools, and store Terraform state files in unversioned local storage to prevent remote locking bottlenecks.
- Configure Cloud Build to use a private worker pool peered into the VPC-SC perimeter, attach a minimal user-managed service account to the pipeline, require approval from a repository maintainer before running PR builds from external contributors, and enforce IaC deployments exclusively through CI/CD using a versioned Cloud Storage backend.Cevap
- DDistribute service account JSON keys to developers so they can run Terraform apply commands directly from local workstations, while allowing Cloud Build integration tests to run unvetted PR scripts on shared default pools.