Select Two (Multi-Select) Questions

Perform a quick format of the drive before disposal.

Why it fails: A quick format operation primarily overwrites the file system's allocation table and root directory, marking the entire drive as empty and ready for new data. However, it does not physically erase the actual data blocks where files reside. Consequently, specialized data recovery software can easily bypass the new file system information and reconstruct the original files from the underlying magnetic patterns, making it an insufficient method for secure data disposal.

Delete the files and empty the Recycle Bin.

Why it fails: Simply deleting files and emptying the Recycle Bin only removes the operating system's pointers to the data, not the data itself. The sectors on the hard drive containing the file's content are merely marked as available for future writes, but the original data remains intact. Until new data overwrites these sectors, the 'deleted' information is readily recoverable using common undelete utilities or forensic tools, posing a significant security risk.

bootrec /fixboot

Why it fails: bootrec /fixboot writes a new boot sector to the system partition. It does not rebuild the BCD. It is used when the boot sector is corrupted or missing, but it does not address BCD corruption. Thus, it is not a correct answer for rebuilding the BCD.

bootrec /fixmbr

Why it fails: bootrec /fixmbr writes a new master boot record to the system partition. It repairs the MBR but does not touch the BCD. It is used for MBR corruption, not BCD issues. Therefore, it is not a correct answer for rebuilding the BCD.

bcdedit /export

Why it fails: bcdedit /export backs up the BCD store to a file. It does not rebuild or repair the BCD. While it is useful for backup before making changes, it does not resolve a corrupted BCD. Therefore, it is not a correct answer for rebuilding.

Low-level formatting

Why it fails: Low-level formatting is a factory process that sets up the drive's sectors. It does not securely erase data and is not a physical destruction method. In fact, it may leave data remnants. Since the policy requires physical destruction, this method is inappropriate and does not meet the security requirement.

Overwriting

Why it fails: Overwriting writes new data over the old data, effectively erasing it. However, it is a logical destruction method, not physical. The policy explicitly requires physical destruction, so overwriting does not comply. Additionally, overwriting may not be reliable on all drive types, such as SSDs with wear leveling, making it less secure than physical destruction.

Degaussing

Why it fails: Degaussing uses a strong magnetic field to erase data on magnetic media. However, it does not physically destroy the drive, and it is ineffective on solid-state drives (SSDs). Since the policy requires physical destruction, degaussing alone may not meet the requirement, especially if SSDs are present. It also leaves the drive intact, so it is not a physical destruction method.

Disk queue length

Why it fails: Disk queue length indicates the number of I/O requests waiting for the disk, which can rise when heavy paging occurs due to low memory. It is a secondary symptom rather than a direct measure of memory exhaustion. The technician needs to confirm the memory leak itself, so disk queue length is less direct than monitoring memory usage and available memory. It may be elevated but does not prove the leak.

CPU utilization

Why it fails: CPU utilization shows the percentage of processor capacity being used, which can reveal high load from a runaway process. However, a memory leak may not cause sustained high CPU usage; the system could slow down due to paging while CPU remains moderate. While useful, this counter alone does not confirm memory exhaustion, so it is not one of the two best indicators for the suspected leak.

GPU usage

Why it fails: GPU usage measures the load on the graphics processor, which is relevant for graphics-intensive tasks but not for diagnosing a memory leak. A memory leak in a user-mode process would not necessarily increase GPU utilization. Monitoring GPU usage would not provide evidence of system memory exhaustion, so it is not an appropriate counter for this scenario.

Run a standard format on the drive before disposal.

Why it fails: A standard format does not securely erase data; it only removes file system pointers. Data can still be recovered with forensic tools. For sensitive company data, a more robust method like physical destruction or secure wipe is required. Standard format is insufficient for data security and does not meet disposal policies.

Delete all partitions and recreate a single empty partition.

Why it fails: Deleting partitions and recreating one does not erase the data; it merely alters the partition table. The underlying data remains on the disk and can be recovered. This method is inadequate for protecting sensitive information and does not meet secure disposal requirements. It should not be used for drives containing confidential data.

Store the drive in a secure cabinet until it can be reused.

Why it fails: Storing the drive does not address data security if the drive is eventually disposed of or stolen. The question asks about disposal and maintaining data security. Simply storing it delays the problem and does not sanitize the data. The technician must either destroy or securely wipe the drive before disposal or reuse.

