Server admins on the city virtualization cluster use uncontrolled sudo and local admin elevation with little logging. What should governance require first?
Select an answer to reveal the explanation.
Short Explanation
Sudo without a paper trail is a blank check. Put elevation on a leash—just-in-time or break-glass style—and record who did what. That is how you govern privilege escalation instead of hoping nobody notices.
Full Explanation
Privileged elevation on city virtualization clusters must be deliberate, time-bound, and fully audited: just-in-time or approved sudo/PAM elevation, session recording or command logging, and rapid expiry back to a standard identity. Uncontrolled standing local admin with little logging removes both least privilege and forensic trail, which governance should reject first. Controlled elevation preserves necessary change capacity while making misuse and mistakes attributable.
Banning all administrative access and forcing vendor screen-sharing alone is rarely operable for day-to-day cluster care and may simply relocate privilege into opaque vendor sessions without municipal audit. A single shared root password in the data-center runbook maximizes credential reuse and eliminates personal accountability. Disabling SELinux or AppArmor so elevation always succeeds quietly weakens host mandatory controls and hides rather than governs privilege use.
Exam caveat: Domains 5 and 7 align on privileged access management—minimize standing admin, monitor what remains, and prefer JIT. Operational check: onboard hypervisor and jump-host admin through a PAM vault, require ticketed elevation, retain session logs for the city’s retention period, alert on off-hours elevation, and periodically attest who can still request cluster admin rights.