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.

This domain covers the forensic investigation process: securing a scene, preserving volatile and non-volatile evidence, maintaining chain of custody, preparing a forensic workstation with write blockers, and acquiring images. Questions present realistic scenarios where you must choose the correct sequence of actions or interpret tool output on Windows and Linux systems.

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.

Editorial oversight:Johnson Ajibi· MSc IT Security, IEEE Senior Member

13 questionsDomain: Computer Forensics Investigation Process

Practice 10 questions Browse domain →

What the exam tests

What to know about Computer Forensics Investigation Process

You must be able to order evidence preservation steps correctly, validate a write blocker, and acquire a forensic image without altering the source. The single most important thing is to preserve volatile data first and maintain chain of custody throughout.

Order of volatility and correct evidence collection sequence for Windows and Linux systems

Use of hardware write blockers and validation before imaging USB or hard drives

Forensic imaging commands such as dd, dcfldd, FTK Imager, and EnCase

BitLocker recovery key usage and post-acquisition decryption of encrypted drives

Watch out for

Common Computer Forensics Investigation Process exam traps

▸Shutting down or rebooting a system before capturing volatile data, destroying RAM, network connections, and running processes.
▸Connecting a suspect drive without a verified write blocker, risking accidental modification of evidence.
▸Misinterpreting e2fsck errors on a Windows system when the tool is meant for Linux ext2/3/4 filesystems.

Practice set

Computer Forensics Investigation Process questions

13 questions · select your answer, then reveal the explanation

Question 1hardmultiple 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 it fails: 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 it fails: 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 it fails: 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 2mediummulti 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 it fails: 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 it fails: 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 it fails: 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 3hardmultiple 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 it fails: 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 it fails: 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 it fails: 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 4mediumdrag 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 or tap steps into the slots.

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 it fails: 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 it fails: 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 it fails: 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 5mediumdrag 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 or tap steps into the slots.

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 it fails: 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 it fails: 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 it fails: 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 6mediummatching

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 it fails: 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 it fails: 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 7mediummatching

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 it fails: 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 it fails: 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 8hardmulti select

Read the full Computer Forensics Investigation Process explanation →

A CHFI analyst is conducting a forensic investigation on a Windows 10 system suspected of unauthorized access. The analyst has created a forensic image and is now analyzing it. Which two of the following actions are appropriate to maintain the integrity of the evidence during analysis? (Choose two.)

Trap 1: Make a working copy of the forensic image and perform analysis on…

Making a working copy of the forensic image is not necessary and could introduce errors. The forensic image itself is a bit-for-bit copy and can be analyzed directly. Creating additional copies increases the risk of accidental modification. The original forensic image should be preserved, and analysis can be done on it or on a verified duplicate, but it's not a required step for integrity.

Trap 2: Enable system restore on the forensic workstation to revert any…

System restore on the forensic workstation does not protect the evidence. It could interfere with forensic tools and introduce inconsistencies. The workstation should be configured to prevent writes to evidence drives, but system restore is not a substitute for proper procedures. It may also create unwanted artifacts.

Trap 3: Use a write-blocker when connecting the original drive to the…

While write-blockers are used during acquisition, they are not needed when analyzing a forensic image. The image is a copy, and analysis is performed on it. Connecting the original drive for analysis is unnecessary and risky. The original should be stored securely. Write-blockers are for acquisition from original media.

Study all Computer Forensics Investigation Process common traps →

A
Document the chain of custody for the original drive and the forensic image.
Chain of custody documentation is essential to prove evidence integrity and admissibility in court. It records who handled the evidence, when, and why. This applies to both the original drive and the forensic image. Without proper documentation, the evidence could be challenged. It is a critical step in the forensic process.
B
Work only on the forensic image, never on the original drive.
Analyzing the forensic image ensures the original drive remains untouched and preserved as evidence. Any analysis on the original could alter metadata or data, compromising its admissibility. Working on the image allows for repeated examinations without risk. This is a fundamental principle of computer forensics.
C
Make a working copy of the forensic image and perform analysis on that copy.
Why it fails: Making a working copy of the forensic image is not necessary and could introduce errors. The forensic image itself is a bit-for-bit copy and can be analyzed directly. Creating additional copies increases the risk of accidental modification. The original forensic image should be preserved, and analysis can be done on it or on a verified duplicate, but it's not a required step for integrity.
D
Enable system restore on the forensic workstation to revert any accidental changes.
Why it fails: System restore on the forensic workstation does not protect the evidence. It could interfere with forensic tools and introduce inconsistencies. The workstation should be configured to prevent writes to evidence drives, but system restore is not a substitute for proper procedures. It may also create unwanted artifacts.
E
Use a write-blocker when connecting the original drive to the forensic workstation for analysis.
Why it fails: While write-blockers are used during acquisition, they are not needed when analyzing a forensic image. The image is a copy, and analysis is performed on it. Connecting the original drive for analysis is unnecessary and risky. The original should be stored securely. Write-blockers are for acquisition from original media.

Full breakdown with real-world context →

Question 9easymultiple 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 it fails: 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 it fails: 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 it fails: 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 10mediummultiple 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 it fails: 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 it fails: 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 it fails: 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 11mediummultiple 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 it fails: 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 it fails: 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 it fails: 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 →

Question 12mediummultiple choice

Read the full Computer Forensics Investigation Process explanation →

A CHFI analyst is preparing a forensic workstation to image a suspect's USB flash drive. The analyst needs to ensure that the write-blocker is functioning correctly before connecting the drive. Which of the following is the most appropriate method to verify that the write-blocker is preventing write operations?