Leave the power cord connected but turn off the power supply switch.

Why it fails: Leaving the power cord connected, even with the switch off, still provides a path for electrical current and keeps the system grounded. This can be dangerous if the switch fails or if there is a short. The power cord should be completely disconnected before opening the case.

Use a magnetic screwdriver to retrieve screws from inside the power supply.

Why it fails: A magnetic screwdriver can damage sensitive components or interfere with the power supply's operation. It may also attract metal debris that could cause short circuits. Using a magnetic tool inside a power supply is unsafe and not recommended.

Work on a carpeted floor to cushion the components.

Why it fails: Carpet generates static electricity, increasing the risk of ESD damage to components. Working on a carpeted floor is strongly discouraged unless antistatic measures are in place. A hard, non-conductive surface is preferred to minimize static buildup.

Enable System Restore and create a restore point.

Why it fails: Creating a restore point after infection is not helpful because the restore point would include the malware. System Restore is useful for reverting to a pre-infection state, but only if a clean restore point exists. Enabling it now does not remediate the current infection.

Reimage the computer immediately without attempting removal.

Why it fails: Reimaging is a drastic step that should be considered only if removal efforts fail or if the infection is severe. It erases all data and requires reinstalling applications. Attempting removal first is less disruptive and often sufficient. Reimaging without trying other methods is premature.

Educate the user on safe browsing habits.

Why it fails: User education is important for prevention but does not remediate an existing infection. It should be done after the malware is removed. The immediate next steps should focus on eliminating the malware, not on training, which can be addressed later.

Role-based access control (RBAC)

Why it fails: RBAC assigns permissions based on job roles, limiting what an authenticated user can do. It does not prevent credential theft or unauthorized login; it only restricts actions after authentication. While valuable for least privilege, it does not address the stated risk of stolen credentials enabling access.

Single sign-on (SSO)

Why it fails: SSO lets users authenticate once and access multiple applications, improving convenience, but it does not by itself reduce the risk of credential theft. If the single credential is compromised, many systems become accessible. SSO should be combined with MFA, but it is not the primary control to implement for this requirement.

Password manager

Why it fails: A password manager helps users create and store strong, unique passwords, which reduces password reuse. However, it does not prevent an attacker who steals the master password or a stored credential from logging in. It is a useful supplement but not a direct defense against credential theft in the way MFA is.

Use Disk Cleanup to remove temporary files.

Why it fails: Disk Cleanup frees space by removing temporary and unnecessary files. It can improve performance if the drive is nearly full, but it does not diagnose a failing hard drive. The symptoms described—constant activity and freezes—are more indicative of hardware degradation than low disk space.

Run the Windows Memory Diagnostic tool.

Why it fails: Windows Memory Diagnostic tests RAM, not the hard drive. While faulty RAM can cause freezes, the constant hard drive activity and the technician's suspicion of a failing HDD point to storage. Testing memory does not confirm or rule out disk problems and is not the appropriate diagnostic here.

Defragment the hard drive using the built-in Windows tool.

Why it fails: Defragmentation reorganizes files to improve access times on a healthy HDD, but it does not diagnose a failing drive. In fact, heavy defragmentation on a drive with bad sectors can stress it further and accelerate failure. It is not a diagnostic step for suspected hardware failure.

Reliability Monitor

Why it fails: Reliability Monitor aggregates stability events, application failures, and Windows updates into a timeline and can show that a driver update coincides with crashes. However, it reports the event and the update name rather than the specific driver file or module that caused the fault, so it helps correlate timing but does not directly identify the offending driver in the crash.

Event Viewer's System log

Why it fails: The System log records the bug check code and sometimes the dump file path, but it rarely names the individual driver responsible. It confirms that a crash occurred and when, which is useful context, yet it does not provide the module-level detail needed to pin the fault on a specific driver, so it is supplementary rather than definitive.

Performance Monitor's counter logs

Why it fails: Performance Monitor tracks resource counters such as CPU, memory, disk, and network utilization over time. It can reveal resource exhaustion preceding a freeze but has no visibility into kernel driver call stacks or bug check analysis, so it cannot name the driver that triggered the IRQL fault. It is a capacity and trend tool, not a crash diagnostic.