During a scheduled failover test for the library catalog, cutover is delayed because DNS TTLs keep clients pointed at the old site. What does this outcome mainly illustrate?
Select an answer to reveal the explanation.
Short Explanation
The failover drill did its job—it showed that sticky DNS TTLs were slowing the cutover. Better to learn that on a calm Tuesday than during a real outage. Testing recovery is how you find the hidden speed bumps.
Full Explanation
Designed high availability only becomes real when failover is exercised. Municipal failover testing validates that recovery completes inside required timeframes and exposes blockers that look fine on paper—such as DNS TTL values that keep citizen browsers and partner systems pointed at the failed site long after cutover. Discovering sticky TTLs or stale records during a calm drill is far cheaper than discovering them during a real outage that strands online payments or emergency portals. Technical failover drills complement tabletops by proving automation, dependencies, and external resolution behavior under live conditions. Treating failover testing as optional because a vendor brochure lists high availability mistakes marketing claims for validated capability. Asserting that DNS TTLs never affect recovery timing denies a common, measurable cause of delayed cutover. Limiting practice to tabletop discussions alone skips the technical path where TTL, certificates, storage locks, and routing actually break. Exam caveat: exam items often hide the lesson inside a specific finding (like DNS TTL); the tested principle is that recovery testing reveals operational blockers before production depends on them. Operational check: include DNS and client-cache behavior in every municipal failover drill, measure time-to-serve from external networks, and adjust TTLs or cutover runbooks until recovery meets the documented RTO.