Library IT must repeatedly enforce kiosk lockdown settings across dozens of branches. Which automation approach best fits ongoing converge versus a one-time laptop run?

Library IT that must repeatedly enforce kiosk lockdown across dozens of branches needs ongoing configuration converge, not a one-time laptop script. A remote SSH session or config-agent converge that reapplies desired state on a schedule or trigger continuously corrects drift: if a branch resets an image, a patron changes a setting, or a technician makes an ad-hoc tweak, the next converge restores the approved lockdown. That model matches fleet-scale municipal kiosk management where the desired state is durable policy rather than a memory of last week's visit.

Emailing screenshots of desired registry keys to each branch manager fails because screenshots are not enforceable automation, managers are not reliable configuration engines, and visual instructions drift immediately from reality. Asking patrons to reconfigure kiosks after each login fails on authority and design—citizens are not administrators, and self-service reconfiguration contradicts lockdown. Burning settings onto paper checklists taped to each kiosk fails similarly: paper cannot converge systems, cannot prove compliance, and cannot scale across branches with auditability.

Exam caveat: a one-off local script on a technician laptop can bootstrap a single machine, but it is not the same as continuous converge. The question contrasts ongoing enforcement versus one-time runs; choose the remote/agent converge pattern for repeated desired-state application.

Operational check: after intentional drift on a test kiosk, confirm the agent or scheduled SSH converge restores lockdown settings without a truck roll; review central reports for branch compliance; and ensure runbooks no longer depend on emailed screenshots or patron cooperation for baseline enforcement.