220-1102 Security Practice Question
A security analyst confirms that a user's workstation is infected with a rootkit that is actively hiding malicious processes and network connections. The analyst has already isolated the system by disconnecting it from the network and has created a forensic image of the hard drive for evidence. According to industry best practices for incident response, what should the analyst do NEXT?
⚠ Common exam trap
Test-takers frequently choose to run a scan or attempt manual removal because they believe the rootkit can be cleaned like a standard virus, but CompTIA tests the principle that once a rootkit is confirmed, the system is considered untrusted and must be rebuilt from scratch.
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
✓
Reinstall the operating system from a known good source
Once a rootkit is confirmed and forensic evidence has been preserved, the only way to guarantee the removal of all hidden malicious components is to wipe the system and reinstall the OS from a known good source. Rootkits operate at a deep level (kernel or boot loader) and can subvert antivirus scans, making any attempt to clean in place unreliable. Industry best practices (e.g., NIST SP 800-61) dictate that after evidence collection, the analyst should restore the system to a trusted state rather than attempt remediation on a compromised host.
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 a full antivirus and anti-rootkit scan on the system
Why it's wrong here
Antivirus and anti-rootkit scanners rely on the operating system's APIs and kernel calls to enumerate processes and files, but a sophisticated rootkit subverts those interfaces, actively hiding its presence and controlling what the scanner sees. Even when components are detected, removal routines cannot guarantee the purge of all persistence mechanisms, such as boot-level hooks, kernel drivers, or malicious firmware tables. Because the host's integrity is already compromised, any scan performed from inside the affected system operates on an untrusted foundation and cannot produce a high-confidence clean result.
- ✓
Reinstall the operating system from a known good source
Why this is correct
Reinstalling the operating system from known-good media writes a completely fresh system partition, resets the Master Boot Record or GUID Partition Table, and overwrites all user-accessible volumes, destroying any file-based or boot-persistent rootkit components. This clean-build approach reestablishes a known-good trust base, eliminating the need to reverse-engineer malicious code and ensuring that hidden kernel modules or autostart entries do not survive. After a bare-metal recovery, the analyst should immediately reapply security patches and reintroduce only verified backups to maintain a defensible, uninfected state.
- ✗
Attempt to manually remove the rootkit using specialized analysis tools
Why it's wrong here
Manual rootkit removal with specialized analysis tools requires deep expertise in kernel internals and attacker persistence mechanisms, and it operates on a machine that is already considered untrusted, making every rootkit observation and removal step suspect. Rootkits often install stealth drivers that hook system service descriptor tables and filter device I/O requests, so any missed or overlooked layer can reinstall the entire infection from a hidden component. The extreme time cost, the high risk of corruption, and the impossibility of proving complete eradication make manual cleanup far less reliable than reimaging the system.
- ✗
Leave the system powered off and disconnected until a patch is available
Why it's wrong here
Disconnecting and powering off the workstation preserves the rootkit's artifacts in non-volatile memory, but it does nothing to remove them, so the infection will be fully active on the next boot. A software security patch cannot remediate a rootkit because the enemy is an installed attacker controller, not a fixable vulnerability in a legitimate application or driver. Holding systems in an offline state simply delays service restoration; only a full wipe and OS reinstall can return the machine to a trusted condition.
Go deeper
Related to this question
Learn chapter
Data Sanitization: Wipe, Degauss, Shred, Incinerate
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.
Key term
Incident response
Incident response is the structured approach an organization uses to identify, contain, and recover from cybersecurity incidents like data breaches or ransomware attacks.
About these practice questions
Courseiva writes every 220-1102 question from scratch — 925 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This 220-1102 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 220-1102 exam.