How should I use these Computer Forensics Investigation Process practice questions?

Read each scenario carefully and choose your answer before revealing the explanation. Then check why your choice was right or wrong. Repeat until the reasoning feels automatic.

CHFI · topic practice

Computer Forensics Investigation Process practice questions

Q: Can I practise just Computer Forensics Investigation Process questions in a focused session?

Yes — use the session launcher on this page to start a 10-, 20-, 30- or 50-question session drawn entirely from the Computer Forensics Investigation Process domain.

Practise Computer Hacking Forensic Investigator CHFI Computer Forensics Investigation Process practice questions — original exam-style scenarios with answer choices, explanations, and analysis of common mistakes.

Courseiva uses original exam-style practice questions designed for learning and revision. The goal is to understand the concepts, recognise exam patterns, and improve through explanations — not memorise copied exam dumps.

Reviewed byJohnson Ajibi· MSc IT Security

10 questionsDomain: Computer Forensics Investigation Process

Practice 10 questions Browse domain →

What the exam tests

What to know about Computer Forensics Investigation Process

Computer Forensics Investigation Process questions test whether you can apply the concept in context, not just recognise a definition.

How the topic appears in realistic exam-style scenarios.

Which detail in the question changes the correct answer.

How to eliminate plausible but wrong options.

How to connect the question back to the wider exam objective.

Watch out for

Common Computer Forensics Investigation Process exam traps

▸Answering from memory before reading the full scenario.
▸Missing a constraint such as cost, availability, security, scope or command context.
▸Choosing a broad answer when the question asks for the most specific fix.
▸Ignoring why the wrong options are tempting.

Practice set

Computer Forensics Investigation Process questions

10 questions · select your answer, then reveal the explanation

Question 1easymultiple choice

Read the full Computer Forensics Investigation Process explanation →

During a forensic investigation, an analyst discovers that the suspect's hard drive was encrypted using BitLocker. The analyst has obtained the recovery key. Which of the following is the best next step to ensure data integrity?

Trap 1: Decrypt the drive using the recovery key and then create a forensic…

Applying the recovery key to decrypt the original drive in place is destructive from an evidentiary perspective: the controller performs writes that alter sector-level plaintext, encrypted metadata, filesystem journal, and access timestamps, contaminating the very evidence you must preserve. You also lose the pristine encrypted snapshot, which may be needed to prove how the encryption was configured, and any imaging afterward captures artifacts introduced by the decryption process. Always image the encrypted medium first and decrypt only a forensic clone.

Trap 2: Run a live analysis tool to extract encryption keys from memory.

Running a live tool to pull keys from memory can produce useful decryption credentials, but it does not produce a forensic image of the encrypted disk, and it involves executing code on the live system, changing memory state and potentially triggering anti-forensic or FDE lockdown routines. Even if key extraction succeeds, you still need a separate disk image to analyze user data; without an image, the keys are only a means to decrypt evidence you failed to collect. Volatile memory acquisition should be performed as a supplementary step — never as a substitute for imaging the disk.

Trap 3: Boot the suspect computer and copy files to an external drive.

Booting the suspect computer to copy files is a textbook contamination scenario: the boot process writes to the registry, prefetch, event logs, hibernation file, and filesystem metadata, and it can overwrite unallocated areas where deleted evidence resides. Manually copying selected files also snatches only active, visible data; you lose deleted files, slack space, and partition-level artifacts, creating an incomplete and legally indefensible evidentiary collection. The correct, non-invasive approach is to acquire a full disk image with the system powered off using a hardware write-blocker.

Study all Computer Forensics Investigation Process common traps →

A
Decrypt the drive using the recovery key and then create a forensic image.
Why wrong: Applying the recovery key to decrypt the original drive in place is destructive from an evidentiary perspective: the controller performs writes that alter sector-level plaintext, encrypted metadata, filesystem journal, and access timestamps, contaminating the very evidence you must preserve. You also lose the pristine encrypted snapshot, which may be needed to prove how the encryption was configured, and any imaging afterward captures artifacts introduced by the decryption process. Always image the encrypted medium first and decrypt only a forensic clone.
B
Run a live analysis tool to extract encryption keys from memory.
Why wrong: Running a live tool to pull keys from memory can produce useful decryption credentials, but it does not produce a forensic image of the encrypted disk, and it involves executing code on the live system, changing memory state and potentially triggering anti-forensic or FDE lockdown routines. Even if key extraction succeeds, you still need a separate disk image to analyze user data; without an image, the keys are only a means to decrypt evidence you failed to collect. Volatile memory acquisition should be performed as a supplementary step — never as a substitute for imaging the disk.
C
Create a forensic image of the encrypted drive, then decrypt the image.
Creating a bit-for-bit forensic image of the encrypted drive before any decryption preserves the original evidence in its native state, capturing the full encrypted volume, partition table, free space, and deleted data remnants. The analyst can then decrypt that image on a write-protected or isolated forensic workstation using the known recovery key or extracted keys, leaving the original exhibit untouched and maintaining chain of custody. This workflow is the accepted standard for full-disk-encrypted evidence because it separates acquisition from decryption and permits multiple independent analyses.
D
Boot the suspect computer and copy files to an external drive.
Why wrong: Booting the suspect computer to copy files is a textbook contamination scenario: the boot process writes to the registry, prefetch, event logs, hibernation file, and filesystem metadata, and it can overwrite unallocated areas where deleted evidence resides. Manually copying selected files also snatches only active, visible data; you lose deleted files, slack space, and partition-level artifacts, creating an incomplete and legally indefensible evidentiary collection. The correct, non-invasive approach is to acquire a full disk image with the system powered off using a hardware write-blocker.

