CHFI Application, Email and Cloud Forensics Practice Question
Which THREE of the following are challenges specific to container forensics?
⚠ Common exam trap
A common misconception in CHFI is that containers are completely un-imageable with standard tools, but in reality, `docker export` and `docker save` produce standard archives that can be ingested by forensic suites.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Ephemeral nature of containers: containers are often short-lived and can be deleted quickly
Option A is correct because containers are frequently ephemeral—they can be stopped, deleted, or replaced in seconds—so volatile evidence such as running processes, memory, and writable layer data may disappear before acquisition, making timely capture critical. Option D is correct because a container image is built from stacked layers (e.g., in OCI/Docker format), and each layer may contain distinct artifacts, deleted files, or modifications, so investigators must analyze every layer rather than just the final filesystem view. Option E is correct because containers share the host's kernel via namespaces and cgroups rather than running their own kernel, so kernel-level artifacts (e.g., kernel modules, some syscalls, and host-level kernel logs) are not isolated within the container and must be examined on the host instead. Option B is not correct because containers and their images can be imaged or exported using standard tools such as docker export, docker save, or dd on the underlying storage, so this is not an inherent limitation. Option C is not correct because container logs are not always centralized; by default they are stored locally on the host (e.g., under /var/lib/docker/containers or via the configured logging driver), and centralization only occurs if a logging driver or aggregation system is explicitly configured.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Ephemeral nature of containers: containers are often short-lived and can be deleted quickly
Why this is correct
Containers are designed to be short-lived and disposable, often existing for seconds or minutes during automated builds, batch jobs, or scaled-out microservices. Unlike VMs that persist as files on disk, a container's writable layer is typically deleted when the container stops, so forensic acquisition must occur live or immediately after the incident before the container is removed by orchestrators or cleanup daemons. Even the container ID, PID, and filesystem may vanish, making time-sensitive triage critical.
- ✗
Containers cannot be imaged using standard forensic tools
Why it's wrong here
The claim is false because a container's filesystem is just an extractable directory tree. When you run a container, you can capture its state using 'docker export' to produce a tar archive of the root filesystem, or 'docker commit' to create a new image from the current container. Alternatively, standard disk-imaging tools like 'dd' or 'dcfldd' can be applied to block devices backing container volumes, and the resulting images can be mounted with FUSE-based tools or inspected with traditional forensic suites such as Autopsy or FTK.
- ✗
Container logs are always stored in a centralized location
Why it's wrong here
In default Docker configurations, logs are written to local JSON-file files on the host under /var/lib/docker/containers/<container-id>/, not to a central log aggregator. If the container is deleted, these local log files are typically removed, losing the evidence unless a logging driver like syslog, journald, awslogs, or fluentd is explicitly configured to forward the data. Thus, assuming centralized log storage can leave an investigator empty-handed.
- ✓
Multiple layers in a container image require analysis of each layer for forensic artifacts
Why this is correct
A container image is composed of multiple read-only layers, and each layer must be extracted and examined for forensic artifacts such as embedded credentials, trojanized binaries, or remnants of previous builds. The writable layer only captures changes made during the container's lifetime, but deleted files, modified libraries, or historical configuration may remain present in the lower layers. Tools like 'docker save' or 'skopeo' preserve the layer tarballs, and each should be hashed and analyzed individually to avoid missing malware hidden in an earlier build step.
- ✓
Containers share the host kernel, so kernel-level artifacts are not available
Why this is correct
Containers do not have their own kernel; all containers on a host share the kernel of the host operating system. As a result, kernel-level memory forensics—such as Volatility's linux_pslist or linux_memmap—reveals host-wide artifacts and cannot isolate container-specific kernel structures or network namespaces. Investigators inside a container cannot access /dev/mem or /proc/kcore for memory acquisition because capabilities are restricted, so kernel-level evasion techniques or rootkits deployed by a compromised container actually affect the host kernel and must be investigated at the host level, not from within the container.
Go deeper
Related to this question
About these practice questions
Courseiva writes every CHFI question from scratch — 745 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CHFI practice question is part of Courseiva's free EC-Council certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CHFI exam.