School-lab account automation must create a standard student user when missing but must not error if the account already exists on a re-run. Which semantics should the job use?
Select an answer to reveal the explanation.
Short Explanation
You want ensure-present management: if the student account is already listed, the job succeeds; if it is missing, the job adds it. That way, a perfectly fine re-run won’t land the account in detention for “already exists.”
Full Explanation
School-lab automation that must create a standard student user when missing, yet succeed when the account already exists on a re-run, needs ensure-present (idempotent) user management. The job succeeds whether it creates the account or finds it already compliant, keeping scheduled convergence and remediation green rather than failing on “already exists.” Failing the entire job whenever the username is found anywhere on the host treats a successful prior run as an error and breaks nightly enforcement. Deleting and recreating the account on every run may show that the script executed, but can destroy sessions and home-directory state and undermine stability. Creating the account only once manually and removing automation afterward abandons continuous assurance across lab fleets. Exam caveat: ensure-present can still update drifted attributes such as shell, groups, or expiry when the declaration specifies them; it does not mean “ignore forever if the name exists.” Practical check: run the job on a host without the user and confirm creation, then run it again and confirm success without a duplicate UID or errors. Intentionally drift a group membership and verify that the next run restores the declared state. Logging whether the job created the account or left it unchanged lets operators audit convergence without mistaking a successful no-op for a mystery.