Companion question bank for the 3-part tutorial series in this folder: 01-linux-process-and-memory-internals.md, 02-tcp-ip-and-dns.md, 03-linux-troubleshooting-toolkit.md.

Answers are short and plain — expand out loud using the diagrams and commands in the tutorials.

---

Part 1 Questions: Process & Memory Internals

1. What's the difference between a process and a thread?#

A process has its own private memory and file descriptors — isolated, heavier to create. A thread lives inside a process and shares that process's memory with sibling threads — lightweight, but a bug in one thread can affect the whole process.

2. What does "D state" (uninterruptible sleep) mean, and why is it a red flag?#

The process is waiting on I/O in a way that can't even be interrupted by a signal — not even SIGKILL can end it until the I/O completes. A process stuck in D state for a long time usually points to a hung disk, a failing network filesystem, or a driver issue, not an application bug.

3. What's a zombie process, and is it a resource leak?#

A process that's finished running but whose parent hasn't yet collected its exit status. It's not really consuming meaningful resources — a large accumulation of zombies points to a buggy parent process that spawns children but never reaps them.

4. What's the difference between SIGTERM and SIGKILL, and why does Kubernetes send them in that order?#

SIGTERM politely asks a process to shut down and can be caught/handled to finish in-flight work cleanly. SIGKILL forcibly, immediately terminates it with zero chance to clean up. Kubernetes sends SIGTERM first (graceful shutdown window) and only escalates to SIGKILL after a grace period, so a well-behaved app can drain requests cleanly.

5. Why should you check "available" instead of "free" in free -h output?#

"Free" memory looks low mostly because of reclaimable disk cache (buff/cache), which isn't a real problem and gets reclaimed instantly when needed. "Available" already accounts for that reclaimable cache and reflects true usable memory.

6. Why is swap activity treated as a warning sign rather than "the system self-healing"?#

Swapping avoids an immediate OOM crash by moving memory to disk, but disk is 100-1000x slower than RAM — a process that starts swapping can appear to hang with confusing latency instead of failing cleanly. Any non-zero swap activity is worth investigating.

7. Walk through the OOM Killer mechanism.#

When RAM and swap are both exhausted, the kernel scores every process by an oom_score (roughly, memory usage) and kills the highest-scoring one to free memory and keep the rest of the system alive — with zero warning to that specific process.

8. How does this connect to a Kubernetes pod showing "OOMKilled"?#

It's the exact same kernel OOM Killer mechanism, but scoped to the container's cgroup memory limit (set via resources.limits.memory). Exceed that limit, and the kernel kills the process within that cgroup specifically — that's mechanically what "OOMKilled" means.

9. What do namespaces do, and what do cgroups do, and how do they relate to containers?#

Namespaces give a process its own isolated VIEW of a resource (its own PIDs, network interfaces, filesystem view). Cgroups control HOW MUCH of a resource a process can actually USE (CPU, memory, I/O limits). A container is just a regular Linux process combined with both — there's no separate "container" object at the kernel level.

10. Why are containers less isolated than a true virtual machine?#

Containers share the host kernel — namespaces create a convincing illusion of isolation, not physical separation, and a VM has its own separate kernel with hardware-level (hypervisor) isolation. A serious kernel vulnerability could theoretically let a process "escape" a namespace in a way a VM's isolation would prevent.

---

Part 2 Questions: TCP/IP & DNS

11. What's the fundamental tradeoff between TCP and UDP?#

TCP is reliable and ordered (guarantees delivery, retransmits lost packets) but has more overhead. UDP is fire-and-forget — fast and low-overhead, but no delivery or ordering guarantee at all.

12. Why does DNS mostly use UDP?#

DNS queries are small, and if one is lost, the client just retries quickly — the overhead of a full TCP handshake for every tiny lookup would be wasteful. (DNS falls back to TCP for larger responses.)

13. Walk through the TCP three-way handshake and explain why it needs exactly three steps.#

SYN (client: I'd like to connect) -> SYN-ACK (server: OK, let's connect) -> ACK (client: confirmed). Three steps are needed because both sides must confirm they can BOTH send and receive — after all three, both directions have been mutually verified.

