Stage 3: Scenario Warrior

Train learners to handle advanced Linux scenarios that require systematic diagnosis across multiple subsystems. Build confidence in explaining troubleshooting steps clearly, showing both technical depth and communication skills.

Hackbook Overview

• Scenario Thinking: Treat problems like stories — symptoms, investigation, resolution.
• Key Areas: Permissions, services, networking, configs, disk usage.
• Tools to Use: ls -l, systemctl, journalctl, df -h, ping, grep.
• Interview Angle: Employers test not just what you do, but how you explain it.

Hands‑On Practice

• Simulate a failed SSH login and troubleshoot using /etc/ssh/sshd_config and logs.
• Break a web server config, then fix it by testing syntax and adjusting firewall rules.
• Fill disk space with dummy files, then recover by cleaning /var/log/ and temp files.
• Create a permissions conflict and resolve it by adjusting ownership and groups.

Interview Question Bank

Conceptual

• Q1. Why do interviewers ask scenario‑based Linux questions?
  A1. To test practical problem‑solving, systematic thinking, and communication skills — not just memorization.
• Q2. What’s the difference between troubleshooting a single error vs. a scenario?
  A2. A single error has one cause, while a scenario involves multiple layers (e.g., config + firewall + permissions).

Practical

• Q3. SSH login fails for a user. How do you troubleshoot?
  A3. Check /etc/ssh/sshd_config, verify user permissions, and review logs in /var/log/auth.log.
• Q4. A web server won’t start after config changes. What’s your process?
  A4. Test config syntax (nginx -t or apachectl configtest), check logs (journalctl -u nginx), and fix errors.
• Q5. Disk usage is full and services crash. How do you recover?
  A5. Run df -h to confirm, clean logs/temp files, move large files, and restart services.

Scenario‑Based

• Q6. A user cannot access a shared directory despite being in the right group. What do you do?
  A6. Check directory permissions (ls -ld), confirm group membership (groups user), and adjust with chmod g+rwx.
• Q7. A web app is inaccessible externally though service is running. How do you solve it?
  A7. Verify firewall rules (firewall-cmd --list-all), confirm port 80/443 is open, and test with curl.
• Q8. A cron job fails silently. How do you troubleshoot?
  A8. Check cron logs (grep CRON /var/log/syslog), verify script permissions, and test script manually.

Behavioral Based

• Q9. Tell me about a time you solved a multi‑layered Linux scenario.
  A9. Example: “I fixed a production outage by correcting Nginx config syntax, reopening firewall ports, and adjusting file permissions — restoring service quickly.”

Cheatsheet (Quick Notes)

• Troubleshooting Steps: Symptoms → Logs → Configs → Permissions → Networking → Disk.
• SSH Issues: /etc/ssh/sshd_config, /var/log/auth.log.
• Web Servers: nginx -t, apachectl configtest, systemctl status.
• Disk Usage: df -h, du -sh.
• Cron Jobs: Logs in /var/log/syslog.