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.

StudyCerts

Professional Cloud DevOps Engineer

Advanced

Prepare and test your skills

Track Readiness

Set Exam Goal

Advanced

Prepare and test your skills

Track Readiness

Set Exam Goal

Cloud Build Trigger Custom Service Account Isolation

Section: CI/CD pipeline triggers

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.

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

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.

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.

Professional Cloud DevOps Engineer

Advanced

Prepare and test your skills

Track Readiness

Set Exam Goal

Advanced

Prepare and test your skills

Track Readiness

Set Exam Goal

Cloud Build Trigger Custom Service Account Isolation

Section: CI/CD pipeline triggers

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.

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.

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.

Explanations

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.

View source documentation

Professional Cloud DevOps Engineer

Cloud Build Trigger Custom Service Account Isolation

Professional Cloud DevOps Engineer

Cloud Build Trigger Custom Service Account Isolation

What User-Specified Custom Service Accounts for Cloud Build Are

How It Meets the Requirements

Key Advantages and Capabilities

Why This Is Optimal

Related questions