Question

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

A healthcare technology organization is conducting an architecture audit of its continuous integration and continuous delivery (CI/CD) pipelines. The pipelines utilize Google Cloud Build to run automated security scans, build container images stored in Artifact Registry, and execute Terraform templates to provision Google Kubernetes Engine (GKE) clusters. An analysis reveals that the pipeline builds currently execute using the default Compute Engine service account, developers manually update infrastructure configurations via the Google Cloud Console, and build steps encounter state conflicts due to unmanaged local state files. Which TWO architectural and security modifications should the organization implement to remediate these issues while adhering to Google Cloud best practices?

  1. Configure Cloud Build triggers to execute using a user-managed service account bound to specific fine-grained IAM roles, and configure a Cloud Storage backend with object versioning for Terraform state storage.Answer
  2. Restrict manual Console modifications by enforcing Organization Policies, and mandate that all infrastructure state modifications be applied exclusively through automated Cloud Build pipeline triggers.Answer
  3. C
    Assign the primitive Owner role (roles/owner) to the default Cloud Build service account to ensure all GKE cluster API operations execute without permission errors.
  4. D
    Grant developers the Service Account Admin role (roles/iam.serviceAccountAdmin) so they can dynamically modify pipeline permissions during deployment runs.
  5. E
    Store Terraform state files in the ephemeral Cloud Build execution workspace storage to maximize pipeline execution performance across build runs.

Answer

The organization must configure Cloud Build triggers to run with a least-privilege user-managed service account, utilize Cloud Storage with object versioning for centralized Terraform state management, enforce Organization Policies to block manual Console edits, and restrict infrastructure deployments exclusively to automated CI/CD pipeline triggers.
Securing enterprise CI/CD pipelines requires replacing over-privileged default build service accounts with fine-grained custom service accounts, locking down infrastructure changes to version-controlled automated build triggers, and persisting IaC state in a centralized Cloud Storage backend with object versioning and state locking.

Step-by-Step Solution

1
Analyze pipeline security and service account identity
Identified over-privileged execution running under default accounts. Remediated by replacing default compute identities with custom user-managed service accounts assigned minimal required IAM roles.
Least-privilege service accounts restrict build capabilities so compromised build steps cannot modify unrelated project resources.
2
Analyze Infrastructure as Code (IaC) state management
Transitioned from local workspace state storage to a central Cloud Storage remote backend configured with object versioning and state locking.
Cloud Storage backends preserve state across builds, prevent concurrent state modification, and support recovery via versioning.
3
Remediate manual configuration drift
Enforced governance policies to prohibit out-of-band Console edits and routed all infrastructure changes through version-controlled CI/CD pipelines.
Mandating deployment via automated pipelines ensures full code review traceability and eliminates configuration drift between code and deployed environments.

Key Concept

Analyzing SDLC & CI/CD Pipelines for IAM Least Privilege, IaC Remote State Integrity, and Drift Prevention
Estimated Time:2m 30s
Rate this question