How to Block Vulnerable Containers in Cloud Run Production?

PCSE By islever Editorial Last updated Sep 9, 2026

Short answer

C Configure Binary Authorization on Cloud Run to enforce image signatures and block deployments exceeding the CVSS medium threshold.

Question

Your organization relies heavily on Cloud Run for its containerized applications. You utilize Cloud Build for image creation, Artifact Registry for image storage, and Cloud Run for deployment. You must ensure that containers with vulnerabilities rated above a common vulnerability scoring system (CVSS) score of "medium" are not deployed to production. What should you do?

Implement vulnerability scanning as part of the Cloud Build process. If any medium or higher vulnerabilities are detected, manually rebuild the image with updated components.
Perform manual vulnerability checks post-build, but before Cloud Run deployment. Implement a manual security-engineer-driven remediation process.
Configure Binary Authorization on Cloud Run to enforce image signatures. Create policies to allow deployment only for images passing a defined vulnerability threshold. Correct Answer
Utilize a vulnerability scanner during the Cloud Build stage and set Artifact Registry permissions to block images containing vulnerabilities above "medium."

Key Takeaways

Tests understanding of automated deployment security gates, with the common trap being confusing IAM permissions or manual review processes with actual policy enforcement mechanisms.

Enforcing deployment security gates in Google Cloud requires automated policy enforcement rather than manual checks. This page establishes why Binary Authorization is the correct service to block high-CVSS containers before they reach production.

Common mistake: Candidates often select option D because it mentions blocking images, but misinterprets Artifact Registry permissions as a vulnerability-scanning enforcement tool rather than an access-control mechanism.

Expert Analysis

Why the Answer Is Correct

Binary Authorization acts as a mandatory admission controller for Cloud Run deployments, enforcing policies based on signed images and container analysis results. By integrating it with Artifact Registry's built-in vulnerability scanning, you can configure strict thresholds that automatically reject any image exceeding a CVSS medium score during the push or deploy phase. This creates a non-bypassable security gate that aligns with zero-trust CI/CD practices.

Why the Other Options Are Wrong

Option A and Option B both rely on manual remediation steps, which introduce human error, slow down release cycles, and fail to provide real-time prevention at the deployment boundary. Option D incorrectly suggests using Artifact Registry IAM permissions to block images based on vulnerability scores; permissions only control who can read or write artifacts, not how scan results are evaluated or enforced during runtime deployment.

Community Comment Notes

Community feedback strongly converges on Binary Authorization as the definitive solution. As Mr_MIXER007 noted, the approach provides a strong policy-based control mechanism that ensures only verified images enter production. JohnDohertyDoe reinforced this by sharing the official Google Cloud documentation link for enabling the feature on Cloud Run, while yokoyan simply confirmed the selection matches exam expectations. The consensus correctly highlights automation over manual workflows.

Official Reference

https://cloud.google.com/binary-authorization/docs/run/enabling-binauthz-cloud-run

This link opens the official vendor documentation in a new tab.

Exam Strategy

When a PCSE question demands automatic prevention of insecure artifacts at deployment time, look for policy engines like Binary Authorization or OPA/Gatekeeper rather than permission settings or manual reviews. Map keywords like 'enforce', 'gate', and 'block' directly to admission controllers that evaluate scan metadata before allowing infrastructure changes.

Frequently Asked Questions

Why isn't Artifact Registry permission blocking effective here?

Permissions control user access, not image vulnerability states. Binary Authorization evaluates scan results against policies before deployment.

Does Binary Authorization replace container vulnerability scanning?

No, it acts as a deployment gate that consumes scan data from Container Analysis. Scanning still occurs in Cloud Build or Artifact Registry.

More PCSE FAQ →

Community Votes

100%

100% of anonymous learners picked answer C. Votes are pick records left by other test-takers — they are not the verified answer.

Discussion 3 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 3

Mr_MIXER007 👍 2 Answered C

The best solution is C. Configure Binary Authorization on Cloud Run to enforce image signatures. Create policies to allow deployment only for images passing a defined vulnerability threshold. Here's why this is the preferred approach: Binary Authorization: Provides a strong, policy-based control mechanism for deploying containers. It ensures only trusted and verified images can be deployed to Cloud Run. Vulnerability Threshold: By setting a policy within Binary Authorization, you can explicitly block the deployment of any container images that have vulnerabilities exceeding a CVSS score of "medium". Automation: This approach enables automated enforcement of security standards at the deployment stage, preventing vulnerable images from reaching production.
JohnDohertyDoe 👍 1 Answered C

https://cloud.google.com/binary-authorization/docs/run/enabling-binauthz-cloud-run
yokoyan 👍 3 Answered C

I think it's C.

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

← Back to PCSE Study Guide