Examkin

Question

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

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?

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

Answer

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.
The optimal solution requires replacing default project-level service accounts with a dedicated user-managed service account configured for Cloud Build triggers. This service account is assigned only the specific predefined or custom IAM roles necessary to provision the target infrastructure. Simultaneously, migrating Terraform state storage from ephemeral container storage to a Google Cloud Storage backend enables native distributed state locking and object versioning, preventing concurrent build runs from corrupting state data.

Step-by-Step Solution

1
Analyze CI/CD service account security requirement
Identified that using primitive roles (Editor/Owner) or default service accounts introduces security risks.
Default service accounts carry excessive broad permissions; custom service accounts allow granular, least-privilege IAM scoping.
2
Analyze Infrastructure as Code (IaC) state management requirement
Identified that local state storage causes concurrency conflicts and state loss in ephemeral build containers.
Terraform remote state stored in a Cloud Storage backend supports automatic state locking via Cloud Storage strongly consistent operations and preserves history via bucket versioning.
3
Synthesize the comprehensive architectural solution
Combined dedicated service account execution with GCS Terraform remote backend configuration.
Meets both least-privilege security policies and operational stability for automated SDLC deployment pipelines.

Key Concept

Least-privilege CI/CD service account configuration and remote IaC state management in Google Cloud
Rate this question

Topics

Analyzing Software Development Lifecycle (SDLC) and CI/CD Pipelines