Courseiva
Security ArchitectureeasyMultiple ChoiceObjective-mapped

SY0-701 Security Architecture Practice Question

A laptop repeatedly starts with an unapproved bootloader, and the security team wants the firmware to refuse boot code that is not signed by a trusted key. Which feature should be used?

⚠ Common exam trap

Many candidates confuse Secure Boot with BitLocker, thinking that disk encryption also verifies boot integrity, but BitLocker only protects data after the OS loads and does not validate the bootloader's signature.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

Secure Boot.

Secure Boot is a UEFI firmware feature that verifies the digital signature of bootloaders and kernel code against a database of trusted keys before allowing execution. By configuring Secure Boot to only accept boot code signed by a trusted key, the firmware will reject any unapproved bootloader, preventing unauthorized code from running during the boot process.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • Secure Boot.

    Why this is correct

    This is the best answer because Secure Boot verifies that boot components are signed by trusted keys before allowing them to load. That helps prevent bootkits and other pre-boot tampering from taking control before the operating system starts. It is a core platform hardening feature on modern systems and directly addresses trust in the boot process.

  • BitLocker full-disk encryption.

    Why it's wrong here

    BitLocker full-disk encryption protects the confidentiality of data at rest by encrypting the entire volume, but it does not cryptographically validate the identity or signature of the boot loader. During startup, the platform loads whatever bootloader is present; BitLocker's pre-boot components and TPM sealing may detect tampering after the fact, but they do not proactively block an unapproved bootloader from executing. In contrast, Secure Boot verifies the signature of boot code before it is allowed to run.

  • A DHCP reservation.

    Why it's wrong here

    DHCP reservation is a server configuration that maps a client's MAC address to a fixed IP address in the DHCP subnet pool. It influences network addressing only; it has no mechanism to inspect, sign, or execute code from the laptop's firmware or disk. Even if the laptop boots via PXE, a DHCP reservation does not control which boot image is supplied; that is determined by the boot server and menu, not the reservation. Therefore, it cannot stop an unapproved bootloader from being launched.

  • A local administrator password policy.

    Why it's wrong here

    Local administrator password policy defines rules for password length, complexity, and rotation for OS-level accounts. These policies are enforced by the operating system's security subsystem after it has already loaded, whereas an unapproved bootloader gains control during the pre-OS boot phase. There is no password prompt in early UEFI boot, and if the bootloader is malicious, it could simply ignore or disable later account checks. Thus, a password policy does not provide any boot-time trust verification.

About these practice questions

One of 1,013 original SY0-701 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

This SY0-701 practice question is part of Courseiva's free CompTIA certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SY0-701 exam.