How should I use these Building and implementing CI/CD pipelines practice questions?

Read each scenario carefully and choose your answer before revealing the explanation. Then check why your choice was right or wrong. Repeat until the reasoning feels automatic.

PCDOE · topic practice

Building and implementing CI/CD pipelines practice questions

Q: Can I practise just Building and implementing CI/CD pipelines questions in a focused session?

Yes — use the session launcher on this page to start a 10-, 20-, 30- or 50-question session drawn entirely from the Building and implementing CI/CD pipelines domain.

Practise Google Professional Cloud DevOps Engineer Building and implementing CI/CD pipelines practice questions — original exam-style scenarios with answer choices, explanations, and analysis of common mistakes.

Courseiva uses original exam-style practice questions designed for learning and revision. The goal is to understand the concepts, recognise exam patterns, and improve through explanations — not memorise copied exam dumps.

Reviewed byJohnson Ajibi· MSc IT Security

20 questionsDomain: Building and implementing CI/CD pipelines

Practice 10 questions Browse domain →

What the exam tests

What to know about Building and implementing CI/CD pipelines

Building and implementing CI/CD pipelines questions test whether you can apply the concept in context, not just recognise a definition.

How the topic appears in realistic exam-style scenarios.

Which detail in the question changes the correct answer.

How to eliminate plausible but wrong options.

How to connect the question back to the wider exam objective.

Watch out for

Common Building and implementing CI/CD pipelines exam traps

▸Answering from memory before reading the full scenario.
▸Missing a constraint such as cost, availability, security, scope or command context.
▸Choosing a broad answer when the question asks for the most specific fix.
▸Ignoring why the wrong options are tempting.

Practice set

Building and implementing CI/CD pipelines questions

20 questions · select your answer, then reveal the explanation

Question 1hardmultiple choice

Read the full Building and implementing CI/CD pipelines explanation →

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?

Trap 1: Use a shared VPC and a single Cloud Build private pool accessible…

Private pool shared, but triggers still per project; not centralized.

Trap 2: Use a single Cloud Build trigger in the governance project and…

Triggers cannot be cross-project directly; each project needs its own trigger.

Trap 3: Deploy a Cloud Function that listens to Cloud Source Repo events…

A Cloud Function triggered by Cloud Source Repo events would create separate builds in each project, but it cannot enforce centralised governance because each build operates independently with its own service account and permissions, failing to meet the requirement for a single trigger to orchestrate cross-project builds with shared artifact storage. This approach is tempting because it uses event-driven automation to react to code changes, which would be correct for triggering individual builds per project in a decentralised workflow where no central coordination is needed.

Study all Building and implementing CI/CD pipelines common traps →

A
Use a shared VPC and a single Cloud Build private pool accessible to all projects, and configure triggers in each project.
Why wrong: Private pool shared, but triggers still per project; not centralized.
B
Create a Cloud Build trigger in the governance project that uses a service account with permissions to send build requests to other projects.
Cloud Build triggers can invoke builds in other projects using the 'projects/{projectId}/builds' resource with appropriate IAM.
C
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.
Why wrong: Triggers cannot be cross-project directly; each project needs its own trigger.
D
Deploy a Cloud Function that listens to Cloud Source Repo events and creates Cloud Build builds in each project.
Why wrong: A Cloud Function triggered by Cloud Source Repo events would create separate builds in each project, but it cannot enforce centralised governance because each build operates independently with its own service account and permissions, failing to meet the requirement for a single trigger to orchestrate cross-project builds with shared artifact storage. This approach is tempting because it uses event-driven automation to react to code changes, which would be correct for triggering individual builds per project in a decentralised workflow where no central coordination is needed.

Full breakdown with real-world context →

Question 2easymultiple choice

Read the full Building and implementing CI/CD pipelines explanation →

A development team wants to automatically run unit tests and static code analysis on every push to a Cloud Source Repository, but only run integration tests on merges to the main branch. Which Cloud Build trigger configuration should they use?

Trap 1: Use a single trigger with a substitution variable like '_BRANCH'…

Substitutions are set at trigger creation, not at runtime based on branch.

Trap 2: Create one trigger with a build config that uses the 'branchName'…

