1.4.1. The Dependency Stack
💡 First Principle: Services depend on infrastructure, infrastructure depends on hardware, and hardware depends on physical environment. A failure anywhere in this stack cascades upward—you cannot have a healthy service running on broken hardware.
The key diagnostic implication: default to troubleshooting bottom-up. A web application error might be caused by a database timeout, which might be caused by a slow disk, which might be caused by a degraded RAID array (one drive failed, operating in degraded mode). Chasing the application logs first would lead you in circles.
Bottom-up is the default, not the only option — pick the strategy that reaches the answer fastest:
| Strategy | Start at | Best when |
|---|---|---|
| Bottom-up | The physical layer, working up | The symptom is vague, or several unrelated services broke at once (a shared lower layer is the likely culprit) |
| Top-down | The application, working down | One application is broken and everything else on the box is healthy |
| Divide-and-conquer | The middle of the stack | You have a strong theory and want to halve the search space in one test — check the network layer first, and the result eliminates half the stack |
This stack also explains why environmental monitoring—tracking temperature, humidity, and power quality—is a legitimate administrative task. A data center that loses cooling degrades hardware, which degrades storage, which degrades services, which affects users. The root cause is environmental.
⚠️ Exam Trap: When a scenario describes an application error, don't assume the application is broken. The exam frequently places the root cause one or two layers below where symptoms appear.
Reflection Question: A web server is returning 500 errors. List the layer-by-layer investigation path you would follow, starting from the lowest layer.