14. What is TIME_WAIT, why does it exist, and what real problem can it cause?#

After closing a connection, the side that initiated the close holds it in TIME_WAIT for 60-120 seconds to safely discard any delayed duplicate packets from that old connection. Under very high connection churn (e.g., load testing with short-lived connections), this can exhaust available local ports, making a perfectly healthy server look broken from the client's side.

15. Why does TLS add real latency on top of TCP?#

It requires its own additional round-trips (exchanging supported ciphers, verifying the certificate, deriving a shared key) on top of the TCP handshake — this is why connection keep-alive and TLS session resumption matter for real-world performance.

16. Walk through the full DNS resolution journey for a brand-new, uncached domain.#

Browser checks its own cache, then the OS resolver's cache, then queries a recursive resolver. If not cached there either, the recursive resolver asks a root server (who handles .com?), then the TLD server (who handles example.com?), then the authoritative server (what's the actual IP?) — and caches the answer along the way back.

17. What's the difference between a recursive resolver and an authoritative DNS server?#

A recursive resolver does the lookup legwork on a client's behalf, walking the hierarchy and caching results. An authoritative server holds the actual, canonical DNS records for a specific domain.

18. What's TTL, and what's the practical tactic around it before a planned migration?#

Time To Live — how long a resolver is allowed to cache a DNS record before re-checking. Before a planned cutover, lower the TTL well in advance so existing longer-TTL caches expire and get replaced with the new short TTL, meaning the actual cutover propagates quickly instead of some clients being stuck on the old IP for up to a full day.

19. Why doesn't a successful ping guarantee a service is actually working?#

Ping only tests basic ICMP network-layer reachability — a host can respond to ping while the actual application/port is completely down, or while a firewall blocks that specific port but allows ICMP through.

---

Part 3 Questions: The Linux Troubleshooting Toolkit

20. Walk through the 60-second triage checklist in order.#

uptime (overall load feel) -> dmesg -T | tail (recent kernel errors/OOM kills) -> vmstat 1 (CPU, run queue, swap at a glance) -> mpstat -P ALL 1 (per-core detail) -> free -h (memory) -> iostat -xz 1 (disk I/O) -> ss -tan (network connections) -> top/htop (which process is responsible).

21. Why does load average need to be interpreted relative to core count?#

A load average of 8 is healthy on a 16-core machine but a serious red flag on a 4-core machine — the raw number alone doesn't tell you if the system is actually oversubscribed.

22. In iostat -xz, what's the difference between %util and await, and which one is the real saturation signal?#

%util is Utilization — how busy the disk is. await (average wait time) is the practical Saturation signal — a high %util with low await can still be healthy (busy but keeping up); a high await means requests are genuinely queueing and waiting.

23. uptime shows a high load average, but mpstat shows all cores at only 30% CPU usage. What does this combination suggest?#

Processes are likely waiting on something OTHER than CPU — most likely disk or network I/O (Linux load average counts uninterruptible-sleep/I/O-waiting processes too, not just CPU-runnable ones). Check iostat for high await, and look for processes in D state.

24. What does strace -p <PID> actually show you, and why is it so useful?#

Every system call the process makes to the kernel, live. It can definitively distinguish a process blocked on I/O (stuck in read()/connect()) from one burning CPU in a loop from one deadlocked on an internal lock — a distinction application logs often can't reveal on their own.

25. What does tcpdump let you determine that application-level "it's hanging" reports cannot?#

Whether the TCP handshake (SYN/SYN-ACK/ACK) even completes at all — telling apart a pure network/firewall problem (SYN never gets a response) from an application-level problem (handshake succeeds, but no application response ever comes back). Both look identical as "it's hanging" from the outside.

26. What's the first thing to check in dmesg during almost any unexplained incident investigation, and why check it early?#

Recent OOM kills (dmesg -T | grep -i "killed process") and kernel-level errors — checking this early can immediately explain an entire incident (a process was killed for memory, not because of an application bug) before spending time investigating the wrong layer.

---

Quick-Fire / Rapid Recall#