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

Question 1

During a Cloud Build pipeline, a build step fails because the Docker image tag already exists in Container Registry. The team wants to avoid overwriting tags. What is the best practice to resolve this?

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

Accepted Answer

Use the commit SHA as the image tag in the build step.. Using the commit SHA as the image tag guarantees uniqueness because each commit produces a distinct SHA. This prevents tag collisions in Container Registry without overwriting, as the SHA is immutable for that commit. It also provides traceability back to the exact source code version that produced the image.

Answer

Specify the :latest tag and always push to that tag.

Answer

Add a step to pull the image before building to ensure it's present.

Answer

Configure the build to retry on failure with a backoff.

Question 2

A company uses Cloud Build to deploy a microservices application to Google Kubernetes Engine (GKE). They want to integrate Container Analysis to scan images for vulnerabilities before deployment. What is the minimal set of changes needed to achieve this?

Accepted Answer

Enable the Container Analysis API; no changes to the build configuration are needed.. Enabling the Container Analysis API allows Cloud Build to automatically scan container images for vulnerabilities when they are pushed to Container Registry or Artifact Registry. No additional build steps or configuration changes are required. Option B is incorrect because migrating to Artifact Registry is not minimal; Container Analysis works with both registries. Option C is incorrect because Cloud Build already integrates with Container Analysis, so adding a separate scanner is unnecessary. Option D is incorrect because Binary Authorization is a policy enforcement tool that uses scan results but does not perform scanning itself.

Answer

Migrate images from Container Registry to Artifact Registry and enable vulnerability scanning there.

Answer

Add a build step to run a vulnerability scanner CLI tool before pushing the image.

Answer

Enable Binary Authorization to block deployment of vulnerable images.

Question 3

A team implements canary deployments using Cloud Deploy and deploys to GKE. They want to automatically roll back if the canary release's error rate exceeds 5% within 10 minutes. Which approach should they use?

Accepted Answer

Set up Cloud Deploy with a rollout strategy that uses Cloud Monitoring metrics to automatically rollback.. Cloud Deploy supports rollout strategies that can reference Cloud Monitoring metrics to automatically roll back a canary release if error rates exceed a threshold. This native integration allows defining a canary deployment with automated rollback based on metrics like error rate within a specified time window, directly meeting the requirement.

Answer

Deploy using Spinnaker on GKE with a canary pipeline that includes an automated rollback step.

Answer

Configure a Cloud Build step to monitor the canary and rollback if needed.

Answer

Use a GKE rolling update strategy within the deployment manifest.

Question 4

Which TWO options are valid methods to trigger a Cloud Build build when code is pushed to a Cloud Source Repository?

Accepted Answer

Use a Cloud Pub/Sub message sent to the Cloud Build topic to create a build.. Options A and D are correct. Cloud Build triggers can be based on branch or tag push, and can also be triggered via Pub/Sub message. Option B is incorrect - Cloud Build does not directly listen to Cloud Pub/Sub subscriptions without a trigger. Option C is incorrect - builds are not automatically triggered by Cloud Logging. Option E is incorrect - Cloud Scheduler cannot directly trigger a build without a Pub/Sub or HTTP intermediary.

Answer

Have Cloud Logging monitor the repository and create a build via a logs-based metric.

Answer

Set up a Cloud Pub/Sub subscription that forwards events to Cloud Build.

Answer

Configure Cloud Scheduler to call the Cloud Build API periodically.

Question 5

Which TWO deployment strategies are directly supported by Cloud Deploy for GKE?

Accepted Answer

Canary. Options C and E are correct. Cloud Deploy for GKE directly supports canary (C) and blue-green (E) deployment strategies. Option A (Rolling update) is incorrect because rolling updates are managed natively by GKE itself, not as a Cloud Deploy strategy. Option B (A/B testing) is incorrect; A/B testing is a traffic management technique but not a built-in deployment strategy in Cloud Deploy. Option D (Shadow) is incorrect; shadow deployments are not supported by Cloud Deploy.

Answer

Rolling update

Answer

A/B testing

Answer

Shadow

Question 6

Which THREE are best practices for securing a CI/CD pipeline on Google Cloud?

Accepted Answer

