PCDOE Building and implementing CI/CD pipelines Practice Test 1 — 15 Questions

Question 1

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?

Choose an answer to begin — your selection is scored in the full session.

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.. Using a single Cloud Build trigger in the governance project with a service account that has permissions to initiate builds in other projects is the most direct and centralized approach. Option A is incorrect because triggers are per-project and a shared VPC or private pool does not enable cross-project triggers. Option C is incorrect because Cloud Build triggers do not natively emit Pub/Sub messages to trigger builds in other projects; this would require additional custom infrastructure and is not a native feature. Option D is incorrect because using a Cloud Function adds unnecessary complexity and is less direct than the native Cloud Build cross-project service account approach.

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 2

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?

Accepted Answer

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.. Cloud Build triggers allow you to define separate triggers with branch filters to execute different build configurations based on the branch. By creating one trigger with a branch filter of '^main$' for integration tests and another with '^.*$' for unit tests, you ensure unit tests run on every push to any branch, while integration tests run only on merges to main. This approach directly maps the desired behavior without requiring conditional logic or manual intervention.

Answer

Use a single trigger with a substitution variable like '_BRANCH' and set it to 'main' for integration tests.

Answer

Create one trigger with a build config that uses the 'branchName' substitution to conditionally skip integration test steps.

Answer

Configure one trigger with no branch filter and rely on developers to manually trigger integration tests.

Question 3

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?

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 4

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?

Accepted Answer

The Spinnaker service account lacks the compute.instanceGroups.update permission on the project.. The error 'Unable to disable server group: Not authorized to perform compute.instanceGroups.update' directly indicates an IAM permissions issue. In Spinnaker, the service account used to interact with GCP must have the compute.instanceGroups.update permission to manage instance groups during the disable phase of a canary deployment. Option C correctly identifies that the Spinnaker service account lacks this specific permission on the project.

Answer

The GKE cluster has reached its maximum node quota.

Answer

The Cloud Deploy pipeline is missing the required IAM role for the Spinnaker service account.

Answer

The Kayenta canary analysis service is not configured correctly.

Question 5

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 6

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 7

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*.*.*'.. Cloud Build supports substitution variables like $TAG_NAME, which can be used in a 'waitFor' condition or as part of a step's entrypoint logic to gate execution. By checking if $TAG_NAME matches the glob pattern 'v*.*.*', the production deployment step will only run when the build is triggered by a matching tag, ensuring environment-specific control within a single cloudbuild.yaml.

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 8

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.. A canary deployment strategy in Cloud Deploy allows you to define phases that gradually shift traffic to a new revision. A 10% phase is the first step in this strategy, ensuring only a small subset of users experience the new version initially, which aligns with the requirement to start with 10% traffic.

Answer

A manual approval gate before the 100% phase.

Answer

An Istio VirtualService configuration for traffic splitting.

Question 9

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 10

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?

Accepted Answer

The service account is missing the 'roles/clouddeploy.approver' role, which includes the 'clouddeploy.releases.promote' permission.. The error 'FAILED_PRECONDITION: The release is not in a state that can be promoted' occurs when a Cloud Deploy pipeline attempts to promote a release but the service account lacks the `clouddeploy.releases.promote` permission. This permission is included in the `roles/clouddeploy.approver` role, which is required to trigger a promotion from one target to the next in the pipeline. Without this role, the release cannot be promoted even if other deployment permissions are present.

Answer

The service account is missing the 'roles/clouddeploy.jobRunner' role.

Answer

The service account is missing the 'roles/cloudbuild.builds.builder' role.

Answer

The service account is missing the 'roles/clouddeploy.operator' role.

Question 11

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?

Accepted Answer

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.. It uses separate Cloud Build triggers per microservice to enable independent builds, and Cloud Deploy with canary deployments and automated promotion after tests pass ensures that only successfully tested builds reach production. This approach aligns with the requirements of independent service deployment and gated promotion to production on GKE.

Answer

Use Cloud Build to build all services and deploy to Cloud Run, then use traffic splitting to promote new versions.

Answer

Create a single Cloud Build trigger that builds all services and deploys to a staging cluster, then manually promote to production.

Answer

Use Spinnaker with a single pipeline that builds all services, and configure manual judgment gates for production promotion.

Question 12

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?

Accepted Answer

The scan step is taking longer than the build timeout; increase the timeout value in the build configuration.. The error 'context deadline exceeded' indicates that the custom vulnerability scan step is taking longer than the build's configured timeout of 600 seconds. Cloud Build enforces a hard timeout for the entire build; if any step exceeds this duration, the build is terminated. Increasing the timeout value in the build configuration provides more time for the scan to complete, directly addressing the root cause.

Answer

The scan tool requires a specific dependency; add an installation step before scanning.

Answer

There is network latency between Cloud Build and the container registry; use VPC Service Controls.

Answer

The build step is running out of memory; increase the machine type to e2-highcpu-8.

Question 13

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?

Accepted Answer

Configure a Cloud Deploy delivery pipeline with a staging target (automatic promotion) and a production target (require approval).. Cloud Deploy natively supports delivery pipelines with multiple targets, where you can configure automatic promotion to staging and require manual approval for production. This aligns with the requirement for a CI/CD pipeline that deploys to staging on every push to main and to production only after manual approval, using Cloud Build for the build and Cloud Deploy for the deployment orchestration.

Answer

Create a single Cloud Build pipeline that deploys to both staging and production using conditional steps based on branch name.

Answer

Use Cloud Build to deploy to Cloud Run, and configure traffic splitting to gradually shift traffic from staging to production.

Answer

Use Cloud Build triggers with two separate build configs: one for staging (automatic), one for production (manual trigger).

Question 14

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

Accepted Answer

Use a Dockerfile to define the build process for containerized applications.. Using a Dockerfile to define the build process for containerized applications is a recommended practice in CI/CD pipelines on Google Cloud. It ensures that the application is built consistently across all environments, leveraging Cloud Build's native support for Dockerfiles to produce container images that can be stored in Container Registry or Artifact Registry.

Answer

Store service account keys in the build configuration file for authentication.

Answer

Deploy to production directly after a successful build without any approval gate.

Answer

Create a single build pipeline that handles all microservices to reduce complexity.

Question 15

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.