A manufacturer already has a working alert for a congested plant circuit and now asks for the optimization that would relieve the congestion. What should the assurance deliverable be?
Select an answer to reveal the explanation.
Short Explanation
You already have the doorbell for the congested circuit, so adding another one won’t relieve it. Since you’re now being asked to reduce the congestion, your deliverable is the circuit optimization, not a duplicate alert. A renamed dashboard or more tests using the same readings won’t change the circuit either.
Full Explanation
A working alert already reports the congested plant circuit. The new request is the optimization that would relieve it, so the deliverable should be a topology, configuration, or QoS change aimed at that congestion—not another copy of the alert. Relief means the circuit is less congested after the change; a second notification, a new dashboard title, or another copy of the same readings cannot produce that result. A second alert on the same congestion duplicates reporting that is already working. A renamed plant dashboard that leaves the congested circuit unchanged changes its label, not the circuit. More tests that collect the same congestion readings without a topology, configuration, or QoS change add measurement but do not perform the requested optimization. Exam caveat: when an alert for the problem is already working, an optimization request is not fulfilled by adding another alert rule for the same condition. Practical check: show the existing alert alongside the proposed topology, configuration, or QoS change, and confirm the deliverable is the circuit optimization rather than a duplicate alert, a renamed dashboard, or more tests that leave the circuit unchanged.