220-1101 Question 403
Single answerBootable device not foundA technician replaces a failed HDD in a user's desktop with a new SSD and restores the company's standard Windows image to the drive. When the PC starts, it displays "Bootable device not found" before loading the operating system. The SSD is detected in the UEFI firmware. The technician confirms the image deployment completed successfully. Which action should the technician take FIRST to resolve the issue?
- A
Change the boot mode in firmware so it matches how the restored OS was installed, such as UEFI versus Legacy/CSM
- B
Replace the SSD because a detected drive that does not boot is physically defective
- C
Increase the system memory allocation in firmware so the SSD can be initialized during POST
- D
Disable Secure Boot because Windows images cannot boot when Secure Boot is enabled
Show answer and explanation
Correct answer: A
Explanation
When a system reports "Bootable device not found" but the storage device is detected in firmware, the technician should first verify firmware boot configuration. In real-world A+ troubleshooting, this includes confirming the correct device is first in the boot order and, importantly, confirming the firmware boot mode matches the installed operating system. UEFI installations generally require GPT and an EFI System Partition; Legacy/CSM installations generally rely on MBR boot code. A mismatch often occurs after drive replacement, cloning, or image deployment. This approach aligns with standard CompTIA troubleshooting methodology: start with the most likely and least invasive cause before replacing hardware. Microsoft deployment and Windows installation guidance also distinguishes between UEFI/GPT and BIOS/MBR boot methods, making boot mode verification a best-practice first step in this scenario.
- A. Correct.
Correct. A very common cause of a "Bootable device not found" message after imaging or drive replacement is a mismatch between the firmware boot mode and the partition style/boot loader used by the restored operating system. For example, a Windows installation deployed in UEFI mode typically expects a GPT disk with an EFI System Partition, while a Legacy/CSM installation typically expects MBR boot records. If the SSD is visible in firmware, the next logical first step is to verify the boot mode and boot order settings match the installed image.
- B. Incorrect.
Incorrect. The SSD being detected by firmware makes a total hardware failure less likely. A boot failure immediately after imaging is more commonly caused by configuration issues such as incorrect boot mode, missing EFI boot files, or an invalid boot order. Replacing the SSD before checking these settings would be premature and not aligned with efficient troubleshooting practice.
- C. Incorrect.
Incorrect. System memory allocation in firmware is not a standard fix for a bootable-device error in this scenario. POST memory settings do not determine whether the firmware can find a valid boot loader on a detected SSD. This distractor reflects a misunderstanding between hardware initialization issues and storage boot configuration problems.
- D. Incorrect.
Incorrect. Secure Boot can prevent untrusted boot loaders from loading, but standard properly deployed Windows images commonly work with Secure Boot enabled. The message in this scenario points more directly to the firmware not locating a valid boot target. Disabling Secure Boot should not be the first action unless there is evidence the image uses unsigned or unsupported boot components.