An application runs on Amazon EC2 instances that are in an Auto Scaling group. A SysOps administrator needs to implement a solution that provides a central storage location for errors that the…

Question

Options

• ADeploy and configure the Amazon CloudWatch agent on the EC2 instances to log to a
• BCreate a cron job on the EC2 instances to identify errors and push the errors to an Amazon
• CDeploy an AWS Lambda function that pushes the errors directly to Amazon CloudWatch Logs.
• DCreate an Auto Scaling lifecycle hook that invokes an EC2 based script to identify errors.

• A
  78% (42)
• B
  6% (3)
• C
  13% (7)
• D
  4% (2)

Explanation

Option A is correct because the CloudWatch agent can be deployed on EC2 instances to stream application log files directly to CloudWatch Logs, which serves as a central, durable storage location - and CloudWatch Metric Filters can then trigger alarms and SNS alerts whenever an error pattern is matched.

Why the distractors fail:

• B - A cron job pushing errors to some destination is fragile, non-native, and the question cuts off the destination (likely SNS or S3), but neither provides the central logging + alerting combination as natively as CloudWatch Logs.
• C - Lambda cannot proactively "pull" errors from disk on EC2 instances; it would need a trigger mechanism, and there's no agent collecting logs in the first place - this inverts the architecture.
• D - Lifecycle hooks fire on scaling events (launch/terminate), not on application errors at runtime, so this solves the wrong problem entirely.

Memory tip: Think "CloudWatch agent = the bridge between EC2 disk logs and CloudWatch Logs." Whenever a question mentions EC2 logs + central storage + alerting, the CloudWatch agent + CloudWatch Logs + Metric Filter/Alarm trio is the canonical AWS answer.

No community discussion yet for this question.