Trap 1: Connect the suspect's USB drive directly to the forensic…

Connecting the suspect's drive directly violates forensic principles by potentially altering evidence. Writing a test file to the suspect's drive would modify the evidence and could destroy data. The write-blocker is essential to prevent such modifications. This method is unsafe and unprofessional.

Trap 2: Use a software write-blocker on the forensic workstation instead of…

Software write-blockers can be less reliable than hardware ones and may be bypassed by certain operations. The scenario already involves a hardware write-blocker, and the analyst needs to verify it. Switching to software does not address the verification need and could introduce risk. Additionally, software blockers are not inherently more reliable.

Trap 3: Check the write-blocker's LED indicators; if the power light is on…

LED indicators only show power and switch position, not actual write-blocking behavior. A faulty write-blocker could still show correct lights. Relying solely on indicators does not confirm that writes are physically blocked. The analyst must perform a functional test to ensure integrity of the evidence.

Study all Computer Forensics Investigation Process common traps →

A
Connect the suspect's USB drive directly to the forensic workstation and attempt to write a test file; if the write succeeds, the write-blocker is not needed.
Why it fails: Connecting the suspect's drive directly violates forensic principles by potentially altering evidence. Writing a test file to the suspect's drive would modify the evidence and could destroy data. The write-blocker is essential to prevent such modifications. This method is unsafe and unprofessional.
B
Connect the write-blocker to the forensic workstation, then use a known clean USB drive and attempt to write a file to it; if the write fails, the write-blocker is working.
This method directly tests the write-blocker's function by attempting a write operation to a known clean drive. If the write is blocked, it confirms the write-blocker is operational. It is safe because the drive is not evidence, and the test does not alter the original evidence. This is a standard validation procedure recommended in forensics.
C
Use a software write-blocker on the forensic workstation instead of a hardware write-blocker, as software blockers are more reliable and do not require validation.
Why it fails: Software write-blockers can be less reliable than hardware ones and may be bypassed by certain operations. The scenario already involves a hardware write-blocker, and the analyst needs to verify it. Switching to software does not address the verification need and could introduce risk. Additionally, software blockers are not inherently more reliable.
D
Check the write-blocker's LED indicators; if the power light is on and the read/write switch is set to read-only, the write-blocker is functioning correctly.
Why it fails: LED indicators only show power and switch position, not actual write-blocking behavior. A faulty write-blocker could still show correct lights. Relying solely on indicators does not confirm that writes are physically blocked. The analyst must perform a functional test to ensure integrity of the evidence.

Full breakdown with real-world context →

Question 13easymultiple choice

Read the full Computer Forensics Investigation Process explanation →

A CHFI analyst is called to investigate a suspected insider threat. The suspect's laptop is turned on and logged in. The analyst needs to capture volatile data before shutting it down. Which of the following should the analyst capture first?

Trap 1: The contents of the hard drive

The hard drive is non-volatile and retains data even when powered off. It can be imaged later without loss. Capturing it first would delay securing volatile data like RAM, which is time-sensitive. The order of volatility dictates that RAM should be captured before the hard drive.

Trap 2: The web browser cache

Browser cache is stored on the hard drive and is non-volatile. It may contain useful artifacts, but it is not as time-sensitive as RAM. Capturing it first would ignore the order of volatility. RAM should be captured before any disk-based data.

Trap 3: The system event logs

Event logs are stored on the hard drive and are non-volatile. While important, they are not as volatile as RAM. They can be collected after memory capture. Prioritizing logs over RAM could result in loss of critical volatile evidence.

Study all Computer Forensics Investigation Process common traps →

A
The contents of the RAM
RAM contains volatile data such as running processes, network connections, and encryption keys, which are lost when the system is powered off. Capturing RAM first preserves this critical evidence. It is the most volatile and should be prioritized. Tools like FTK Imager or Volatility can be used for memory capture.
B
The contents of the hard drive
Why it fails: The hard drive is non-volatile and retains data even when powered off. It can be imaged later without loss. Capturing it first would delay securing volatile data like RAM, which is time-sensitive. The order of volatility dictates that RAM should be captured before the hard drive.
C
The web browser cache
Why it fails: Browser cache is stored on the hard drive and is non-volatile. It may contain useful artifacts, but it is not as time-sensitive as RAM. Capturing it first would ignore the order of volatility. RAM should be captured before any disk-based data.
D
The system event logs
Why it fails: Event logs are stored on the hard drive and are non-volatile. While important, they are not as volatile as RAM. They can be collected after memory capture. Prioritizing logs over RAM could result in loss of critical volatile evidence.

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?: You must be able to order evidence preservation steps correctly, validate a write blocker, and acquire a forensic image without altering the source. The single most important thing is to preserve volatile data first and maintain chain of custody throughout.
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

▸Shutting down or rebooting a system before capturing volatile data, destroying RAM, network connections, and running processes.
▸Connecting a suspect drive without a verified write blocker, risking accidental modification of evidence.
▸Misinterpreting e2fsck errors on a Windows system when the tool is meant for Linux ext2/3/4 filesystems.

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

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.

A CHFI analyst is conducting a forensic investigation on a Windows 10 system suspected of unauthorized access. The analyst has created a forensic image and is now analyzing it. Which two of the following actions are appropriate to maintain the integrity of the evidence during analysis? (Choose two.)

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 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

A CHFI analyst is called to investigate a suspected insider threat. The suspect's laptop is turned on and logged in. The analyst needs to capture volatile data before shutting it down. Which of the following should the analyst capture first?

Track your progress over time

Start a Computer Forensics Investigation Process only practice session

Related CHFI topic practice pages