Full breakdown with real-world context →

Question 2mediummultiple choice

Read the full Computer Forensics Investigation Process explanation →

A CHFI analyst is called to investigate a suspected data breach. The IT team has already shut down the server. Which of the following is the most appropriate order of actions to preserve evidence?

Trap 1: Immediately power on the server to check for running processes.

Powering on the server to inspect running processes is improper because it alters volatile evidence and writes to the disk. Booting the system updates file access timestamps, modifies registry keys, creates or rotates logs, and swaps data into the pagefile, thereby contaminating the media. Additionally, process information is lost unless a live response toolkit is used with proper volatile data collection procedures before shutdown. The correct approach is to preserve and acquire evidence without executing the operating system.

Trap 2: Copy all files from the server to an external USB drive.

Copying all files to an external USB drive produces a logical extraction that fails to capture deleted data, residual data in unallocated space, slack space, or hidden partitions. It also does not preserve critical metadata such as file system timestamps and MAC times, and may alter access times during the copy operation. A forensic image is a bit-for-bit duplicate with hash verification, which is required to prove integrity and to recover artifacts that a file copy would omit.

Trap 3: Run antivirus scan to ensure no malware is present before imaging.

Running an antivirus scan before imaging is an invasive action that can modify the evidence itself. The scanner will read numerous files, updating their last-accessed timestamps, and may write quarantine records, log files, or virus definitions to the target disk. Some AV engines also unpack or decrypt suspect files, changing their content on disk. To preserve the original state, an image must be created first, and then malware analysis can be performed on the copy.

Study all Computer Forensics Investigation Process common traps →

A
Immediately power on the server to check for running processes.
Why wrong: Powering on the server to inspect running processes is improper because it alters volatile evidence and writes to the disk. Booting the system updates file access timestamps, modifies registry keys, creates or rotates logs, and swaps data into the pagefile, thereby contaminating the media. Additionally, process information is lost unless a live response toolkit is used with proper volatile data collection procedures before shutdown. The correct approach is to preserve and acquire evidence without executing the operating system.
B
Copy all files from the server to an external USB drive.
Why wrong: Copying all files to an external USB drive produces a logical extraction that fails to capture deleted data, residual data in unallocated space, slack space, or hidden partitions. It also does not preserve critical metadata such as file system timestamps and MAC times, and may alter access times during the copy operation. A forensic image is a bit-for-bit duplicate with hash verification, which is required to prove integrity and to recover artifacts that a file copy would omit.
C
Run antivirus scan to ensure no malware is present before imaging.
Why wrong: Running an antivirus scan before imaging is an invasive action that can modify the evidence itself. The scanner will read numerous files, updating their last-accessed timestamps, and may write quarantine records, log files, or virus definitions to the target disk. Some AV engines also unpack or decrypt suspect files, changing their content on disk. To preserve the original state, an image must be created first, and then malware analysis can be performed on the copy.
D
Secure the scene, photograph the setup, document connections, remove hard drives, and create forensic images using a write-blocker.
This is the correct forensic process: first secure the scene to prevent interference, then photograph and document the physical setup and all connections to preserve the context. Identify and collect volatile data if applicable, then remove the hard drives using proper anti-static procedures. Using a write-blocker when creating a forensic image prevents any write operations to the original drive, and hashing the image ensures the preservation of a verifiable, bit-for-bit copy for analysis and chain-of-custody.

Full breakdown with real-world context →

Question 3hardmultiple choice

Read the full Computer Forensics Investigation Process explanation →

An incident responder has acquired a forensic image of a Linux server suspected of being compromised. The image was taken using 'dd' with no compression. The analyst needs to verify the integrity of the image. Which command should be used and what should be compared?

Trap 1: Use 'cmp' to compare the image byte-by-byte with the original drive.

Running 'cmp' against the original drive is impractical and risky: it requires the original evidence drive to be directly accessible again, and merely connecting it can risk altering metadata or expose it to accidental writes. Even with a write-blocker, a raw byte-by-byte comparison is inefficient for large acquisitions and provides no cryptographic integrity validation, unlike a hash based on the acquisition process itself.

Trap 2: Use 'md5sum image.dd' and compare with the original file's MD5 hash…

MD5 is cryptographically broken and not collision-resistant, so an attacker could deliberately craft a different image with the same MD5 hash. Furthermore, the original file's MD5 supplied by the system administrator is not an independent, forensically sound baseline; the hash to compare against should be computed from the source device during the imaging session, using a stronger algorithm like SHA-256.

Trap 3: Run 'fsck' on the image to check for filesystem errors.

The 'fsck' utility checks the internal consistency of the filesystem (e.g., inode links, superblock fields, and directory structures) within the image, not the integrity of the image file itself. A forensic image can be perfectly intact at the bit level yet contain filesystem errors, or be corrupted in the copy while still appearing fsck-clean; thus fsck cannot validate that the image is an exact, unaltered copy of the source.

Study all Computer Forensics Investigation Process common traps →