Cloud Build does not support conditional step skipping based on substitutions.

Trap 3: Configure one trigger with no branch filter and rely on developers…

Defeats automation; manual triggers are not the intended solution.

Study all Building and implementing CI/CD pipelines common traps →

A
Use a single trigger with a substitution variable like '_BRANCH' and set it to 'main' for integration tests.
Why wrong: Substitutions are set at trigger creation, not at runtime based on branch.
B
Create one trigger with a build config that uses the 'branchName' substitution to conditionally skip integration test steps.
Why wrong: Cloud Build does not support conditional step skipping based on substitutions.
C
Create two triggers: one with a branch filter for '^main$' that runs integration tests, and another with a branch filter for '^.*$' that runs unit tests.
Correct: separate triggers with branch filters allow different pipelines per branch.
D
Configure one trigger with no branch filter and rely on developers to manually trigger integration tests.
Why wrong: Defeats automation; manual triggers are not the intended solution.

Full breakdown with real-world context →

Question 3mediummultiple choice

Read the full Building and implementing CI/CD pipelines explanation →

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?

Trap 1: Kaniko requires a running Docker daemon in the build step.

Kaniko is daemonless; it does not need Docker.

Trap 2: The base image specified in the Dockerfile is not accessible from…

Pull errors are different; the error indicates push failure.

Trap 3: The Dockerfile has an invalid instruction causing Kaniko to fail.

Syntax errors produce different error messages.

Study all Building and implementing CI/CD pipelines common traps →

A
Kaniko requires a running Docker daemon in the build step.
Why wrong: Kaniko is daemonless; it does not need Docker.
B
The base image specified in the Dockerfile is not accessible from the build environment.
Why wrong: Pull errors are different; the error indicates push failure.
C
The Dockerfile has an invalid instruction causing Kaniko to fail.
Why wrong: Syntax errors produce different error messages.
D
The Cloud Build service account does not have the storage.objectAdmin role on the Container Registry bucket.
Missing push permissions cause credential failures.

Full breakdown with real-world context →

Question 4hardmultiple choice

Read the full Building and implementing CI/CD pipelines explanation →

A company uses Spinnaker for continuous delivery across multiple GKE clusters. After a recent infrastructure change, the 'Canary' deployment strategy fails during the 'disable' phase of the old version. The error log shows: 'Unable to disable server group: Not authorized to perform compute.instanceGroups.update.' What is the most likely root cause?

Trap 1: The GKE cluster has reached its maximum node quota.

Quota issues would produce resource exhaustion errors, not authorization.

Trap 2: The Cloud Deploy pipeline is missing the required IAM role for the…

The error is from Spinnaker directly, not Cloud Deploy.

Trap 3: The Kayenta canary analysis service is not configured correctly.

Kayenta handles metric analysis, not disabling server groups.

Study all Building and implementing CI/CD pipelines common traps →

A
The GKE cluster has reached its maximum node quota.
Why wrong: Quota issues would produce resource exhaustion errors, not authorization.
B
The Cloud Deploy pipeline is missing the required IAM role for the Spinnaker service account.
Why wrong: The error is from Spinnaker directly, not Cloud Deploy.
C
The Spinnaker service account lacks the compute.instanceGroups.update permission on the project.
Correct: Spinnaker uses this permission to disable old server groups.
D
The Kayenta canary analysis service is not configured correctly.
Why wrong: Kayenta handles metric analysis, not disabling server groups.

Full breakdown with real-world context →

Question 5easymultiple choice

Read the full Building and implementing CI/CD pipelines explanation →

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?

Trap 1: The Cloud Build service account should have the Owner role on the…

Incorrect: The Owner role is overly permissive and not required. The Cloud Run Admin role should be sufficient if used correctly.

Trap 2: The Cloud Run service must be deployed in the same region as the…

Incorrect: Region mismatch does not cause a permission error. Regions are independent of IAM permissions.

Trap 3: The Cloud Build service account needs the 'run.services.update'…

Incorrect: The Cloud Build service account already has the Cloud Run Admin role, which includes 'run.services.update'. The error persists because the gcloud command does not correctly utilize the service account's permissions.

