A DevOps engineer is designing an automated CI/CD pipeline on Google Cloud to deploy containerized microservices to Google Kubernetes Engine (GKE). The organization mandates strict supply chain security and deployment governance: Build artifacts must undergo automated vulnerability scanning for operating system and language dependencies. Container images must only run on GKE clusters if they have verified attestations confirming that pre-deployment quality gates and security tests passed. Progressive delivery across staging and production targets must include built-in auditability and automated rollback support. Which combination of Google Cloud services and architectural components satisfies these requirements?

Configure Cloud Build to run automated tests and generate attestations, store images in Artifact Registry with Artifact Analysis automated scanning, enforce deploy-time signature validation on GKE using Binary Authorization, and orchestrate progressive multi-target rollouts with automated rollbacks using Cloud Deploy.: What the Solution Is This architecture combines Cloud Build, Artifact Registry with Artifact Analysis, Binary Authorization, and Cloud Deploy to establish a secure, policy-driven software supply chain on Google Cloud. How It Meets the Requirements Automated vulnerability scanning: Artifact Analysis integrates with Artifact Registry to provide proactive, automated scanning of container images for both operating system package vulnerabilities and language package vulnerabilities. Deploy-time cryptographic verification: Binary Authorization enforces signature validation at deploy time on GKE. It checks that images are signed by designated trusted authorities (attestors) after Cloud Build successfully runs automated test suites and validation steps. Progressive rollout and rollback: Cloud Deploy provides declarative continuous delivery pipelines to deploy workloads across multiple target environments in sequence, featuring native approval workflows and one-click or automated rollbacks. Key Advantages Shifts security left: Detects vulnerabilities early in the build lifecycle before deployment occurs. Prevents unauthorized deployments: Restricts runtime environments to cryptographically verified container images. Enterprise delivery governance: Delivers end-to-end auditability and traceability from source commit to production deployment. Standardized release pipelines: Reduces operational friction by unifying automated testing, vulnerability gating, and target orchestration. Why This Is Optimal Native integration between Cloud Build, Artifact Analysis, Binary Authorization, and Cloud Deploy creates a zero-trust software supply chain pipeline without requiring third-party plugins or custom admission webhooks.

Software Delivery Shield | Professional Cloud DevOps Engineer

Secure Supply Chain with Binary Authorization and Cloud Deploy

A DevOps engineer is designing an automated CI/CD pipeline on Google Cloud to deploy containerized microservices to Google Kubernetes Engine (GKE). The organization mandates strict supply chain security and deployment governance:

Build artifacts must undergo automated vulnerability scanning for operating system and language dependencies.
Container images must only run on GKE clusters if they have verified attestations confirming that pre-deployment quality gates and security tests passed.
Progressive delivery across staging and production targets must include built-in auditability and automated rollback support.

Which combination of Google Cloud services and architectural components satisfies these requirements?

Configure Cloud Build to package applications into virtual repositories in Artifact Registry, enable Assured Open Source Software for all internal containers, and enforce GKE cluster admission using PodSecurityPolicies with manual rollback procedures.

Configure Cloud Build to push images to Artifact Registry remote repositories, configure Web Security Scanner to scan containers for runtime vulnerabilities, deploy workloads using Deployment Manager templates, and configure Cloud Monitoring alerts to trigger automated rollbacks via Cloud Functions.

Configure Cloud Workstations to compile container images, use Security Command Center Event Threat Detection to block unsigned container deployments, and execute gcloud container clusters update commands to roll back failed GKE releases.

Configure Cloud Build to run automated tests and generate attestations, store images in Artifact Registry with Artifact Analysis automated scanning, enforce deploy-time signature validation on GKE using Binary Authorization, and orchestrate progressive multi-target rollouts with automated rollbacks using Cloud Deploy.

Explanations

Configure Cloud Build to package applications into virtual repositories in Artifact Registry, enable Assured Open Source Software for all internal containers, and enforce GKE cluster admission using PodSecurityPolicies with manual rollback procedures.

What the Option Is/Does

This approach uses Virtual Repositories, Assured Open Source Software (Assured OSS), deprecated PodSecurityPolicies, and manual rollback procedures.

Why It Doesn't Meet the Requirement

Misapplied dependency management: Assured Open Source Software provides curated, Google-tested third-party open-source packages. It does not scan or verify custom proprietary microservices built by internal development teams.
Deprecated technology: PodSecurityPolicies are deprecated and removed in modern Kubernetes versions; furthermore, they enforce runtime pod privileges (e.g., non-root user execution) rather than cryptographic image attestations.
Virtual repository function: While Virtual Repositories consolidate multiple repositories behind a single endpoint to mitigate dependency confusion, they do not provide deploy-time validation or quality gates.
Manual operations: Manual rollback procedures fail the requirement for an automated rollback and progressive delivery mechanism.

