Courseiva

Google PCA Manage implementation of cloud architecture Practice Question

A company is deploying a microservices application on Google Kubernetes Engine (GKE). They want to ensure that each microservice can only communicate with specific other microservices, and they need to enforce this at the network level. They also want to minimize operational overhead. Which approach should they use?

⚠ Common exam trap

The trap here is assuming that VPC firewall rules can provide pod-level isolation, but they operate at the node level and cannot distinguish between pods.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Use Kubernetes NetworkPolicies to define ingress and egress rules between pods.

Kubernetes NetworkPolicies are the native, low-overhead way to enforce pod-level network segmentation in GKE. They allow you to define which pods can communicate based on labels and namespaces, and they are enforced by the CNI plugin. This meets the requirement for fine-grained control with minimal operational effort compared to a service mesh or node-level firewall rules.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • ✗

    Configure VPC firewall rules to allow or deny traffic between GKE nodes.

    Why it's wrong here

    VPC firewall rules operate at the node level, not the pod level. They cannot distinguish between different pods on the same node, so they cannot enforce microservice-to-microservice communication policies. While they can restrict traffic to nodes, they lack the granularity needed for pod-level isolation, which is required for microservices.

  • ✓

    Use Kubernetes NetworkPolicies to define ingress and egress rules between pods.

    Why this is correct

    Kubernetes NetworkPolicies allow you to specify which pods can communicate with each other based on labels and namespaces. They are enforced by the container network interface (CNI) plugin, such as Calico, which is available in GKE. This approach provides fine-grained control at the pod level and is native to Kubernetes, minimizing operational overhead compared to custom solutions.

  • ✗

    Use Google Cloud Armor security policies to restrict traffic between services.

    Why it's wrong here

    Google Cloud Armor is designed to protect against external threats at the edge, such as DDoS attacks and web application firewalls. It operates at the HTTP(S) load balancer level and cannot enforce pod-to-pod communication within a GKE cluster. It is not suitable for internal microservice communication policies.

  • ✗

    Implement a service mesh like Istio to manage service-to-service communication.

    Why it's wrong here

    A service mesh like Istio provides advanced traffic management, security, and observability, but it adds significant operational overhead, including deploying and managing the control plane and sidecar proxies. While it can enforce policies, the requirement is to minimize operational overhead, so a simpler native solution is preferable.

Go deeper

Related to this question

About these practice questions

One of 807 original PCA practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

JA

Written and reviewed by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

Last reviewed September 2026 · checked against the official Google Cloud exam blueprint

This PCA practice question is part of Courseiva's free Google Cloud certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the PCA exam.