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

Question 1

A company uses Cloud Build to deploy a containerized application to Google Kubernetes Engine (GKE). They want to ensure that the deployment only proceeds if the container image passes a vulnerability scan with no critical vulnerabilities. They also want to automatically roll back if the deployment fails. Which combination of Google Cloud services should they use?

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

Accepted Answer

Cloud Build with a custom step that runs a vulnerability scan and fails the build, and Cloud Deploy with a rollback configuration.. Cloud Build can integrate a vulnerability scan step that fails the build if critical issues are found, acting as a gate. Cloud Deploy is designed for continuous delivery to GKE and supports rollback strategies, such as automatically rolling back if the deployment fails to become healthy. Together, they provide the required security check and rollback capability.

Answer

Binary Authorization with a policy that requires attestations, and GKE with Istio for traffic management.

Answer

Artifact Registry with vulnerability scanning enabled, and GKE with Pod Security Policies.

Answer

Cloud Build with a step that deploys to GKE using kubectl, and Cloud Monitoring for alerting.

Question 2

You are designing a CI/CD pipeline for a microservices application on GKE. You want to use Cloud Deploy to manage progressive rollouts. Your security team requires that deployments to production only proceed if the container images are signed by a trusted authority. Which Cloud Deploy configuration should you implement?

Accepted Answer

Enable Binary Authorization on the GKE cluster and configure the Cloud Deploy delivery pipeline with a `binaryAuthorization` policy that requires attestations from a trusted attestor.. Cloud Deploy integrates with Binary Authorization to enforce image signature verification at deploy time. By enabling Binary Authorization on the GKE cluster and configuring the delivery pipeline to use a policy that requires attestations, Cloud Deploy will only deploy images that have valid attestations. This is a declarative, policy-based approach that meets the security requirement without custom scripting.

Answer

In the delivery pipeline, add a `verify` stage that runs a script to check image signatures using `cosign verify` before the deploy stage.

Answer

Use Cloud Deploy's `canary` deployment strategy with a custom analysis job that verifies image signatures and aborts the rollout if verification fails.

Answer

Enable Binary Authorization on the GKE cluster and configure the Cloud Deploy delivery pipeline to use the `binaryAuthorization` evaluation mode `ALWAYS_ALLOW`.

Question 3

A team is using Cloud Build to build a Docker image and push it to Artifact Registry. They want to ensure that the image is scanned for vulnerabilities before deployment. Which Cloud Build step should they add to their build config?

Accepted Answer

Enable vulnerability scanning on the Artifact Registry repository, and add a step that waits for the scan to complete and checks for critical vulnerabilities using `gcloud artifacts docker images describe`.. Vulnerability scanning in Artifact Registry is enabled at the repository level. Once enabled, images are scanned automatically on push. To enforce a gate in Cloud Build, you can add a step that queries the scan results and fails the build if critical vulnerabilities are present. The other options use invalid or deprecated commands that do not trigger or retrieve scan results.

Answer

A step that uses the `gcr.io/cloud-builders/gcloud` builder to call `gcloud container images scan`.

Answer

A step that runs `gcloud artifacts docker images list --show-occurrences` to retrieve vulnerability findings.

Answer

A step that runs `gcloud artifacts docker images scan`.

Question 4

A startup uses Cloud Build to build and push container images to Artifact Registry. Their security team requires that all images be scanned for vulnerabilities before they are deployed to GKE. The team wants to integrate this check into the CI/CD pipeline without adding external tools. What should they do?

Accepted Answer

Add a Cloud Build step that runs `gcloud artifacts docker images scan` and then checks the results with `gcloud artifacts docker images list-vulnerabilities`, failing the build if critical vulnerabilities exist.. To enforce vulnerability scanning in Cloud Build without external tools, the pipeline must explicitly run a scan and then evaluate the results to decide whether to fail. The `gcloud artifacts docker images scan` command triggers scanning, and `gcloud artifacts docker images list-vulnerabilities` retrieves findings; a custom step can parse these and fail the build on critical vulnerabilities. Other options either rely on nonexistent features or assume automatic build failure that is not provided.

Answer

Configure Artifact Registry to automatically scan images on push and set up a Cloud Build trigger that fails if the scan finds vulnerabilities.

Answer

Enable Container Analysis on the Artifact Registry repository and configure the build to fail if vulnerabilities are found using the `gcloud artifacts docker images scan` command.

Answer

Use Cloud Build's built-in vulnerability scanning step that automatically blocks builds with critical vulnerabilities.

Question 5

A healthcare company uses Cloud Build to build and deploy a Java application to App Engine. They have a cloudbuild.yaml that includes steps for unit tests, building a JAR, and deploying. They want to optimize build times by caching Maven dependencies between builds. Which approach should they take?

Accepted Answer

