220-1102 Operating Systems Practice Question

Answer analysis

Option-by-option breakdown

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

• ✗

  In the computer's UEFI/BIOS settings.

  Why it's wrong here

  The UEFI/BIOS firmware is responsible for hardware initialization, POST, and boot configuration, but it lacks the cryptographic storage and file system to permanently hold a BitLocker recovery key. While the TPM (Trusted Platform Module) is a separate chip that can store key protectors like the VMK, the 48-digit recovery key itself is never persisted in firmware. BitLocker's design intentionally keeps recovery material off the local hardware that might be stolen; storing it in firmware would be no more secure than storing it on the disk and would still be accessible to physical attackers.

• ✗

  On the user's Microsoft account recovery page.

  Why it's wrong here

  For a domain-joined Windows 10 computer, BitLocker recovery key backup is enforced through Group Policy, which redirects the escrow target to Active Directory Domain Services (AD DS), not to a personal Microsoft account. The 'Microsoft account recovery page' is intended for consumer devices that are enrolled with a Microsoft account (e.g., outlook.com or live.com credentials); enterprise devices that authenticate against Active Directory do not automatically link to such accounts, and the recovery key is stored under the computer object, not the user object. Even if the user also logs in with a Microsoft account on a domain PC, the default AD-backed policy ensures the key is escrowed in the domain's AD database for IT administrators to retrieve.

• ✓

  In Active Directory under the computer object's properties.

  Why this is correct

  This is correct: On domain-joined computers, the BitLocker recovery key is backed up to Active Directory by default, appearing under the computer object's properties in the 'BitLocker Recovery Information' tab. The key is stored in the msFVE-RecoveryInformation class as an attribute of the computer object, allowing domain administrators to find it easily via AD User and Computers or PowerShell (e.g., Get-ADObject). This escrow is controlled by Group Policy ('Choose how BitLocker recovery keys are recovered') and is essential for enterprise data recovery when a user is locked out or the TPM fails. Without AD escrow, managing encryption at scale would be impractical.

• ✗

  On the system drive in a hidden folder.

  Why it's wrong here

  Placing the recovery key on the same encrypted volume it is meant to unlock would create a logical paradox: the drive's contents are inaccessible without the key, so the key itself could not be read to unlock it. Even if stored in an unencrypted hidden folder on the system drive, an attacker with physical access could extract it using offline tools, defeating the entire purpose of BitLocker encryption. BitLocker wraps the volume encryption key (VEK) with a VMK protected by TPM or a password, but the 48-digit recovery key is deliberately kept outside the encrypted drive, typically in AD or printed out.

Go deeper

Related to this question