Security+ PBQ Lab: Firmware Integrity and Storage Recovery
By QH · Updated Jun 21, 2026
| Certification | Security+ (SY0-701) |
| Questions | 1 |
| Passing Score | 100% |
| Format | 100% Pbq Platform |
| Sessions Logged | 586 |
| Your progress | Log in / Register to track times taken, best score, questions mastered, and coverage on this quiz. |
| Rating |
Certification Summary
CompTIA Security+ SY0-701 is the standard hurdle for systems administrators and junior security analysts tasked with maintaining basic infrastructure defenses. People sit this exam because their leads view it as a prerequisite for getting access to production environments, often using it to satisfy a checkbox for compliance audits or government contracts.
The exam leans on scenario based questions that force you to prioritize mitigation steps during a simulated breach. Security Operations at 28 percent, Threats, Vulnerabilities, and Mitigations at 22 percent, and Security Program Management and Oversight at 20 percent carry the weight of the assessment. You will also see questions on Security Architecture and General Security Concepts that require you to identify specific cryptographic implementations and the standard access control models defined in the CompTIA framework.
Topics covered
Uncategorized1 question
Question catalog for this preview
Catalog listing of the 1 preview question for this quiz.
Question 1
In this Security+ performance-based lab, learners investigate a critical firmware vulnerability on a payment database server while balancing remediation, availability, change control, and supply-chain integrity. They must review the ticket, inspect BMC and RAID evidence, verify firmware authenticity, avoid unsafe shortcuts, apply the correct out-of-band remediation path, and validate that both the vulnerability and storage health are resolved.
Explanation
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.