Study all Building and implementing CI/CD pipelines common traps →

A
The build config must use the Cloud Run deployer step instead of the gcloud command.
Correct: The Cloud Run deployer step is designed to handle permissions correctly and is the recommended method for deploying Cloud Run services from Cloud Build. Using gcloud directly can lead to permission errors despite having the correct roles.
B
The Cloud Build service account should have the Owner role on the project.
Why wrong: Incorrect: The Owner role is overly permissive and not required. The Cloud Run Admin role should be sufficient if used correctly.
C
The Cloud Run service must be deployed in the same region as the build.
Why wrong: Incorrect: Region mismatch does not cause a permission error. Regions are independent of IAM permissions.
D
The Cloud Build service account needs the 'run.services.update' permission or the Cloud Run Admin role.
Why wrong: Incorrect: The Cloud Build service account already has the Cloud Run Admin role, which includes 'run.services.update'. The error persists because the gcloud command does not correctly utilize the service account's permissions.

Full breakdown with real-world context →

Question 6mediummultiple choice

Read the full Building and implementing CI/CD pipelines explanation →

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?

Trap 1: Verify that the Cloud Build service account has the…

DNS permissions are needed for private zones, but the error is connection refused, not DNS resolution.

Trap 2: Check that the Cloud Build service account has the…

Artifactory is not a GCS bucket; the error is network, not permissions.

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

Cloud NAT is for internet egress; on-premises is accessed via VPN/Interconnect.

Study all Building and implementing CI/CD pipelines common traps →

A
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.
Private pools require peering; missing peering stops traffic.
B
Verify that the Cloud Build service account has the dns.networks.bindPrivateZone permission.
Why wrong: DNS permissions are needed for private zones, but the error is connection refused, not DNS resolution.
C
Check that the Cloud Build service account has the storage.objectViewer role on the Artifactory bucket.
Why wrong: Artifactory is not a GCS bucket; the error is network, not permissions.
D
Ensure that Cloud NAT is configured in the private pool's VPC.
Why wrong: Cloud NAT is for internet egress; on-premises is accessed via VPN/Interconnect.

Full breakdown with real-world context →

Question 7hardmulti select

Read the full Building and implementing CI/CD pipelines explanation →

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.)

Trap 1: In the cloudbuild.yaml, add a condition that checks if the branch…

Tags are not branch names.

Trap 2: Create a separate cloudbuild.yaml for production and use a branch…

Branch filter does not match tags.

Trap 3: Configure a manual approval step in Cloud Build that requires a…

Approval does not restrict trigger to tags.

Study all Building and implementing CI/CD pipelines common traps →

A
In the cloudbuild.yaml, use a 'waitFor' condition that only runs the production step when the substitution variable $TAG_NAME matches 'v*.*.*'.
Conditional step execution based on tag substitution.
B
Create a Cloud Build trigger with a tag filter '^v[0-9]+\.[0-9]+\.[0-9]+$' and use that trigger for production deployments.
Tag filter restricts trigger to matching tags.
C
In the cloudbuild.yaml, add a condition that checks if the branch name matches 'v*.*.*'.
Why wrong: Tags are not branch names.
D
Create a separate cloudbuild.yaml for production and use a branch filter '^main$' to trigger it.
Why wrong: Branch filter does not match tags.
E
Configure a manual approval step in Cloud Build that requires a production manager to approve before running the production deployment.
Why wrong: Approval does not restrict trigger to tags.

Full breakdown with real-world context →

Question 8mediummulti select

Read the full Building and implementing CI/CD pipelines explanation →

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.)

Trap 1: A manual approval gate before the 100% phase.

Manual approval would block automatic promotion.

Trap 2: An Istio VirtualService configuration for traffic splitting.

Cloud Deploy uses GKE Service Manifest; Istio is not required.

Study all Building and implementing CI/CD pipelines common traps →

A
A canary deployment strategy with a 10% phase.
Canary enables traffic splitting.
B
An automated promotion policy that promotes after the wait phase.
Automated promotion removes the need for manual step.
C
A manual approval gate before the 100% phase.
Why wrong: Manual approval would block automatic promotion.
D
An Istio VirtualService configuration for traffic splitting.
Why wrong: Cloud Deploy uses GKE Service Manifest; Istio is not required.
E
A 30-minute wait phase in the canary strategy.
Wait phase provides the observation window.

