Monitoring, Logging, Analysis, Remediation, and Performance Optimization practice questions

The CloudWatch agent reads a JSON configuration describing which metrics and log files to collect. The operational best practice for fleets is to store that configuration centrally in Systems Manager Parameter Store and to install and configure the agent through Systems Manager rather than by hand.

Parameter Store gives the whole fleet one authoritative agent configuration, and Systems Manager performs the installation and configuration at scale — no SSH, no per-instance drift. SSHing to each instance is unmanageable at 300 instances; detailed monitoring cannot produce in-guest metrics at all; and a custom PutMetricData script reinvents the agent with code the team must now maintain.

1. Author the CloudWatch agent JSON configuration listing the memory and disk metrics to collect.
2. Store the configuration as a parameter in Systems Manager Parameter Store.
3. Use Systems Manager to install the agent across the fleet.
4. Configure the agent on every instance to load the shared parameter, then verify metrics arrive.

Exam tip: Fleet-wide agent rollout means Systems Manager for installation and Parameter Store for one shared agent configuration.

EC2 standard monitoring publishes instance metrics every 5 minutes at no charge. Detailed monitoring publishes the same metrics every 1 minute for an additional cost — it changes frequency only, adding no new metrics — and is enabled per instance or in a launch template.

Enabling detailed monitoring is the built-in, direct way to get 1-minute EC2 metrics so alarms and Auto Scaling react faster. The CloudWatch agent solves a different problem (in-guest metrics and logs); a high-resolution custom metric means writing collection code for data AWS already provides; and shrinking the alarm period cannot conjure datapoints that are only published every 5 minutes.

1. Identify that the bottleneck is metric frequency, not metric availability.
2. Enable detailed monitoring on the instances or in their launch template.
3. Confirm CPUUtilization now arrives at 1-minute granularity.
4. Adjust the scaling policy's alarm period to evaluate 1-minute datapoints.

Exam tip: Standard monitoring is 5-minute and free; detailed monitoring is 1-minute and paid — and it changes frequency, never the metric set.

Custom metrics come in two resolutions: standard resolution stores data at 1-minute granularity, while high-resolution metrics store data down to 1-second granularity. Only high-resolution metrics support high-resolution alarms, which evaluate on 10-second or 30-second periods.

Reacting inside a 30-second window requires both halves: publishing the metric at high resolution so datapoints exist at second-level granularity, and a high-resolution alarm with a 10-second period to evaluate them. Standard resolution caps evaluation at 1-minute periods; detailed monitoring governs EC2 instance metrics, not custom metrics; and a metric filter is a log-pattern tool that does not deliver 1-second data.

1. Decide the required detection speed — here, well under a minute.
2. Publish the queue-depth metric with PutMetricData as a high-resolution metric.
3. Create a high-resolution alarm with a 10-second period on the metric.
4. Attach a notification or remediation action and test with a simulated spike.

Exam tip: Sub-minute detection needs a high-resolution custom metric plus a high-resolution alarm on a 10- or 30-second period.

Container Insights deploys the collection machinery into Amazon ECS or EKS clusters to gather cluster-, service-, task-, and pod-level metrics and logs into CloudWatch — the purpose-built path for container observability in CloudWatch.

Enabling Container Insights delivers exactly the requested task- and service-level metrics plus container logs with the least effort, because it is the packaged feature for this job. Hand-installing agents and inventing dimensions rebuilds the same capability manually; Managed Prometheus answers a different requirement (Prometheus-standardized teams); and subscription filters move log events rather than producing container metrics.

1. Enable Container Insights on the ECS cluster.
2. Confirm task- and service-level CPU and memory metrics appear in CloudWatch.
3. Verify container logs are flowing into the cluster's log groups.
4. Build alarms and dashboards on the collected metrics.

Exam tip: For ECS or EKS metrics and logs in CloudWatch, enable Container Insights — do not hand-roll agent deployments.

A metric filter watches a log group for a pattern and increments a CloudWatch metric on every match, converting unstructured log lines into an alarmable number. Pairing it with an alarm and an SNS action is the standard zero-code log-alerting pipeline.

The metric filter to alarm to SNS chain meets the requirement entirely with managed configuration: pattern FATAL, count metric, alarm on sum of at least 5 over 5 minutes, SNS page. The subscription-filter-plus-Lambda option achieves the same result but adds custom code the team must maintain — failing the least-overhead constraint. Logs Insights only answers questions when someone asks them, and CloudTrail audits API activity, not application log text.

1. Create a metric filter on the log group with the pattern FATAL, publishing a count metric with value 1 per match.
2. Set a default value of 0 so the metric emits datapoints during quiet periods.
3. Create an alarm: sum of the metric at least 5 over a 5-minute period.
4. Set the alarm action to an SNS topic with a confirmed on-call subscription.
5. Test by writing FATAL lines and confirming the page arrives.

Exam tip: Alert on a log pattern with a metric filter feeding an alarm — reserve subscription filters and Lambda for when the log data itself must flow somewhere.

Metric filters apply only to log data ingested after the filter is created. They convert future pattern matches into metric datapoints and never re-scan the log group's history.

The absence of historical datapoints is the designed behavior — no backfill exists. Retention is ruled out because the events remain visible (and retention would not enable retroactive evaluation anyway); there is no 24-hour delay before metric filters work; and a default value shapes quiet-period behavior for new data, not history. To analyze the past spike, the engineer should query the existing events with CloudWatch Logs Insights instead.

1. Create the metric filter to cover future occurrences of the error pattern.
2. For the historical spike, run a Logs Insights query over yesterday's time range to count matches.
3. Add a default value of 0 to the filter so future quiet periods still emit datapoints.
4. Attach an alarm to the new metric for the next occurrence.

Exam tip: Metric filters never backfill — analyze historical log data with Logs Insights, and use the filter for everything ingested from now on.