A library kiosk lockdown configuration must be safe to apply repeatedly during nightly automation. What IaC property ensures repeat runs converge to the same end state without compounding changes?
Select an answer to reveal the explanation.
Short Explanation
Idempotent lockdown is flipping the library’s ‘closed’ sign — flip it twice and it is still closed, not double-locked into a weird state. Nightly re-runs should be boringly safe.
Full Explanation
Library kiosk lockdown configuration applied by nightly automation must be safe to re-run. Idempotency is the IaC property that ensures repeat runs converge to the same end state without compounding changes—users are not duplicated, firewall rules are not stacked endlessly, and already-correct settings remain correct. Nightly jobs can therefore enforce desired state without special “first run only” logic.
Volatility that randomly mutates settings to prove the script is alive destroys predictability and auditability. Ephemerality of intent that forgets desired state after first success leaves later drift uncorrected. One-shot destructiveness that fails on second apply makes scheduled automation impossible once lockdown is already present.
Exam caveat: idempotent does not mean “does nothing”; it means the end state matches the declaration whether the resource was missing or already compliant. Operational check: apply lockdown twice in a lab image, diff system state after each run, and confirm the second run reports success with no duplicate accounts, rules, or conflicting files. Express lockdown as desired packages, services, and file contents so the configuration engine can no-op when already compliant. Idempotent design is what makes nightly library automation boring—and safe.