SOA-C02 Monitoring, Logging, and Remediation 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.

• ✗

  Use the AWS CLI to periodically upload the log file using the put-log-events command.

  Why it's wrong here

  Using the AWS CLI to periodically run put-log-events against a log file requires a custom cron job or scheduler that tracks file offsets, handles batching, and manages sequence tokens for each log stream. This approach is inherently not near real-time because the upload only occurs on the schedule you configure, introducing latency that can grow arbitrarily large between runs. Furthermore, if the application writes to the same log stream concurrently, the CLI will need to handle `InvalidSequenceTokenException` and retries, adding operational complexity that the CloudWatch Logs agent avoids by continuously tailing the file.

• ✓

  Install the CloudWatch Logs agent on the instance and configure it to tail the log file.

  Why this is correct

  The CloudWatch Logs agent (or the newer unified CloudWatch agent) runs as a daemon on the EC2 instance and uses the `tail` mechanism to monitor the specified log file, each time a new log line is written it is picked up and pushed to CloudWatch Logs in near real time. The agent manages checkpointing, so if the process restarts it can resume from the last-read position without re-sending old lines or losing new ones, and it also handles batching and `put-log-events` calls to the CloudWatch Logs API automatically. This is the purpose-built solution for streaming application logs to CloudWatch and is the correct choice for a near real-time requirement.

• ✗

  Install the Amazon Kinesis Agent on the instance and configure it to send logs to CloudWatch Logs.

  Why it's wrong here

  The Amazon Kinesis Agent is a different tool intended to ingest logs into Amazon Kinesis Data Streams (or Kinesis Data Firehose), not directly to CloudWatch Logs. While the Kinesis Agent can be configured with a `cloudwatchLogs` destination in certain configurations, it actually requires an intermediate Kinesis Data Stream or Firehose and does not natively push to CloudWatch Logs without additional resources. This means you would need to set up a Kinesis stream, a consumer (like a Lambda or KCL application) to read the log records, and then forward them to CloudWatch Logs — adding unnecessary infrastructure, cost, and operational overhead compared to directly using the CloudWatch Logs agent.

• ✗

  Configure the application to write logs to an S3 bucket and use S3 Event Notifications to trigger a Lambda function that puts logs to CloudWatch.

  Why it's wrong here

  Having the application write to an S3 bucket and using S3 Event Notifications to invoke a Lambda that puts logs to CloudWatch Logs introduces multiple sources of latency: the application must write to S3, the event notification must be generated and delivered, the Lambda must be cold-started or warmed, and then it must parse and call `PutLogEvents`. This architecture is also more complex because you need IAM roles for the application to write to S3 and for Lambda to subscribe to the bucket and access CloudWatch Logs, and you must manage the S3 lifecycle and event configurations. It is designed for infrequent or large-scale batch processing, not for streaming logs in near real time, so it does not meet the low-latency requirement.

Go deeper

Related to this question