Question

Difficulty: HardAnalyzing Software Development Lifecycle (SDLC) and CI/CD Pipelines

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?

  1. 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
  2. B
    Maintain 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.
  3. C
    Grant 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.
  4. D
    Configure 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.

Answer

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.
The solution requiring a dedicated user-managed service account with fine-grained roles, combined with Cloud Storage object versioning and state locking for Terraform, directly remediates all identified SDLC process flaws. Enforcing automated pipeline execution eliminates manual drift and ensures traceable, repeatable deployment environments.

Step-by-Step Solution

1
Analyze security boundaries for CI/CD pipeline execution.
Identify that using primitive roles like Editor grants overly broad privileges. Replacing this with a dedicated user-managed service account adhering to least privilege isolates pipeline access.
CI/CD execution service accounts must only hold specific permissions required for artifact build and infrastructure deployment.
2
Evaluate Infrastructure as Code (IaC) state management integrity.
Determine that the Cloud Storage remote backend for Terraform must have Object Versioning enabled and support native state locking.
State locking prevents concurrent pipeline runs from corrupting state, while object versioning allows rollback and recovery if state corruption occurs.
3
Assess environment governance and configuration drift prevention.
Enforce strict GitOps principles where all infrastructure changes are declared in code and executed via automated builds, disallowing manual Console modifications.
Manual changes introduce configuration drift that invalidates IaC state tracking and leads to deployment failures in subsequent release cycles.

Key Concept

Secure SDLC and CI/CD Pipeline Optimization with Terraform State Management and IAM Security
Estimated Time:2m 0s
Rate this question