A government agency's tests fail in the same minute a route flap is logged, and the path returns when the route stabilizes. What matches that failure?
Select an answer to reveal the explanation.
Short Explanation
When the lights go out at the same moment the breaker flips, you look at the breaker. You tie the failed tests to the routing change because the flap and the failures share the same minute and the path returns when the route settles. A browser cache, DNS with no routing change, or an office wireless ticket does not follow that flap.
Full Explanation
The agency's tests fail in the same minute a route flap is logged, and they recover when the route stabilizes. The failure lines up with the routing change at both the start and the recovery, which a local wireless problem would not do. The routing change that shares the minute the tests failed is the event that matches the timeline. A stale browser cache on the analyst workstation would stick until the cache is cleared. It would not fail and recover in step with a route flap. A DNS-only problem with no routing change in that same minute would show a resolution failure without a flap. That is not the timeline in front of the agency. A wireless fault on an office access point inside the agency would be a local radio symptom. It does not explain tests that fail and return together with the route flap. Exam caveat: when a routing event and a test failure share a minute and a recovery, test the route before you open a wireless ticket or a client-cache ticket. Operational check: align the test timestamps with the route-flap log, confirm they match, and verify the path is stable again after the route stops flapping.