Remote Administrative Redundancy for Unresponsive Switches

The core of this question is distinguishing between in-band and out-of-band (OOB) management. The scenario specifies that the switch is "unresponsive through an SSH," which implies that the primary production network path (in-band) is either congested, misconfigured, or completely down. To achieve redundancy in this state, a technician must use a management channel that does not rely on the same network infrastructure as the SSH session.

Option D (Connect a physical console cable) is the most attractive but wrong answer because it describes a local, physical interaction rather than remote administrative access. While a console cable provides direct access to the device's command-line interface (CLI), it requires physical proximity to the hardware rack. The question explicitly asks for remote administrative redundancy. Therefore, plugging into the console port fails the "remote" constraint, even though it is a valid troubleshooting step for a locally available unresponsive device.

Option B (Use an out-of-band management solution) is the correct approach. OOB management utilizes a dedicated, separate network path (such as a cellular link, a dedicated management VLAN with its own router, or a terminal server connected via modem/serial) that is independent of the production data plane. If the production network causing the SSH failure goes down, the OOB channel remains operational, allowing the technician to remotely log in and troubleshoot the switch without needing to be physically present.

Option A (Deploy a jump host) relies on the production network to reach the target, so if the network is failing, the jump host cannot reach the switch. Option C (Enable administrative GUI) typically shares the same IP stack and network interface as SSH, offering no redundancy against network-level failures.