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.

• ✗

  Share a root SSH key with the operations team so anyone can run the job.

  Why it's wrong here

  Sharing a root SSH key with the operations team is dangerous because a single compromised key grants unrestricted control over every system, and since multiple people share the same key, you cannot attribute actions to a specific individual—violating non-repudiation and making security audits nearly impossible. Additionally, rotating the key when someone leaves disrupts all team members, and the key often exists without passphrase protection or centralized storage. This approach far exceeds the least privilege needed for a weekly patch/reboot and should be replaced with per-user or service accounts.

• ✓

  Use a configuration management tool with a dedicated service account and restricted sudo permissions.

  Why this is correct

  Using a configuration management tool like Ansible or Puppet with a dedicated service account is ideal because it enforces least privilege: the account can be restricted via sudoers to only execute the specific patching and reboot commands (e.g., yum, apt, systemctl reboot), not a full root shell. The tool provides centralized execution, idempotent playbooks, and immutable audit logs showing exactly which commands ran on which hosts, eliminating human variability. A dedicated service account also supports credential rotation and integration with enterprise secret management, without exposing interactive root access.

• ✗

  Have each administrator log in manually and run the commands from an interactive shell.

  Why it's wrong here

  Having each administrator log in manually and run commands interactively is error-prone and inconsistent because every admin may choose different flags, skip ordering steps, or miss a server, leading to configuration drift across the infrastructure. Interactive shells do not automatically produce a centralized, tamper-proof audit trail; logs are scattered across individual systems and users often operate with their normal sudo rights, which may be overly broad or inconsistent. This approach also introduces a high risk of accidental disruption (e.g., rebooting during business hours) because there's no standardized changelog or approval workflow.

• ✗

  Create a local root account on every server for maintenance tasks.

  Why it's wrong here

  Creating a local root account on every server for maintenance tasks multiplies attack surface by introducing many privileged accounts with identical passwords (often stored in insecure places) and no central management. Each local root account bypasses Active Directory/LDAP integration, making it impossible to enforce password policies, disable old accounts, or obtain a unified accountability trail, and an attacker who compromises one password can pivot across all servers. It also gives full root privileges—far more than needed to run a patch/reboot—so a single mistake or compromise leads to complete host takeover.

Go deeper

Related to this question