Full breakdown with real-world context →

Question 9mediummultiple choice

Read the full Building and implementing CI/CD pipelines explanation →

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?

Network Topology

Trap 1: The substitution variable ${_ENV} is not properly passed to the…

The substitution is used correctly; the error is not about missing variables.

Trap 2: The 'gcr.io/cloud-builders/gcloud' image does not support the…

The image does support it; the error is permissions.

Trap 3: The Cloud Build service account at the top level does not have the…

The top-level service account has Cloud Run Admin, but the nested build uses a different identity.

Study all Building and implementing CI/CD pipelines common traps →

A
The substitution variable ${_ENV} is not properly passed to the nested build.
Why wrong: The substitution is used correctly; the error is not about missing variables.
B
The nested 'gcloud builds submit' command runs with a different service account that does not have the Cloud Run Admin role.
Nested builds use the default Cloud Build service account of the second build, which may lack permissions.
C
The 'gcr.io/cloud-builders/gcloud' image does not support the 'gcloud run deploy' command.
Why wrong: The image does support it; the error is permissions.
D
The Cloud Build service account at the top level does not have the 'run.services.update' permission.
Why wrong: The top-level service account has Cloud Run Admin, but the nested build uses a different identity.

Full breakdown with real-world context →

Question 10hardmultiple choice

Read the full Building and implementing CI/CD pipelines explanation →

A Cloud Deploy pipeline fails during a rollout with: 'FAILED_PRECONDITION: The release is not in a state that can be promoted.' The Cloud Build service account has the IAM roles shown in the exhibit. What is the missing role or permission?

Exhibit

Refer to the exhibit.

```
{
  "bindings": [
    {
      "role": "roles/cloudbuild.builds.builder",
      "members": [
        "serviceAccount:my-project@cloudbuild.gserviceaccount.com"
      ]
    },
    {
      "role": "roles/clouddeploy.jobRunner",
      "members": [
        "serviceAccount:my-project@cloudbuild.gserviceaccount.com"
      ]
    },
    {
      "role": "roles/clouddeploy.operator",
      "members": [
        "serviceAccount:my-project@cloudbuild.gserviceaccount.com"
      ]
    }
  ]
}
```

Trap 1: The service account is missing the 'roles/clouddeploy.jobRunner'…

It already has that role; jobRunner does not include promote.

Trap 2: The service account is missing the…

It already has that role; the error is about Cloud Deploy promotion.

Trap 3: The service account is missing the 'roles/clouddeploy.operator'…

It already has that role; operator does not include promote.

Study all Building and implementing CI/CD pipelines common traps →

A
The service account is missing the 'roles/clouddeploy.jobRunner' role.
Why wrong: It already has that role; jobRunner does not include promote.
B
The service account is missing the 'roles/cloudbuild.builds.builder' role.
Why wrong: It already has that role; the error is about Cloud Deploy promotion.
C
The service account is missing the 'roles/clouddeploy.operator' role.
Why wrong: It already has that role; operator does not include promote.
D
The service account is missing the 'roles/clouddeploy.approver' role, which includes the 'clouddeploy.releases.promote' permission.
Approver role is needed for promotion.

Full breakdown with real-world context →

Question 11mediummultiple choice

Read the full Building and implementing CI/CD pipelines explanation →

A company is implementing CI/CD for a microservices application on Google Kubernetes Engine (GKE). The team wants to ensure that each service can be built and deployed independently without affecting other services. They also need to enforce that only successfully tested builds are deployed to production. Which CI/CD approach should they use?

Trap 1: Use Cloud Build to build all services and deploy to Cloud Run, then…

Cloud Run is serverless, not GKE, and doesn't meet the requirement of GKE deployment.

Trap 2: Create a single Cloud Build trigger that builds all services and…

A single trigger builds all services together, reducing independence and increasing build time.

Trap 3: Use Spinnaker with a single pipeline that builds all services, and…

Spinnaker is complex and overkill; a single pipeline reduces independence.

