PCDOE Building and implementing CI/CD pipelines — Timed 50 Questions

Question 1

A team uses Cloud Build with a Kaniko builder to containerize their application. The build fails with the error: 'failed to push to destination: failed to get credentials: failed to get credential from metadata service: failed to fetch metadata...' What is the most likely cause?

50 minute time limit — choose an answer to begin.

Accepted Answer

The Cloud Build service account does not have the storage.objectAdmin role on the Container Registry bucket.. The error indicates that Kaniko cannot authenticate to push the built image to Container Registry. Kaniko uses the Cloud Build service account's credentials to authenticate with the registry. By default, the Cloud Build service account has the storage.objectViewer role on the Container Registry bucket, which allows pulling images but not pushing. To push, the service account needs the storage.objectAdmin or storage.objectCreator role on the bucket. Option D correctly identifies this missing permission as the most likely cause.

Answer

Kaniko requires a running Docker daemon in the build step.

Answer

The base image specified in the Dockerfile is not accessible from the build environment.

Answer

The Dockerfile has an invalid instruction causing Kaniko to fail.

Question 2

A team uses Cloud Build to deploy a Cloud Run service. The build fails with: 'ERROR: (gcloud.run.services.update) PERMISSION_DENIED: Permission 'run.services.update' denied on resource.' The Cloud Build service account has the Cloud Run Admin role. What is missing?

Accepted Answer

The build config must use the Cloud Run deployer step instead of the gcloud command.. The error occurs because using the gcloud command directly in a Cloud Build step does not automatically handle IAM permissions as the Cloud Run deployer step does. Although the Cloud Build service account has the Cloud Run Admin role, the gcloud command may fail due to missing resource-level permissions or because it uses a different service account context. The Cloud Run deployer step is designed to properly authenticate and apply the necessary permissions for deploying to Cloud Run.

Answer

The Cloud Build service account should have the Owner role on the project.

Answer

The Cloud Run service must be deployed in the same region as the build.

Answer

The Cloud Build service account needs the 'run.services.update' permission or the Cloud Run Admin role.

Question 3

An organization uses Cloud Build with a private pool to build container images that require access to on-premises Artifactory. After moving to a new VPC, builds fail with 'Connection refused' when fetching dependencies. What is the best step to troubleshoot?

Accepted Answer

Verify that VPC Network Peering is established between the Cloud Build private pool's service producer VPC and the customer VPC, and that routes to on-premises are present.. The error 'Connection refused' indicates that the Cloud Build private pool's worker VMs cannot reach the on-premises Artifactory server. Private pools are deployed in a Google-managed service producer VPC that must be connected to the customer VPC via VPC Network Peering. Without this peering and the correct routes to the on-premises network (e.g., via Cloud VPN or Dedicated Interconnect), traffic from the private pool is dropped, causing the connection refusal.

Answer

Verify that the Cloud Build service account has the dns.networks.bindPrivateZone permission.

Answer

Check that the Cloud Build service account has the storage.objectViewer role on the Artifactory bucket.

Answer

Ensure that Cloud NAT is configured in the private pool's VPC.

Question 4

A team uses Cloud Build with a cloudbuild.yaml that deploys to multiple environments. They want to ensure that the production deployment step only runs when the build is triggered by a tag matching 'v*.*.*'. Which TWO configurations achieve this? (Choose two.)

Accepted Answer

In the cloudbuild.yaml, use a 'waitFor' condition that only runs the production step when the substitution variable $TAG_NAME matches 'v*.*.*'.. Option A is correct because Cloud Build provides the built-in substitution variable $TAG_NAME when a build is triggered by a tag, and a step can use a waitFor-based conditional (or a shell conditional on $TAG_NAME) to gate the production deployment step so it only executes when the tag matches the 'v*.*.*' pattern. Option B is correct because a Cloud Build trigger can be configured with a tag filter using the RE2 regular expression '^v[0-9]+\.[0-9]+\.[0-9]+$', which restricts that trigger to only fire on tags matching the v*.*.* semantic-versioning pattern, ensuring production deployments only run for such tags. Option C is incorrect because branch names do not carry tag information, so checking the branch name against 'v*.*.*' would never correctly identify a tag-triggered build. Option D is incorrect because a branch filter on '^main$' triggers on branch pushes, not on tags, so it does not satisfy the tag-matching requirement. Option E is incorrect because a manual approval step adds human gating but does not enforce the 'v*.*.*' tag condition, so it does not achieve the stated requirement.

