Card 1 of 20
Front. Load Average. Why can Linux load average be high while CPU utilization is low?
These cards are original study material. They are not questions from a named employer or a live hiring loop.
All 20 cards in this deck
1.Load Average
Why can Linux load average be high while CPU utilization is low?
Load includes runnable tasks and tasks in uninterruptible sleep, commonly waiting on I/O. Inspect task states and storage waits before adding CPU.
2.Container Cpu
A container is throttled while its host has idle cores. What should be inspected?
The container's effective cgroup CPU quota and throttling counters, including ancestor limits. Host spare capacity does not override a configured quota.
3.OOM Evidence
An application disappears without a stack trace. How can you test whether memory enforcement killed it?
Inspect exit status, kernel or runtime events, and cgroup memory.events counters. Distinguish a cgroup OOM from an application crash or host-wide memory pressure.
4.Memory Available
Why is low free memory alone not proof that a Linux host is unhealthy?
The kernel uses otherwise available memory for caches. Inspect available memory, reclaim pressure, swapping, and application latency before treating useful cache as a leak.
5.Deleted File
A large log was deleted but disk usage stayed high. What should you check?
A process may still hold the deleted file open. Inspect deleted open files, such as with lsof +L1, and arrange safe log reopening; deleting the pathname does not release an active file's storage.
6.Inodes
Why can creating a tiny file fail with no space left while many bytes remain free?
The filesystem may have exhausted inodes or a quota. Compare df -h, df -i, and relevant quota information rather than checking capacity alone.
7.Fd Limit
Connections fail with too many open files. What distinguishes a leak from an undersized limit?
Compare open descriptor types and counts over time with expected concurrent work and process limits. Raising the limit only postpones a leak.
8.Signal Drain
Why should a service handle SIGTERM differently from relying on SIGKILL?
SIGTERM can initiate bounded draining and cleanup. SIGKILL cannot be caught; supervisors need a grace period and a recovery design for unfinished work.
9.Pid One
Why can a container's shell entrypoint interfere with graceful termination?
If it does not forward signals or exec the application, the service may not receive shutdown notification. Use an appropriate entrypoint or init process and test termination behavior.
10.Listen Check
What does ss -ltnp help establish when a TCP service is unreachable?
Whether a process is listening, on which address and port, and, with sufficient permission, which process owns it. It does not prove external routing or firewall access.
11.Loopback Bind
A service works through localhost but not from another host. What binding error is worth checking?
It may listen only on a loopback address. Verify the intended interface binding, then independently inspect routing and access rules.
12.Refused Timeout
How do connection refused and connection timeout guide different first checks?
Refusal suggests an active rejection such as no listener or a reject rule; timeout suggests packets or replies may be dropped or delayed. Neither uniquely identifies the cause—inspect both ends and the path.
13.Dns Scope
Why should DNS resolution be tested from the failing container rather than only a laptop?
Resolvers, search domains, caches, network policy, and split-horizon answers can differ. Query the same name through the application's actual resolution path.
14.Tls Sni
Why can connecting to a server's IP produce a certificate error when its hostname works?
Certificate identity and virtual-host selection depend on the hostname and SNI. Preserve the expected server name when testing an IP; disabling verification hides the distinction.
15.Route Source
What can ip route get DEST reveal that a routing-table listing alone may not make obvious?
The selected route, interface, and source address for that destination. Check from the correct namespace because containers can have different routing state.
16.Mtu Blackhole
Small requests work but larger transfers stall across a tunnel. What network hypothesis fits?
An MTU or path-MTU discovery problem can drop larger packets while small ones pass. Inspect packet sizes, ICMP handling, and tunnel overhead before changing application timeouts.
17.Time Wait
Does a large number of TIME_WAIT sockets automatically mean an application leaked connections?
No. TIME_WAIT is a normal TCP lifecycle state. Relate it to connection churn and port pressure; reuse connections where appropriate instead of blindly changing kernel timers.
18.Nat Capacity
Why can many healthy application replicas collectively exhaust outbound connectivity?
They may share a NAT or connection-tracking capacity limit. Inspect concurrent mappings, destination concentration, and port allocation rather than only per-pod sockets.
19.Tcp Bytes
Why must an application frame messages even when TCP delivers bytes reliably in order?
TCP is a byte stream and does not preserve application message boundaries. Reads can contain part of a message or several messages; use lengths, delimiters, or a defined protocol.
20.Capture Scope
How should a packet capture be scoped during an incident?
Capture on the relevant interface or namespace with a narrow host/port filter, bounded duration, and suitable handling of payload data. Correlate both ends when distinguishing loss from application delay.