A global telecommunications provider is analyzing its automated SDLC and CI/CD release workflow for provisioning multi-region Google Cloud infrastructure using Terraform and Cloud Build. The current pipeline executes builds using the default Cloud Build service account, which has been assigned the primitive `roles/editor` role at the project level. Additionally, concurrent pipeline runs occasionally overwrite each other's infrastructure state because state files are saved locally within the Cloud Build ephemeral build container. The architecture team needs to refactor the pipeline to enforce least-privilege security access and ensure state file integrity and concurrency control during automated deployments. Which strategy should the team implement?
- Configure Cloud Build triggers to run as a dedicated user-managed service account assigned only the granular IAM roles required for target GCP resources, and configure Terraform to store state in a Cloud Storage backend with object versioning and state locking.Cevap
- BAssign the primitive `roles/owner` role to the default Cloud Build service account to prevent deployment authorization failures, and write state files to an attached persistent disk on the build worker.
- CMaintain Cloud Build execution under the default service account, but write Terraform state files directly to a standard Cloud Storage bucket without object versioning or backend state locking enabled.
- DGrant pipeline developers the `roles/iam.serviceAccountAdmin` role across the GCP organization resource hierarchy so Cloud Build can impersonate any service account, while caching state files in local build container memory.