Use Secret Manager to securely pass credentials to build steps.. Options A, B, and E are correct. Using Secret Manager (A) securely passes credentials without hardcoding or storing them in repos. Binary Authorization (B) ensures only signed, trusted container images are deployed, preventing tampering. Cloud Build private pools (E) provide isolated, controlled build environments, reducing exposure. Option C is incorrect because public pools may be less secure and not recommended for sensitive workloads. Option D is incorrect because storing service account keys in source repos is a security risk.

Answer

Run builds on the publicly hosted pool for better scalability.

Answer

Store service account keys in the source repository for build steps to use.

Question 7

A developer wants to trigger a Cloud Build execution whenever a pull request is created against the main branch in Cloud Source Repositories. Which Cloud Build trigger configuration should be used?

Accepted Answer

Event: pull request on branch ^main$. The correct trigger configuration is an event of type 'pull request' on the branch matching ^main$. Cloud Build supports pull request triggers that fire when a PR is created or updated against a specific branch, allowing automated checks or builds before merge. This directly addresses the requirement to trigger on PR creation against the main branch.

Answer

Event: push on branch ^main$

Answer

Event: push on tag

Answer

Event: manual invocation

Question 8

A team uses a monorepo with multiple microservices in separate directories. They want to build only the changed service(s) when a push occurs to the repo. How can they achieve this efficiently?

Accepted Answer

Create multiple Cloud Build triggers, each with a different includeFiles filter matching the service directory.. Cloud Build triggers can be configured with includeFiles filters to trigger only when files in a specific directory change, allowing each microservice to build independently. Option A builds all services, which is inefficient for a monorepo with multiple microservices. Option B uses Cloud Functions to invoke Cloud Build, adding unnecessary complexity and overhead. Option D relies on dynamic detection with git diff, which is not a built-in feature of Cloud Build triggers and would require custom scripting.

Answer

Use a single Cloud Build trigger with a Dockerfile build step that builds all services.

Answer

Use Cloud Functions to invoke Cloud Build per changed directory.

Answer

Use a Cloud Build trigger with a build config that dynamically detects changes using git diff.

Question 9

During a Cloud Build execution, the step fails with 'Error: could not find a valid 'Dockerfile' in context '.''. The build configuration file is located in a subdirectory called 'build/' and the Dockerfile is in the root of the repository. How should the team fix this?

Accepted Answer

Specify the 'dir' field in the build step to point to the root.. The Cloud Build step's `dir` field explicitly sets the working directory for the step. By specifying `dir: '.'` (or the repository root), Cloud Build will look for the Dockerfile in the root context, even though the build configuration file (`cloudbuild.yaml`) resides in the `build/` subdirectory. This ensures the Docker build context points to the correct location where the Dockerfile exists.

Answer

Create a symbolic link.

Answer

Move the Cloud Build configuration file to the root.

Answer

Use the 'substitutions' to change context.

Question 10

A team uses Spinnaker on GKE for deployment. They notice that deployments are taking too long because of manual judgment gates. They want to automatically approve deployments if the canary analysis passes predefined thresholds. What Spinnaker feature should they use?

Accepted Answer

Automated canary analysis. Spinnaker's Automated Canary Analysis (ACA) feature allows teams to define canary analysis thresholds and automatically promote or roll back deployments based on the analysis results, eliminating the need for manual judgment gates. This directly addresses the requirement to automatically approve deployments when predefined thresholds are met, without human intervention.

Answer

Automated rollback

Answer

Policy engine with OPA

Answer

Pipeline expressions

Question 11

A team is setting up CI/CD for a microservices architecture. They want to ensure each service is independently buildable and deployable. What practices should they adopt? (Select THREE)

Accepted Answer

Use Artifact Registry with separate repositories per service. Option A is correct because Artifact Registry lets you create separate repositories per service, so each microservice's container images and packages are versioned and stored independently, which supports independent build and deploy workflows. Option C is correct because a single monorepo with separate Cloud Build triggers per service (using included files or path filters) allows each service to be built only when its own code changes, preserving independent buildability. Option D is correct because separate source repositories per service give each team full autonomy over its own codebase, release cadence, and pipeline, which is the clearest way to ensure services are independently buildable and deployable. Option B is not correct here because Cloud Deploy's multi-target pipeline is about promoting releases across environments (e.g., dev, staging, prod), not about making each service independently buildable. Option E is not correct because a single Cloud Build config with substitutions to build multiple services couples the services into one build definition, which undermines independent buildability and deployability.

