A retail company is auditing its automated CI/CD pipeline built with Cloud Build to deploy microservices to Cloud Run and provision resources using Terraform. The audit reveals two major compliance and operational risks: build jobs currently run using the broad default Compute Engine service account, and Terraform execution state is stored on local ephemeral build runner storage, causing state locks to fail during concurrent build executions. Which combination of security and operational refactoring should the Cloud Architect recommend to remediate these issues?
- Configure Cloud Build triggers to use a custom service account granted minimal required IAM roles, and migrate the Terraform state backend to a Cloud Storage bucket with object versioning and state locking enabled.Answer
- BGrant the primitive Owner role to the default Compute Engine service account to prevent pipeline permission errors, and store the Terraform state in a Cloud Storage bucket without versioning.
- CGrant the Service Account Admin role directly to developers so they can modify pipeline execution accounts, while keeping Terraform state files on local build runner storage.
- DConfigure a custom service account for Cloud Build, but maintain the Terraform state file on local persistent disks attached to build worker instances to avoid network storage overhead.
Answer
The architect should configure Cloud Build to run using a custom service account with least privilege permissions and configure a Cloud Storage remote backend for Terraform state locking and versioning.
Configuring Cloud Build triggers to use a custom service account restricted to necessary IAM roles adheres strictly to the principle of least privilege. Simultaneously, utilizing a Cloud Storage remote backend with state locking resolves concurrent execution conflicts and safeguards Terraform state integrity through versioning.
Step-by-Step Solution
Key Concept
CI/CD Pipeline Security Least Privilege and Remote IaC State Lock Management