Key Limitations

Assured OSS is limited to third-party open-source packages, not internal application code.
PodSecurityPolicies cannot validate cryptographic digital signatures on container digests.
Relies on manual operational intervention during release failures.

This Answer Would Be Correct If

The requirement specifically addressed protecting application builds from upstream open-source dependency confusion and public repository poisoning.

View source documentation

Configure Cloud Build to push images to Artifact Registry remote repositories, configure Web Security Scanner to scan containers for runtime vulnerabilities, deploy workloads using Deployment Manager templates, and configure Cloud Monitoring alerts to trigger automated rollbacks via Cloud Functions.

What the Option Is/Does

This architecture attempts to use Artifact Registry remote repositories, Web Security Scanner, Cloud Deployment Manager, and custom Cloud Functions to handle security scanning and deployment automation.

Why It Doesn't Meet the Requirement

Vulnerability scanning tool mismatch: Web Security Scanner is a crawler designed to detect OWASP Top 10 vulnerabilities in public-facing web endpoints and compute application frontends; it cannot scan container image layers or static language packages in a registry.
Repository purpose: Remote repositories in Artifact Registry act as caching proxies for external upstream registries (such as Docker Hub or Maven Central) rather than private hosting for internal application container builds.
Missing deploy-time gate: The architecture lacks Binary Authorization, meaning unverified or compromised images can still be scheduled on GKE without cryptographic signature validation.
Complex rollback mechanism: Using custom Cloud Functions triggered by Cloud Monitoring adds unnecessary maintenance overhead compared to native deployment management tools.

Key Limitations

No cryptographic attestation or admission control mechanism for Kubernetes.
Web Security Scanner operates post-deployment and cannot serve as a pre-deployment container quality gate.

This Answer Would Be Correct If

The goal was to perform dynamic application security testing (DAST) on live, exposed web services and trigger automated alerts upon HTTP misconfiguration detection.

View source documentation

Configure Cloud Workstations to compile container images, use Security Command Center Event Threat Detection to block unsigned container deployments, and execute gcloud container clusters update commands to roll back failed GKE releases.

What the Option Is/Does

This option relies on Cloud Workstations for image builds, Security Command Center Event Threat Detection for admission control, and manual gcloud commands for rollback operations.

Why It Doesn't Meet the Requirement

Misaligned build environment: Cloud Workstations provides managed development environments for individual developers to write code interactively; it is not a scalable CI/CD build runner like Cloud Build.
Incorrect admission control: Event Threat Detection monitors Cloud Logging streams to detect suspicious activity and security threats (such as anomalous IAM grants or cryptomining) asynchronously after the event occurs; it is not a Kubernetes admission controller that can block pod deployment.
Lack of automated release orchestration: Using scripted cluster update commands lacks structured release definitions, target sequencing, and built-in continuous delivery metrics.

Key Limitations

Cloud Workstations is intended for developer environments, not unattended CI/CD automation.
Event Threat Detection provides detective controls rather than preventative deploy-time admission gates.
Does not integrate container vulnerability scanning.

This Answer Would Be Correct If

The scenario focused on securing interactive developer IDEs against data exfiltration and monitoring audit logs for compromised credentials in real time.

View source documentation

Configure Cloud Build to run automated tests and generate attestations, store images in Artifact Registry with Artifact Analysis automated scanning, enforce deploy-time signature validation on GKE using Binary Authorization, and orchestrate progressive multi-target rollouts with automated rollbacks using Cloud Deploy.

What the Solution Is

This architecture combines Cloud Build, Artifact Registry with Artifact Analysis, Binary Authorization, and Cloud Deploy to establish a secure, policy-driven software supply chain on Google Cloud.

How It Meets the Requirements

Automated vulnerability scanning: Artifact Analysis integrates with Artifact Registry to provide proactive, automated scanning of container images for both operating system package vulnerabilities and language package vulnerabilities.
Deploy-time cryptographic verification: Binary Authorization enforces signature validation at deploy time on GKE. It checks that images are signed by designated trusted authorities (attestors) after Cloud Build successfully runs automated test suites and validation steps.
Progressive rollout and rollback: Cloud Deploy provides declarative continuous delivery pipelines to deploy workloads across multiple target environments in sequence, featuring native approval workflows and one-click or automated rollbacks.

Key Advantages

