A retailer with branch stores sees tests fail while a bad route is present and recover at every store as soon as that route is withdrawn, with no application change. What caused the failure?
Select an answer to reveal the explanation.
Short Explanation
When the detour sign comes down and every store can drive again without a software update, the sign was the problem. You attribute the retailer outage to the routing event, because tests recovered with no code change. Bandwidth, QoS, and laptop replacement do not fit a failure that left with the route.
Full Explanation
The failure and the recovery share one change: the bad route was present while tests failed, and tests recovered at every store when that route was withdrawn, with no application change. That timeline makes the routing event the cause. Too little bandwidth does not explain a simultaneous recovery that required no capacity change and tracked a route withdrawal. A QoS policy problem would remain after the route left, unless someone also changed the policy, and nothing in the evidence says the scheduler was edited. Faulty branch laptops would not all recover, across stores, at the moment one route disappeared, and no laptop was replaced. Exam caveat: two changes that land at the same minute can still be confused, so check that no separate code or policy push coincided with the withdrawal. Operational check: line the test timeline up with the route advertisement and the withdrawal, and confirm the application build is the same build that failed and then recovered. If the route is the only thing that changed, the outage was a routing event.