SY0-701 Security Operations Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Run the script with a dedicated automation account that has only the required sudo permissions

  Why this is correct

  Using a dedicated automation account bound to a narrowly scoped sudoers policy is the correct application of least privilege. This approach grants only the specific commands the patch script needs—such as systemctl restart and package manager updates—while preventing interactive login and any access beyond the maintenance task. Because the account is non-human and non-interactive, its credentials can be securely stored in a vault or secrets manager, and its actions are fully auditable through the sudo and auditd logs. This design minimizes the blast radius if the account is compromised and ensures unattended patching remains compliant with defense-in-depth practices.

• ✗

  Use the root account for every scheduled execution to avoid permission errors

  Why it's wrong here

  Elevating every scheduled execution to the root account violates the principle of least privilege and turns the nightly patch process into a high-risk operation. Root has unrestricted read/write/execute authority over the entire operating system, so any flaw in the script, a malicious command injection, or a compromised automation platform would immediately yield full administrative control over all 40 servers. Furthermore, root-level actions are often exempt from fine-grained auditing by default, making it harder to trace exactly which command caused a failure or security incident. The correct approach is to grant only the exact sudo permissions required for patch and service-restart operations, not blanket root access.

• ✗

  Hard-code the administrator password in the script so it never prompts

  Why it's wrong here

  Hard-coding an administrator password into a script is a critical credential-management failure because it exposes the password in plaintext to anyone who can read the file, inspect process listings, or access version control history. When the password rotates—which it must regularly—the script breaks, forcing an emergency update that is error-prone and may cause missed patching windows. Even if the script is on a restricted server, the embedded secret becomes a single point of compromise that can be lifted by an attacker who exploits any read vulnerability. Secure automation should instead use managed identities, SSH keys with passphrases, or a secrets manager to retrieve credentials at runtime without persisting them in code.

• ✗

  Ask each server owner to manually patch their system during the maintenance window

  Why it's wrong here

  Delegating patching to each server owner removes the centralized control and consistency that a nightly automated script provides, leading to drift in patch levels across the fleet. Manual patching depends on individual administrators remembering their assigned window, which regularly results in missed deadlines, incomplete reboots, and systems that remain vulnerable. It also destroys the repeatable audit trail that a scripted run produces, making it nearly impossible to prove compliance or reconstruct exactly what changed on which host. Even with good intentions, manual processes are slower and more prone to human error than a controlled, automated pipeline with a least-privilege service account.

Go deeper

Related to this question