A library technician wants to tighten a production firewall rule tonight. Policy requires an approved, scheduled change record before any production edit. What should the technician do?
Select an answer to reveal the explanation.
Short Explanation
A tighter rule is still a change to a live door, and you do not sand the lock while the library is open just because the new shape is safer. Policy wants an approved, scheduled change record before the production firewall is edited. Skipping that line, or polishing only the paperwork copy, leaves the real process behind.
Full Explanation
Change management exists so a production edit is reviewed, scheduled, and reversible before it touches a live policy. The library already requires an approved, scheduled change record before firewall edits. The technician's next action is to submit that request and perform the tighter rule only in the window that was approved. Editing production tonight because the change feels safer skips the review that would catch a rule which also blocks a patron service. Speed is not an exception the policy granted. Updating only the golden template records what someone wishes production looked like and leaves the live firewall on the old rule, so the risk the technician wanted to reduce is still in production, and the template now lies about what is deployed. A service-level claim is a complaint against a provider's availability or response commitment. The firewall rule is an internal change, not a vendor outage, and a claim does not tighten the rule. Exam caveat: an emergency change process can compress the approval, and it is still a change record, not a silent edit. If the library has no emergency path, tonight's idea waits for the normal window. Operational check: open the change record, confirm the approver and the window, compare the proposed rule with the live rule, and edit production only when that record says the window has started.