An enterprise operates a sensitive multi-tier financial application running across multiple namespaces on Google Kubernetes Engine (GKE). To comply with a zero-trust security framework, the architecture must satisfy two core requirements: Cryptographic Data Encapsulation & Identity Verification: All inter-service traffic between application tiers must be authenticated and encrypted in transit using mutual TLS (mTLS), strictly rejecting any unencrypted plaintext connections. Network-Layer Boundary Segmentation: Microservices must be isolated at Layer 3/Layer 4 (L3/L4) so that workloads can only receive network traffic from designated tier Pods and authorized namespaces, mitigating lateral movement. Which combination of controls should the security team implement to satisfy these requirements?

Apply a Cloud Service Mesh PeerAuthentication policy configured with STRICT mode, and implement Kubernetes NetworkPolicies targeting Pod labels and namespace selectors.: ### What the Solution Is This architecture combines **Cloud Service Mesh** transport authentication controls with native Kubernetes **NetworkPolicy** resources to create a defense-in-depth, zero-trust boundary around containerized microservice tiers in GKE. ### How It Meets the Requirements - **Cryptographic encapsulation and mTLS enforcement**: Applying a `PeerAuthentication` custom resource with `spec.mtls.mode: STRICT` (either across the mesh in the `istio-system` root namespace or per workload namespace) ensures that the sidecar proxies mandate mutual TLS. Plaintext traffic and unauthenticated requests are actively blocked at the application/transport layer. - **L3/L4 microsegmentation and boundary control**: Kubernetes `NetworkPolicy` objects enforce container-level packet filtering. By leveraging `podSelector` and `namespaceSelector`, security teams specify exact ingress and egress whitelists, ensuring that only explicitly authorized Pods can establish network connections to sensitive backend tiers. ### Key Advantages and Capabilities - **Dual-layer defense**: Operates across Layer 3/4 (IP/port packet filtering) and Layer 7 (workload identity verification and cryptographic encryption). - **Zero-trust verification**: Requires workloads to present cryptographic identity certificates provided by the mesh control plane while disallowing unauthorized lateral movement at the kernel/CNI level. - **Automated certificate rotation**: Cloud Service Mesh dynamically provisions and rotates x509 certificates to proxy sidecars without code modifications. - **Namespace isolation**: Enforces boundaries between diverse application tiers deployed across separate Kubernetes namespaces. ### Why This Is Optimal Combining **`PeerAuthentication` in `STRICT` mode** with **Kubernetes `NetworkPolicies`** addresses both transport-layer data encapsulation and network-level microsegmentation. It prevents lateral movement from compromised Pods while guaranteeing that all in-flight microservice data is cryptographically secure.

Gke Microsegmentation Service Mesh Strict Mtls | Professional Cloud Security Engineer

Gke Microsegmentation Service Mesh Strict Mtls

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 operates a sensitive multi-tier financial application running across multiple namespaces on Google Kubernetes Engine (GKE). To comply with a zero-trust security framework, the architecture must satisfy two core requirements:

Cryptographic Data Encapsulation & Identity Verification: All inter-service traffic between application tiers must be authenticated and encrypted in transit using mutual TLS (mTLS), strictly rejecting any unencrypted plaintext connections.
Network-Layer Boundary Segmentation: Microservices must be isolated at Layer 3/Layer 4 (L3/L4) so that workloads can only receive network traffic from designated tier Pods and authorized namespaces, mitigating lateral movement.

Which combination of controls should the security team implement to satisfy these requirements?

Apply a Cloud Service Mesh PeerAuthentication policy configured with PERMISSIVE mode, and configure Google Cloud VPC firewall rules referencing Compute Engine network tags.

Configure Cloud Service Mesh DestinationRule resources with DISABLE TLS mode, and enforce GKE node-to-node IPsec encryption using Cloud VPN tunnels.

Apply a Cloud Service Mesh PeerAuthentication policy configured with STRICT mode, and implement Kubernetes NetworkPolicies targeting Pod labels and namespace selectors.

Deploy Binary Authorization attestation policies to Pod admission controllers, and configure Google Cloud Armor security policies on internal HTTP(S) Load Balancers.

Professional Cloud Security Engineer

Gke Microsegmentation Service Mesh Strict Mtls

Related questions