Troubleshooting Cross-Subnet Connectivity via Routing Tables
A cloud engineer is troubleshooting a connectivity issue. The application server with IP 192.168.1.10 in one subnet is not connecting to the MySQL database server with IP 192.168.2.20 in a different subnet. The cloud engineer reviews the following information:
Which of the following should the cloud engineer address to fix the communication issue?
Community Insight
The question tests the ability to interpret routing tables; the common trap is assuming a default route suffices for all traffic or misidentifying the firewall as the blocker when the path is undefined.
This page analyzes a cross-subnet connectivity failure between an application server and a MySQL database, identifying the missing specific route in the application server's subnet routing table as the root cause.
Learners often incorrectly select the Stateful Firewall (A or C) because they assume security policies block traffic, ignoring the fundamental requirement that a valid next-hop route must exist before packets can be processed by security devices.
Community Discussion (3 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
The Application Server Subnet Routing Table (B) is the correct answer because it lacks a specific route for the 192.168.2.0/24 network. In cloud networking, if a host needs to communicate with a destination outside its local subnet, it consults its routing table. Without an explicit entry for the database subnet, the packet may fail to route correctly depending on the presence and configuration of a default gateway versus specific static routes. The exhibit implies a mismatch where the application server cannot resolve the path to the database IP, necessitating a route update.Why the Other Options Are Wrong
Options A and C (Stateful Firewalls) are incorrect because firewalls filter traffic that has already been routed; if the packet isn't routed, the firewall never sees it. Option D (MySQL Server Subnet Routing Table) is incorrect because the issue is initiated by the Application Server attempting to send traffic out; the return path would typically rely on reverse path forwarding or general connectivity, but the primary failure point described is the inability to connect from the app side.Community Comment Notes
Community discussion highlights the nuance between default routes and specific entries. One user noted that while a default route might cover unknown destinations, the specific scenario suggests a need for explicit routing logic or a missing entry in the context of the exam's simplified topology. Another commenter argued for the firewall, but this contradicts the fundamental networking principle that routing precedes filtering. The consensus leans towards the routing table being the structural fix required.Exam Strategy
When troubleshooting connectivity, always verify Layer 3 reachability (routing) before investigating Layer 4/7 controls (firewalls). Check the source device's routing table first to ensure it knows how to reach the destination subnet.
Frequently Asked Questions
Why not the firewall if it blocks connections?
Firewalls only inspect traffic that arrives at the interface. If the routing table doesn't have a path to send the packet, the packet is dropped locally before reaching the firewall.
Does a default route always solve cross-subnet issues?
Not always. In complex cloud environments or specific exam scenarios, explicit routes may be required for security zoning or policy-based routing, making the default route insufficient or non-existent for the specific segment.
Related Analysis
Practice All CV0-004 Questions
Access 100 questions with complete answers and detailed explanations.
View Full CV0-004 Practice Test →