An audit finds batch-job service accounts for the water billing system with non-expiring passwords and interactive logon rights on jump hosts. Which remediation best hardens those accounts?
Select an answer to reveal the explanation.
Short Explanation
Service accounts are not people and should not lounge on jump boxes. Lock interactive logon, stash secrets in a vault with rotation, and keep rights skinny—non-expiring password plus Domain Admin is how outages become breaches.
Full Explanation
Service accounts that run water-billing batch jobs should be non-interactive, least-privilege, and backed by vaulted or platform-managed secrets with rotation—not human-style passwords that never expire and can log onto jump hosts. Prohibiting interactive logon blocks lateral misuse if the secret leaks; vaulting and rotation shrink the lifetime of any stolen credential; scoping rights to the specific batch tasks limits blast radius inside the billing domain.
Giving every service account a mailbox so resets arrive by email invents an unnecessary attack surface and still leaves interactive and non-expiring problems unsolved. Converting service accounts into personal user accounts for night operators collapses machine identity into shared human identities and wrecks non-repudiation. Setting passwords to never expire and adding Domain Admin for “reliability” maximizes both theft value and privilege—precisely the opposite of hardening.
Exam caveat: service identities are not people; distractors often humanize them or crown them Domain Admin for convenience. Operational check: inventory billing batch principals, disable interactive logon and GUI rights, move secrets to a managed store or gMSA-class mechanism, alert on any interactive attempt, and recertify service entitlements with the application owner each cycle.