An enterprise organization is designing a secure CI/CD pipeline on Google Cloud to align with the Supply-chain Levels for Software Artifacts (SLSA) framework and mitigate insider risk. The pipeline must satisfy the following security and governance requirements: Prevent unilateral changes: Ensure that no individual developer acting alone can directly merge unvetted source code into production builds. Verifiable build provenance: Build container images in an isolated, centralized service that generates tamper-evident provenance metadata linking the artifact to its exact source repository commit and build steps. Deploy-time policy enforcement: Block the deployment of any container image unless it carries verified attestations confirming mandatory peer reviews and legitimate build provenance. Which combination of controls and architecture should the DevOps team implement?

Require two-person code reviews in the source control system, execute container builds in a centralized build service that automatically generates signed provenance attestations, and enforce deployment policies using Binary Authorization.: ### What this solution is This architecture combines branch protection rules, centralized verifiable build execution, and deploy-time policy admission controllers to establish end-to-end software supply chain security aligned with the **Supply-chain Levels for Software Artifacts (SLSA)** framework. ### How it meets the requirements - **Prevent unilateral changes**: Enforcing mandatory **two-person code reviews** in source control ensures that every code change undergoes independent verification before merging. This eliminates the risk of an individual developer acting alone to deploy malicious or unauthorized modifications to production systems. - **Verifiable build provenance**: Executing builds in a managed, centralized service (such as Cloud Build) isolates the compilation and packaging environment. The build service generates signed, non-falsifiable provenance metadata that explicitly records the source repository URL, commit hash, build entry points, and output artifact hashes. - **Deploy-time policy enforcement**: Using **Binary Authorization** introduces an admission control gate on Google Kubernetes Engine (GKE) or Cloud Run. The admission controller verifies cryptographic signatures and attestations against an enterprise policy, ensuring that non-compliant images lacking valid provenance or peer reviews are rejected prior to execution. ### Key advantages - Implements the foundational principles of Google's Binary Authorization for Borg (BAB) and SLSA framework. - Mitigates both external supply chain tampering and internal insider threat vectors. - Shifting security checks left into the build phase while maintaining non-bypassable enforcement at the deployment choke point. - Generates an immutable, auditable trail linking production containers back to reviewed source commits. ### Why this is optimal Centralizing build execution and binding it to cryptographic attestations evaluated by Binary Authorization creates a zero-trust build and deployment pipeline that prevents compromised developer workstations or untrusted artifacts from entering production.

Slsa Framework Verifiable Provenance Binary Authorization | Professional Cloud DevOps Engineer

Slsa Framework Verifiable Provenance Binary Authorization

Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.

An enterprise organization is designing a secure CI/CD pipeline on Google Cloud to align with the Supply-chain Levels for Software Artifacts (SLSA) framework and mitigate insider risk.

The pipeline must satisfy the following security and governance requirements:

Prevent unilateral changes: Ensure that no individual developer acting alone can directly merge unvetted source code into production builds.
Verifiable build provenance: Build container images in an isolated, centralized service that generates tamper-evident provenance metadata linking the artifact to its exact source repository commit and build steps.
Deploy-time policy enforcement: Block the deployment of any container image unless it carries verified attestations confirming mandatory peer reviews and legitimate build provenance.

Which combination of controls and architecture should the DevOps team implement?

Deploy application code using Cloud Run source-to-container continuous deployment triggers directly from developer feature branches, and rely on Cloud Monitoring alerts for unauthorized deployments.

Require two-person code reviews in the source control system, execute container builds in a centralized build service that automatically generates signed provenance attestations, and enforce deployment policies using Binary Authorization.

Have developers sign container images locally using personal PGP keys following a self-review checklist, push the images to Artifact Registry, and configure automated vulnerability scanning.

Implement feature flags and blue-green traffic shifting in the deployment pipeline, and configure a Change Advisory Board approval gate in the continuous delivery tool.

Professional Cloud DevOps Engineer

Slsa Framework Verifiable Provenance Binary Authorization

Related questions