Server+ PBQ Lab: Storage Path Outage
By QH · Updated Jul 10, 2026
| Certification | Security+ (SY0-701) |
| Questions | 1 |
| Passing Score | 100% |
| Format | 100% Pbq Platform |
| Sessions Logged | 585 |
| 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
Investigate a post-maintenance storage outage affecting multiple dependent server workloads. Use the ticket, dependency map, host evidence, SAN presentation, switch configuration, metrics, logs, and bounded console tools to determine why the affected applications are failing and what remediation actually restores stable storage access. This lab is designed to test Server+ storage, virtualization, networking, monitoring, and troubleshooting skills through evidence-based analysis rather than a single obvious fix.
Explanation
The correct answer is to restore the HV-02 storage-b path configuration on SW-STOR-B so the storage VLAN and MTU match the intended jumbo-frame storage design, remove any bad target-discovery entries, rescan HV-02 storage, verify DS-PROD-01/LUN 12 and two optimized MPIO paths, and then recover DB-01, API-01, and WEB-01 in dependency order.
This is correct because the outage is not caused by a failed SAN, a bad application service, or a missing datastore. The evidence points to a degraded storage path on one hypervisor host after network maintenance. HV-02 is the affected host, and the impacted workloads all depend on DS-PROD-01/LUN 12. The storage array still presents the production LUN, the controllers are healthy, and a comparison host still has healthy access. That rules out a broad storage-array failure.
The critical detail is that the second iSCSI path is not fully healthy even though basic connectivity appears to work. Small pings can succeed, but storage I/O still fails or flaps because the storage-b path no longer matches the jumbo-frame configuration used by the host and storage network. The switch-side path reverted to an incorrect configuration after maintenance, leaving HV-02 with degraded multipath access. Restoring the correct storage VLAN and MTU on SW-STOR-B fixes the underlying transport problem rather than treating a symptom.
The answer also correctly requires validation before application recovery. After fixing the storage path, HV-02 must rescan storage and confirm the correct production LUN, not merely any visible datastore. Two optimized MPIO paths must be verified so the host is no longer operating through a single degraded path. Only after storage latency and path health are corrected should DB-01, API-01, and WEB-01 be recovered in dependency order. That order matters because restarting applications before stable storage is restored can produce temporary or misleading results while the root cause remains.
Replacing a disk group or rebuilding the RAID pool is incorrect because the array evidence does not show a failed disk group, degraded RAID state, or controller-side storage failure. The production datastore problem is host/path-specific, not a SAN-wide hardware failure. Treating it as a RAID incident would add unnecessary risk and downtime without addressing the broken storage-b path.
Restarting DB-01, API-01, and WEB-01 as the primary fix is incorrect because the application errors are downstream symptoms of storage latency and path instability. The services are timing out because their underlying VM storage is unhealthy. Restarting them before correcting the iSCSI/MPIO path may briefly change the symptoms, but it does not restore stable access to the datastore.
Mounting DS-ARCHIVE-02 or another visible datastore is incorrect because visibility is not the same as correctness. The affected workloads depend on DS-PROD-01/LUN 12. Mounting a different datastore does not repair the degraded production storage path and could create additional operational risk by moving or attaching workloads to the wrong storage target.
Recreating the iSCSI discovery entry with a new target IQN and CHAP secret is incorrect because the evidence does not show that the correct production target was replaced or that CHAP should be changed. A wrong IQN, look-alike target, or mismatched CHAP value can create authentication failures or stale discovery entries. Disabling multipathing is especially wrong because the problem is degraded multipath resiliency; removing MPIO would make the environment less redundant and could worsen the outage.
Changing HV-02 vmk2 to MTU 1500 is incorrect because it normalizes the host down to the broken switch state instead of restoring the intended storage-network design. The environment is designed for jumbo frames on the storage path. Small pings succeeding at MTU 1500 do not prove storage I/O is healthy. The correct fix is to restore consistency across the storage path, including the switch configuration, so large storage traffic and multipath failover operate correctly after the next reboot.