An enterprise organization operates a multi-tenant Google Cloud environment where multiple development teams share a central CI/CD project. Each team builds containerized microservices and deploys them to dedicated Artifact Registry repositories in their respective workload projects. To meet stringent security compliance standards, the DevOps team must ensure that: CI/CD pipeline triggers strictly enforce least privilege and prevent privilege escalation or cross-tenant access. Build execution permissions are isolated such that a compromised build script cannot access another team's artifacts or cloud resources. Administrative overhead for managing trigger execution identity remains minimal and compliant with Google Cloud security best practices. How should the DevOps engineer configure the Cloud Build triggers and IAM permissions?

Create dedicated, user-managed custom service accounts for each team with granular roles scoped to their resources, assign each custom service account to its corresponding Cloud Build trigger, and grant developers the Service Account User role on their team's service account.: ### What User-Specified Custom Service Accounts for Cloud Build Are **User-specified custom service accounts** allow Cloud Build triggers to execute builds under a defined identity rather than using the default Cloud Build service account. This allows fine-grained access management and complete IAM isolation across different workloads and development teams. ### How It Meets the Requirements - **Principle of least privilege**: By creating dedicated custom service accounts for each tenant, you grant only the exact permissions needed for that team's build steps—such as `roles/artifactregistry.writer` restricted directly to the team's specific Artifact Registry repository and `roles/logging.logWriter` for build logs. - **Tenant isolation**: Because each trigger runs under an isolated service account identity, a build script running within Tenant A cannot read, write, or tamper with resources belonging to Tenant B. - **Security best practices and impersonation**: Granting `roles/iam.serviceAccountUser` to the development team on their dedicated service account allows them to associate that service account with their build triggers without granting excessive project-level permissions or managing long-lived static credentials. ### Key Advantages and Capabilities - **Elimination of overly broad default permissions**: Bypasses the legacy Cloud Build service account which often accumulates wide-ranging permissions across projects. - **Granular resource-level IAM bindings**: Permissions can be scoped at the resource level (such as specific Artifact Registry repositories or Cloud Storage buckets). - **Comprehensive auditability**: Cloud Audit Logs capture API calls initiated under the distinct identity of each team's service account. - **Secure credential-less execution**: Eliminates the risk of credential leakage associated with exported JSON keys. ### Why This Is Optimal Assigning custom service accounts directly to Cloud Build triggers is Google Cloud's recommended architectural pattern for multi-tenant CI/CD pipelines. It provides strong boundary separation, enforces least privilege out of the box, and relies entirely on native IAM governance without operational overhead.

Cloud Build Trigger Custom Service Account Isolation | Professional Cloud DevOps Engineer

Cloud Build Trigger Custom Service Account Isolation

Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.

An enterprise organization operates a multi-tenant Google Cloud environment where multiple development teams share a central CI/CD project. Each team builds containerized microservices and deploys them to dedicated Artifact Registry repositories in their respective workload projects.

To meet stringent security compliance standards, the DevOps team must ensure that:

CI/CD pipeline triggers strictly enforce least privilege and prevent privilege escalation or cross-tenant access.
Build execution permissions are isolated such that a compromised build script cannot access another team's artifacts or cloud resources.
Administrative overhead for managing trigger execution identity remains minimal and compliant with Google Cloud security best practices.

How should the DevOps engineer configure the Cloud Build triggers and IAM permissions?

Grant the Cloud Build Service Agent role directly to custom user-managed service accounts and attach them to each team's trigger configuration.

Create dedicated, user-managed custom service accounts for each team with granular roles scoped to their resources, assign each custom service account to its corresponding Cloud Build trigger, and grant developers the Service Account User role on their team's service account.

Generate long-lived JSON service account keys for each tenant, store them in Secret Manager, and download and activate them using gcloud auth activate-service-account in the first build step.

Execute all triggers using the default Cloud Build service account, and apply IAM condition tags at the central project level to restrict resource access per repository.

Professional Cloud DevOps Engineer

Cloud Build Trigger Custom Service Account Isolation

Related questions