GCP Professional Cloud Security Engineer Practice Question

Your team maintains a Cloud Build pipeline that builds container images for a business-critical microservice, pushes them to Artifact Registry, and then deploys the image to Cloud Run. A new compliance policy states that any image containing HIGH or CRITICAL vulnerabilities must never be deployed. You need to implement automated enforcement without introducing third-party scanners or manual approval steps, and the build should fail as early as possible when disallowed vulnerabilities are detected. Which design meets these requirements while keeping operational overhead low?

Schedule a daily Cloud Scheduler job that exports vulnerability findings from Security Command Center; trigger a rollback of the Cloud Run service via Pub/Sub if HIGH or CRITICAL findings are present.
Enable Container Analysis vulnerability scanning on the Artifact Registry repository and add a Cloud Build step that runs "gcloud artifacts docker images list-vulnerabilities" for the just-built image, exiting with a non-zero status if any HIGH or CRITICAL findings are detected before the deploy step.
Insert an open-source container scanner as an additional Jenkins stage after Cloud Build completes; have Jenkins delete the Cloud Run service when HIGH or CRITICAL issues are found.
Configure Cloud Run with Binary Authorization in Dry Run mode so deployments containing HIGH or CRITICAL vulnerabilities are logged; allow the pipeline to proceed only after manual verification.

Report Issue

Answer Description

Artifact Registry automatically scans each pushed container image and stores the results in Container Analysis. You can add a step to the Cloud Build workflow that waits briefly after the push, then uses the gcloud command-line tool (available in the gcr.io/google.com/cloudsdktool/cloud-sdk image) to call "gcloud artifacts docker images list-vulnerabilities" for the newly-built image. The step parses the returned JSON, and if any vulnerability of severity HIGH or CRITICAL is present, it exits with a non-zero status, causing the build to fail and preventing the subsequent Cloud Run deploy stage from running. This solution relies solely on native Google Cloud services and enforces the compliance policy at build time, minimizing extra operational effort.

Incorrect answers explained:

Enabling Binary Authorization in Dry Run mode only logs violations; it does not block deployments, so HIGH or CRITICAL vulnerabilities could still reach production.
Running a daily Security Command Center export detects issues post-deployment and cannot stop non-compliant images from being released.
Adding an external open-source scanner in a separate Jenkins stage introduces additional tooling and maintenance overhead, contrary to the requirement to avoid third-party scanners.

Ask Bash

Bash is our AI bot, trained to help you pass your exam. AI Generated Content may display inaccurate information, always double-check anything important.