An incorrect DNS entry resolves the cloud cluster into the wrong subnet and breaks hybrid scaling
Given a scenario, troubleshoot connectivity issues.
AnswerCorrect answer: A — The cloud cluster belongs in 10.168.0.0/16 yet resolves into 192.168.x.x, so an incorrect DNS entry is misdirecting the on-premises pings.
An organization’s two-node, hybrid container cluster is experiencing failures during horizontal scaling to the cloud cluster instance. The on-premises IP range is 192.168.0.0/16, and the cloud environment is 10.168.0.0/16. Overlapping or stretched VLANs are not permitted, and a node is deployed in each location. The cloud monitoring agent reports a healthy status for the second instance, but when pining the clusters from on premises, the following output is received: Which of the following is the most likely reason for the scaling failure? -
100% of anonymous learners picked answer A.
Votes are pick records left by other test-takers — they are not the verified answer.
Community Insight
When a monitoring agent inside the cloud sees the node healthy but on-premises pings return an address from the wrong /16, the fault is name resolution, not routing or the node itself.
A hybrid container cluster fails to scale into the cloud node, whose network is 10.168.0.0/16, while the cloud monitoring agent reports it healthy. The ping output from on premises shows the cloud cluster resolving to a 192.168.x.x address, a name-resolution fault that sends traffic to the wrong subnet.
Choosing an incorrect IP route (E) overlooks that the monitoring agent works fine, which rules out a broken path; the addresses themselves are wrong, and that is DNS.
Community Discussion (3 comments)
WereAllinThisTogether👍 1Selected: A
I believe the first cluster is on-prem and the second cluster is in the cloud. A incorrect DNS entry would explain the time-out because the IP does not exist.
Stonetales987👍 3Selected: A
If you look at the response of pinging cluster 2 which resides in the cloud and is in the 10.168.0.0/16 network. We wouldn't see a 192.x.x.x address. A DNS error would result in the ping failing. For D. The cluster IP address on the output appears wrong because of the DNS error. For E. Incorrect IP route, the monitoring agent wouldn't be working if there was a network issue.
TehScrag👍 2
I would go with D. The second IP should be pointing to 10.168.x.x
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Log in to comment, report an error, or add a note about this question.
Expert Analysis
Why the Answer Is Correct
The cloud node sits in 10.168.0.0/16, so any reply showing a 192.168.x.x source or a ping resolving the cloud cluster name into that range means the name was translated to the wrong address. The monitoring agent, running inside the cloud, reports the second instance healthy, which proves the node and its networking are fine from within. A stale or wrong DNS entry for the cloud cluster name is the one fault that makes on-premises clients dial the wrong subnet while the target itself stays healthy.
Why the Other Options Are Wrong
B, an offline cluster node, contradicts the monitoring agent's healthy report for the second instance. C, an incorrect proxy entry, would affect HTTP-based management traffic rather than raw ICMP name resolution, and nothing in the scenario involves a proxy. D, an incorrect cluster IP, is tempting, but the wrong-looking address in the output is a symptom of DNS handing out the wrong value, not a misconfiguration of the cluster's real IP. E, an incorrect IP route, cannot explain the healthy agent and would produce timeouts rather than replies from a foreign subnet.
Community Comment Notes
Stonetales987 walks the output precisely: cluster 2 lives in 10.168.0.0/16, so seeing a 192.x.x.x response means the name resolved wrong, and a monitoring agent that works rules out routing. WereAllinThisTogether agrees that a DNS entry pointing at a nonexistent address explains the timeout from on premises. TehScrag argues for D on the observation that the second IP should be 10.168.x.x, but that wrong value is exactly what a bad DNS record produces.
