Security+ PBQ Lab: Firmware Integrity and Storage Recovery

Why the correct answer is right

Verified out-of-band firmware remediation is the only option that follows a complete secure remediation process instead of simply making the scanner quiet. The learner has to preserve support evidence, export the RAID controller configuration metadata, stage a rollback path, verify the firmware package against the vendor advisory hash, reject the compromised local package, download and verify a clean vendor mirror copy, apply the supported ASR-94xx firmware through the BMC lifecycle controller, perform a controlled power cycle, and then validate both storage health and vulnerability remediation.

This path is correct because the vulnerability exists at the controller firmware layer, not merely in the operating system driver. It also respects the operational constraints in the ticket: the database server is business-critical, the storage volumes must not be reinitialized, and the change requires pre-flash backup verification. The clean solution balances security, availability, integrity, and change-control discipline.

It is also the only answer that handles the supply-chain trap correctly. The locally cached package has a trustworthy-looking name and signature language, but its hash does not match the vendor advisory. A secure technician should not install firmware based only on filename, version string, or “signed” wording. They must verify integrity against the official digest and use the clean verified copy.

Why the other options are wrong

In-band driver remediation and monitor is wrong because applying an operating system storage driver does not remediate a vulnerable RAID controller firmware version. It may change the driver inventory or temporarily reduce symptoms after a reboot, but the underlying firmware remains vulnerable. This is the “patching is patching” trap: the learner must remediate the affected layer, not the most convenient layer.

Controller replacement and foreign import is wrong because the newer spare controller cannot safely read the existing RAID metadata. Replacing a controller family without validating metadata compatibility can make healthy disks appear foreign or unavailable. This creates a storage outage while failing to solve the original secure remediation requirement.

Preview firmware with risk acceptance is wrong because the beta or preview firmware may clear the vulnerability scanner, but it is not an approved production remediation path. In the lab, it creates delayed operational fallout: write-cache degradation, I/O timeouts, and database service impact. Security remediation that breaks production without approval, validation, or rollback is not a clean solution.

Locally cached signed package remediation is wrong because the local “signed LTS” package is intentionally not trustworthy. Its hash does not match the vendor advisory digest. Installing it because the filename looks correct ignores cryptographic integrity verification and simulates a corrupted or compromised supply-chain package. The learner must use the verified mirror copy, not the suspicious local cache.