Task 4.1: Configure the collection, aggregation, and storage of logs and metrics.

• AAssociate the customer managed KMS key with each log group, after allowing the CloudWatch Logs service principal to use the key in its key policy

  Correct

  Encryption with AWS KMS is turned on per log group by associating a KMS key, and the key policy must give the CloudWatch Logs service principal permission to use the key.

• BSet the retention of each log group to 400 days

  Correct

  400 days is one of the allowed retention values, and data older than the retention setting is deleted automatically.

• CExport the log groups to an S3 bucket every day and turn on SSE-KMS with the customer managed key for the bucket

  Incorrect

  This encrypts the exported copies in S3, not the log data stored in CloudWatch Logs, and the log groups still never expire.

• DAttach a data protection policy to each log group so that log events are protected with the security team's KMS key

  Incorrect

  A data protection policy does not change the KMS key that encrypts the log group's data.

• EMove the log groups to the Infrequent Access log class so that old log events expire after 400 days

  Incorrect

  The log class does not decide when log events expire. Expiry is set by the retention setting.

CloudWatch Logs always encrypts data at rest; associating a customer managed KMS key with a log group puts the encryption under the key owner's control. Retention is a separate per-log-group setting with fixed allowed values.

• ASchedule a Lambda function every minute that calls GetMetricData for the three namespaces and writes the results to S3 as Parquet files with a date prefix

  Incorrect

  This is the polling code the team wants to avoid, and its latency and completeness depend on the schedule and the code.

• BCreate a CloudWatch metric stream for the three namespaces to an Amazon Data Firehose stream that converts the records to Parquet in S3

  Correct

  Metric streams deliver metrics continually with low latency to Firehose, where a transformation can convert the data to formats such as Parquet before it lands in S3.

• CAdd a CloudWatch Logs subscription filter for the three namespaces that sends the metric data points to the Firehose stream for S3

  Incorrect

  Subscription filters stream log events from log groups. Metrics in the AWS/EC2, AWS/RDS and AWS/ApplicationELB namespaces are not log events.

• DBuild a CloudWatch dashboard with the three namespaces and export its widgets to S3 as CSV files on a schedule

  Incorrect

  Dashboards display metrics. They are not a continuous delivery mechanism for metric data to a data lake.

Metric streams are the push path out of CloudWatch. With the custom Firehose setup you choose the namespaces, and Firehose can transform the native JSON or OpenTelemetry records into Parquet for Athena.

• ATurn on detailed monitoring for every instance so that EC2 publishes its metrics at one-minute intervals

  Incorrect

  Detailed monitoring changes the period of the metrics EC2 already sends. It adds neither memory nor per-process metrics, nor log files.

• BTurn on Container Insights for the account so that CloudWatch collects memory and process metrics from the instances

  Incorrect

  Container Insights collects metrics and logs from containerized applications on ECS and EKS. These are plain EC2 instances.

• CAdd a cron job on each instance that reads memory and process CPU every minute and calls PutMetricData, and ship the log files to CloudWatch Logs with a script

  Incorrect

  This is collection code installed on every instance, and changing it means touching every instance again.

• DKeep one CloudWatch agent configuration with procstat and the log files in Parameter Store, and roll the agent out with Systems Manager

  Correct

  The agent collects memory, per-process metrics through procstat, and log files. Systems Manager installs it fleet-wide and applies the configuration that is kept in Parameter Store.

The CloudWatch agent covers in-guest metrics, process metrics and log files. Keeping its configuration in Parameter Store and rolling it out with Systems Manager gives one source of truth and no logins to individual servers.

• Afilter status >= 500 | stats count(*) as errors by clientIp | sort errors desc | limit 10

  Correct

  The filter keeps only 5xx events, stats counts them per IP, and sort with limit after the last stats returns the top 10.

• Bstats count(*) as errors by clientIp | filter status >= 500 | sort errors desc | limit 10

  Incorrect

  After a stats command only the fields it defines can be referenced, so status is no longer available to filter on.

• Cfilter status >= 500 | sort errors desc | stats count(*) as errors by clientIp | limit 10

  Incorrect

  A sort or limit command must come after the last stats command; otherwise the query is not valid.

• Dfilter status >= 500 | sort @timestamp desc | limit 10

  Incorrect

  This returns the 10 most recent 5xx events, not the IP addresses with the most errors.

