Enforcing Container Provenance with Binary Authorization | PCSE

PCSE By islever Editorial Last updated

Short answer

C Create a Binary Authorization attestor that retrieves the Cloud Build build ID and configure a policy allowing deployment only with a matching attestation.

Question

Your organization heavily utilizes serverless applications while prioritizing security best practices. You are responsible for enforcing image provenance and compliance with security standards before deployment. You leverage Cloud Build as your continuous integration and continuous deployment (CI/CD) tool for building container images. You must configure Binary Authorization to ensure that only images built by your Cloud Build pipeline are deployed and that the images pass security standard compliance checks. What should you do?
  1. Create a Binary Authorization attestor that uses a scanner to assess source code management repositories. Deploy images only if the attestor validates results against a security policy.
  2. Create a Binary Authorization attestor that utilizes a scanner to evaluate container image build processes. Define a policy that requires deployment of images only if this attestation is present.
  3. Create a Binary Authorization attestor that retrieves the Cloud Build build ID of the container image. Configure a policy to allow deployment only if there's a matching build ID attestation. Correct Answer
  4. Utilize a custom Security Health Analytics module to create a policy. Enforce the policy through Binary Authorization to prevent deployment of images that do not meet predefined security standards.

Key Takeaways

Tests Binary Authorization attestation mechanisms; the common trap is assuming a standalone scanner or source-code check replaces pipeline-native provenance tracking.

This question tests how to enforce container image provenance and compliance in Google Cloud using Binary Authorization and Cloud Build. It establishes that linking deployments to a specific Cloud Build build ID via an attestor is the correct configuration.

Common mistake: Candidates often select A or B because they expect a separate vulnerability scanner to be configured directly inside Binary Authorization, overlooking Cloud Build's automatic attestation workflow.

Expert Analysis

Why the Answer Is Correct

Binary Authorization enforces deploy-time constraints by requiring cryptographic attestations from trusted sources. When integrated with Cloud Build, the pipeline can automatically generate an attestation tied to the specific build ID once all steps pass. Configuring an attestor to verify this build ID guarantees that only images produced by your approved CI/CD workflow reach production. Compliance checks are embedded within the pipeline stages, so the attestation itself serves as proof that both provenance and security standards were satisfied before deployment.

Why the Other Options Are Wrong

Option A focuses on scanning source code repositories rather than evaluating the final container image or build artifacts, which misses the provenance requirement. Option B suggests a generic scanner for build processes but lacks the explicit Cloud Build integration mechanism required for verifiable image signing. Option D incorrectly applies Security Health Analytics, which monitors runtime VM and workload posture rather than providing cryptographic proof of container image origin during CI/CD.

Community Comment Notes

As jmaquino noted, users initially questioned whether a separate tool handles compliance, but clarified that scanners run inside the pipeline before the attestation step. abdelrahman89 emphasized that linking the deployed image to the exact build process ensures strict provenance control. KLei pointed out that Google provides built-in security containers, making external scanner configurations unnecessary for this specific setup. The consensus confirms that native Cloud Build attestation aligns perfectly with exam expectations.

Exam Strategy

When configuring deploy-time enforcement in Google Cloud, always prioritize native CI/CD integrations like Cloud Build’s automatic attestation over third-party or out-of-band scanning tools. Map each requirement (provenance versus compliance) to the specific service designed to handle it at the right stage of the pipeline to avoid misconfiguring attestors.

Frequently Asked Questions

How does Binary Authorization verify compliance alongside provenance?

Compliance checks run inside the Cloud Build pipeline; only after passing do you trigger the attestation step that ties the image to the build ID.

Why isn't a standalone scanner used for Binary Authorization?

Binary Authorization relies on attestations produced during CI/CD. Standalone scanners lack the cryptographic proof linking the final image back to the approved build process.

More PCSE FAQ →

Community Votes

C
100%

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

Discussion 5 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 5

  1. abdelrahman89 👍 1
    C - Image Provenance: By using the Cloud Build build ID as the attestation, you can directly link the deployed image to the specific build process that created it. This ensures that only images built by your trusted CI/CD pipeline are deployed. Security Standards Compliance: You can integrate security checks into your Cloud Build pipeline, such as vulnerability scanning or compliance audits. If an image fails these checks, the build process can be aborted, preventing the creation of a non-compliant image. Policy Enforcement: The Binary Authorization policy ensures that only images with the correct build ID attestation are deployed, effectively enforcing the security standards you've defined in your CI/CD pipeline.
  2. jmaquino 👍 1
    C: Binary Authorization (overview) is a Google Cloud product that enforces deploy-time constraints on applications. Its Google Kubernetes Engine (GKE) integration allows users to enforce that containers deployed to a Kubernetes cluster are cryptographically signed by a trusted authority and verified by a Binary Authorization attestor. You can configure Binary Authorization to require attestations based on the location of the source code to prevent container images built from unauthorized source from being deployed.
  3. KLei 👍 1 Answered C
    Google has built-in security container. So not scanner is need. opt out A B Add a Verification Method: Use a built-in security scanner (e.g., Container Analysis) to evaluate the image against compliance policies.
  4. jmaquino 👍 1
    C, but I have doubts about this part: and that the images pass security standard compliance checks. What should you do? Because Security Command Center can do that
  5. json4u 👍 1 Answered C
    I think it's C.

Reader comments & corrections

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

Log in to comment, report an error, or add a note about this question.

How to Implement TLS Interception for On-Premise Traffic in GCP

S-grade

How to Secure Vertex AI Training Jobs with Regional CMEK?

S-grade

How to Alert on Suspicious Outbound Traffic Using Threat Intelligence?

S-grade

How to Securely Host Databases Without Direct Internet Access?

S-grade

← Back to PCSE Study Guide