An enterprise architecture team is conducting an SDLC audit of a multi-project CI/CD deployment pipeline using Cloud Build and Terraform to provision infrastructure across target Google Cloud projects. The audit reveals two critical security and governance findings: the build pipeline uses the default Cloud Build service account with primitive Owner permissions across target projects, and build steps maintain Terraform state within ephemeral Cloud Build workspace storage committed back to git repositories. Additionally, developers require administrative rights over service accounts to run build triggers. Which set of refactoring steps should the architecture team recommend to remediate these pipeline vulnerabilities while adhering to Google Cloud best practices?
- AMaintain the Editor primitive role on target projects for deployment flexibility, migrate Terraform state storage to a central Cloud Storage bucket with object versioning, and grant developers the Service Account User role on the build service account.
- BCreate a user-managed service account for Cloud Build with specific predefined roles on target projects, migrate Terraform state storage to a central Cloud Storage bucket with object versioning, and grant developers the Service Account Admin role to execute triggers.
- Create a user-managed service account for Cloud Build configured with fine-grained predefined roles on target projects, configure a Cloud Storage remote backend with object versioning and state locking for Terraform, and grant developers the Service Account User role on the build service account.Cevap
- DCreate a user-managed service account for Cloud Build with fine-grained predefined roles on target projects, encrypt Terraform state files locally inside Cloud Build workspace containers using KMS before committing them, and grant developers the Service Account User role on the build service account.