DOP-C02 Incident and Event Response Practice Question

Answer analysis

Option-by-option breakdown

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

• ✗

  Install the CloudWatch Agent in each container.

  Why it's wrong here

  Installing the CloudWatch Agent inside each container adds operational overhead by requiring custom container images with the agent pre-installed, whereas the correct approach uses the `awslogs` log driver built into the ECS task definition to stream stdout and stderr directly without modifying the application image. This option is tempting because the CloudWatch Agent is the standard method for collecting logs from EC2 instances or on-premises servers, and it would be the correct choice if the application ran on a standalone server rather than within an ECS-managed container environment.

• ✗

  Configure AWS CloudTrail to capture logs.

  Why it's wrong here

  AWS CloudTrail is an auditing service that records management events and data plane API calls made on your AWS account, such as creating an ECS service or modifying a security group. It does not capture application-generated logs, container stdout, or runtime output from tasks. Even with CloudTrail data events enabled, it only logs object-level operations for S3 or Lambda functions, not the content of application log streams. Therefore, it cannot help diagnose why an ECS application intermittently fails.

• ✓

  Use the awslogs log driver in the task definition.

  Why this is correct

  The `awslogs` log driver, configured under the `logConfiguration` element in the ECS task definition, makes Docker send the container's `stdout` and `stderr` directly to a specified CloudWatch Logs group and stream. The ECS agent automatically creates log streams, and you can set `awslogs-group`, `awslogs-region`, and `awslogs-stream-prefix`; the task execution role must have `logs:CreateLogStream` and `logs:PutLogEvents` permissions. This approach requires no changes to the application image, works on both Fargate and EC2 launch types, and provides near-real-time access to logs through the CloudWatch console, CLI, or APIs. It is the native, recommended method for centralizing ECS container logs.

• ✗

  Write logs to a file and use an S3 bucket with event notifications.

  Why it's wrong here

  Writing logs to a file and then uploading to S3 with event notifications adds several moving parts: you must modify the application to persist logs to a file (or run a sidecar agent), ship that file to S3 on a schedule, and then rely on an S3 `s3:ObjectCreated` event to trigger a downstream process such as Lambda or Step Functions to read the object. This design is brittle because it introduces significant latency between log emission and retrieval, lacks real-time streaming or structured querying via CloudWatch Logs Insights, and incurs extra storage and compute costs. Additionally, S3 event notifications only tell you that an object was written; they do not ingest the log content into any searchable log management system. Compared to the native `awslogs` driver, this is an indirect, inefficient, and operationally complex solution.

Go deeper

Related to this question