An enterprise is designing a secure software supply chain pipeline for containerized applications deployed to Google Kubernetes Engine (GKE). The security architecture must satisfy the following requirements: Store build artifacts in Artifact Registry with encryption controlled by company-managed keys in Cloud KMS. Protect the repository and vulnerability scanning services against data exfiltration using network perimeters. Prevent unverified images or container images containing policy violations from being deployed to production GKE clusters. Which combination of Google Cloud security controls and architectural practices should the DevOps engineer implement?

Create an Artifact Registry repository configured with Customer-Managed Encryption Keys (CMEK), include Artifact Registry and Container Security APIs inside a VPC Service Controls perimeter, and enforce Binary Authorization policies with admission webhooks on GKE.: What the solution is This architecture combines Artifact Registry Customer-Managed Encryption Keys (CMEK), VPC Service Controls (VPC SC) perimeters, and Binary Authorization on Google Kubernetes Engine (GKE) to establish an end-to-end secure software supply chain. How it meets the requirements Company-controlled encryption: Configuring Artifact Registry with CMEK ensures that container images and layers are encrypted at rest using a dedicated Cloud KMS key managed by the organization's security team. Exfiltration and perimeter protection: Adding the Artifact Registry and Container Security API (containersecurity.googleapis.com) services to a VPC Service Controls perimeter prevents data exfiltration and restricts unauthorized ingress/egress across project boundaries. Block non-compliant deployments: Deploying Binary Authorization admission controllers on GKE ensures that images must possess valid cryptographic attestations (such as passing vulnerability scan checks in CI/CD) before they are permitted to run in production. Key advantages and capabilities Comprehensive perimeter isolation: Secures artifact access and vulnerability reporting endpoints without exposing service APIs to public data exfiltration. Cryptographic verification: Enforces deploy-time compliance by checking attestations generated during CI vulnerability scanning. Centralized key rotation: Allows instant revocation of repository data access by disabling the Cloud KMS key. Automated enforcement: Prevents human error or unauthorized deployments via Kubernetes validating admission webhooks. Why this is optimal This approach directly addresses storage encryption, network-level data exfiltration boundaries, and deploy-time admission enforcement natively within Google Cloud without requiring third-party runtime agents or unmanaged custom scripts.

Block Unverified Images with Binary Authorization

Secure Artifact Supply Chain with CMEK and Admission Control

An enterprise is designing a secure software supply chain pipeline for containerized applications deployed to Google Kubernetes Engine (GKE). The security architecture must satisfy the following requirements:

Store build artifacts in Artifact Registry with encryption controlled by company-managed keys in Cloud KMS.
Protect the repository and vulnerability scanning services against data exfiltration using network perimeters.
Prevent unverified images or container images containing policy violations from being deployed to production GKE clusters.

Which combination of Google Cloud security controls and architectural practices should the DevOps engineer implement?

Configure automated vulnerability scanning in Artifact Registry, configure GKE Enterprise Policy Controller to audit container security contexts, and configure Istiod control plane isolation with VPC firewall rules.

Configure an Artifact Registry repository with CMEK, apply VPC firewall rules to restrict node pool outbound access, and restrict GKE cluster operations exclusively using namespace-scoped Kubernetes RBAC roles.

Create an Artifact Registry repository configured with Customer-Managed Encryption Keys (CMEK), include Artifact Registry and Container Security APIs inside a VPC Service Controls perimeter, and enforce Binary Authorization policies with admission webhooks on GKE.

Create an Artifact Registry repository using default Google-managed encryption keys, apply Kubernetes Network Policies to the GKE ingress namespace, and use Cloud Service Mesh sidecar injection to block unverified images.

Explanations

Configure automated vulnerability scanning in Artifact Registry, configure GKE Enterprise Policy Controller to audit container security contexts, and configure Istiod control plane isolation with VPC firewall rules.

What the option is

This proposal relies on Policy Controller constraint templates for pod security context auditing, standard vulnerability scanning, and control plane isolation for Cloud Service Mesh.

Why it doesn't meet the requirement

Fails customer key encryption: It does not configure Customer-Managed Encryption Keys (CMEK) on the Artifact Registry repository.
Fails exfiltration perimeter: It does not implement VPC Service Controls around Artifact Registry or the Container Security API.
Fails automated signature verification: Auditing container security contexts (such as seccomp or privileged flags) does not verify cryptographic CI/CD attestations or prevent images with unpatched vulnerabilities from being deployed.

Key characteristics and limitations