A
Use 'cmp' to compare the image byte-by-byte with the original drive.
Why wrong: Running 'cmp' against the original drive is impractical and risky: it requires the original evidence drive to be directly accessible again, and merely connecting it can risk altering metadata or expose it to accidental writes. Even with a write-blocker, a raw byte-by-byte comparison is inefficient for large acquisitions and provides no cryptographic integrity validation, unlike a hash based on the acquisition process itself.
B
Use 'md5sum image.dd' and compare with the original file's MD5 hash provided by the system administrator.
Why wrong: MD5 is cryptographically broken and not collision-resistant, so an attacker could deliberately craft a different image with the same MD5 hash. Furthermore, the original file's MD5 supplied by the system administrator is not an independent, forensically sound baseline; the hash to compare against should be computed from the source device during the imaging session, using a stronger algorithm like SHA-256.
C
Run 'fsck' on the image to check for filesystem errors.
Why wrong: The 'fsck' utility checks the internal consistency of the filesystem (e.g., inode links, superblock fields, and directory structures) within the image, not the integrity of the image file itself. A forensic image can be perfectly intact at the bit level yet contain filesystem errors, or be corrupted in the copy while still appearing fsck-clean; thus fsck cannot validate that the image is an exact, unaltered copy of the source.
D
Use 'sha256sum image.dd' and compare with the hash computed during acquisition from the source device.
Using 'sha256sum' on the image and comparing it with the SHA-256 hash computed during acquisition from the source device is the correct forensic integrity check. SHA-256 is a strong cryptographic hash that is collision-resistant, and the acquisition-time hash provides a trusted baseline generated from the original evidence while it was write-protected, so any subsequent modification to the image will cause a mismatch.

Full breakdown with real-world context →

Question 4mediummulti select

Read the full Computer Forensics Investigation Process explanation →

Which TWO of the following are considered essential steps in the computer forensics investigation process according to EC-Council guidelines?

Trap 1: Data recovery from damaged media

Data recovery from damaged media is a specialized technical procedure, not a universal step in every forensic examination. It is only invoked when media is physically deteriorated, logically corrupted, or otherwise inaccessible, and must be performed after the evidence is safely imaged using write-blocking techniques. Most investigations involve intact media where standard forensic acquisition works, so listing recovery as an essential step overstates resource needs and confuses a contingency technique with a core procedural requirement. Its absence does not invalidate a forensic process.

Trap 2: Deletion of irrelevant data

Deletion of irrelevant data is strictly prohibited in forensic practice because relevance cannot be reliably determined until after full analysis, and physical deletion destroys potential evidence. The core forensic principle is non-destruction; an examiner must preserve the original and any forensic image exactly as captured, even if a portion appears irrelevant at first review. Physically removing data would break the chain of custody, expose the examiner to spoliation sanctions, and render the entire examination inadmissible. Irrelevant data is instead simply ignored during analysis, never deleted from the evidence.

Trap 3: Public disclosure of findings

Public disclosure of findings violates the confidentiality that governs forensic work, as evidence and analytical results are typically protected by statutes, agency policies, or court orders. Premature or unauthorized disclosure can jeopardize an ongoing criminal investigation, invade the privacy of third parties, and create grounds for suppression of evidence. Findings are only shared through formal mechanisms such as expert testimony, reports provided to authorized counsel, or compelled disclosure under a court order. Thus, public release is not an essential step but rather a breach of forensic ethics and protocol.

Study all Computer Forensics Investigation Process common traps →

A
Identification of potential evidence
Identification is the systematic recognition of potential evidence sources within the legal boundary of an investigation, and it is the first mandatory step in the forensic process. It involves cataloging devices, storage media, logs, and other items that may hold relevant data, done before any seizure or acquisition. Without proper identification, investigative efforts lack direction and legal authority, making all subsequent forensic actions vulnerable to challenge. This step is essential because it defines the scope of evidence and informs the search warrant or other authorization.
B
Data recovery from damaged media
Why wrong: Data recovery from damaged media is a specialized technical procedure, not a universal step in every forensic examination. It is only invoked when media is physically deteriorated, logically corrupted, or otherwise inaccessible, and must be performed after the evidence is safely imaged using write-blocking techniques. Most investigations involve intact media where standard forensic acquisition works, so listing recovery as an essential step overstates resource needs and confuses a contingency technique with a core procedural requirement. Its absence does not invalidate a forensic process.
C
Deletion of irrelevant data
Why wrong: Deletion of irrelevant data is strictly prohibited in forensic practice because relevance cannot be reliably determined until after full analysis, and physical deletion destroys potential evidence. The core forensic principle is non-destruction; an examiner must preserve the original and any forensic image exactly as captured, even if a portion appears irrelevant at first review. Physically removing data would break the chain of custody, expose the examiner to spoliation sanctions, and render the entire examination inadmissible. Irrelevant data is instead simply ignored during analysis, never deleted from the evidence.
D
Preservation of the integrity of evidence
Preservation of integrity ensures that evidence is secured against alteration from the moment of identification, using write-blockers to perform bit-for-bit forensic images and cryptographic hashes like SHA-256 to verify that copies match the original. This must be accomplished before any analysis begins, because courts require proof that the evidence examined is the same as what was seized. Chain of custody documentation, including who handled the evidence and when, is a direct component of preservation. Without these controls, evidence loses its legal admissibility regardless of its technical value.
E
Public disclosure of findings
Why wrong: Public disclosure of findings violates the confidentiality that governs forensic work, as evidence and analytical results are typically protected by statutes, agency policies, or court orders. Premature or unauthorized disclosure can jeopardize an ongoing criminal investigation, invade the privacy of third parties, and create grounds for suppression of evidence. Findings are only shared through formal mechanisms such as expert testimony, reports provided to authorized counsel, or compelled disclosure under a court order. Thus, public release is not an essential step but rather a breach of forensic ethics and protocol.

Full breakdown with real-world context →

Question 5hardmultiple choice

Read the full Computer Forensics Investigation Process explanation →

