DOP-C02 Monitoring and Logging 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.

• ✓

  Create a CloudWatch Logs metric filter to count occurrences of specific error codes and create an alarm

  Why this is correct

  A CloudWatch Logs metric filter continuously scans new log events as they arrive in the log group and increments a custom metric whenever a pattern such as 'ERROR' or a specific error code appears. This metric can then drive a CloudWatch alarm with an associated SNS topic, providing a near-real-time notification without building any separate ingestion pipeline. Metric filters are the native, low-latency mechanism for monitoring textual patterns in logs.

• ✗

  Use Amazon Kinesis Data Analytics to analyze logs in real-time and send alerts

  Why it's wrong here

  Amazon Kinesis Data Analytics would require you to set up a Kinesis Data Stream or Firehose to feed logs, then write SQL or Flink applications to extract error codes, and finally publish results to a destination for alerts. This introduces provisioning, buffering, and operational overhead that is unnecessary when CloudWatch Logs metric filters already perform pattern matching directly on the log stream. For simple error-count thresholds, the cost and complexity of a streaming analytics pipeline cannot be justified.

• ✗

  Enable AWS CloudTrail to log the application's API calls

  Why it's wrong here

  AWS CloudTrail records management events and data events for AWS API calls made by principals against AWS services; it does not capture stdout, stderr, or json logs emitted by an application running inside an ECS container. Application-level logs are typically shipped to CloudWatch Logs using the awslogs log driver in the ECS task definition, so CloudTrail would neither see nor analyze the error codes the application writes. Enabling CloudTrail would not satisfy the alerting requirement and would only produce unrelated API activity records.

• ✗

  Stream logs to Amazon S3 via Amazon Kinesis Data Firehose and use S3 event notifications to trigger alerts

  Why it's wrong here

  Streaming logs with Amazon Kinesis Data Firehose to Amazon S3 introduces an inherent buffer interval (for example, 60 seconds or up to 128 MB per object) before objects are delivered, and S3 event notifications fire only after that object lands, making alerts significantly less immediate than a native metric filter. Additionally, you would need an S3 event notification to trigger an AWS Lambda function that reads the object, scans for error codes, and publishes an alarm, creating extra components and potential failure points. For near-real-time error alerting, a CloudWatch Logs metric filter is both simpler and faster.

• ✓

  Configure a CloudWatch Logs retention policy to keep logs for 5 years

  Why this is correct

  A CloudWatch Logs retention policy — such as keeping logs for 5 years — ensures that log data is automatically stored, encrypted, and not expired for the mandated period, which is essential for compliance or auditability. However, a retention policy is a passive storage setting; it does not evaluate the content of the logs and therefore cannot generate alerts when error codes appear. It should be configured for compliance reasons, but it must be paired with a metric filter and alarm to achieve real-time monitoring.

Go deeper

Related to this question