Policy Controller audits in-cluster pod configurations against security policies but does not act as an attestation-based deployment authority like Binary Authorization.
Securing the Istiod control plane protects service mesh configuration but does not protect the artifact build and deployment pipeline.

This answer would be correct if

The goal were ensuring that running pods follow CIS GKE security baselines (such as dropping Linux capabilities or enforcing non-root users).

View source documentation

Configure an Artifact Registry repository with CMEK, apply VPC firewall rules to restrict node pool outbound access, and restrict GKE cluster operations exclusively using namespace-scoped Kubernetes RBAC roles.

What the option is

This configuration applies customer-managed encryption to the repository, uses Google Cloud VPC firewall rules for network filtering, and configures namespace-scoped Kubernetes RBAC bindings.

Why it doesn't meet the requirement

Lacks managed API perimeters: VPC firewall rules filter VM and pod network traffic at the VPC level, but they do not establish VPC Service Controls perimeters to protect Google Cloud API endpoints (like Container Security API) from exfiltration.
Lacks image signature admission enforcement: Kubernetes RBAC restricts which users can submit deployment manifests, but it cannot inspect container image digests, vulnerability scan results, or cryptographic attestations upon pod creation.

Key characteristics and limitations

RBAC governs user permissions against Kubernetes API objects, not artifact integrity or vulnerability thresholds.
Standard VPC firewall rules cannot protect managed multi-tenant Google Cloud storage endpoints without VPC SC.

This answer would be correct if

The objective were limited to restricting human operator access to specific Kubernetes namespaces and filtering GKE node egress traffic.

View source documentation

Create an Artifact Registry repository configured with Customer-Managed Encryption Keys (CMEK), include Artifact Registry and Container Security APIs inside a VPC Service Controls perimeter, and enforce Binary Authorization policies with admission webhooks on GKE.

What the solution is

This architecture combines Artifact Registry Customer-Managed Encryption Keys (CMEK), VPC Service Controls (VPC SC) perimeters, and Binary Authorization on Google Kubernetes Engine (GKE) to establish an end-to-end secure software supply chain.

How it meets the requirements

Company-controlled encryption: Configuring Artifact Registry with CMEK ensures that container images and layers are encrypted at rest using a dedicated Cloud KMS key managed by the organization's security team.
Exfiltration and perimeter protection: Adding the Artifact Registry and Container Security API (containersecurity.googleapis.com) services to a VPC Service Controls perimeter prevents data exfiltration and restricts unauthorized ingress/egress across project boundaries.
Block non-compliant deployments: Deploying Binary Authorization admission controllers on GKE ensures that images must possess valid cryptographic attestations (such as passing vulnerability scan checks in CI/CD) before they are permitted to run in production.

Key advantages and capabilities

Comprehensive perimeter isolation: Secures artifact access and vulnerability reporting endpoints without exposing service APIs to public data exfiltration.
Cryptographic verification: Enforces deploy-time compliance by checking attestations generated during CI vulnerability scanning.
Centralized key rotation: Allows instant revocation of repository data access by disabling the Cloud KMS key.
Automated enforcement: Prevents human error or unauthorized deployments via Kubernetes validating admission webhooks.

Why this is optimal

This approach directly addresses storage encryption, network-level data exfiltration boundaries, and deploy-time admission enforcement natively within Google Cloud without requiring third-party runtime agents or unmanaged custom scripts.

View source documentation

Create an Artifact Registry repository using default Google-managed encryption keys, apply Kubernetes Network Policies to the GKE ingress namespace, and use Cloud Service Mesh sidecar injection to block unverified images.

What the option is

This approach relies on Google default storage encryption, Layer 3/4 Kubernetes Network Policies, and Cloud Service Mesh sidecars for traffic management.

Why it doesn't meet the requirement

Fails storage encryption control: Google-managed keys do not give the enterprise direct management, revocation, or rotation control over the encryption keys in Cloud KMS.
Fails data exfiltration perimeter: Kubernetes Network Policies operate strictly within the Kubernetes cluster network (L3/L4) and cannot secure cloud API services like Artifact Registry or Container Security API against cross-project exfiltration.
Fails admission blocking: Cloud Service Mesh sidecars manage runtime service-to-service communication and mTLS, but cannot prevent unauthorized container images from being pulled and scheduled on GKE nodes.

Key characteristics and limitations

Kubernetes Network Policies only filter IP and port traffic between pods and namespaces.
Cloud Service Mesh enforces Layer 7 traffic policies but does not validate container image signatures at container deployment time.
Default encryption keys are rotated and managed entirely by Google without customer governance.