Answer

In the cloudbuild.yaml, add a condition that checks if the branch name matches 'v*.*.*'.

Answer

Create a separate cloudbuild.yaml for production and use a branch filter '^main$' to trigger it.

Answer

Configure a manual approval step in Cloud Build that requires a production manager to approve before running the production deployment.

Question 5

A company uses Cloud Deploy to manage rollouts to GKE. They need to implement a deployment strategy where a new version receives 10% of traffic for 30 minutes, then automatically rolls forward to 100% if no issues are detected. Which THREE Cloud Deploy features are required? (Choose three.)

Accepted Answer

A canary deployment strategy with a 10% phase.. Option A is correct because Cloud Deploy's canary deployment strategy is what enables splitting traffic to a new revision, and defining a 10% phase is exactly how you route only 10% of traffic to the new version. Option E is correct because the canary strategy supports a wait phase, and specifying a 30-minute wait duration holds the 10% traffic split for 30 minutes before any further action. Option B is correct because an automated promotion policy (for example, promoteReleaseRule or an automation with a promote action) is what automatically rolls the rollout forward to 100% after the wait phase when no issues are detected, without human intervention. Option C is not correct because a manual approval gate would require human action and contradicts the requirement to automatically roll forward. Option D is not correct because Cloud Deploy natively manages canary traffic splitting for GKE without requiring a user-authored Istio VirtualService.

Answer

A manual approval gate before the 100% phase.

Answer

An Istio VirtualService configuration for traffic splitting.

Question 6

A Cloud Build pipeline uses the above cloudbuild.yaml. When triggered, the deploy step fails with: 'ERROR: (gcloud.run.deploy) PERMISSION_DENIED: Permission 'run.services.update' denied on resource.' The Cloud Build service account has the 'Cloud Run Admin' role. What is the most likely cause?

Accepted Answer

The nested 'gcloud builds submit' command runs with a different service account that does not have the Cloud Run Admin role.. When a Cloud Build pipeline uses a nested `gcloud builds submit` command, the nested build runs under the default Compute Engine service account (or a user-specified service account) rather than the top-level Cloud Build service account. Even if the top-level service account has the Cloud Run Admin role, the nested build's service account may lack the `run.services.update` permission, causing the deploy step to fail with PERMISSION_DENIED.

Answer

The substitution variable ${_ENV} is not properly passed to the nested build.

Answer

The 'gcr.io/cloud-builders/gcloud' image does not support the 'gcloud run deploy' command.

Answer

The Cloud Build service account at the top level does not have the 'run.services.update' permission.

Question 7

You are a DevOps engineer for a large e-commerce platform running on Google Kubernetes Engine (GKE). The platform consists of 15 microservices, each with its own code repository. Your team uses Cloud Build for CI and Cloud Deploy for CD. Recently, the deployment to production has been failing intermittently because the new version of the 'payment' service is not compatible with the current version of the 'order' service. This causes a production outage every few weeks. The team wants to implement a strategy to catch such incompatibilities before promoting to production, without slowing down development velocity. Currently, the pipeline builds each service independently, runs unit tests, deploys to a shared staging environment, runs integration tests, and then promotes to production after manual approval. What should you do?

Accepted Answer

Implement canary deployments in staging: deploy the new payment service alongside the current version, route a percentage of test traffic to the new version, and run integration tests before promoting. If tests pass, promote to production.. It introduces canary deployments in the staging environment, allowing the new payment service to be tested with a subset of realistic traffic alongside the current order service. This catches incompatibilities early by running integration tests against the canary, without blocking the pipeline or slowing development velocity. Cloud Deploy supports canary deployment strategies natively, making this a practical and automated solution.

Answer

Define strict version compatibility matrices between services and enforce them in the pipeline by locking versions.

Answer

Add a manual testing phase after staging deployment where QA engineers manually test the integration before production promotion.

Answer