Use the maven:3.8.6-openjdk-11 builder and add a step to restore the ~/.m2 directory from a Cloud Storage bucket before the build, and another step to save it after the build.. To cache Maven dependencies between Cloud Build runs, you need to persist the ~/.m2 directory externally. The correct method is to add steps that download the directory from a Cloud Storage bucket before the build and upload it after. This approach leverages Cloud Storage as a cache and significantly speeds up subsequent builds by reusing dependencies.

Answer

Use the maven:3.8.6-openjdk-11 builder and enable the Cloud Build cache by setting the --cache-from flag to a previously built image.

Answer

Use the maven:3.8.6-openjdk-11 builder and configure a volume to persist the ~/.m2 directory across builds.

Answer

Use the maven:3.8.6-openjdk-11 builder and configure the build to use a Cloud Storage bucket as a Maven repository cache by setting the localRepository to a mounted bucket.

Question 6

A development team is using Cloud Build to build and test a Node.js application. They want to reduce build times by caching dependencies between builds. Which Cloud Build feature should they use?

Accepted Answer

Configure a Cloud Storage bucket as a cache and use the `gsutil` command to copy the `node_modules` directory to and from the bucket in the build steps.. Cloud Build does not have built-in dependency caching, so the team should implement a custom caching mechanism using Cloud Storage. By copying the `node_modules` directory to a bucket at the end of a build and restoring it at the beginning of the next build, they can avoid re-downloading dependencies. This is a widely used pattern and can be optimized by keying the cache on the hash of the lock file.

Answer

Use the `kaniko` builder with the `--cache=true` flag to cache layers in Artifact Registry.

Answer

Enable the `--cache` flag in the `gcloud builds submit` command to automatically cache all build artifacts.

Answer

Use a persistent volume in the build steps to store the `node_modules` directory across builds.

Question 7

Your organization uses Cloud Deploy to manage deployments to multiple GKE clusters across different environments. You need to ensure that a deployment to the production environment only proceeds after a manual approval by a release manager. Which Cloud Deploy feature should you use?

Accepted Answer

Use Cloud Deploy's `approval` field in the delivery pipeline to specify that a manual approval is required before deploying to the production target.. Cloud Deploy provides a built-in approval mechanism through the `approval` field in the delivery pipeline. When configured, the pipeline will pause before deploying to the specified target and wait for a manual approval. This is the correct way to gate production deployments and ensures that only authorized personnel can promote releases.

Answer

Create a Cloud Build trigger that listens for a Pub/Sub message from Cloud Deploy and sends an email to the release manager to manually trigger the next stage.

Answer

Configure a `canary` deployment strategy with a long pause and require manual promotion.

Answer

Set the `requireApproval` flag on the GKE cluster's deployment resource to enforce manual approval before any deployment.

Question 8

A DevOps team uses Cloud Build to run unit tests and build artifacts for a Python application. They want to speed up builds by caching dependencies between builds. The dependencies are installed into a virtual environment at `/workspace/venv`. They need the cache to persist across builds and be shared by all builds in the project. What should they do?

Accepted Answer

Store the virtual environment in a Cloud Storage bucket and copy it into `/workspace/venv` at the start of each build, then upload changes at the end.. Cloud Build workspaces are ephemeral, so to cache dependencies across builds, the team must use an external persistent store. Cloud Storage is the native choice: copy the virtual environment from a bucket at the start of the build and upload it back after updates. This pattern is widely used for dependency caching. The other options either describe unsupported features or misapply Docker layer caching.

Answer

Configure the build to use a persistent disk that is attached to each build and mounted at `/workspace/venv`.

Answer

Use the `--cache-from` flag with a cached image stored in Artifact Registry to restore dependencies.

Answer

Enable the `cache` option in the Cloud Build trigger to automatically persist `/workspace` between builds.

Question 9

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 10

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 11

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 12

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 13

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 14

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 15

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.. Option D is correct because using a Dockerfile to define the build process is the standard, reproducible way to build containerized applications in a CI/CD pipeline, and Cloud Build natively supports Dockerfile-based builds (e.g., via the docker builder or `gcloud builds submit`), ensuring consistent images across environments. Option E is correct because Cloud Build substitutions (user-defined variables like `${_ENV}` or built-in ones like `$PROJECT_ID`) let you parameterize a single build configuration (cloudbuild.yaml) so the same pipeline can target dev, staging, and prod with different values, avoiding duplicated configs. Option A is wrong because storing service account keys in the build configuration file exposes long-lived credentials in source control; the recommended practice is Workload Identity Federation or attaching a user-managed service account to the build, not embedding keys. Option B is wrong because deploying straight to production after a successful build skips approval gates and progressive delivery, which is not a recommended CI/CD practice for production safety. Option C is wrong because a single monolithic pipeline for all microservices reduces isolation and blast radius control; per-service pipelines (or at least independent triggers) are recommended so services can build, test, and deploy independently.

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.