Study all Building and implementing CI/CD pipelines common traps →

A
Create separate Cloud Build triggers per microservice, each building a container image, and use Cloud Deploy to manage canary deployments to GKE with automated promotion after tests pass.
This approach provides independent builds and automated promotion based on tests.
B
Use Cloud Build to build all services and deploy to Cloud Run, then use traffic splitting to promote new versions.
Why wrong: Cloud Run is serverless, not GKE, and doesn't meet the requirement of GKE deployment.
C
Create a single Cloud Build trigger that builds all services and deploys to a staging cluster, then manually promote to production.
Why wrong: A single trigger builds all services together, reducing independence and increasing build time.
D
Use Spinnaker with a single pipeline that builds all services, and configure manual judgment gates for production promotion.
Why wrong: Spinnaker is complex and overkill; a single pipeline reduces independence.

Full breakdown with real-world context →

Question 12hardmultiple choice

Read the full Building and implementing CI/CD pipelines explanation →

A DevOps team is troubleshooting a Cloud Build pipeline that fails intermittently when building a container image. The build step uses a custom build step that runs a vulnerability scan. The error log shows: 'Step #1: Error: failed to scan image: context deadline exceeded'. The build configuration includes 'timeout: 600s'. Which is the most likely cause and solution?

Trap 1: The scan tool requires a specific dependency; add an installation…

Missing dependency would cause command not found or similar errors.

Trap 2: There is network latency between Cloud Build and the container…

Network latency would cause connection errors, not a deadline exceeded within the build.

Trap 3: The build step is running out of memory; increase the machine type…

Memory issues would produce out-of-memory errors, not timeout.

Study all Building and implementing CI/CD pipelines common traps →

A
The scan tool requires a specific dependency; add an installation step before scanning.
Why wrong: Missing dependency would cause command not found or similar errors.
B
There is network latency between Cloud Build and the container registry; use VPC Service Controls.
Why wrong: Network latency would cause connection errors, not a deadline exceeded within the build.
C
The build step is running out of memory; increase the machine type to e2-highcpu-8.
Why wrong: Memory issues would produce out-of-memory errors, not timeout.
D
The scan step is taking longer than the build timeout; increase the timeout value in the build configuration.
The error 'context deadline exceeded' indicates the step timed out.

Full breakdown with real-world context →

Question 13easymultiple choice

Read the full Building and implementing CI/CD pipelines explanation →

An organization wants to implement a CI/CD pipeline that automatically deploys to a staging environment on every push to the main branch, and deploys to production only after a manual approval. They use Cloud Build and Cloud Deploy. What is the best way to configure this?

Trap 1: Create a single Cloud Build pipeline that deploys to both staging…

This would not include manual approval; both deployments would be automatic.

Trap 2: Use Cloud Build to deploy to Cloud Run, and configure traffic…

This doesn't provide a separate staging environment with manual approval for production.

Trap 3: Use Cloud Build triggers with two separate build configs: one for…

Manual trigger requires human intervention to start the build, but not approval within a pipeline.

Study all Building and implementing CI/CD pipelines common traps →

A
Configure a Cloud Deploy delivery pipeline with a staging target (automatic promotion) and a production target (require approval).
Cloud Deploy supports automatic promotion to staging and manual approval to production.
B
Create a single Cloud Build pipeline that deploys to both staging and production using conditional steps based on branch name.
Why wrong: This would not include manual approval; both deployments would be automatic.
C
Use Cloud Build to deploy to Cloud Run, and configure traffic splitting to gradually shift traffic from staging to production.
Why wrong: This doesn't provide a separate staging environment with manual approval for production.
D
Use Cloud Build triggers with two separate build configs: one for staging (automatic), one for production (manual trigger).
Why wrong: Manual trigger requires human intervention to start the build, but not approval within a pipeline.

Full breakdown with real-world context →

Question 14mediummulti select

Read the full Building and implementing CI/CD pipelines explanation →

Which TWO practices are recommended for implementing CI/CD pipelines on Google Cloud?

Trap 1: Store service account keys in the build configuration file for…

Hardcoding keys is insecure; use Secret Manager or workload identity.