Answer

Use Cloud Deploy's multi-target pipeline

Answer

Use Cloud Build's build config with substitutions to build multiple services

Question 12

Refer to the exhibit. The build fails with error: 'invalid tag format' for the image. What is the issue?

Accepted Answer

The substitution $SHORT_SHA is not defined and the tag becomes empty.. The error 'invalid tag format' occurs because the substitution $SHORT_SHA is not defined in the Cloud Build trigger or build configuration. When the substitution is not defined, it resolves to an empty string, resulting in an image tag that is either empty or malformed (e.g., 'gcr.io/project/image:'), which violates the tag format requirements.

Answer

The project ID substitution is not present.

Answer

The build step must explicitly push the image.

Answer

The image name must include a tag.

Question 13

An organization uses Cloud Deploy with Skaffold to manage progressive delivery on GKE. After a rollout, the new revision shows a higher error rate in Stackdriver, but the Cloud Deploy pipeline did not automatically roll back. What is the most likely cause?

Accepted Answer

The Cloud Deploy pipeline does not have a stackdriverMetrics verification job defined to check error rates.. Cloud Deploy does not automatically roll back based on error rates unless a verification job (such as a Stackdriver metrics check) is explicitly defined in the pipeline. Without a verification step that monitors error rates and fails the rollout, Cloud Deploy will continue advancing through phases even if the new revision is unhealthy. Therefore, the absence of a stackdriverMetrics verification job is the most likely cause.

Answer

The rollout strategy includes a manual approval step before advancing to the next phase.

Answer

The release was created with a '--disable-rollback' flag.

Answer

The rollout has not yet reached 100% traffic, so Cloud Deploy waits for full completion before evaluating health.

Question 14

Which THREE of the following are best practices for securing a CI/CD pipeline using Cloud Build? (Choose 3.)

Accepted Answer

Configure Cloud Build triggers to run only from protected branches (e.g., main, release).. Option A is correct because restricting Cloud Build triggers to protected branches such as main or release prevents unreviewed or malicious code from being built and deployed, enforcing code review and branch protection as a supply-chain control. Option B is correct because Secret Manager integrated with Cloud Build via the availableSecrets field injects secrets at build time without hardcoding them in source, cloudbuild.yaml, or trigger substitutions, reducing credential leakage. Option D is correct because enabling Container Analysis on the Artifact Registry repository automatically scans pushed images for vulnerabilities (CVEs) after the build, providing continuous visibility into image risk. Option C is not a best practice because Storage Admin is overly broad; pushing images only requires Artifact Registry Writer (or roles/artifactregistry.writer), so least privilege should be applied instead. Option E is not a best practice because disabling build cache does not meaningfully improve security and increases build time and cost; cache integrity is better addressed by trusted builders and pinned dependencies.

Answer

Grant the Cloud Build service account the Storage Admin role for the project to allow pushing images.

Answer

Disable build cache to ensure fresh builds and avoid using potentially compromised cached layers.

Question 15

A startup is building a CI/CD pipeline for their Cloud Run service. They use Cloud Build to build a Docker image, push it to Artifact Registry, and then deploy to Cloud Run with the 'gcloud run deploy' command in the build config. The initial deployment works, but subsequent builds fail at the deploy step with a permission error: 'Permission denied to deploy revision to Cloud Run service'. The Cloud Build service account has the Cloud Run Developer role. The developers can manually deploy from their workstations using their own accounts. What is the most likely cause?

Accepted Answer

The Cloud Build service account needs the 'iam.serviceAccounts.actAs' permission on the Cloud Run runtime service account.. The Cloud Build service account needs the 'iam.serviceAccounts.actAs' permission on the Cloud Run runtime service account to deploy a revision that runs as that service account. Even with the Cloud Run Developer role, the actAs permission is required to impersonate the runtime service account during deployment. This is a common IAM requirement in Google Cloud.

Answer

The developers added the '--impersonate-service-account' flag inadvertently in the build config.

Answer

The Cloud Run API is not enabled in the project.

Answer

The Cloud Build service account lacks Artifact Registry read permissions to pull the image.