Courseiva
Threat Detection and Incident ResponsehardMultiple ChoiceObjective-mapped

SCS-C02 Threat Detection and Incident Response Practice Question

A security engineer is designing an incident response plan for a containerized application running on Amazon ECS with Fargate. The engineer needs to ensure that if a container is compromised, the incident response team can capture a memory dump and disk snapshot for forensic analysis. The containers are stateless and use ephemeral storage. Which approach provides the necessary forensic data?

⚠ Common exam trap

Many candidates assume stopping the task (Option D) is safe because containers are stateless, but they overlook that forensic data (memory and ephemeral disk) is lost upon task termination, making live capture via ECS Exec (Option C) the only viable method.

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

Use ECS Exec to access the container and capture a memory dump; snapshot the task's ephemeral storage.

ECS Exec allows interactive access to a running container without stopping it, enabling the capture of a memory dump (e.g., via `gcore` or `/proc/kcore`). Additionally, the task's ephemeral storage can be snapshotted while the container is still running, preserving disk state for forensic analysis. This approach aligns with incident response best practices for stateless containers on Fargate, where traditional host-level forensics are unavailable.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • Configure the container to stream /dev/mem to CloudWatch Logs.

    Why it's wrong here

    /dev/mem is a raw character device that maps physical memory, but inside an ECS container it is not exposed without host-level privileges and a privileged container. CloudWatch Logs is designed to ingest structured text log streams, not binary memory images, and the standard CloudWatch agent cannot read kernel memory devices. Even if you captured memory, you would need to write it to a file for analysis, not stream it directly to a log service.

  • Enable ECS task memory dumps to CloudWatch Logs.

    Why it's wrong here

    Amazon ECS does not provide any native capability to generate or capture a memory dump of a running task; the service manages the container lifecycle but does not expose debug interfaces for memory snapshots. CloudWatch Logs is meant for application and container log output, typically stdout/stderr, and cannot receive a raw memory image as a log event. You would need to build your own memory acquisition mechanism inside the container, not rely on an 'ECS task memory dump' option that does not exist.

  • Use ECS Exec to access the container and capture a memory dump; snapshot the task's ephemeral storage.

    Why this is correct

    ECS Exec uses the ExecuteCommand API to open an interactive shell in a running container without opening inbound ports, allowing you to run forensic utilities like 'dd' or 'gcore' to capture volatile memory from inside the container's PID namespace. Before the task is stopped, you can also snapshot the task's ephemeral storage by copying files to an external volume or using an EBS-optimized instance to preserve the disk state. This preserves both volatile and persistent evidence, unlike stopping the task first.

  • Stop the task and create a new task from the same image.

    Why it's wrong here

    Stopping the task sends a SIGTERM to the container, which terminates all processes and deallocates the container's ephemeral storage, permanently losing any in-memory data and the filesystem state that could be forensic evidence. Creating a new task from the same image only deploys a fresh, clean container; it does not capture or preserve anything from the original task. The proper response is to preserve the current state before taking action, not kill it and recreate a pristine replacement.

About these practice questions

Courseiva writes every SCS-C02 question from scratch — 376 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 →

How Courseiva writes practice questions · Editorial policy

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

This SCS-C02 practice question is part of Courseiva's free Amazon Web Services 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 SCS-C02 exam.