An enterprise is deploying a multi-tier microservices application across Google Kubernetes Engine (GKE) and standalone Compute Engine virtual machines (VMs) in a custom-mode Virtual Private Cloud (VPC). The infrastructure must satisfy the following architectural and security requirements: GKE Pods must have directly routable IP addresses across the VPC network to communicate with database workloads running on Compute Engine instances without using NAT or consuming static route quotas. Internal East-West traffic between containerized microservices within the cluster must be restricted at Layer 3 and Layer 4 using Kubernetes pod labels to prevent unauthorized lateral communication. Which network architecture and security configuration should you implement?

Create a VPC-native GKE cluster using secondary subnet CIDR ranges for alias IP pod allocation, and define Kubernetes NetworkPolicy resources to restrict pod-to-pod ingress traffic.: What VPC-Native Clusters and Network Policies Are A VPC-native cluster leverages Google Cloud's native alias IP ranges to assign internal IP addresses directly to GKE Pods from a dedicated secondary CIDR range in a VPC subnet. A Kubernetes NetworkPolicy is a native Kubernetes resource that acts as a packet-level firewall for Pods, restricting traffic flow based on pod selectors, namespace labels, and port definitions. How It Meets the Requirements Direct VPC Routability Without Routes Quota: By using alias IP ranges, Pod IP addresses are native internal addresses recognized across the entire VPC network. Traffic between GKE Pods and Compute Engine VM databases flows directly without intermediate network address translation (NAT) and without consuming custom VPC route quotas. Pod-to-Pod Traffic Segmentation: Enforcing Kubernetes NetworkPolicy objects allows fine-grained East-West micro-segmentation inside the cluster, restricting pod ingress and egress traffic based on application labels and target ports at Layer 3 and Layer 4. Key Advantages and Capabilities Scalable Address Management: Separates VM infrastructure addressing (primary CIDR) from container pod addressing (secondary CIDR). Built-in Anti-spoofing: Automatically protects VM and Pod network interfaces without disabling Google Cloud anti-spoofing checks. Granular Pod-Level Security: Isolates application tiers within the cluster while allowing authorized pods to communicate natively across the broader VPC network. Why This Is Optimal This architecture is Google Cloud's recommended best practice for enterprise GKE deployments. It avoids the scaling limits of legacy routes-based clusters and enables native pod-level security controls without requiring external appliances.

StudyCerts

Professional Cloud Architect

Intrigued by the art of cloud architecture? Discover how to design, develop, and manage robust, secure, scalable, and dynamic solutions on Google Cloud as you prepare for the Professional Cloud Architect exam!

Intermediate

Prepare and test your skills

Track Readiness

Set Exam Goal

Intermediate

Prepare and test your skills

Track Readiness

Set Exam Goal

Gke Vpc Native Alias Ip Network Policy

Section: Cloud-native network configuration for compute resources (e.g., Compute Engine, GKE, serverless networking, and Google Cloud VMware Engine)

An enterprise is deploying a multi-tier microservices application across Google Kubernetes Engine (GKE) and standalone Compute Engine virtual machines (VMs) in a custom-mode Virtual Private Cloud (VPC).

The infrastructure must satisfy the following architectural and security requirements:

GKE Pods must have directly routable IP addresses across the VPC network to communicate with database workloads running on Compute Engine instances without using NAT or consuming static route quotas.
Internal East-West traffic between containerized microservices within the cluster must be restricted at Layer 3 and Layer 4 using Kubernetes pod labels to prevent unauthorized lateral communication.

Which network architecture and security configuration should you implement?

Create a VPC-native GKE cluster allocating pod IPs from the primary subnet range, and configure Google Cloud Armor security policies on internal BackendConfigs to filter container labels.

Create a routes-based GKE cluster with IP forwarding enabled on worker node VMs, and configure VPC firewall rules targeting Compute Engine network tags to restrict pod-to-pod communication.

Create a VPC-native GKE cluster using secondary subnet CIDR ranges for alias IP pod allocation, and define Kubernetes NetworkPolicy resources to restrict pod-to-pod ingress traffic.

Create a private GKE cluster in default auto-mode VPC networking, and apply hierarchical firewall policies at the folder level to block containerized traffic across namespaces.

Professional Cloud Architect

Intermediate

Prepare and test your skills

Track Readiness

Set Exam Goal

Intermediate

Prepare and test your skills

Track Readiness

Set Exam Goal

Gke Vpc Native Alias Ip Network Policy

Section: Cloud-native network configuration for compute resources (e.g., Compute Engine, GKE, serverless networking, and Google Cloud VMware Engine)

The infrastructure must satisfy the following architectural and security requirements:

GKE Pods must have directly routable IP addresses across the VPC network to communicate with database workloads running on Compute Engine instances without using NAT or consuming static route quotas.
Internal East-West traffic between containerized microservices within the cluster must be restricted at Layer 3 and Layer 4 using Kubernetes pod labels to prevent unauthorized lateral communication.

Which network architecture and security configuration should you implement?

Create a VPC-native GKE cluster allocating pod IPs from the primary subnet range, and configure Google Cloud Armor security policies on internal BackendConfigs to filter container labels.

Create a routes-based GKE cluster with IP forwarding enabled on worker node VMs, and configure VPC firewall rules targeting Compute Engine network tags to restrict pod-to-pod communication.

Create a VPC-native GKE cluster using secondary subnet CIDR ranges for alias IP pod allocation, and define Kubernetes NetworkPolicy resources to restrict pod-to-pod ingress traffic.

Create a private GKE cluster in default auto-mode VPC networking, and apply hierarchical firewall policies at the folder level to block containerized traffic across namespaces.

Explanations

What VPC-Native Clusters and Network Policies Are

A VPC-native cluster leverages Google Cloud's native alias IP ranges to assign internal IP addresses directly to GKE Pods from a dedicated secondary CIDR range in a VPC subnet. A Kubernetes NetworkPolicy is a native Kubernetes resource that acts as a packet-level firewall for Pods, restricting traffic flow based on pod selectors, namespace labels, and port definitions.

How It Meets the Requirements

Direct VPC Routability Without Routes Quota: By using alias IP ranges, Pod IP addresses are native internal addresses recognized across the entire VPC network. Traffic between GKE Pods and Compute Engine VM databases flows directly without intermediate network address translation (NAT) and without consuming custom VPC route quotas.
Pod-to-Pod Traffic Segmentation: Enforcing Kubernetes NetworkPolicy objects allows fine-grained East-West micro-segmentation inside the cluster, restricting pod ingress and egress traffic based on application labels and target ports at Layer 3 and Layer 4.

Key Advantages and Capabilities

Scalable Address Management: Separates VM infrastructure addressing (primary CIDR) from container pod addressing (secondary CIDR).
Built-in Anti-spoofing: Automatically protects VM and Pod network interfaces without disabling Google Cloud anti-spoofing checks.
Granular Pod-Level Security: Isolates application tiers within the cluster while allowing authorized pods to communicate natively across the broader VPC network.

Why This Is Optimal

This architecture is Google Cloud's recommended best practice for enterprise GKE deployments. It avoids the scaling limits of legacy routes-based clusters and enables native pod-level security controls without requiring external appliances.

View source documentation

Professional Cloud Architect

Gke Vpc Native Alias Ip Network Policy

Professional Cloud Architect

Gke Vpc Native Alias Ip Network Policy

What VPC-Native Clusters and Network Policies Are

How It Meets the Requirements

Key Advantages and Capabilities

Why This Is Optimal

Related questions