A logistics hub can fail over to a backup path, but that path is too thin to carry the traffic the primary path carries today. Which capacity recommendation addresses the finding?
Select an answer to reveal the explanation.
Short Explanation
A spare bridge that cannot hold the trucks is not really a spare. You size or redesign the logistics hub's backup path so a failover has enough capacity. Another alert, a clearer dashboard name, or a repeat of the same test leaves that thin path unchanged.
Full Explanation
A backup path that cannot carry the primary load will fail the moment it is asked to. The capacity recommendation is to size or redesign that path so failover has enough capacity. Adding an alert that fires when live traffic moves onto the thin path tells operators the under-sized path is in use, which they may already know from the test, and it does not make the path able to carry the load. Renaming the hub dashboard so the backup label is easier to read changes a title and leaves the path's capacity as it is. Repeating the same failover measurement without enlarging or redesigning the path produces another observation of the shortfall and still contains no topology, configuration, or QoS change. Exam caveat: detecting a thin backup is useful, and the recommendation that belongs in the capacity report is the resize or redesign, not a new notification of the same gap. Operational check: after the backup is resized or redesigned, fail a maintenance window's worth of traffic onto it and confirm loss and delay stay acceptable for the primary load. If the backup still cannot carry that load, the report did not change the design.