An enterprise organization is establishing automated security gating mechanisms within their Google Cloud CI/CD pipeline. The security policy mandates that container images deployed to production Google Kubernetes Engine (GKE) clusters must satisfy the following criteria: Container images must be scanned for Common Vulnerabilities and Exposures (CVEs) prior to registry storage and deployment. Artifacts containing any fixable vulnerabilities above MEDIUM severity or unfixable vulnerabilities above HIGH severity must be blocked from progressing to production. Deploy-time admission control must strictly block unauthorized or non-compliant containers and log all enforcement events. Which architecture should the security team implement to enforce these gating requirements?

Execute vulnerability scanning in Cloud Build using the Artifact Analysis On-Demand Scanning API, evaluate CVE severity against policy thresholds, sign the image digest using Cloud KMS to create an attestation upon passing, and enforce a Binary Authorization policy on GKE requiring that attestor with ENFORCED_BLOCK_AND_AUDIT_LOG.: ### What the Attestation-Based Binary Authorization Architecture Is **Binary Authorization** provides deploy-time policy enforcement for containerized workloads deployed across **Google Kubernetes Engine (GKE)**. It works symbiotically with **Artifact Analysis** and **Cloud Key Management Service (Cloud KMS)** to cryptographically attest that specific quality, security, and vulnerability checks have been completed before an image descriptor is admitted to a runtime cluster. ### How It Meets the Requirements - **Pre-deployment Vulnerability Scanning**: Executing the **Artifact Analysis On-Demand Scanning API** as an integrated step in **Cloud Build** enables vulnerability analysis directly on newly built container images before pushing or deploying. - **Enforcing Severity Thresholds**: A custom CI/CD pipeline step inspects the structured scan results returned by the API, programmatically checking for CVE findings that exceed the organization's risk tolerance (`maximumFixableSeverity: MEDIUM` and `maximumUnfixableSeverity: HIGH`). - **Attestation Generation**: Upon verifying compliance, the build pipeline uses a private key in **Cloud KMS** to digitally sign the container image digest and creates an **attestation** stored as an occurrence linked to an **Artifact Analysis note**. - **Strict Deploy-Time Admission**: The GKE cluster's Binary Authorization policy specifies `evaluationMode: REQUIRE_ATTESTATION` referencing the vulnerability attestor, and sets `enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG` to block non-compliant deployments while logging events to **Cloud Audit Logs**. ### Key Advantages and Capabilities - **Cryptographic Trust**: Verifies image digests against digital signatures rather than mutable tags. - **Separation of Duties**: Decouples security scanning authority from build execution through distinct IAM roles and attestor public key verification. - **Shift-Left Security**: Enforces policy gates during build execution while retaining an authoritative, tamper-proof gate at admission time. - **Audit Visibility**: Generates structured entries in Cloud Audit Logs whenever non-compliant container deployment attempts are blocked. ### Why This Is Optimal This solution prevents non-compliant or unscanned artifacts from entering production environments by enforcing a cryptographically signed gate that GKE validates before runtime pod creation.

Binary Authorization Cve Gating Pipeline | Professional Cloud Security Engineer

Binary Authorization Cve Gating Pipeline

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 establishing automated security gating mechanisms within their Google Cloud CI/CD pipeline. The security policy mandates that container images deployed to production Google Kubernetes Engine (GKE) clusters must satisfy the following criteria:

Container images must be scanned for Common Vulnerabilities and Exposures (CVEs) prior to registry storage and deployment.
Artifacts containing any fixable vulnerabilities above MEDIUM severity or unfixable vulnerabilities above HIGH severity must be blocked from progressing to production.
Deploy-time admission control must strictly block unauthorized or non-compliant containers and log all enforcement events.

Which architecture should the security team implement to enforce these gating requirements?

Configure Cloud Build to push images to Artifact Registry, rely on the default built-by-cloud-build attestor in Binary Authorization, and set the defaultAdmissionRule evaluationMode to ALWAYS_ALLOW with DRYRUN_AUDIT_LOG_ONLY.

Deploy Continuous Validation platform policies in Binary Authorization with a vulnerabilityCheck check set, while keeping GKE cluster admission rules configured to ALWAYS_ALLOW.

Configure Security Command Center Security Health Analytics to scan Artifact Registry, apply container metadata labels indicating scan compliance, and use GKE admission controllers with ALWAYS_DENY to evaluate label presence.

Execute vulnerability scanning in Cloud Build using the Artifact Analysis On-Demand Scanning API, evaluate CVE severity against policy thresholds, sign the image digest using Cloud KMS to create an attestation upon passing, and enforce a Binary Authorization policy on GKE requiring that attestor with ENFORCED_BLOCK_AND_AUDIT_LOG.

Professional Cloud Security Engineer

Binary Authorization Cve Gating Pipeline

Related questions