Resource faults versus network faults: when each matters?

WHAT THIS TESTS Whether you can reason about a system's dominant failure surface and select the fault type that exercises its real weaknesses rather than defaulting to a generic test.

A GOOD ANSWER COVERS Resource faults exhaust a local resource, CPU, memory, disk, or file descriptors, on a host or container. They reveal how a single instance degrades under saturation: whether resource limits and requests are set correctly, whether the OOM killer fires, whether autoscaling kicks in, and whether the service sheds load or simply collapses. Network faults perturb communication between components, packet loss, added latency, bandwidth throttling, DNS failures, or full partitions. They reveal whether timeouts, bounded retries, circuit breakers, and fallbacks protect the service when a dependency or the network misbehaves, and whether retries amplify load. The two probe different planes, intra-node capacity versus inter-node communication. Choose based on architecture and the dominant risk. A largely self-contained, compute-heavy workload is most threatened by resource exhaustion, while a service whose correctness depends on many remote calls is most threatened by network faults.

COMMON WRONG ANSWERS Treating the two as interchangeable. Always picking network faults because microservices are trendy, ignoring compute-bound workloads. Confusing high latency injected via the network with CPU saturation. Forgetting that retries can turn a network fault into a self-inflicted resource fault.

LIKELY FOLLOW-UPS How could a network fault cause a resource fault. Which would you run for a stateless API gateway. How do you safely inject CPU exhaustion. How do limits and autoscaling change the outcome.

ONE CONCRETE EXAMPLE Consider a CPU-bound video transcoding service that reads a job, transcodes locally, and writes the result, with few external calls. A network packet-loss test teaches little because the service barely talks to others. A CPU-exhaustion test is far more valuable: it shows whether per-pod CPU limits, queue backpressure, and autoscaling let the service degrade gracefully under a transcoding spike. Conversely, for a chatty API aggregator calling ten downstreams, packet loss and latency injection would be the higher-value test.