This answer would be correct if

The primary goal were to isolate East-West microservice network traffic and enforce mutual TLS between active workloads inside the cluster.

View source documentation

Last updated August 28, 2026Validated August 28, 2026

Secure Artifact Supply Chain with CMEK and Admission Control

Store build artifacts in Artifact Registry with encryption controlled by company-managed keys in Cloud KMS.
Protect the repository and vulnerability scanning services against data exfiltration using network perimeters.
Prevent unverified images or container images containing policy violations from being deployed to production GKE clusters.

Which combination of Google Cloud security controls and architectural practices should the DevOps engineer implement?

Explanations

Configure automated vulnerability scanning in Artifact Registry, configure GKE Enterprise Policy Controller to audit container security contexts, and configure Istiod control plane isolation with VPC firewall rules.

What the option is

This proposal relies on Policy Controller constraint templates for pod security context auditing, standard vulnerability scanning, and control plane isolation for Cloud Service Mesh.

Why it doesn't meet the requirement

Fails customer key encryption: It does not configure Customer-Managed Encryption Keys (CMEK) on the Artifact Registry repository.
Fails exfiltration perimeter: It does not implement VPC Service Controls around Artifact Registry or the Container Security API.
Fails automated signature verification: Auditing container security contexts (such as seccomp or privileged flags) does not verify cryptographic CI/CD attestations or prevent images with unpatched vulnerabilities from being deployed.

Key characteristics and limitations

Policy Controller audits in-cluster pod configurations against security policies but does not act as an attestation-based deployment authority like Binary Authorization.
Securing the Istiod control plane protects service mesh configuration but does not protect the artifact build and deployment pipeline.

This answer would be correct if

The goal were ensuring that running pods follow CIS GKE security baselines (such as dropping Linux capabilities or enforcing non-root users).

View source documentation

Configure an Artifact Registry repository with CMEK, apply VPC firewall rules to restrict node pool outbound access, and restrict GKE cluster operations exclusively using namespace-scoped Kubernetes RBAC roles.

What the option is

This configuration applies customer-managed encryption to the repository, uses Google Cloud VPC firewall rules for network filtering, and configures namespace-scoped Kubernetes RBAC bindings.

Why it doesn't meet the requirement

Lacks managed API perimeters: VPC firewall rules filter VM and pod network traffic at the VPC level, but they do not establish VPC Service Controls perimeters to protect Google Cloud API endpoints (like Container Security API) from exfiltration.
Lacks image signature admission enforcement: Kubernetes RBAC restricts which users can submit deployment manifests, but it cannot inspect container image digests, vulnerability scan results, or cryptographic attestations upon pod creation.

Key characteristics and limitations

RBAC governs user permissions against Kubernetes API objects, not artifact integrity or vulnerability thresholds.
Standard VPC firewall rules cannot protect managed multi-tenant Google Cloud storage endpoints without VPC SC.

This answer would be correct if

The objective were limited to restricting human operator access to specific Kubernetes namespaces and filtering GKE node egress traffic.

View source documentation

Create an Artifact Registry repository configured with Customer-Managed Encryption Keys (CMEK), include Artifact Registry and Container Security APIs inside a VPC Service Controls perimeter, and enforce Binary Authorization policies with admission webhooks on GKE.

What the solution is

How it meets the requirements

Company-controlled encryption: Configuring Artifact Registry with CMEK ensures that container images and layers are encrypted at rest using a dedicated Cloud KMS key managed by the organization's security team.
Exfiltration and perimeter protection: Adding the Artifact Registry and Container Security API (containersecurity.googleapis.com) services to a VPC Service Controls perimeter prevents data exfiltration and restricts unauthorized ingress/egress across project boundaries.
Block non-compliant deployments: Deploying Binary Authorization admission controllers on GKE ensures that images must possess valid cryptographic attestations (such as passing vulnerability scan checks in CI/CD) before they are permitted to run in production.

Key advantages and capabilities

Comprehensive perimeter isolation: Secures artifact access and vulnerability reporting endpoints without exposing service APIs to public data exfiltration.
Cryptographic verification: Enforces deploy-time compliance by checking attestations generated during CI vulnerability scanning.
Centralized key rotation: Allows instant revocation of repository data access by disabling the Cloud KMS key.
Automated enforcement: Prevents human error or unauthorized deployments via Kubernetes validating admission webhooks.

Why this is optimal

View source documentation

Create an Artifact Registry repository using default Google-managed encryption keys, apply Kubernetes Network Policies to the GKE ingress namespace, and use Cloud Service Mesh sidecar injection to block unverified images.

