Google ACE Practice Question: A team needs to build a CI/CD pipeline that…

A team needs to build a CI/CD pipeline that automatically tests and deploys to GKE when code is pushed to the main branch. Which GCP-native service builds and deploys the code automatically based on source code repository events?

⚠ Common exam trap

Google Cloud often tests the distinction between event-driven compute services (Cloud Functions, Cloud Run) and purpose-built CI/CD services (Cloud Build), leading candidates to mistakenly choose Cloud Functions or Cloud Run because they can be triggered by repository events, even though they lack the integrated build-and-deploy pipeline required for GKE deployments.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Cloud Build with a trigger configured on the repository's main branch

Cloud Build is the correct GCP-native service for building and deploying code automatically based on source code repository events. By configuring a Cloud Build trigger on the main branch, any push to that branch automatically initiates a build and deployment to GKE, fulfilling the CI/CD pipeline requirement without additional orchestration.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Cloud Composer with a Git polling DAG
Why it's wrong here
Cloud Composer (managed Airflow) is designed for orchestrating data pipelines with dependencies and retries, not for CI/CD workflows. A Git polling DAG would repeatedly watch a repository, but Airflow has no native support for building container images, running tests, or deploying to GKE. It would require custom operators and separate tooling, making it an awkward, inefficient choice compared to Cloud Build Triggers.
✓
Cloud Build with a trigger configured on the repository's main branch
Why this is correct
Cloud Build Triggers are the native, fully managed CI/CD solution on Google Cloud. Configuring a trigger on the main branch means every push automatically executes a pipeline defined in cloudbuild.yaml, which can include steps for unit tests, container image building with Kaniko or Buildpacks, pushing to Artifact Registry, and deploying to a GKE cluster using the kubectl or gke-deploy builder. This is exactly the intended use case, with built-in integration, logging, and minimal operational overhead.
✗
Cloud Run jobs triggered by a Pub/Sub subscription on the repository
Why it's wrong here
Cloud Run jobs execute containerized batch workloads and are not designed for CI/CD orchestration. While you could theoretically use a Pub/Sub subscription to invoke a job on repository events, you would need to write all the build/test/deploy logic yourself, manage container images for the job, and handle retries and status reporting manually. Cloud Build Triggers are purpose-built to handle these steps declaratively, so this adds unnecessary complexity without any benefit.
✗
Cloud Functions triggered by Cloud Source Repositories push events
Why it's wrong here
Cloud Functions are lightweight, event-driven Python, Go, Node.js, or Java functions that execute within a limited timeout (up to 9 minutes) and are intended for simple event processing, not multi-step pipelines. A push event from Cloud Source Repositories could trigger a function, but building, testing, and deploying an application to GKE requires sequentially running multiple commands with state, which doesn't fit the Cloud Functions execution model. Cloud Build Triggers provide a declarative, step-based CI/CD pipeline that is far more appropriate for this scenario.

Go deeper

Google ACE Practice Question: A team needs to build a CI/CD pipeline that…

Why each option matters

Option-by-option breakdown

Related to this question