Deploying Packet Mirroring Policies in GCP Regions

You are designing a packet mirroring policy as part of your network security architecture for your gaming workload. Your infrastructure is located in the us-west2 region and deployed across several zones: us-west2-a, us-west2-b, and us-west2-c. The infrastructure is running a web-based application on TCP ports 80 and 443 with other game servers that utilize the UDP protocol. You need to deploy packet mirroring policies and collector instances to monitor web application traffic while minimizing inter-zonal network egress costs. Following Google-recommended practices, how should you deploy the packet mirroring policies and collector instances?

Crate three packet mirroring policies: one for each zone. Create one group of collector instances for the us-west2 region. Configure each packet mirroring policy to match traffic for its zone based on instance-tags, and create a filter for TCP traffic.
Create one packet mirroring policy for the us-west2 region. Create one group of collector instances for the us-west2 region. Configure the packet mirroring policy to match traffic for web server instances based on instance-tags, and create a filter for TCP traffic. Source Reference Answer
Create three packet mirroring policies: one for each zone. Create three groups of collector instances: one group for each zone. Configure each policy to match traffic for its zone based on instance-tags, and create a filter for TCP traffic.
Create three packet mirroring policies: one for each zone. Create three groups of collector instances: one group for each zone. Configure each policy to match traffic for its zone based on subnets, and create a filter for TCP traffic.

Community Votes

50%

50% of anonymous learners picked answer B. Votes are pick records left by other test-takers — they are not the verified answer.

Community Insight

Examines the distinction between regional and zonal packet mirroring configurations, trapping candidates who assume zone-specific collectors are required to eliminate inter-zone data transfer costs.

GCP packet mirroring policies and collector instances operate at the regional level to centralize traffic monitoring across multiple availability zones. Although test-takers frequently debate zone-level placement to avoid egress fees, Google’s official architecture favors a unified regional policy paired with regional collector groups.

Option C is the most frequent incorrect choice, driven by the logical but outdated assumption that deploying collectors in each zone is necessary to prevent expensive cross-zone mirrored traffic.

Community Discussion (9 comments)

Popa 👍 2 Selected: C

While Option B does simplify the setup by using a single packet mirroring policy and a single group of collector instances for the region, it might result in inter-zonal network egress costs. This is because traffic from zones like us-west2-a and us-west2-c would need to travel to the collector instances if those instances are primarily located in another zone (e.g., us-west2-b). Google-recommended practices aim to minimize these egress costs by keeping mirrored traffic within the same zone. This is why Option C is generally favored: it creates separate packet mirroring policies and collector instances for each zone. This ensures that mirrored traffic does not cross zones, effectively eliminating inter-zonal egress costs. By matching traffic to web server instances using instance-tags and filtering only for TCP traffic, it provides a focused and efficient solution without unnecessary data transfer.

RKS_2021 👍 1 Selected: C

B you can not create single packet mirroring policy for three zones. C is correct - D is wrong subnets are not zone, they are regional

waelghaith 👍 1 Selected: C

C is the correct answer

anshad666 👍 1 Selected: B

Policy created based on region , not based Zone

Positron75 👍 2 Selected: C

Wouldn't it be C if we want to minimize data egress costs between zones? C and D are the only options that create packet mirroring policies and collector instances in each zone, and instance tags sound like a better (more specific) option than subnets. Both A and B would result in additional egress costs as with only one group of collector instances for the whole region, all the mirrored data has to be travel between zones. From the documentation (https://cloud.google.com/vpc/docs/packet-mirroring#key_properties): "The cost of Packet Mirroring varies depending on the amount of egress traffic traveling from a mirrored instance to an instance group and whether the traffic travels between zones." Seems to me like C is the only one that minimizes this cost.

desertlotus1211 👍 3

Answer is C. You need to use tags. D is incorrect

gonlafer 👍 2 Selected: B

Should not be inter-zonal egress cost. So I'd go now for B

gonlafer 👍 1 Selected: D

To me, D makes sense to minimize the egress traffic across zones, which is one requirement.

[Removed] 👍 3 Selected: B

To deploy packet mirroring policies and collector instances following Google-recommended practices while minimizing inter-zonal network egress costs, we need to consider the requirements and best practices outlined in the scenario. Given that the infrastructure is deployed across multiple zones within the us-west2 region and that the goal is to monitor web application traffic while minimizing egress costs, the most appropriate approach would be to consolidate collector instances and policies to cover the entire region. Option B seems to align with this approach

Comments & Corrections

No comments yet — spotted an error or have a note? Share it below.

Expert Analysis

Why the Answer Is Correct

Google Cloud natively supports regional packet mirroring policies, allowing a single configuration to capture traffic from all zones within us-west2 without redundant management overhead. Collector instances are also scoped regionally, meaning one managed group efficiently receives mirrored streams regardless of the originating zone. Matching traffic via instance-tags provides granular, protocol-aware filtering that easily spans subnets, aligning with security best practices. While inter-zone egress charges apply when collectors reside outside the source zone, Google’s recommended architecture prioritizes centralized observability and operational efficiency.

Why the Other Options Are Wrong

Options A and C incorrectly fragment the architecture by creating multiple zonal policies and collector groups, violating the principle of least complexity and increasing maintenance burden. Option D compounds this issue by relying on subnets rather than instance-tags, which limits flexibility if web servers span multiple subnets or use dynamic IP assignments. Furthermore, GCP’s current documentation explicitly states that packet mirroring policies are regional resources, making multi-policy deployments unnecessary and non-compliant with modern standards.

Community Comment Notes

The voting split reflects a common exam dilemma where practical cost concerns clash with vendor best practices. Comments 3 and 4 rightly highlight that inter-zone egress fees incentivize zone-local collectors, yet they overlook that regional policies are fully supported and optimized by Google. Comments 2 and 5 correctly identify that consolidated regional deployment follows official recommendations, while comment 6 accurately notes that policies are inherently regional, not zonal. This highlights the importance of trusting documented architecture over hypothetical cost scenarios in certification contexts.

Official Reference

Exam Strategy

When encountering cloud monitoring questions, always prioritize the vendor’s documented resource scope before optimizing for hypothetical cost scenarios. Certification exams typically reward standardized, centrally managed architectures unless the prompt explicitly mandates local processing for compliance or strict latency requirements.

Related Analysis

Practice All PCNE Questions

Access 80 questions with complete answers and detailed explanations.

View Full PCNE Practice Test →

← Back to PCNE Study Guide