You are a CHFI analyst responding to a security incident at a medium-sized financial firm. The IT team reports that an employee's workstation (Windows 10, single SSD) was used to access sensitive customer data without authorization. The workstation is still running, and the employee is currently logged in. The IT team has isolated the machine from the network but has not powered it off. You have been called to perform forensic acquisition. The company policy requires preservation of volatile data and a full disk image. The machine has 16 GB RAM and a 512 GB SSD. You have a forensic toolkit including FTK Imager, win32dd (for memory acquisition), and a write-blocker. Which of the following is the best course of action?

Trap 1: Perform a graceful shutdown via the operating system, then remove…

A graceful shutdown is an active operating-system process that writes a large amount of data to persistent storage: registry hives are flushed, event logs are updated, prefetch and Superfetch files are modified, and filesystem metadata/journal entries are committed. Even though using a hardware write-blocker afterwards ensures the SSD image is forensically sound, the shutdown itself has already contaminated the disk and completely destroyed the contents of RAM, including the very processes, network connections, and memory-resident malware that likely triggered the incident. The correct approach is to image volatile memory first, not to shut down the system cleanly.

Trap 2: Boot the workstation from a forensic live CD, then use 'dd' to…

Booting from a forensic live CD alters the system state before any acquisition begins: the boot process overwrites RAM, the live OS may mount the internal SSD and update volume metadata or journal files, and hardware/firmware state is changed by the BIOS/UEFI. A dd image created after booting from the CD therefore captures only the disk's post-boot state and loses the live memory evidence needed to identify active malware, open ports, and encryption keys. Dead-box imaging with dd and a write-blocker is appropriate only when the system is already powered off; starting from a running system, volatile data must be preserved first.

Trap 3: Immediately shut down the workstation by unplugging the power cord,…

Unplugging the power cord instantly destroys all volatile memory, eliminating every running process, kernel object, network connection, and encryption key, and it may also leave the filesystem in an inconsistent state because pending writes and SSD FTL mappings were never flushed. While removing the SSD and imaging it with a hardware write-blocker on a forensic workstation is a valid method for acquiring a dead disk, that step should occur only after the machine is no longer a live incident-response target. Performing this first reverses the correct order: the memory image must be captured while the system is running, before any power loss.

Study all Computer Forensics Investigation Process common traps →

A
Use win32dd to capture the contents of RAM to an external drive, then use FTK Imager to create a physical image of the SSD over the network to a secure share.
RAM is the most volatile evidence source and holds running processes, open network sockets, decrypted data, cryptographic keys, and injected malware code. Using win32dd first captures this memory to an external drive before further system activity or disk writes can overwrite it; after that, FTK Imager can acquire a physical image of the SSD over the network to a secure share, which minimizes additional writes to the evidentiary drive. This sequence follows the Order of Volatility (RFC 3227) and is the only methodology that preserves both volatile and non-volatile evidence while the system is still running.
B
Perform a graceful shutdown via the operating system, then remove the SSD and image it using a hardware write-blocker.
Why wrong: A graceful shutdown is an active operating-system process that writes a large amount of data to persistent storage: registry hives are flushed, event logs are updated, prefetch and Superfetch files are modified, and filesystem metadata/journal entries are committed. Even though using a hardware write-blocker afterwards ensures the SSD image is forensically sound, the shutdown itself has already contaminated the disk and completely destroyed the contents of RAM, including the very processes, network connections, and memory-resident malware that likely triggered the incident. The correct approach is to image volatile memory first, not to shut down the system cleanly.
C
Boot the workstation from a forensic live CD, then use 'dd' to image the SSD to an external USB drive.
Why wrong: Booting from a forensic live CD alters the system state before any acquisition begins: the boot process overwrites RAM, the live OS may mount the internal SSD and update volume metadata or journal files, and hardware/firmware state is changed by the BIOS/UEFI. A dd image created after booting from the CD therefore captures only the disk's post-boot state and loses the live memory evidence needed to identify active malware, open ports, and encryption keys. Dead-box imaging with dd and a write-blocker is appropriate only when the system is already powered off; starting from a running system, volatile data must be preserved first.
D
Immediately shut down the workstation by unplugging the power cord, remove the SSD, and create a forensic image using a write-blocker on a forensic workstation.
Why wrong: Unplugging the power cord instantly destroys all volatile memory, eliminating every running process, kernel object, network connection, and encryption key, and it may also leave the filesystem in an inconsistent state because pending writes and SSD FTL mappings were never flushed. While removing the SSD and imaging it with a hardware write-blocker on a forensic workstation is a valid method for acquiring a dead disk, that step should occur only after the machine is no longer a live incident-response target. Performing this first reverses the correct order: the memory image must be captured while the system is running, before any power loss.

Full breakdown with real-world context →

Question 6mediumdrag order

Read the full Computer Forensics Investigation Process explanation →

Drag and drop the steps to perform forensic imaging of a hard drive using FTK Imager into the correct order.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

5Step 5

Trap 1: 1

This sequence fails because the destination image settings are configured before the source drive is identified. In FTK Imager's Create Disk Image dialog, the source drive selection dictates critical destination parameters such as segment size recommendations and the expected target volume, so choosing a destination profile without knowing the source's capacity can lead to fragmented evidence images or an undersized/oversized segment configuration. The tool's wizard also presents verification as part of the destination settings, so starting imaging after source selection remains valid only after the image path and type are finalized.

Trap 2: 1

