SSCP Systems and Application Security Practice Question
A security operations team suspects that an attacker has compromised a Linux web server and is maintaining persistence. The team wants to identify unauthorized scheduled tasks that survive reboots. Which set of locations should the team review FIRST?
⚠ Common exam trap
The trap here is equating general incident-response artifacts such as logs and shell history with persistence mechanisms, when only scheduled execution structures survive a reboot.
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
✓
The systemd timer units, cron tables in /etc/cron* and /var/spool/cron, and the /etc/rc.local startup script.
Reboot-surviving persistence on Linux resides in scheduled execution mechanisms such as systemd timers, cron directories, and legacy startup scripts. These are the components that automatically run code after a restart. Name resolution files, shell history, and authentication logs are valuable for context and detection but do not themselves relaunch an implant.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The /etc/hosts file and the resolver configuration in /etc/resolv.conf.
Why it's wrong here
These files control name resolution and are common targets for traffic redirection, but they do not establish persistence across reboots. Reviewing them may reveal a secondary indicator, yet they will not expose a scheduled task that re-executes an implant after restart, so they are not the first place to look for the stated objective.
- ✓
The systemd timer units, cron tables in /etc/cron* and /var/spool/cron, and the /etc/rc.local startup script.
Why this is correct
On modern Linux, persistence that survives reboot is typically implemented through systemd timers, user and system cron entries, or legacy startup scripts such as rc.local. Reviewing these locations directly targets mechanisms that re-launch malicious code after a restart, making this the correct first step for identifying reboot-surviving persistence.
- ✗
The bash history files in each user's home directory.
Why it's wrong here
Shell history records commands typed interactively and can reveal attacker activity, but it is trivially cleared, disabled, or modified. It does not itself cause anything to run at boot, so it cannot reveal a persistent scheduled task. History review is useful for timeline reconstruction, not for locating reboot-surviving mechanisms.
- ✗
The /var/log/auth.log and /var/log/secure authentication logs.
Why it's wrong here
Authentication logs record logins, sudo usage, and service account activity, which helps establish how access was obtained. They are retrospective evidence rather than a persistence store, and a scheduled task will not necessarily appear there. The team needs to inspect the mechanisms that launch code at boot, not the record of past logins.
Go deeper
Related to this question
About these practice questions
This SSCP question is part of Courseiva's 971-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official ISC2 exam blueprint
This SSCP practice question is part of Courseiva's free ISC2 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 SSCP exam.