Logs Insights commands run in order, separated by pipes. Filter raw events first, aggregate with stats, then use sort and limit for a top-N result.

• ARaise the agent's metrics collection interval so that lines are batched together

  Incorrect

  The metrics interval controls metric collection, not how log lines are grouped.

• BSet multi_line_start_pattern to match the timestamp at the start of each message

  Correct

  A message is a line that matches the pattern plus the following lines that do not, so each stack trace becomes one event.

• CSet the log stream name to the instance ID so that related lines are kept together

  Incorrect

  The stream name does not combine lines into one event.

• DCreate a metric filter on the log group that merges lines with the same timestamp

  Incorrect

  Metric filters create metrics; they do not merge log events.

The CloudWatch agent identifies the start of each log message with multi_line_start_pattern, so multi-line output such as stack traces is sent as single events.

• ARaise the buffer size of the stream to the maximum value

  Incorrect

  Larger buffers do not keep Firehose retrying a failing destination.

• BTurn off the S3 error bucket so that no records leave the stream

  Incorrect

  After retries end, records go to the error bucket rather than being held by the stream.

• CSet the OpenSearch retry duration above 90 minutes, such as 7200 seconds

  Correct

  Firehose retries with backoff until the retry duration expires, and a higher value avoids delivering to the error bucket during downtime.

• DAdd index rotation by day so that the domain accepts writes during maintenance

  Incorrect

  Index rotation names indexes by time; it does not help when the domain is unavailable.

For OpenSearch destinations, Firehose retries failed index requests for the retry duration, from 0 to 7200 seconds, and then sends data to the S3 error bucket, from which it must be redriven.

• ACloudTrail data events for all objects in the bucket on a new trail

  Incorrect

  Data events record each object-level request within minutes, but they incur a fee per event, which this analysis does not need to pay.

• BS3 server access logging delivered to a separate logging bucket

  Correct

  Server access logs record each request, cost nothing beyond log storage when delivered to S3, and arrive within a few hours.

• CS3 Storage Lens advanced metrics with a daily metrics export for the bucket

  Incorrect

  Storage Lens shows aggregated usage and activity trends at low effort, but it does not record individual requests.

• DCloudTrail Insights on the existing trail

  Incorrect

  Insights flags unusual API call rates; it does not record each request.

S3 offers server access logging and CloudTrail logging. AWS recommends CloudTrail for auditing, with integrity validation and faster delivery; server access logs are a cheaper record of each request, delivered within a few hours.

• APublish it as a high-resolution metric every second and alarm on it with a 10-second period

  Correct

  High-resolution metrics are stored at 1-second resolution, can be read with periods down to 1 second, and support alarms with 10- or 30-second periods at a higher charge.

• BTurn on detailed monitoring for the EC2 instances that run the service

  Incorrect

  Detailed monitoring sends EC2 metrics every minute; it changes neither the custom metric nor its resolution.

• CPublish it every 10 seconds at standard resolution and alarm on the Maximum statistic over one minute

  Incorrect

  The one-minute Maximum would include the spike's value, but alarms on standard-resolution data use periods of at least 60 seconds, which is too slow.

• DCreate an anomaly detection alarm on the existing one-minute metric

  Incorrect

  Anomaly detection replaces a static threshold with a learned band, but it still evaluates the one-minute values that hide the spikes.

Custom metrics can be standard resolution, with one-minute granularity, or high resolution, with one-second granularity. Only high-resolution metrics allow high-resolution alarms with 10- or 30-second periods, which cost more.

• ADeploy the AWS Config managed rule cw-loggroup-retention-period-check with MinRetentionTime set to 90

  Incorrect

  The rule checks for a minimum retention, so it treats Never expire as compliant, and it only reports; it does not set retention.

• BExport all log groups to S3 every day and then delete the exported log events

  Incorrect

  This adds a daily job to maintain instead of setting retention on the log groups.

• CTurn on log-level filtering at WARN for every function in the templates

  Incorrect

  Filtering sends fewer log lines to CloudWatch Logs, but whatever is sent is still kept forever.

• DDeclare each function's log group in its template with RetentionInDays set to 90

  Correct

  Defining the log group in the template creates it with its retention setting when the function is deployed, before the first invocation.

By default, log data is stored indefinitely, and Lambda creates a log group on first use. Declaring each log group with a retention period in infrastructure as code applies the setting from the start.