Trap 2: Deploy to production directly after a successful build without any…

CI/CD best practice includes approval gates for production.

Trap 3: Create a single build pipeline that handles all microservices to…

Monolithic pipelines reduce independence and slow down deployment.

Study all Building and implementing CI/CD pipelines common traps →

A
Store service account keys in the build configuration file for authentication.
Why wrong: Hardcoding keys is insecure; use Secret Manager or workload identity.
B
Deploy to production directly after a successful build without any approval gate.
Why wrong: CI/CD best practice includes approval gates for production.
C
Create a single build pipeline that handles all microservices to reduce complexity.
Why wrong: Monolithic pipelines reduce independence and slow down deployment.
D
Use a Dockerfile to define the build process for containerized applications.
Dockerfile is the standard way to define container builds.
E
Use Cloud Build substitutions to parameterize build configurations for different environments.
Substitutions make pipelines reusable across environments.

Full breakdown with real-world context →

Question 15hardmultiple choice

Read the full Building and implementing CI/CD pipelines explanation →

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?

Trap 1: Define strict version compatibility matrices between services and…

Locking versions reduces flexibility and may not be feasible.

Trap 2: Add a manual testing phase after staging deployment where QA…

Manual testing is slow and does not scale with frequent deployments.

Trap 3: Combine all microservice builds into a single pipeline that builds…

Monolithic pipeline reduces velocity and independence.

Study all Building and implementing CI/CD pipelines common traps →

A
Define strict version compatibility matrices between services and enforce them in the pipeline by locking versions.
Why wrong: Locking versions reduces flexibility and may not be feasible.
B
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.
Canary deployments in staging catch incompatibilities early without slowing development.
C
Add a manual testing phase after staging deployment where QA engineers manually test the integration before production promotion.
Why wrong: Manual testing is slow and does not scale with frequent deployments.
D
Combine all microservice builds into a single pipeline that builds and tests all services together before deploying to staging.
Why wrong: Monolithic pipeline reduces velocity and independence.

Full breakdown with real-world context →

Question 16easymulti select

Read the full Building and implementing CI/CD pipelines explanation →

Which TWO are benefits of using Cloud Build triggers to implement CI/CD pipelines?

Trap 1: Deploy to a specific Google Cloud region based on the trigger

Triggers are not region-specific.

Trap 2: Support only a single branch per trigger

Triggers can be configured for multiple branches using regex.

Trap 3: Automatically provision infrastructure as part of the build

Cloud Build does not manage infrastructure provisioning.

Study all Building and implementing CI/CD pipelines common traps →

A
Start a build automatically when changes are pushed to a repository
Triggers automate builds on source code changes.
B
Deploy to a specific Google Cloud region based on the trigger
Why wrong: Triggers are not region-specific.
C
Support only a single branch per trigger
Why wrong: Triggers can be configured for multiple branches using regex.
D
Integrate with Cloud Source Repositories, GitHub, and Bitbucket
Triggers integrate with these source control systems.
E
Automatically provision infrastructure as part of the build
Why wrong: Cloud Build does not manage infrastructure provisioning.

Full breakdown with real-world context →

Question 17mediummultiple choice

Read the full Building and implementing CI/CD pipelines explanation →

Refer to the exhibit. A team uses this cloudbuild.yaml to deploy a service to Cloud Run. They notice that the deployment fails intermittently with a 'permission denied' error. Which is the most likely cause?

Network Topology

Trap 1: The image tag $SHORT_SHA is invalid because it contains a variable

Variables are substituted correctly by Cloud Build.

Trap 2: The region in the gcloud run deploy command does not match the…

The region is specified as us-central1 and is likely enabled.

Trap 3: The Cloud Build service account does not have permission to push…

Push succeeds, so permission is granted.

Study all Building and implementing CI/CD pipelines common traps →

A
The image tag $SHORT_SHA is invalid because it contains a variable
Why wrong: Variables are substituted correctly by Cloud Build.
B
The Cloud Build service account does not have the `roles/run.admin` or `roles/run.developer` role
These roles grant permission to deploy Cloud Run services.
C
The region in the gcloud run deploy command does not match the region where Cloud Run is enabled
Why wrong: The region is specified as us-central1 and is likely enabled.
D
The Cloud Build service account does not have permission to push images to Artifact Registry
Why wrong: Push succeeds, so permission is granted.