Combine all microservice builds into a single pipeline that builds and tests all services together before deploying to staging.

Question 8

Your team manages a CI/CD pipeline for a microservices application deployed on Google Kubernetes Engine (GKE). The pipeline uses Cloud Build to build container images and push them to Artifact Registry, then uses a Cloud Build step with kubectl to apply Kubernetes manifests stored in a separate 'manifests' repository. Recently, the team has experienced issues: sometimes a new image is deployed to production even though the corresponding pull request (PR) has not been merged into the main branch of the manifests repository. Also, rollbacks are slow because the previous image tag is overwritten. The team wants to ensure that only code that passes all tests and is merged to main is deployed, and that each deployment uses a unique immutable image tag. What should the team do?

Accepted Answer

Consolidate application code and Kubernetes manifests into a single repository. Configure Cloud Build triggers to build and run tests on all branches, but only deploy to GKE when changes are merged to the main branch. Use the full commit SHA as the image tag.. Consolidating the application code and Kubernetes manifests into a single repository ensures that the image tag (full commit SHA) is uniquely tied to the exact code and manifest changes that passed all tests. By configuring Cloud Build triggers to deploy only on merges to the main branch, the team guarantees that only fully tested, merged code reaches production. Using the full commit SHA as the image tag provides immutability and enables fast, precise rollbacks by referencing the exact image from Artifact Registry.

Answer

Keep the current architecture but modify Cloud Build triggers to only run on the main branch of both repositories. Use the short SHA ($SHORT_SHA) as the image tag.

Answer

Move all source code and manifests into a single repository. Use Cloud Build triggers to build and test on every push, and deploy only on pushes to the main branch. Use the commit SHA ($COMMIT_SHA) as the image tag.

Answer

Keep application and manifests in separate repositories. Use Cloud Build triggers to build on changes to the app repo, and use a separate trigger on the manifests repo to deploy. Use the 'latest' tag for the image.

Question 9

A team is using Cloud Build to build a Docker image and push to Artifact Registry. After each build, they want to automatically trigger a deployment to Cloud Run. What is the best way to achieve this?

Accepted Answer

Configure a Cloud Run trigger on Artifact Registry push.. Cloud Run natively supports continuous deployment from Artifact Registry: when a new image is pushed to the registry, Cloud Run can automatically deploy the latest image without requiring an external pipeline or scheduler. This is the simplest and most direct approach, as it eliminates the need for additional CI/CD orchestration while ensuring deployments happen immediately after each successful build.

Answer

Use Cloud Build builder to deploy to Cloud Run in the same pipeline.

Answer

Use Cloud Deploy to manage the rollout.

Answer

Use Cloud Scheduler to periodically check for new images and deploy.

Question 10

A company uses Cloud Source Repositories and wants automatic builds on pull requests to the main branch. Which Cloud Build trigger type should they configure?

Accepted Answer

Pull request (any). A pull request trigger in Cloud Build allows you to run builds automatically when a pull request is opened, synchronized, or updated.

Answer

Pull request (comment)

Answer

Push to a branch

Answer

Tag push

Question 11

A company uses Cloud Source Repositories and Cloud Build to build and deploy a Node.js application to Google Kubernetes Engine (GKE). The build step fails intermittently with an error 'npm ERR! network timeout'. What is the most efficient way to reduce build failures?

Accepted Answer

Configure npm to use a proxy and increase the timeout in the build step.. Configuring npm to use a proxy and increasing the timeout directly addresses network timeouts during package downloads. Option B is incorrect because using Artifact Registry to cache npm packages changes the registry URL but does not mitigate intermittent network timeouts; the npm client still needs to reach the registry. Option C is incorrect because setting the build to retry on failure in Cloud Build trigger only retries the entire build, which is inefficient and still may fail repeatedly due to the same timeout. Option D is incorrect because increasing the machine type does not resolve network timeouts; it only provides more CPU/memory.

Answer

Use Artifact Registry to cache npm packages and change npm registry url.

Answer

Set the build to retry on failure in the Cloud Build trigger configuration.

Answer

Increase the machine type to e2-highmem-4 in the cloudbuild.yaml.

Question 12

