Quiz: Incident Response

← Back to quiz index

7 questions

L1 (2 questions)

1. You suspect a server is compromised. What are your first three steps?

Show answer

1. Isolate: restrict network access (security group/firewall) but do NOT power off.
2. Preserve: snapshot disk and dump memory before changes.
3. Assess: check running processes (ps auxf), network connections (ss -tlnp), recent logins (last, lastb), and cron jobs.

2. Why should you NOT immediately shut down a compromised server?

Show answer

Volatile evidence is lost: running processes, network connections, memory contents (encryption keys, malware in RAM). Instead: isolate network, capture memory dump (e.g., LiME), snapshot disk, then investigate. Power off only if active data exfiltration can't be stopped otherwise.

L2 (5 questions)

1. You get paged at 2am for a production outage. What are your first 60 seconds?

Show answer

1. Check monitoring dashboards (is it total or partial outage?).
2. Check recent deployments/changes (was anything deployed?).
3. Check cluster health (kubectl get nodes, kubectl get pods -A | grep -v Running).
4. Check external dependencies. Don't start fixing until you understand scope.

2. How do you decide between rolling back and fixing forward?

Show answer

Roll back if: recent deploy is the obvious cause, rollback is safe and fast, data migrations haven't run. Fix forward if: rollback would cause data loss, the fix is small and well-understood, or the issue isn't deploy-related.

3. What is the difference between containment and eradication in incident response?

Show answer

Containment = stop the bleeding (isolate affected systems, block C2 IPs, disable compromised accounts). Eradication = remove the threat (patch vulnerability, remove malware, rebuild from clean image). Contain first, then eradicate. Premature eradication tips off the attacker.

4. What are Indicators of Compromise (IOCs) and give three examples?

Show answer

IOCs are forensic artifacts that suggest a breach. Examples:
1. Unexpected outbound connections to unknown IPs.
2. Modified system binaries (check with rpm -Va or debsums).
3. New cron jobs or systemd services you didn't create. Also: unusual login times, new user accounts.

5. What should a post-incident review (PIR) document include?

Show answer

1. Timeline of events (detection to resolution).
2. Root cause and contributing factors.
3. What went well and what didn't.
4. Concrete action items with owners and deadlines. Focus on systems and processes, not blame. Share findings widely to prevent recurrence.