Full breakdown with real-world context →

Question 18hardmultiple choice

Read the full Building and implementing CI/CD pipelines explanation →

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?

Trap 1: Keep the current architecture but modify Cloud Build triggers to…

The short SHA is not guaranteed to be unique across branches and separate repositories still cause race conditions.

Trap 2: Move all source code and manifests into a single repository

This runs tests on every push, which is excessive and uses commit SHA but still deploys on every push to main, which might be fine but does not address the rollback slowness explicitly.

Trap 3: Keep application and manifests in separate repositories

Using 'latest' makes images mutable and separate repos can lead to inconsistency.

Study all Building and implementing CI/CD pipelines common traps →

A
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.
Why wrong: The short SHA is not guaranteed to be unique across branches and separate repositories still cause race conditions.
B
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.
This ensures that only merged code triggers deployments, and the full commit SHA provides an immutable unique tag for easy rollback.
C
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.
Why wrong: This runs tests on every push, which is excessive and uses commit SHA but still deploys on every push to main, which might be fine but does not address the rollback slowness explicitly.
D
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.
Why wrong: Using 'latest' makes images mutable and separate repos can lead to inconsistency.

Full breakdown with real-world context →

Question 19mediumdrag order

Read the full Building and implementing CI/CD pipelines explanation →

Arrange the steps to recover a Google Cloud SQL instance from a point-in-time backup.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

5Step 5

Trap 1: Clone, then Identify time, then Verify, then Promote, then Update…

This is incorrect because you must identify the recovery time before creating a clone; otherwise you cannot specify the point-in-time for the clone.

Trap 2: Identify time, then Clone, then Promote, then Verify, then Update…

This is incorrect because promoting the clone before verifying its data may lead to promoting an inconsistent or incorrect state; verification must precede promotion.

Trap 3: Clone, then Identify time, then Promote, then Verify, then Update…

This is incorrect because it combines the errors of option B and C: identifying time after cloning is invalid, and promoting before verifying is unsafe.

Study all Building and implementing CI/CD pipelines common traps →

A
Identify time, then Clone, then Verify, then Promote, then Update connections
This is the correct order because point-in-time recovery requires first identifying the exact recovery time, then cloning the instance to that time, verifying the clone's data consistency, promoting the clone to become the primary, and finally updating application connections to point to the new primary.
B
Clone, then Identify time, then Verify, then Promote, then Update connections
Why wrong: This is incorrect because you must identify the recovery time before creating a clone; otherwise you cannot specify the point-in-time for the clone.
C
Identify time, then Clone, then Promote, then Verify, then Update connections
Why wrong: This is incorrect because promoting the clone before verifying its data may lead to promoting an inconsistent or incorrect state; verification must precede promotion.
D
Clone, then Identify time, then Promote, then Verify, then Update connections
Why wrong: This is incorrect because it combines the errors of option B and C: identifying time after cloning is invalid, and promoting before verifying is unsafe.

Full breakdown with real-world context →

Question 20mediummatching

Read the full Building and implementing CI/CD pipelines explanation →

Match each Google Cloud deployment strategy to its description.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Two identical environments; switch traffic

Gradually replace instances with new version

Route small traffic percentage to new version

Compare two versions based on user metrics

New version receives mirrored traffic without impact

Trap 1: Blue/green deployment: Gradually replacing instances of the current…

This describes rolling deployment, not blue/green.

Trap 2: Canary deployment: Running two versions side-by-side and routing…

This describes A/B testing, which is similar but typically for comparing features rather than deployment stability.

Trap 3: Rolling deployment: Switching traffic between two separate…

This describes blue/green deployment, not rolling.

Study all Building and implementing CI/CD pipelines common traps →