A DevOps engineer is setting up a CI/CD pipeline for a Python application using Cloud Build. The build takes too long because pip install is downloading packages every time. What is the best approach to speed up the build?

Accepted Answer

Configure a volume mount to a Cloud Storage bucket for pip cache and set PIP_CACHE_DIR.. Configuring a volume mount to a Cloud Storage bucket for pip cache and setting PIP_CACHE_DIR allows packages to be cached across builds, significantly reducing download time. Option A is incorrect: custom base images require maintenance and may not cover all dependencies. Option B is incorrect: increasing machine type does not address the network-bound pip download bottleneck. Option C is incorrect: Kaniko cache is for Docker image layer caching, not for pip package caching.

Answer

Use a custom base image that includes all dependencies pre-installed.

Answer

Increase the machine type to a higher CPU and memory instance.

Answer

Use Kaniko cache in Cloud Build with a remote cache location.

Question 13

A team is using Cloud Build to build and deploy to multiple environments (dev, staging, prod) using Cloud Deploy. They want to ensure that only builds from the main branch are promoted to prod. How should they configure this?

Accepted Answer

Configure a Cloud Deploy promotion with an approval gate required for the prod target.. Cloud Deploy's approval gate feature allows you to require manual approval before a release is promoted to a specific target, such as prod. By configuring an approval gate on the prod target, you ensure that only builds from the main branch (which can be verified via the release metadata or source) are manually approved for promotion, providing a controlled, auditable gate. This approach directly enforces the branch-based promotion policy without relying on build-time filtering or IAM restrictions.

Answer

Use Cloud Build tags to mark builds from the main branch and filter in Cloud Deploy.

Answer

Set IAM policies on the Container Registry or Artifact Registry to restrict access to the prod image.

Answer

Set the Cloud Build trigger to only run on the main branch.

Question 14

A company uses Cloud Build with a private pool in a shared VPC to access on-premises resources. Several builds fail intermittently with 'failed to connect to backend' errors when trying to pull from a private npm registry hosted on-premises. The error occurs only during peak hours. What is the most likely cause?

Accepted Answer

The private pool has insufficient worker count or is too small, causing connectivity timeouts.. The intermittent 'failed to connect to backend' errors during peak hours point to resource exhaustion in the private pool. Private pools have a fixed number of workers; when all workers are busy, new builds must wait, and if the queue or connection timeout is exceeded, the build fails. This is a classic capacity issue, not a DNS, certificate, or firewall problem.

Answer

The DNS resolution for the private npm registry is failing due to caching issues.

Answer

The private pool's service account does not have the correct SSL certificates.

Answer

The Cloud NAT IP addresses have been blocked by the on-premises firewall.

Question 15

A large enterprise uses Cloud Build across multiple projects for different microservices. They want to create a centralized CI/CD governance where a single trigger can initiate builds across multiple projects, but each project's artifacts must be stored in a shared Artifact Registry. What is the best way to achieve this?

Accepted Answer

Create a Cloud Build trigger in the governance project that uses a service account with permissions to send build requests to other projects.. Option B is correct because Cloud Build triggers can be created in a central governance project and configured to run builds in other projects by using a service account that has the necessary IAM permissions (such as Cloud Build Editor and Service Account User) in each target project, while all builds can push artifacts to a shared Artifact Registry repository. This centralizes trigger management and governance while still allowing per-project builds and a common artifact destination. Option A is wrong because a shared VPC and private pool only affect networking and worker placement, not cross-project trigger execution or artifact storage. Option C is wrong because Cloud Build triggers do not natively listen to Pub/Sub notifications from another trigger to initiate builds in other projects. Option D is wrong because a Cloud Function reacting to Cloud Source Repo events adds unnecessary complexity and does not provide the centralized trigger governance described.

Answer

Use a shared VPC and a single Cloud Build private pool accessible to all projects, and configure triggers in each project.

Answer

Use a single Cloud Build trigger in the governance project and configure triggers in each project to listen to Pub/Sub notifications from the governance trigger.

Answer

Deploy a Cloud Function that listens to Cloud Source Repo events and creates Cloud Build builds in each project.

Question 16

