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 1easymultiple 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 2mediummultiple choice

Read the full NAT/PAT 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 3hardmultiple 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 4easymultiple 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 build config must use the Cloud Run deployer step instead of…

gcloud is fine if permissions are correct.

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

Overly permissive; Cloud Run Admin is sufficient.

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

Region mismatch would produce a different error.

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.
Why wrong: gcloud is fine if permissions are correct.
B
The Cloud Build service account should have the Owner role on the project.
Why wrong: Overly permissive; Cloud Run Admin is sufficient.
C
The Cloud Run service must be deployed in the same region as the build.
Why wrong: Region mismatch would produce a different error.
D
The Cloud Build service account needs the 'run.services.update' permission or the Cloud Run Admin role.
The error indicates missing permissions; Cloud Run Admin includes it.

Full breakdown with real-world context →

Question 5mediummultiple 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 6hardmulti 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 7mediummulti 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 8mediummultiple 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 9hardmultiple 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 10mediummultiple 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 11hardmultiple 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 12easymultiple 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 13mediummulti 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 14hardmultiple choice

Read the full NAT/PAT 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 15easymulti 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 16mediummultiple 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 17hardmultiple 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 18mediumdrag 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

Question 19mediummatching

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

Question 20easymultiple choice

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

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?

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

While possible, it requires additional configuration and is not as automatic as a dedicated trigger.

Trap 2: Use Cloud Deploy to manage the rollout.

Cloud Deploy is for Kubernetes and Anthos, not directly for Cloud Run.

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

Cloud Scheduler is not designed for event-driven deployments; it adds latency and complexity.

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

A
Use Cloud Build builder to deploy to Cloud Run in the same pipeline.
Why wrong: While possible, it requires additional configuration and is not as automatic as a dedicated trigger.
B
Use Cloud Deploy to manage the rollout.
Why wrong: Cloud Deploy is for Kubernetes and Anthos, not directly for Cloud Run.
C
Configure a Cloud Run trigger on Artifact Registry push.
Cloud Run triggers can automatically deploy new images pushed to Artifact Registry.
D
Use Cloud Scheduler to periodically check for new images and deploy.
Why wrong: Cloud Scheduler is not designed for event-driven deployments; it adds latency and complexity.

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.

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?

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

Managing service incidents practice questions

Managing Google Cloud costs practice questions