Troubleshooting Cross-Subnet Connectivity via Routing Tables
Short answer
B The Application Server Subnet Routing Table should be addressed to fix the communication issue by adding the necessary route to the database subnet.
Question
Which of the following should the cloud engineer address to fix the communication issue?
Key Takeaways
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.
Common mistake: 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.
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?
Does a default route always solve cross-subnet issues?
Discussion 3 contributions
Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.
From public community threads 3
-
phryde 👍 3 Answered BThere is no route to 192.168.2.0/24 from the application server subnet, it would be unable to reach it. compare to the MySQL server subnet routing table.
-
ef74e4b 👍 2 Answered CC. The MySQL Server Stateful Firewall
-
balls99 👍 1 Answered DIt isn't B. The application server’s table has default → 192.168.1.1, and a default route matches any destination that doesn’t have a more specific entry, including 192.168.2.0/24. Traffic for the MySQL subnet goes to 192.168.1.1, and the router forwards it from there. An explicit 192.168.2.0/24 entry isn’t needed, because the default route already covers it. The MySQL subnet routing table has 192.168.1.1 locally attached, so traffic to the Application Server never leaves the local link. The fix is for the MySQL subnet’s table to list 192.168.2.0/24 as local and reach 192.168.1.0/24 (or a default route) through its own gateway, likely 192.168.2.1.
Reader comments & corrections
No reader corrections yet — spotted an error or have a note? Share it below.
Related Analysis
Practice All CV0-004 Questions
Access 100 questions with complete answers and detailed explanations.
View Full CV0-004 Practice Test →