Shifts security left: Detects vulnerabilities early in the build lifecycle before deployment occurs.
Prevents unauthorized deployments: Restricts runtime environments to cryptographically verified container images.
Enterprise delivery governance: Delivers end-to-end auditability and traceability from source commit to production deployment.
Standardized release pipelines: Reduces operational friction by unifying automated testing, vulnerability gating, and target orchestration.

Why This Is Optimal

Native integration between Cloud Build, Artifact Analysis, Binary Authorization, and Cloud Deploy creates a zero-trust software supply chain pipeline without requiring third-party plugins or custom admission webhooks.

View source documentation

Last updated August 28, 2026Validated August 28, 2026

Secure Supply Chain with Binary Authorization and Cloud Deploy

Build artifacts must undergo automated vulnerability scanning for operating system and language dependencies.
Container images must only run on GKE clusters if they have verified attestations confirming that pre-deployment quality gates and security tests passed.
Progressive delivery across staging and production targets must include built-in auditability and automated rollback support.

Which combination of Google Cloud services and architectural components satisfies these requirements?

Explanations

Configure Cloud Build to package applications into virtual repositories in Artifact Registry, enable Assured Open Source Software for all internal containers, and enforce GKE cluster admission using PodSecurityPolicies with manual rollback procedures.

What the Option Is/Does

This approach uses Virtual Repositories, Assured Open Source Software (Assured OSS), deprecated PodSecurityPolicies, and manual rollback procedures.

Why It Doesn't Meet the Requirement

Misapplied dependency management: Assured Open Source Software provides curated, Google-tested third-party open-source packages. It does not scan or verify custom proprietary microservices built by internal development teams.
Deprecated technology: PodSecurityPolicies are deprecated and removed in modern Kubernetes versions; furthermore, they enforce runtime pod privileges (e.g., non-root user execution) rather than cryptographic image attestations.
Virtual repository function: While Virtual Repositories consolidate multiple repositories behind a single endpoint to mitigate dependency confusion, they do not provide deploy-time validation or quality gates.
Manual operations: Manual rollback procedures fail the requirement for an automated rollback and progressive delivery mechanism.

Key Limitations

Assured OSS is limited to third-party open-source packages, not internal application code.
PodSecurityPolicies cannot validate cryptographic digital signatures on container digests.
Relies on manual operational intervention during release failures.

This Answer Would Be Correct If

The requirement specifically addressed protecting application builds from upstream open-source dependency confusion and public repository poisoning.

View source documentation

Configure Cloud Build to push images to Artifact Registry remote repositories, configure Web Security Scanner to scan containers for runtime vulnerabilities, deploy workloads using Deployment Manager templates, and configure Cloud Monitoring alerts to trigger automated rollbacks via Cloud Functions.

What the Option Is/Does

Why It Doesn't Meet the Requirement

Vulnerability scanning tool mismatch: Web Security Scanner is a crawler designed to detect OWASP Top 10 vulnerabilities in public-facing web endpoints and compute application frontends; it cannot scan container image layers or static language packages in a registry.
Repository purpose: Remote repositories in Artifact Registry act as caching proxies for external upstream registries (such as Docker Hub or Maven Central) rather than private hosting for internal application container builds.
Missing deploy-time gate: The architecture lacks Binary Authorization, meaning unverified or compromised images can still be scheduled on GKE without cryptographic signature validation.
Complex rollback mechanism: Using custom Cloud Functions triggered by Cloud Monitoring adds unnecessary maintenance overhead compared to native deployment management tools.

Key Limitations

No cryptographic attestation or admission control mechanism for Kubernetes.
Web Security Scanner operates post-deployment and cannot serve as a pre-deployment container quality gate.

This Answer Would Be Correct If

The goal was to perform dynamic application security testing (DAST) on live, exposed web services and trigger automated alerts upon HTTP misconfiguration detection.

View source documentation

Configure Cloud Workstations to compile container images, use Security Command Center Event Threat Detection to block unsigned container deployments, and execute gcloud container clusters update commands to roll back failed GKE releases.

What the Option Is/Does

This option relies on Cloud Workstations for image builds, Security Command Center Event Threat Detection for admission control, and manual gcloud commands for rollback operations.

Why It Doesn't Meet the Requirement

Misaligned build environment: Cloud Workstations provides managed development environments for individual developers to write code interactively; it is not a scalable CI/CD build runner like Cloud Build.
Incorrect admission control: Event Threat Detection monitors Cloud Logging streams to detect suspicious activity and security threats (such as anomalous IAM grants or cryptomining) asynchronously after the event occurs; it is not a Kubernetes admission controller that can block pod deployment.
Lack of automated release orchestration: Using scripted cluster update commands lacks structured release definitions, target sequencing, and built-in continuous delivery metrics.