A
Blue/green deployment: Running two identical environments, only one serves traffic at a time.
Blue/green deployment uses two separate environments (blue and green) to switch traffic between them, minimizing downtime.
B
Blue/green deployment: Gradually replacing instances of the current version with the new one.
Why wrong: This describes rolling deployment, not blue/green.
C
Canary deployment: Releasing a new version to a small subset of users before full rollout.
Canary deployment tests the new version on a small percentage of users to monitor performance and errors.
D
Canary deployment: Running two versions side-by-side and routing users based on test groups.
Why wrong: This describes A/B testing, which is similar but typically for comparing features rather than deployment stability.
E
Rolling deployment: Updating instances incrementally without downtime.
Rolling deployment replaces old instances with new ones gradually, maintaining availability.
F
Rolling deployment: Switching traffic between two separate environments.
Why wrong: This describes blue/green deployment, not rolling.

Full breakdown with real-world context →

Continue with 20-question session →

Free account

Track your progress over time

Create a free account to save your results and see which topics improve across sessions.

Focused Building and implementing CI/CD pipelines sessions

Start a Building and implementing CI/CD pipelines only practice session

Every question in these sessions is drawn from the Building and implementing CI/CD pipelines domain — nothing else.

10 questions 20 questions 30 questions 50 questions

Browse all Building and implementing CI/CD pipelines questions →Mixed PCDOE session

Frequently asked questions

What does the PCDOE exam test about Building and implementing CI/CD pipelines?: Building and implementing CI/CD pipelines questions test whether you can apply the concept in context, not just recognise a definition.
How should I use these practice questions?: Select your answer before revealing the explanation. Then read why each option is right or wrong — this active recall approach builds retention far faster than re-reading notes.
Can I practise just Building and implementing CI/CD pipelines questions in a focused session?: Yes — the session launcher on this page draws every question from the Building and implementing CI/CD pipelines domain. Use a 10-question session first to gauge your baseline, then move to 20 or 30 once the weak spots are clear.
Where can I practise other PCDOE topics?: Use the topic links above to move to related areas, or go back to the PCDOE question bank to see all topics.
Are these real exam questions or dumps?: These are original practice questions written to test the same concepts the PCDOE exam covers. They are not copied from any real exam or dump site.

Building and implementing CI/CD pipelines only

10 questions 20 questions 30 questions 50 questions

Mixed PCDOE session

Track your progress

A free account saves results across sessions and highlights which topics need work.

Study resources

All PCDOE questions Building and implementing CI/CD pipelines domain overview PCDOE exam guide

Exam traps to avoid

▸Answering from memory before reading the full scenario.
▸Missing a constraint such as cost, availability, security, scope or command context.
▸Choosing a broad answer when the question asks for the most specific fix.
▸Ignoring why the wrong options are tempting.

Building and implementing CI/CD pipelines practice questions

What to know about Building and implementing CI/CD pipelines

Common Building and implementing CI/CD pipelines exam traps

Building and implementing CI/CD pipelines questions

A development team wants to automatically run unit tests and static code analysis on every push to a Cloud Source Repository, but only run integration tests on merges to the main branch. Which Cloud Build trigger configuration should they use?

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?

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?

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?

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.)

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.)

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?

A Cloud Deploy pipeline fails during a rollout with: 'FAILED_PRECONDITION: The release is not in a state that can be promoted.' The Cloud Build service account has the IAM roles shown in the exhibit. What is the missing role or permission?

Exhibit

An organization wants to implement a CI/CD pipeline that automatically deploys to a staging environment on every push to the main branch, and deploys to production only after a manual approval. They use Cloud Build and Cloud Deploy. What is the best way to configure this?

Which TWO practices are recommended for implementing CI/CD pipelines on Google Cloud?

Which TWO are benefits of using Cloud Build triggers to implement CI/CD pipelines?

Refer to the exhibit. A team uses this cloudbuild.yaml to deploy a service to Cloud Run. They notice that the deployment fails intermittently with a 'permission denied' error. Which is the most likely cause?

Arrange the steps to recover a Google Cloud SQL instance from a point-in-time backup.

Match each Google Cloud deployment strategy to its description.

Track your progress over time

Start a Building and implementing CI/CD pipelines only practice session

Related PCDOE topic practice pages

Bootstrapping a Google Cloud organization for DevOps practice questions

Applying site reliability engineering practices practice questions

Optimizing performance and cost practice questions