A systems administrator manages a Linux-based database server that has begun to experience unpredictable kernel panics multiple times a day. The administrator has performed the following troubleshooting steps:
Analyzed coredump files, which indicate different driver or module faults with each crash.
Updated the kernel and all system packages to the latest vendor-supported versions.
Rolled back the kernel to a previous known-good version.
Executed comprehensive hardware diagnostics, including memory and disk integrity checks, all of which passed without errors.
Verified application-level configurations and logs, finding no irregularities.
Despite these efforts, the system instability persists. Which of the following is the MOST appropriate next action to resolve the issue?
Replace the server's motherboard.
Reinstall the operating system.
Isolate the server from the network to check for malicious traffic.
Implement a script to automatically reboot the server after each panic.
The correct answer is to reinstall the operating system. The scenario describes a situation where the server is experiencing kernel panics with inconsistent causes, and standard troubleshooting steps like updating software, rolling back changes, and running hardware diagnostics have failed. This pattern strongly suggests systemic OS corruption that cannot be easily pinpointed or repaired. Reinstalling the OS provides a clean, stable base and is the most direct and definitive step to eliminate the operating system as the source of the problem after other logical steps have been exhausted.
Replacing the motherboard is incorrect because all hardware diagnostics have passed. While a faulty motherboard can cause such issues, replacing major hardware components without evidence of failure is a drastic and expensive step that should come after ruling out software corruption. Implementing an automatic reboot script is a workaround that treats the symptom (downtime) but does not resolve the root cause of the crashes. Malicious traffic is an unlikely cause for kernel panics that point to varied driver faults, making a network analysis a less probable solution path compared to addressing the clear signs of OS instability.