Attempting to enable verification before configuring the destination is not possible because the verification checkbox is embedded within the destination image dialog in FTK Imager, not a standalone pre-step. More critically, launching the imaging process before the destination image type, path, and segment size are specified leaves the tool with no output container definition, resulting in an immediate error or a prompt for missing parameters. The correct sequence is to finalize every destination-related option and then start the capture.

Trap 3: 1

This ordering compounds two procedural errors: it configures both the destination and the verification toggle before selecting the source, which inverts the wizard's dependency chain. FTK Imager builds the evidence item from the source drive first, and only then exposes the destination and verification controls in the Create Disk Image workflow, so source selection is a mandatory prerequisite for meaningful settings. Selecting verification before the source also risks applying a hash algorithm to an uninitialized evidence item, which undermines the integrity check the step is meant to establish.

Study all Computer Forensics Investigation Process common traps →

A
1. Launch FTK Imager and select 'Create Disk Image'. 2. Select the source drive. 3. Configure destination image settings (name, location, segment size, image type). 4. Enable verification and start imaging. 5. Verify image integrity after completion.
This order follows standard forensic imaging procedure: first set up the tool, select the source, configure where and how to save the image, enable hash verification during imaging, and finally verify the hash to ensure integrity.
B
1. Launch FTK Imager and select 'Create Disk Image'. 2. Configure destination image settings. 3. Select the source drive. 4. Enable verification and start imaging. 5. Verify image integrity after completion.
Why wrong: This sequence fails because the destination image settings are configured before the source drive is identified. In FTK Imager's Create Disk Image dialog, the source drive selection dictates critical destination parameters such as segment size recommendations and the expected target volume, so choosing a destination profile without knowing the source's capacity can lead to fragmented evidence images or an undersized/oversized segment configuration. The tool's wizard also presents verification as part of the destination settings, so starting imaging after source selection remains valid only after the image path and type are finalized.
C
1. Launch FTK Imager and select 'Create Disk Image'. 2. Select the source drive. 3. Enable verification. 4. Configure destination image settings. 5. Start imaging. 6. Verify image integrity after completion.
Why wrong: Attempting to enable verification before configuring the destination is not possible because the verification checkbox is embedded within the destination image dialog in FTK Imager, not a standalone pre-step. More critically, launching the imaging process before the destination image type, path, and segment size are specified leaves the tool with no output container definition, resulting in an immediate error or a prompt for missing parameters. The correct sequence is to finalize every destination-related option and then start the capture.
D
1. Launch FTK Imager and select 'Create Disk Image'. 2. Configure destination image settings. 3. Enable verification. 4. Select the source drive. 5. Start imaging. 6. Verify image integrity after completion.
Why wrong: This ordering compounds two procedural errors: it configures both the destination and the verification toggle before selecting the source, which inverts the wizard's dependency chain. FTK Imager builds the evidence item from the source drive first, and only then exposes the destination and verification controls in the Create Disk Image workflow, so source selection is a mandatory prerequisite for meaningful settings. Selecting verification before the source also risks applying a hash algorithm to an uninitialized evidence item, which undermines the integrity check the step is meant to establish.

Full breakdown with real-world context →

Question 7mediumdrag order

Read the full Computer Forensics Investigation Process explanation →

Drag and drop the steps to perform a forensic analysis of a PDF file for hidden data or malicious content into the correct order.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

5Step 5

Trap 1: Step 1: Extract and examine embedded files and JavaScript

This order inverts the static analysis workflow by attempting to extract embedded files and JavaScript before mapping the PDF's object tree. Because PDF components are referenced via indirect object numbers and a cross-reference table, extraction without first parsing the structure will miss objects hidden in compressed object streams or accessed only through malformed or obfuscated references. Attackers frequently bury JavaScript or embedded payloads in streams that require identifying the correct filters (e.g., FlateDecode) and object hierarchy to even decompress. Thus, this sequence yields incomplete extraction, and the later structural parse becomes a redundant confirmation rather than a foundational step.

Trap 2: Step 1: Analyze metadata, annotations, and hidden data

This order is incorrect because metadata analysis should come after structure parsing to ensure all metadata fields are located. Sandbox execution before extracting scripts risks missing script-based behaviors, and extraction after sandbox is out of order for comprehensive analysis.

Trap 3: Step 1: Perform sandbox execution for dynamic analysis

This order is incorrect because dynamic analysis should be performed only after thorough static analysis to understand potential threats. Sandbox execution first may activate malicious code without proper context or safeguards, and subsequent static steps may be compromised.

Study all Computer Forensics Investigation Process common traps →

