BIOS (Basic Input/Output System) and UEFI (Unified Extensible Firmware Interface) are the low-level software that fires up a server the moment you press the power button. Without this firmware, the server would not know how to talk to its own components, let alone load an operating system. Understanding how to configure these settings and manage firmware updates is crucial for the SK0-005 exam because you will be asked to troubleshoot boot issues, change boot order, and apply security patches that live at the firmware level.
Jump to a section
A simple way to picture BIOS/UEFI and Firmware Management
A coffee machine's firmware is the low-level software burned into its chip that controls every basic function. When you press the button for an espresso, it’s the firmware that tells the heating element to warm up to 93°C, the pump to run for 25 seconds at 15 bar, and the grinder to pulse exactly seven times.
Every few years, the manufacturer releases a firmware update to fix a bug where the machine gets stuck in descaling mode, or to add a new feature like pre-infusion timing. Updating the firmware is like updating the BIOS or UEFI on a server. You must first check the current version, download the correct update file from the manufacturer’s website, and then follow a precise process to flash it onto the chip. If you lose power during the update, the machine might become a brick – unable to function at all. Similarly, a server with a failed BIOS or UEFI update won’t boot.
The coffee machine’s firmware is separate from the app you use to schedule a brew (the operating system). It sits between the physical hardware (boiler, pump, grind burrs) and the user interface. Changing the firmware is not like changing a recipe; it’s more like replacing the machine’s brain. This is exactly what BIOS/UEFI does for a server: it initialises hardware components (RAM, CPU, disks) and hands control to the operating system – all before Windows or Linux even loads.
When you press the power button on a server, the very first thing that happens is not Windows or Linux starting. It is a piece of software stored on a special chip called the firmware. This firmware is the BIOS or, on modern systems, the UEFI. Think of it as the server’s own tiny operating system that lives on a read-only memory (ROM) chip called the CMOS (Complementary Metal-Oxide-Semiconductor) or flash memory.
What does BIOS/UEFI actually do?
Its primary job is power-on self-test (POST). During POST, the firmware tests the server’s hardware components – CPU, RAM, disk controllers, and network cards – to make sure they are present and working. If something fails, you will hear beeps or see error codes on the screen. After POST, the firmware finds a boot device (like a hard drive or USB stick) using the boot order you have configured, and hands control over to the operating system’s boot loader.
BIOS vs UEFI: the key differences
BIOS has been around since the early 1980s. It runs in 16-bit mode, can only address up to 2.2 terabytes of disk space, and uses the Master Boot Record (MBR) partitioning scheme. BIOS also has a limited user interface – usually a text-based blue screen with keyboard controls. UEFI is the modern replacement. It runs in 32-bit or 64-bit mode, supports disks larger than 2.2 TB, uses the GUID Partition Table (GPT), and offers a graphical interface that can also be controlled with a mouse. UEFI also includes Secure Boot – a feature that checks the digital signature of the operating system loader to prevent malicious software from loading during startup.
Firmware management: configuration and updates
During server setup, you often need to enter the BIOS/UEFI setup utility – usually by pressing F2, Del, or another key immediately after power on. Once inside, you can configure settings such as:
Boot order: which device (USB, hard drive, network) the server tries first to find an OS.
CPU features: enabling virtualisation (Intel VT-x or AMD-V), core count, and hyper-threading.
RAM settings: memory frequency, timings, and voltage.
Power management: configuring wake-on-LAN, sleep states, or fan profiles.
Security: setting an administrator password, enabling Secure Boot, or locking the chassis.
Firmware updates (also called flashing) involve replacing the existing BIOS/UEFI code with a new version from the server manufacturer (Dell, HPE, Lenovo, etc.). Updates fix bugs, add support for new hardware (like a faster CPU), patch security vulnerabilities (e.g., against firmware-level attacks), and improve stability. The process typically requires you to download the updated firmware file, copy it to a bootable media (USB) or use the vendor’s update tool, and then reboot the server. The server performs the update during the POST phase. Critical warning: do not interrupt the update process. If power is lost or the server is restarted halfway through, the firmware can become corrupted, turning the server into a “brick” that will not boot.
Why firmware management matters for the SK0-005 exam
The exam will test your knowledge of when to update firmware, how to verify the current version, what happens if an update fails, and what settings you might change to fix a server that does not boot. You will also need to know the difference between BIOS and UEFI, the partitioning schemes they support, and the concept of Secure Boot. Be prepared to see scenario-based questions where you have to choose the correct setting to enable virtualisation or to change the boot order from a USB drive.
In summary, BIOS/UEFI is the first software that runs on a server. It initialises hardware, performs a self-test, and hands control to the OS. Managing firmware updates ensures the server stays secure, stable, and compatible with new hardware. Mastering this chapter will help you troubleshoot boot problems and configure servers correctly from the start.
Check Current Firmware Version
Before updating, note the existing BIOS/UEFI version. This is usually shown during POST or in the setup utility. Verify that the new firmware is a newer version and compatible with your server model.
Download the Correct Firmware File
Obtain the firmware update from the server manufacturer’s official support site. Ensure you download the file specific to your server’s make and model. Incorrect files can cause update failures or brick the device.
Prepare an Update Environment
Choose a safe method: use the vendor’s bootable ISO on a USB drive, or an in-OS update tool if the vendor supports it and you have a UPS. For highest safety, boot into the dedicated update environment (e.g., Dell Lifecycle Controller or HPE Intelligent Provisioning).
Perform the Flash Update
Boot from the update media. The utility will detect the current firmware and the new file. Confirm the update. Do not power off or reset the server during the process. Wait for a progress bar to complete and for the server to automatically reboot.
Verify the Update and Reset Settings
After reboot, enter the BIOS/UEFI setup and check the firmware version to confirm it updated. Review your custom settings (boot order, virtualisation, Secure Boot). Some updates reset these to defaults, so reapply them as needed. Save and exit.
Document the Change
Record the new firmware version, date updated, and any issues encountered. This helps with future troubleshooting and compliance. Update your server inventory list accordingly.
Imagine you are a junior IT technician at a medium-sized company that hosts its own email and file servers. One morning, a senior colleague tells you that the main file server needs a firmware update because the manufacturer released a critical security patch for the UEFI to protect against a recently disclosed vulnerability (like Logofail or BootHole). You have never done this before, so your colleague walks you through it.
Step by step: real-world firmware update
First, you check the current firmware version. You reboot the server and watch for the POST screen. It shows “BIOS v2.1.0” or you can press F2 to enter the setup utility and find the version under System Information. You also check the manufacturer’s support website (Dell PowerEdge, HPE ProLiant, or Lenovo ThinkSystem) and find the latest firmware file – say v2.2.1. The release notes say it fixes a vulnerability and improves memory support. You download the file, which is often an executable or a .bin file.
Next, you need to apply the update. Many modern servers allow firmware updates from within the operating system using vendor tools, like Dell’s OpenManage or HPE’s Smart Update Manager. However, your company policy requires offline updates, so you boot into the BIOS/UEFI update environment, often via a USB drive with the vendor’s bootable ISO or using the Lifecycle Controller (on Dell) or Intelligent Provisioning (on HPE). You insert the USB, reboot, and press F11 to enter the boot menu, selecting the USB drive.
The update tool loads, detects the current firmware, and presents the new firmware. You confirm the update. The screen warns you not to power off the server. The flashing process begins – you see a progress bar. It takes about five minutes. The server automatically reboots once complete. After reboot, you enter the setup utility again to verify the version now reads v2.2.1. You also check that all previous settings (boot order, RAID configuration) are unchanged – sometimes firmware updates reset settings to defaults, which is why you should always note down custom settings before starting.
Another real scenario: changing boot order
Another day, a new operating system needs to be installed from a USB DVD drive. The server is currently set to boot from the internal hard drive first. You enter the UEFI setup, navigate to Boot Configuration, and set the USB DVD drive as the first boot device. You save and exit, and the server boots from the USB to start the OS installation. After installation, you change the order back to boot from the internal drive.
Common pitfalls in the real world
Forgetting to enable virtualisation (Intel VT-x) in the CPU settings when deploying a hypervisor (like Hyper-V or VMware). The server will still boot but virtual machines will not run.
Using the wrong firmware update file (e.g., updating a Dell server with an HPE file) – the update tool will refuse, but if you force it, you could brick the server.
Interrupting the update due to a power outage – always use a UPS and ensure the server has stable power.
Not documenting the original settings before a firmware update – then spending hours reconfiguring them.
In your job, you will also encounter legacy servers that still use BIOS instead of UEFI. You must know how to identify which one is running and how to configure both. The CompTIA Server+ exam expects you to understand these practical tasks because real IT pros deal with them almost daily.
The SK0-005 exam objective 4.3 – “Configure BIOS/UEFI settings and manage firmware updates” – is a relatively straightforward topic, but it has several common traps. The exam will test you on both conceptual knowledge and scenario-based decision making. Here is what you need to focus on.
Concepts the exam loves to test
The difference between BIOS (legacy, 16-bit, MBR, limited to 2.2TB disks) and UEFI (modern, 32/64-bit, GPT, supports larger disks, Secure Boot).
The purpose of POST (Power-On Self-Test) and what it checks.
Secure Boot: a UEFI feature that verifies the OS boot loader’s digital signature.
Boot order: how to change it and why (e.g., installing OS from USB).
Firmware update process: verifying current version, downloading correct file, using vendor tool, not interrupting.
What happens when a firmware update fails: the server may become unbootable (bricked). Recovery methods include using a backup ROM or a specialised USB recovery image.
Exam question patterns
Multiple choice that asks: “Which of the following is a feature of UEFI but not of traditional BIOS?” The answer is usually “Secure Boot” or “GPT support” or “ability to boot from disks larger than 2.2TB.”
Scenario-based: “A technician needs to install a new operating system on a server. The server currently boots from the hard drive. Which of the following should the technician do first?” The answer is to change the boot order in the UEFI to boot from the installation media (USB or DVD).
“A server fails to boot after a firmware update. What is the most likely cause?” The update was interrupted.
“Which key is commonly used to enter the UEFI setup utility on a Dell server?” Answer: F2.
“A technician needs to enable hardware virtualisation support. Which BIOS/UEFI setting should they adjust?” Look for options like “Intel VT-x”, “VMX”, or “Virtualisation Technology”.
Traps and common wrong answers
Some questions might imply that you can update BIOS/UEFI from within the operating system while it is running – technically you can with vendor tools (like Dell Command Update), but the exam often expects the safest method: booting into a special update environment. Know that some vendor tools do allow in-OS flashing, but the risk is higher. The exam may ask for the “most reliable” method or “best practise”.
Confusing BIOS with CMOS: CMOS is the memory chip that stores BIOS settings, not the firmware itself. If the CMOS battery dies, settings are lost but the BIOS code (firmware) remains intact.
Thinking that Secure Boot is available in traditional BIOS – it is not; it is a UEFI-only feature.
Assuming that all firmware updates require a reboot – some can be applied hot, but the exam usually focuses on the reboot process.
Key definitions to memorise
POST: Power-On Self-Test – initial hardware check.
CMOS: Complementary Metal-Oxide-Semiconductor – stores BIOS settings.
MBR: Master Boot Record – legacy partition scheme, limited to 2.2TB.
GPT: GUID Partition Table – modern scheme, supports up to 9.4ZB.
Secure Boot: UEFI security feature that verifies boot loader signature.
Boot order: list of devices the firmware tries to boot from.
Flash: the process of updating firmware.
What to study
Review the POST beep codes for common hardware failures (e.g., one beep usually means memory failure). The exam might not ask specific beep codes, but understanding that POST indicates hardware health is important.
Practise identifying when to update firmware: after a security advisory, to fix bugs, or when adding new hardware.
Understand the difference between a BIOS update and a BIOS setting change – one updates the firmware, the other changes configuration.
The exam will likely include at least 2–3 questions from this objective. Mastery here is easy to achieve because the concepts are fundamental. Pay attention to the UEFI vs BIOS comparison – it is the most common differentiator tested.
BIOS is a legacy firmware that uses MBR partitioning and cannot address disks larger than 2.2 TB.
UEFI is the modern firmware that supports GPT, Secure Boot, and can boot from disks larger than 2.2 TB.
The POST process checks hardware components and reports errors through beep codes or on-screen messages.
Firmware updates must never be interrupted; if power is lost during flashing, the server can become unbootable.
Secure Boot is a UEFI-only feature that verifies the digital signature of the OS boot loader to prevent unauthorised code from loading at startup.
The boot order in the BIOS/UEFI setup determines which device the server attempts to boot from first.
Clearing the CMOS (by removing the battery or using a jumper) resets firmware settings to defaults, but does not erase the firmware itself.
Always document current settings before performing a firmware update, because some updates may reset them to factory defaults.
These come up on the exam all the time. Here's how to tell them apart.
BIOS (Legacy)
Runs in 16-bit mode
Uses MBR, limited to 2.2 TB disks
Interface is text-based, keyboard only
UEFI (Modern)
Runs in 32-bit or 64-bit mode
Uses GPT, supports disks over 2.2 TB
Interface can be graphical, supports mouse
Secure Boot (UEFI)
Verifies digital signature of boot loader
Prevents malicious or unsigned boot code from loading
Requires OS that supports Secure Boot (e.g., Windows 8+, most Linux distros)
Standard Boot (UEFI without Secure Boot)
No signature verification
Allows any boot loader to run
Compatible with older operating systems that lack Secure Boot support
Firmware Update (Flash)
Writes new code to firmware chip
Riskier – can brick the server if interrupted
Requires resetting custom settings afterwards
CMOS Setting Change
Changes configuration stored in CMOS memory
Low risk – can be reset by clearing CMOS
Settings persist after reboot without erasing firmware
POST (Power-On Self-Test)
Runs before any boot device is accessed
Tests hardware components (RAM, CPU, storage)
Reports errors via beep codes or on-screen messages
Boot Loader (e.g., GRUB, Windows Boot Manager)
Runs after POST and after BIOS/UEFI finds a bootable device
Loads the operating system kernel into memory
Is controlled by the OS, not the firmware
Mistake
BIOS and UEFI are the same thing; UEFI is just a newer name for BIOS.
Correct
UEFI is a completely different interface with more features (GPT, Secure Boot, graphical UI) and runs in 64-bit mode, while BIOS runs in 16-bit mode and has limitations.
Many beginners hear 'firmware' and think it's all the same. The terms are often used interchangeably, but the exam distinguishes them.
Mistake
If I clear the CMOS, I will lose the BIOS/UEFI firmware and need to reinstall it.
Correct
Clearing the CMOS resets the settings (boot order, passwords, etc.) but does not erase the firmware code. The firmware remains on the flash chip.
People confuse the battery-backed memory that stores settings with the read-only memory that holds the firmware. They think 'clearing everything' means losing the BIOS itself.
Mistake
Updating firmware is exactly like updating a driver or operating system patch – you can do it from the OS without any special precautions.
Correct
Firmware updates are riskier because they write to the chip that controls hardware initialisation. A power failure during update can permanently 'brick' the server. It is best done from a dedicated update environment (like a bootable USB) or with a UPS.
Users are accustomed to driver updates that can be reversed. Firmware updates require a stable environment and cannot be easily rolled back if interrupted.
Mistake
Secure Boot prevents all malware from running on the server.
Correct
Secure Boot only checks the digital signature of the OS boot loader at startup. It does not protect against malware that loads after the OS is running, nor does it prevent unsigned drivers from being installed later (unless other features like Driver Signature Enforcement are used).
The name 'Secure Boot' sounds comprehensive. Beginners assume it is a total security solution, when it is only one layer during initial boot.
Mistake
You can change the boot order without entering the BIOS/UEFI setup – just by pressing a key during POST.
Correct
Pressing a key (e.g., F12 on Dell) brings up a one-time boot menu, which allows you to override the boot order for that boot only. The permanent boot order is changed inside the BIOS/UEFI setup utility.
The one-time boot menu is often mistaken for the actual boot order configuration. People think they have permanently changed it, but next boot it reverts.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Some manufacturers provide tools that allow in-OS flashing (e.g., Dell Command Update), but the safest practise is to boot into a dedicated firmware update environment to avoid OS interference and power loss risks.
Check if your server has a backup ROM or recovery mode. Many servers can boot from a recovery USB or use a hardware jumper to force the system to load a backup BIOS image. If not, you may need to send the server to the manufacturer for chip replacement.
During boot, press the F2 key repeatedly as soon as the Dell logo appears. This opens the System Setup (BIOS/UEFI). For a one-time boot menu (boot override), press F12.
Yes. A firmware update (flashing) replaces the code stored on the flash chip. A setting change modifies configuration parameters (like boot order or virtualisation) stored in the CMOS and is much safer.
You likely need to change the boot order in BIOS/UEFI to put the USB drive first, or use the one-time boot menu (F11 or F12) to select it for that boot. Also ensure that the USB is formatted as FAT32 and is bootable.
The firmware can become corrupted, and the server may no longer POST. This is called ‘bricking’. Recovery may require a specialised programmer or replacement of the firmware chip. Always use an uninterruptible power supply (UPS).
Many modern servers support out-of-band management interfaces like iDRAC (Dell), iLO (HPE), or IMM (Lenovo). These allow you to change BIOS settings and even perform firmware updates over the network from a remote console.
You've finished BIOS/UEFI and Firmware Management. Continue through the SK0-005 study guide to build a complete picture of the exam.
Done with this chapter?