PCNE Practice Question: Managing, Monitoring, and Optimising Network Operations
A company has two VPC networks connected via VPC peering. They notice asymmetric routing: traffic from Network A to Network B follows one path, but return traffic from B to A takes a different path. This is causing connectivity issues for stateful firewalls. What is the likely cause?
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
✓
Both VPCs have a default route (0.0.0.0/0) pointing to different next hops
VPC peering does not enforce symmetric routing by default. If both networks have subnet CIDRs that overlap, or if one network has a route that sends traffic to the other via a different next hop (e.g., VPN or NAT), asymmetric routing can occur. The most common cause is when both VPCs have a default route pointing to different next hops (e.g., one to the internet, one to a VPN), causing different paths.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The peering connection is in an inactive state
Why it's wrong here
Inactive peering would break connectivity entirely, not cause asymmetry.
- ✗
The firewall rules in Network A are more permissive than in Network B
Why it's wrong here
Firewall rules do not affect routing paths.
- ✗
There is a Cloud NAT configured in Network A but not in Network B
Why it's wrong here
NAT is for outbound internet, not internal peering.
- ✓
Both VPCs have a default route (0.0.0.0/0) pointing to different next hops
Why this is correct
Different default routes can cause traffic to exit via different gateways, breaking symmetry.
Visual reference
Quick reference
Asymmetric Encryption Algorithm Comparison
| Algorithm | Key Exchange | Signatures | Equivalent Security Key | Notes |
|---|---|---|---|---|
| RSA-3072 | Yes | Yes | 128-bit | Widely deployed; slow for bulk data |
| ECDSA P-256 | No | Yes | 128-bit | Fast signatures; standard TLS certs |
| ECDH / ECDHE | Yes | No | 128-bit | Perfect forward secrecy in TLS 1.3 |
| DH / DHE | Yes | No | 128-bit (3072-bit key) | Replaced by ECDHE in modern TLS |
| Ed25519 | No | Yes | ~128-bit | SSH keys, modern PKI |
Go deeper
Related to this question
About these practice questions
One of 961 original PCNE 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 →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This PCNE 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 PCNE exam.