A
Step 1: Parse PDF structure and identify objects/streams. Step 2: Extract and examine embedded files and JavaScript. Step 3: Analyze metadata, annotations, and hidden data. Step 4: Perform sandbox execution for dynamic analysis.
This order is correct because it follows a logical progression from static analysis to dynamic analysis. First, understanding the structure helps locate embedded objects and scripts. Then extraction and examination of these elements ensures any malicious content is identified before further analysis. Metadata and hidden data analysis then reveals additional context or steganography. Finally, sandbox execution safely tests behavior in a controlled environment.
B
Step 1: Extract and examine embedded files and JavaScript. Step 2: Parse PDF structure and identify objects/streams. Step 3: Analyze metadata, annotations, and hidden data. Step 4: Perform sandbox execution for dynamic analysis.
Why wrong: This order inverts the static analysis workflow by attempting to extract embedded files and JavaScript before mapping the PDF's object tree. Because PDF components are referenced via indirect object numbers and a cross-reference table, extraction without first parsing the structure will miss objects hidden in compressed object streams or accessed only through malformed or obfuscated references. Attackers frequently bury JavaScript or embedded payloads in streams that require identifying the correct filters (e.g., FlateDecode) and object hierarchy to even decompress. Thus, this sequence yields incomplete extraction, and the later structural parse becomes a redundant confirmation rather than a foundational step.
C
Step 1: Analyze metadata, annotations, and hidden data. Step 2: Parse PDF structure and identify objects/streams. Step 3: Perform sandbox execution for dynamic analysis. Step 4: Extract and examine embedded files and JavaScript.
Why wrong: This order is incorrect because metadata analysis should come after structure parsing to ensure all metadata fields are located. Sandbox execution before extracting scripts risks missing script-based behaviors, and extraction after sandbox is out of order for comprehensive analysis.
D
Step 1: Perform sandbox execution for dynamic analysis. Step 2: Parse PDF structure and identify objects/streams. Step 3: Extract and examine embedded files and JavaScript. Step 4: Analyze metadata, annotations, and hidden data.
Why wrong: This order is incorrect because dynamic analysis should be performed only after thorough static analysis to understand potential threats. Sandbox execution first may activate malicious code without proper context or safeguards, and subsequent static steps may be compromised.

Full breakdown with real-world context →

Question 8mediummatching

Read the full Computer Forensics Investigation Process explanation →

Match each forensic tool to its primary purpose.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Acquisition and preview of disk images

Forensic analysis and evidence processing

Memory forensics and analysis

Network packet capture and analysis

Open-source file system analysis

Trap 1: EnCase: Memory forensics and analysis

This assignment is incorrect because EnCase's fundamental domain is disk and evidence acquisition, not RAM analysis. Although modern EnCase versions can capture a memory image or embed basic memory parsing, they lack Volatility's extensive plugin set and deep kernel-object interpretation, which are essential for extracting artifacts from memory dumps. Memory forensics is a specialized discipline requiring tools like Volatility or Rekall, not a general-purpose imaging suite.

Trap 2: FTK: Network packet analysis

This pairing is incorrect because FTK is not designed for network packet capture or protocol-level PCAP analysis. Live network inspection, packet decoding, and stream reassembly are performed by dedicated network forensic tools such as Wireshark or tcpdump. FTK can only analyze network-related artifacts that are already stored as files (e.g., saved network captures or browser history), but its primary analytical engine is oriented toward disk and file content, not raw packet streams.

Study all Computer Forensics Investigation Process common traps →

A
EnCase: Forensic imaging and data acquisition
EnCase Forensic is a commercial suite developed by Guidance Software (now OpenText) whose foundational capability is the acquisition of bit-for-bit forensic images from hard drives, solid-state drives, removable media, and mobile devices. Its proprietary E01 image format embeds per-sector CRC and MD5/SHA-1 hash values to verify data integrity, and it integrates hardware write-blocking workflows to preserve evidence. While EnCase also offers later-stage analysis features, its core identity remains forensic imaging and evidence acquisition for legal proceedings.
B
FTK: In-depth forensic analysis and indexing
The Forensic Toolkit (FTK) from AccessData (now Exterro) is purpose-built for post-acquisition evidence processing and examination. It creates a centralized case database that indexes millions of files with full-text and metadata search, enabling rapid identification of relevant documents, images, and email archives. FTK's advanced filtering, file carving, and registry parsing capabilities make it the go-to tool for in-depth forensic analysis and triage of large data sets, not for initial image capture.
C
Volatility: Memory forensics and analysis
Volatility is an open-source Python framework specifically engineered for random access memory (RAM) analysis. It operates on memory dumps to recover running processes, open network sockets, loaded kernel modules, injected code, and other ephemeral artifacts that vanish when a system powers down. Unlike disk-oriented tools, Volatility parses kernel data structures and uses a plugin architecture (e.g., pslist, malfind, timeliner) to reconstruct system activity from volatile memory, making it the definitive tool for memory forensics.
D
Autopsy: File system and disk analysis
Autopsy is a graphical front-end for The Sleuth Kit (TSK) that focuses on examining disk images and filesystems. It provides a visual interface for analyzing partitions, deleted file recovery, file system metadata (MFT, inodes), and folder hierarchies, with modules for timeline generation and keyword search. Its primary purpose is filesystem and disk-level forensic analysis, complementing tools used for acquisition or memory examination.
E
EnCase: Memory forensics and analysis
Why wrong: This assignment is incorrect because EnCase's fundamental domain is disk and evidence acquisition, not RAM analysis. Although modern EnCase versions can capture a memory image or embed basic memory parsing, they lack Volatility's extensive plugin set and deep kernel-object interpretation, which are essential for extracting artifacts from memory dumps. Memory forensics is a specialized discipline requiring tools like Volatility or Rekall, not a general-purpose imaging suite.
F
FTK: Network packet analysis
Why wrong: This pairing is incorrect because FTK is not designed for network packet capture or protocol-level PCAP analysis. Live network inspection, packet decoding, and stream reassembly are performed by dedicated network forensic tools such as Wireshark or tcpdump. FTK can only analyze network-related artifacts that are already stored as files (e.g., saved network captures or browser history), but its primary analytical engine is oriented toward disk and file content, not raw packet streams.

Full breakdown with real-world context →

Question 9mediummatching

Read the full Computer Forensics Investigation Process explanation →

Match each email forensic artifact to its source.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Message source (RFC 5322 headers)

Microsoft Outlook personal folder

Microsoft Exchange server

Unix-based email clients

Individual email message export

Trap 1: PST: Generic email message file

