Library kiosk SSH banners were edited by hand and no longer match the approved text. What drift remediation should config management perform?
Select an answer to reveal the explanation.
Short Explanation
You can think of drift remediation as putting the approved poster back after someone changes it: config management re-applies the approved SSH banner on the next converge. Keeping customized text in place only baptizes drift instead of restoring the managed baseline.
Full Explanation
When library kiosk SSH banners are edited by hand, drift remediation should automatically re-apply the approved banner state on the next configuration-management converge. This closes the loop after detection: the declared resource overwrites unmanaged local edits and restores a consistent patron-facing message and security posture across kiosks. Keeping customized banners in place and excluding them from future convergence leaves unauthorized local changes in place, defeating the managed baseline. Opening every kiosk to unrestricted root SSH without a banner worsens security rather than restoring policy. Storing drifted banner text as the new global security standard promotes an unreviewed change; it is appropriate only after deliberate approval and writing the approved text back into code, not by silently accepting drift. Exam caveat: remediation frequency and enforcement mode matter. Some systems only detect drift, while others enforce desired state on converge. When a question asks what remediation should perform, choose enforcement of the approved state. Any temporary break-glass pause in enforcement should be ticketed and time-bounded so kiosks do not remain divergent. Practical check: change a lab kiosk banner, trigger a converge or wait for the schedule, confirm the approved banner returns, and verify the host’s drift report clears. Before district-wide enforcement, check that the repository’s banner text matches the legally and communications-approved text.