Key Limitations

Cloud Workstations is intended for developer environments, not unattended CI/CD automation.
Event Threat Detection provides detective controls rather than preventative deploy-time admission gates.
Does not integrate container vulnerability scanning.

This Answer Would Be Correct If

The scenario focused on securing interactive developer IDEs against data exfiltration and monitoring audit logs for compromised credentials in real time.

View source documentation

Configure Cloud Build to run automated tests and generate attestations, store images in Artifact Registry with Artifact Analysis automated scanning, enforce deploy-time signature validation on GKE using Binary Authorization, and orchestrate progressive multi-target rollouts with automated rollbacks using Cloud Deploy.

What the Solution Is

How It Meets the Requirements

Automated vulnerability scanning: Artifact Analysis integrates with Artifact Registry to provide proactive, automated scanning of container images for both operating system package vulnerabilities and language package vulnerabilities.
Deploy-time cryptographic verification: Binary Authorization enforces signature validation at deploy time on GKE. It checks that images are signed by designated trusted authorities (attestors) after Cloud Build successfully runs automated test suites and validation steps.
Progressive rollout and rollback: Cloud Deploy provides declarative continuous delivery pipelines to deploy workloads across multiple target environments in sequence, featuring native approval workflows and one-click or automated rollbacks.

Key Advantages

Shifts security left: Detects vulnerabilities early in the build lifecycle before deployment occurs.
Prevents unauthorized deployments: Restricts runtime environments to cryptographically verified container images.
Enterprise delivery governance: Delivers end-to-end auditability and traceability from source commit to production deployment.
Standardized release pipelines: Reduces operational friction by unifying automated testing, vulnerability gating, and target orchestration.

Why This Is Optimal

View source documentation

Last updated August 28, 2026Validated August 28, 2026

Secure Supply Chain with Binary Authorization and Cloud Deploy

Explanations

Configure Cloud Build to package applications into virtual repositories in Artifact Registry, enable Assured Open Source Software for all internal containers, and enforce GKE cluster admission using PodSecurityPolicies with manual rollback procedures.

What the Option Is/Does

Why It Doesn't Meet the Requirement

Key Limitations

This Answer Would Be Correct If

What the Option Is/Does

Why It Doesn't Meet the Requirement

Key Limitations

This Answer Would Be Correct If

Configure Cloud Workstations to compile container images, use Security Command Center Event Threat Detection to block unsigned container deployments, and execute gcloud container clusters update commands to roll back failed GKE releases.

What the Option Is/Does

Why It Doesn't Meet the Requirement

Key Limitations

This Answer Would Be Correct If

What the Solution Is

How It Meets the Requirements

Key Advantages

Why This Is Optimal

Try 10 interactive questions like this one, free

Related questions

Software Delivery Shield

Secure Multi-Environment Terraform CI/CD Pipeline

Artifact Registry Standard Remote Virtual Repositories

Organization-Level Aggregated Log Sink to BigQuery

Spinnaker Automated Canary Analysis with Cloud Monitoring

CMEK vs CSEK vs Google-Managed Encryption Keys

Secure Supply Chain with Binary Authorization and Cloud Deploy

Explanations

Configure Cloud Build to package applications into virtual repositories in Artifact Registry, enable Assured Open Source Software for all internal containers, and enforce GKE cluster admission using PodSecurityPolicies with manual rollback procedures.

What the Option Is/Does

Why It Doesn't Meet the Requirement

Key Limitations

This Answer Would Be Correct If

What the Option Is/Does

Why It Doesn't Meet the Requirement

Key Limitations

This Answer Would Be Correct If

Configure Cloud Workstations to compile container images, use Security Command Center Event Threat Detection to block unsigned container deployments, and execute gcloud container clusters update commands to roll back failed GKE releases.

What the Option Is/Does

Why It Doesn't Meet the Requirement

Key Limitations

This Answer Would Be Correct If

What the Solution Is

How It Meets the Requirements

Key Advantages

Why This Is Optimal

Try 10 interactive questions like this one, free

Related questions

Software Delivery Shield

Secure Multi-Environment Terraform CI/CD Pipeline

Artifact Registry Standard Remote Virtual Repositories

Organization-Level Aggregated Log Sink to BigQuery

Spinnaker Automated Canary Analysis with Cloud Monitoring

CMEK vs CSEK vs Google-Managed Encryption Keys