PST is not a generic email message file; it is a proprietary, container-based format specific to Microsoft Outlook, designed to hold multiple folders and messages in a structured database. A generic email message file is typically EML, which is a single, self-contained text file adhering to RFC 822 standard. Confusing PST with a generic format is a common error; PST's binary structure, encryption, and compression make it fundamentally different from EML or other mail message files.

Trap 2: MBOX: Microsoft Outlook email folder file

MBOX is not a Microsoft Outlook email folder file; it is a mailbox format used by Apple Mail, Mozilla Thunderbird, and several Unix mail agents, storing multiple messages in a single plain-text file. Microsoft Outlook relies on PST or OST files for folder storage, which are binary and proprietary. Using mbox to describe Outlook folders is incorrect, as the mbox format's line-based 'From ' separators and lack of Outlook-specific metadata make it incompatible with Outlook's internal storage model.

Study all Computer Forensics Investigation Process common traps →

A
PST: Microsoft Outlook email folder file
PST (Personal Storage Table) is a proprietary container format used by Microsoft Outlook to store emails, contacts, calendar items, and other folder data in a hierarchical structure. It is not a generic email format but a complex database-like file that preserves the original folder organization, making it a primary forensic artifact when investigating Outlook-based mail clients. The file's structure includes a header, node database, and block allocation, which forensic tools parse to recover deleted items and metadata.
B
EML: Generic email message file
EML is a generic email message format standardized under RFC 822 and MIME, representing a single email message as a plain-text file with headers and body. It is used by various email clients such as Outlook Express, Thunderbird, and Windows Live Mail, and is often the default export format for email clients. Each EML file contains exactly one message, making it an individual artifact that can be easily carved from disk and examined for metadata, attachments, and original headers.
C
MBOX: Apple Mail or Mozilla Thunderbird mailbox
MBOX is a file format that stores a collection of email messages concatenated into a single text file, with each message delimited by a 'From ' line. It is natively used by Apple Mail and Mozilla Thunderbird, as well as many Unix-based mail systems. Forensic examination of MBOX files focuses on identifying message boundaries and parsing the embedded RFC 822 headers to reconstruct user mailboxes and recover deleted or fragmented messages.
D
DBX: Outlook Express email folder
DBX is a proprietary folder file format used by Microsoft Outlook Express to store emails, contacts, and newsgroup messages in a specific folder. Unlike PST, which is used by the full Outlook client, DBX files are associated exclusively with Outlook Express, typically located in the user's 'Identities' directory. Forensic analysis of DBX files requires know-how of their internal structure, which differs significantly from PST and often requires dedicated tools to extract messages and metadata.
E
PST: Generic email message file
Why wrong: PST is not a generic email message file; it is a proprietary, container-based format specific to Microsoft Outlook, designed to hold multiple folders and messages in a structured database. A generic email message file is typically EML, which is a single, self-contained text file adhering to RFC 822 standard. Confusing PST with a generic format is a common error; PST's binary structure, encryption, and compression make it fundamentally different from EML or other mail message files.
F
MBOX: Microsoft Outlook email folder file
Why wrong: MBOX is not a Microsoft Outlook email folder file; it is a mailbox format used by Apple Mail, Mozilla Thunderbird, and several Unix mail agents, storing multiple messages in a single plain-text file. Microsoft Outlook relies on PST or OST files for folder storage, which are binary and proprietary. Using mbox to describe Outlook folders is incorrect, as the mbox format's line-based 'From ' separators and lack of Outlook-specific metadata make it incompatible with Outlook's internal storage model.

Full breakdown with real-world context →

Question 10mediummultiple choice

Read the full Computer Forensics Investigation Process explanation →

An analyst executed the commands shown in the exhibit on a Windows system to prepare a forensic image for analysis. What is the most likely reason for the error message from e2fsck?

Exhibit

Refer to the exhibit.

C:\> fsutil volume dismount C:

C:\> diskpart
DISKPART> select volume 1
DISKPART> attribute volume clear readonly
DISKPART> exit

C:\> e2fsck -fn image.dd

e2fsck 1.45.6 (20-Mar-2020)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
image.dd: ********** WARNING: Filesystem still has errors **********

Trap 1: The forensic image was not acquired with a write-blocker, causing…

The absence of a dedicated hardware write-blocker is a limitation of the acquisition chain, but the command history here shows `diskpart` operations, not the actual imaging utility; there is no evidence that the source drive was written to during acquisition. Corruption from a missing write-blocker would manifest as read errors or altered hash values in the original device, not as filesystem-integrity errors reported by e2fsck from inside the image. The e2fsck findings point to an inconsistency in the filesystem state itself, which is directly explained by an unclean dismount, rather than by external hardware writes.

Trap 2: The image file contains an NTFS filesystem, but e2fsck is designed…

e2fsck is designed for ext-family filesystems, but it does not simply 'work on NTFS'; it first validates the superblock magic number and would immediately terminate with a message like 'Couldn't find a valid filesystem superblock' or 'bad magic number'. The detailed errors about group descriptors, inode bitmaps, or the like are ext-specific structures, so the image must actually contain an ext filesystem that was imaged while inconsistent. Therefore, the problem is not that the tool was run on NTFS; the tool's output itself proves the media is ext-based.

Trap 3: The e2fsck command syntax is incorrect; it should be 'e2fsck -f -n'…

The invocation `e2fsck -fn` is a valid and common shorthand; like `-f -n` it forces the check even if the filesystem is marked clean and opens the filesystem read-only so no changes are made. Combined single-letter switches are standard for e2fsck, so `-fn` is not the reason the check surfaces recoverable inconsistencies. If the analyst had used `-p` or omitted `-n`, the tool might have written repairs, but that would be a separate operational concern, not a syntax error.

