DOP-C02 Monitoring and Logging Practice Question
Your company runs a multi-tier web application on AWS. The application consists of an Application Load Balancer (ALB) that distributes traffic to a fleet of Amazon EC2 instances running a web server. The web servers write access logs to a shared Amazon EFS filesystem. The operations team needs to monitor the web server logs in real-time to detect and alert on 5xx error spikes. Currently, the team manually SSHes into instances to tail logs, which is inefficient and doesn't provide real-time alerting. The team wants a centralized, near-real-time logging solution with minimal operational overhead. They have asked you to design a solution that ingests logs from the EFS filesystem into a centralized log analytics platform. Which solution would you recommend?
⚠ Common exam trap
The trap here is that candidates may overcomplicate the solution by choosing Kinesis or Lambda-based approaches (Options B and C) when a simple agent-based solution (Option D) is sufficient, or they may confuse CloudTrail data events (Option A) with log file monitoring, not realizing CloudTrail captures API activity, not file content changes.
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
✓
Install and configure the Amazon CloudWatch Logs agent on each EC2 instance to tail the log files from the EFS mount and send them to CloudWatch Logs. Create a metric filter and alarm for 5xx errors.
Installing the CloudWatch Logs agent on each EC2 instance allows it to tail the log files from the shared EFS mount point and stream them to CloudWatch Logs in near real-time. This provides centralized log ingestion with minimal operational overhead, and you can create a metric filter and alarm to detect and alert on 5xx error spikes without manual SSH access.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Enable AWS CloudTrail data events for the EC2 instances to capture log file modifications.
Why it's wrong here
AWS CloudTrail records API activity across AWS services, not operating system level file modifications on EC2 instances or Amazon EFS filesystems. The application writes ASCII log lines directly to an EFS mount, and CloudTrail data events are not supported for EC2 instance storage or EFS file content changes. Even if enabled, CloudTrail would only show PutObject-style calls to S3, not the file writes performed by the web application, so it cannot extract 5xx error patterns.
- ✗
Configure an Amazon EventBridge scheduled rule to invoke an AWS Lambda function that reads new log lines from EFS and publishes them to Amazon CloudWatch Logs.
Why it's wrong here
This pattern uses a scheduled EventBridge rule to trigger a Lambda function at fixed intervals, but the Lambda would need the EFS filesystem mounted and must track a file offset across invocations to find only new log lines. Polling every minute (or longer) is not near-real-time, and the state management for 'new lines' is error-prone if log rotation occurs. The CloudWatch agent's tailing mechanism handles file rotation and sends data as it is written, eliminating the need for custom state.
- ✗
Stream the log files to Amazon Kinesis Data Streams using a custom producer, then use a Lambda function to analyze and alert on 5xx errors.
Why it's wrong here
Injecting a Kinesis custom producer onto each EC2 instance requires writing, packaging, and maintaining an agent to read the EFS log file, serialize records, and put them into a stream, and then a Lambda consumer must emit metrics. This replicates the functionality of the CloudWatch Logs agent while adding shard provisioning, data retention tuning, and an extra event-driven pipeline to debug. The operational burden is higher for the same outcome: near-real-time ingestion and alerting on 5xx errors.
- ✓
Install and configure the Amazon CloudWatch Logs agent on each EC2 instance to tail the log files from the EFS mount and send them to CloudWatch Logs. Create a metric filter and alarm for 5xx errors.
Why this is correct
The Amazon CloudWatch Logs agent (now part of the unified CloudWatch agent) can be installed on each EC2 instance to monitor the EFS-mounted log file and push new lines to CloudWatch Logs in near-real-time. After the log group receives the entries, a metric filter can extract the '5xx' HTTP status code pattern to create a custom metric, and a CloudWatch alarm on that metric will page the team when the error rate breaches a threshold. This is the purpose-built, low-overhead solution that supports tailing, rotation, and automatic delivery.
Visual reference
Go deeper
Related to this question
About these practice questions
One of 251 original DOP-C02 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This DOP-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 DOP-C02 exam.