A team uses Cloud Build with a trigger on Cloud Source Repository. The build fails intermittently with error 'Failed to pull builder image 'gcr.io/cloud-builders/gcloud'' but sometimes succeeds. What is the most likely cause?

Accepted Answer

Network egress from Cloud Build is throttled due to high concurrency.. The intermittent failure to pull the builder image 'gcr.io/cloud-builders/gcloud' indicates a transient network issue rather than a permanent misconfiguration. Cloud Build uses a shared pool of network resources, and under high concurrency, egress traffic to Container Registry can be throttled, causing pull operations to time out or fail. This explains why the build sometimes succeeds and sometimes fails, as throttling depends on the current load.

Answer

The Cloud Build worker pool is in a different region.

Answer

The builder image is too large.

Answer

The build service account lacks permissions to access Container Registry.

Question 17

A company uses Cloud Deploy for continuous delivery to GKE. They have a delivery pipeline with a rollout strategy: canary (25% for 30m) then full. The canary rollout fails because the new revision's health check errors. The team wants to automatically rollback the canary and notify. What native GCP feature can achieve this?

Accepted Answer

Configure a Cloud Deploy rollout strategy with an automated rollback policy.. Cloud Deploy natively supports automated rollback policies within a rollout strategy. When a canary rollout fails due to health check errors, the automated rollback policy can trigger a rollback to the previous stable revision without manual intervention. This is a built-in feature of Cloud Deploy, designed to handle exactly this scenario.

Answer

Configure Cloud Monitoring alerting policy on deployment errors that triggers a Cloud Function to rollback.

Answer

Set up a Cloud Build trigger that detects deployment failure and runs a rollback.

Answer

Use a Cloud Deploy rollout strategy with a post-deploy hook that calls Cloud Run jobs to revert.

Question 18

A company uses Cloud Build with a custom service account that has minimal permissions. The build needs to deploy to Cloud Run. After configuring the service account with roles/run.admin, the build fails with 'Permission denied' on gcloud run deploy. What is the most likely cause?

Accepted Answer

The build service account lacks roles/iam.serviceAccountUser on the Cloud Run runtime service account.. When a Cloud Build service account with only roles/run.admin attempts to deploy to Cloud Run, it must also have the iam.serviceAccountUser role on the Cloud Run runtime service account to impersonate it. Without this, gcloud run deploy fails with 'Permission denied'. Option B is incorrect because an unset Cloud Run service account would result in a different error, typically about an unspecified service account, not a permission denied. Option C is incorrect because roles/cloudbuild.serviceAgent is not required for deploying to Cloud Run; it's a broader role. Option D is unlikely because syntax errors would produce a build configuration parsing error, not a runtime permission denied.

Answer

The Cloud Run service account is not set.

Answer

Cloud Build requires the roles/cloudbuild.serviceAgent role.

Answer

The build configuration file has syntax errors.

Question 19

Which GCP service is used to store build artifacts such as Docker images?

Accepted Answer

Container Registry. Both Container Registry and Artifact Registry are GCP services used to store build artifacts such as Docker images. Container Registry is the older service, while Artifact Registry is the newer, recommended service that supports multiple artifact formats. The question asks which service is used, and both are valid, so the correct answer is 'Both Container Registry and Artifact Registry.'

Answer

Cloud Storage

Answer

Both Container Registry and Artifact Registry

Question 20

A company uses Cloud Build to compile a Java application. The build takes 15 minutes due to dependency downloads. They want to cache the Maven dependencies to speed up subsequent builds. What is the best approach?

Accepted Answer

Use Cloud Build's built-in caching mechanism by specifying volumes.. Cloud Build supports volumes that can be used to cache directories between builds. Specifically, you can specify a volume for the Maven local repository (.m2) to persist across runs, speeding up builds by avoiding repeated downloads. Option A is possible but less integrated and requires manual restoration. Option B is not ideal because layer caching depends on Docker image caching, not Maven dependencies. Option D is not a native Cloud Build feature; the correct approach is via volumes.

Answer

Use a Cloud Storage bucket to store the .m2 directory and restore it at the start of the build.

Answer

Use a Docker layer caching with a custom image that includes dependencies.

Answer

Use Cloud Build's 'cache' configuration to persist directories.