A hotel chain finds a guest-facing application marked into the wrong traffic class, so it contends with bulk transfers even though the circuit still has spare capacity. Which capacity recommendation fits?
Select an answer to reveal the explanation.
Short Explanation
Marking a guest application into the bulk class is like putting ambulances in the freight lane while the road still has room. You recommend a configuration change so the hotel application is marked into its assigned class. Another alert, a renamed dashboard, or more samples of the same marking leave the policy wrong.
Full Explanation
The application is in the wrong traffic class, and the circuit still has spare capacity, so the contention comes from how packets are marked and scheduled. The capacity recommendation is a configuration change that marks the guest application into the class it was assigned. Adding another alert whenever the application loses to bulk transfers notifies staff of a misclassification the report should correct, and it does not rewrite the marking. Renaming the property dashboard so the wrong class is easier to spot changes a label and leaves every packet in the class it already uses. Collecting more samples of the current marking without changing the class or the policy produces a longer record of the same mistake and is not a topology, configuration, or QoS change. Exam caveat: spare capacity plus the wrong class is a configuration problem, whereas a full circuit with the right class would point at a different capacity action. Operational check: after the marking change, confirm the guest application is classified in its assigned class and that it no longer waits behind bulk transfers while the circuit still has room. If the old class is still on the packets, the configuration was not updated.