What the option is

This approach relies on Google default storage encryption, Layer 3/4 Kubernetes Network Policies, and Cloud Service Mesh sidecars for traffic management.

Why it doesn't meet the requirement

Fails storage encryption control: Google-managed keys do not give the enterprise direct management, revocation, or rotation control over the encryption keys in Cloud KMS.
Fails data exfiltration perimeter: Kubernetes Network Policies operate strictly within the Kubernetes cluster network (L3/L4) and cannot secure cloud API services like Artifact Registry or Container Security API against cross-project exfiltration.
Fails admission blocking: Cloud Service Mesh sidecars manage runtime service-to-service communication and mTLS, but cannot prevent unauthorized container images from being pulled and scheduled on GKE nodes.

Key characteristics and limitations

Kubernetes Network Policies only filter IP and port traffic between pods and namespaces.
Cloud Service Mesh enforces Layer 7 traffic policies but does not validate container image signatures at container deployment time.
Default encryption keys are rotated and managed entirely by Google without customer governance.

This answer would be correct if

The primary goal were to isolate East-West microservice network traffic and enforce mutual TLS between active workloads inside the cluster.

View source documentation

Last updated August 28, 2026Validated August 28, 2026

Secure Artifact Supply Chain with CMEK and Admission Control

Explanations

Configure automated vulnerability scanning in Artifact Registry, configure GKE Enterprise Policy Controller to audit container security contexts, and configure Istiod control plane isolation with VPC firewall rules.

What the option is

Why it doesn't meet the requirement

Key characteristics and limitations

This answer would be correct if

Configure an Artifact Registry repository with CMEK, apply VPC firewall rules to restrict node pool outbound access, and restrict GKE cluster operations exclusively using namespace-scoped Kubernetes RBAC roles.

What the option is

Why it doesn't meet the requirement

Key characteristics and limitations

This answer would be correct if

Create an Artifact Registry repository configured with Customer-Managed Encryption Keys (CMEK), include Artifact Registry and Container Security APIs inside a VPC Service Controls perimeter, and enforce Binary Authorization policies with admission webhooks on GKE.

What the solution is

How it meets the requirements

Key advantages and capabilities

Why this is optimal

Create an Artifact Registry repository using default Google-managed encryption keys, apply Kubernetes Network Policies to the GKE ingress namespace, and use Cloud Service Mesh sidecar injection to block unverified images.

What the option is

Why it doesn't meet the requirement

Key characteristics and limitations

This answer would be correct if

Try 10 interactive questions like this one, free

Related questions

Artifact Registry KEEP vs DELETE Policy Precedence

Artifact Registry Standard Remote Virtual Repositories

Build-Time vs Runtime Secret Injection

Config Sync RootSync vs RepoSync

Resource-Based vs Spend-Based CUDs with Discount Sharing

Service Account OpenID Connect Identity Token Creator

Secure Artifact Supply Chain with CMEK and Admission Control

Explanations

Configure automated vulnerability scanning in Artifact Registry, configure GKE Enterprise Policy Controller to audit container security contexts, and configure Istiod control plane isolation with VPC firewall rules.

What the option is

Why it doesn't meet the requirement

Key characteristics and limitations

This answer would be correct if

Configure an Artifact Registry repository with CMEK, apply VPC firewall rules to restrict node pool outbound access, and restrict GKE cluster operations exclusively using namespace-scoped Kubernetes RBAC roles.

What the option is

Why it doesn't meet the requirement

Key characteristics and limitations

This answer would be correct if

Create an Artifact Registry repository configured with Customer-Managed Encryption Keys (CMEK), include Artifact Registry and Container Security APIs inside a VPC Service Controls perimeter, and enforce Binary Authorization policies with admission webhooks on GKE.

What the solution is

How it meets the requirements

Key advantages and capabilities

Why this is optimal

Create an Artifact Registry repository using default Google-managed encryption keys, apply Kubernetes Network Policies to the GKE ingress namespace, and use Cloud Service Mesh sidecar injection to block unverified images.

What the option is

Why it doesn't meet the requirement

Key characteristics and limitations

This answer would be correct if

Try 10 interactive questions like this one, free

Related questions

Artifact Registry KEEP vs DELETE Policy Precedence

Artifact Registry Standard Remote Virtual Repositories

Build-Time vs Runtime Secret Injection

Config Sync RootSync vs RepoSync

Resource-Based vs Spend-Based CUDs with Discount Sharing

Service Account OpenID Connect Identity Token Creator