Study all Computer Forensics Investigation Process common traps →

A
The analyst failed to properly dismount the source volume before imaging, leading to filesystem inconsistencies.
The sequence shows `fsutil dismount` being run on C:, but a forensic image taken afterward—especially after Windows remounts the volume or during a live acquisition—will capture the volume in an inconsistent state. When Windows later performs recovery on the dirty volume, metadata updates begin immediately, so e2fsck in the analyst's analysis environment will legitimately report superblock, group descriptor, or inode inconsistencies that were never present in the source. This is the classic 'dirty volume' imaging error, not a problem with the image tool.
B
The forensic image was not acquired with a write-blocker, causing data corruption.
Why wrong: The absence of a dedicated hardware write-blocker is a limitation of the acquisition chain, but the command history here shows `diskpart` operations, not the actual imaging utility; there is no evidence that the source drive was written to during acquisition. Corruption from a missing write-blocker would manifest as read errors or altered hash values in the original device, not as filesystem-integrity errors reported by e2fsck from inside the image. The e2fsck findings point to an inconsistency in the filesystem state itself, which is directly explained by an unclean dismount, rather than by external hardware writes.
C
The image file contains an NTFS filesystem, but e2fsck is designed for ext filesystems.
Why wrong: e2fsck is designed for ext-family filesystems, but it does not simply 'work on NTFS'; it first validates the superblock magic number and would immediately terminate with a message like 'Couldn't find a valid filesystem superblock' or 'bad magic number'. The detailed errors about group descriptors, inode bitmaps, or the like are ext-specific structures, so the image must actually contain an ext filesystem that was imaged while inconsistent. Therefore, the problem is not that the tool was run on NTFS; the tool's output itself proves the media is ext-based.
D
The e2fsck command syntax is incorrect; it should be 'e2fsck -f -n' instead.
Why wrong: The invocation `e2fsck -fn` is a valid and common shorthand; like `-f -n` it forces the check even if the filesystem is marked clean and opens the filesystem read-only so no changes are made. Combined single-letter switches are standard for e2fsck, so `-fn` is not the reason the check surfaces recoverable inconsistencies. If the analyst had used `-p` or omitted `-n`, the tool might have written repairs, but that would be a separate operational concern, not a syntax error.

Full breakdown with real-world context →

Continue with 20-question session →

Free account

Track your progress over time

Create a free account to save your results and see which topics improve across sessions.

Focused Computer Forensics Investigation Process sessions

Start a Computer Forensics Investigation Process only practice session

Every question in these sessions is drawn from the Computer Forensics Investigation Process domain — nothing else.

10 questions 20 questions 30 questions 50 questions

Browse all Computer Forensics Investigation Process questions →Mixed CHFI session

Frequently asked questions

What does the CHFI exam test about Computer Forensics Investigation Process?: Computer Forensics Investigation Process questions test whether you can apply the concept in context, not just recognise a definition.
How should I use these practice questions?: Select your answer before revealing the explanation. Then read why each option is right or wrong — this active recall approach builds retention far faster than re-reading notes.
Can I practise just Computer Forensics Investigation Process questions in a focused session?: Yes — the session launcher on this page draws every question from the Computer Forensics Investigation Process domain. Use a 10-question session first to gauge your baseline, then move to 20 or 30 once the weak spots are clear.
Where can I practise other CHFI topics?: Use the topic links above to move to related areas, or go back to the CHFI question bank to see all topics.
Are these real exam questions or dumps?: These are original practice questions written to test the same concepts the CHFI exam covers. They are not copied from any real exam or dump site.

Computer Forensics Investigation Process only

10 questions 20 questions 30 questions 50 questions

Mixed CHFI session

Track your progress

A free account saves results across sessions and highlights which topics need work.

Study resources

All CHFI questions Computer Forensics Investigation Process domain overview CHFI exam guide

Exam traps to avoid

▸Answering from memory before reading the full scenario.
▸Missing a constraint such as cost, availability, security, scope or command context.
▸Choosing a broad answer when the question asks for the most specific fix.
▸Ignoring why the wrong options are tempting.

Computer Forensics Investigation Process practice questions

What to know about Computer Forensics Investigation Process

Common Computer Forensics Investigation Process exam traps

Computer Forensics Investigation Process questions

During a forensic investigation, an analyst discovers that the suspect's hard drive was encrypted using BitLocker. The analyst has obtained the recovery key. Which of the following is the best next step to ensure data integrity?

A CHFI analyst is called to investigate a suspected data breach. The IT team has already shut down the server. Which of the following is the most appropriate order of actions to preserve evidence?

An incident responder has acquired a forensic image of a Linux server suspected of being compromised. The image was taken using 'dd' with no compression. The analyst needs to verify the integrity of the image. Which command should be used and what should be compared?

Which TWO of the following are considered essential steps in the computer forensics investigation process according to EC-Council guidelines?

Drag and drop the steps to perform forensic imaging of a hard drive using FTK Imager into the correct order.

Drag and drop the steps to perform a forensic analysis of a PDF file for hidden data or malicious content into the correct order.

Match each forensic tool to its primary purpose.

Match each email forensic artifact to its source.

An analyst executed the commands shown in the exhibit on a Windows system to prepare a forensic image for analysis. What is the most likely reason for the error message from e2fsck?

Exhibit

Track your progress over time

Start a Computer Forensics Investigation Process only practice session

Related CHFI topic practice pages