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.

• ✗

  Use the root account for the scheduled job so it always succeeds.

  Why it's wrong here

  Running the job as the root account grants the script unrestricted privileges across the entire operating system. If the maintenance script has a bug or is tampered with, the resulting damage is not limited to the intended service; an attacker could compromise the whole host, disable security controls, or exfiltrate sensitive data. This also violates the principle of least privilege, because routine service restarts and log rotations only need specific capabilities, not full administrative ownership. Furthermore, root cron entries are harder to audit for accountability because every action is attributable to a shared, all-powerful account.

• ✓

  Create a dedicated account with sudo rights limited to the required service commands.

  Why this is correct

  Creating a dedicated, non-interactive service account and granting it only the sudo commands the script requires (for example, `/usr/bin/systemctl restart myservice` with `NOPASSWD`) allows the scheduled job to run unattended while strictly limiting its blast radius. In the `/etc/sudoers` file, you can specify the exact command path and permitted arguments, so even a compromised script cannot pivot to a root shell or modify system files outside those commands. This design follows least privilege and provides a clear audit trail because `sudo` logs which user executed which command. It is a standard, secure pattern for automated operational tasks.

• ✗

  Ask an administrator to log in manually each week and run the script.

  Why it's wrong here

  Asking a human to log in manually each week defeats the purpose of an automated maintenance schedule; it depends on the administrator remembering, being available, and following the steps consistently. Manual execution introduces the risk of missed runs, typos, or accidental deviations from the script, and each interactive login requires exposing credentials or operating in a session that could be observed or intercepted. The requirement explicitly calls for a weekly script, which is exactly what cron or systemd timers are designed to handle; manual intervention is neither reliable nor scalable, and it breaks entirely if the designated administrator is unavailable or leaves the organization.

• ✗

  Store the administrator password in the script so the task can authenticate automatically.

  Why it's wrong here

  Storing the administrator's password in plaintext inside the script means any user or process that can read that file—whether through a backup, a debugger, or a misconfigured permission—will obtain privileged credentials. Embedded secrets also fail automatically when the password expires or is rotated, and they bypass all AAA controls such as MFA and centralized authentication auditing. Even using obfuscation or encryption at rest does not solve the underlying secret-management problem; the script still needs a key, which must be protected separately. Hardcoding credentials is insecure and hard to maintain, whereas modern approaches use a credential vault or a service account with scoped privileges.

Go deeper

Related to this question