Task 4.2: Audit, monitor, and analyze logs and metrics to detect issues.

• AA composite alarm that combines the existing low-count and high-count alarms with an OR rule

  Incorrect

  A composite alarm combines the states of other alarms. The underlying static thresholds still ignore the time of day.

• BA metric math expression that averages the request count over the last 24 hours, with a static alarm on the result of that expression

  Incorrect

  A 24-hour average flattens the daily pattern and still needs a fixed threshold, so short drops during busy hours are hidden.

• CAn anomaly detection alarm on the request count metric that fires when the value is outside the band in either direction

  Correct

  Anomaly detection models account for hourly, daily and weekly seasonality, and the alarm can fire above the band, below it, or both.

• DTwo scheduled EventBridge Scheduler jobs that change the static alarm threshold at 08:00 and 20:00 on weekdays

  Incorrect

  Switching thresholds by schedule is the hand tuning the team wants to avoid, and it does not cover weekends or gradual changes.

Seasonal metrics need a moving baseline. A CloudWatch anomaly detection alarm compares each data point with the expected range from the model instead of a static threshold.

• ATurn on access logging for the API stage and use CloudWatch Logs Insights to compare the integration latency with the total latency

  Incorrect

  Access logs show latency at the API only. They cannot split the time among Lambda, the ECS service and DynamoDB.

• BTurn on VPC Flow Logs for the Fargate tasks' subnets and look for slow connections between the tasks and DynamoDB

  Incorrect

  Flow logs record IP traffic metadata, not request timings inside applications, so they cannot attribute latency to a hop.

• CInstall the X-Ray daemon on each Fargate task host and use the X-Ray SDK in the ECS service, leaving tracing turned off in API Gateway and in the Lambda function

  Incorrect

  With Fargate there are no servers to manage, the X-Ray SDKs and daemon are in maintenance mode, and leaving tracing off upstream breaks the end-to-end view.

• DTurn on X-Ray tracing for the API stage and the Lambda function, and run the AWS Distro for OpenTelemetry collector as a sidecar in the ECS tasks

  Correct

  API Gateway and Lambda can send traces to X-Ray, and ECS uses an ADOT sidecar container to collect and route trace data to X-Ray. AWS recommends OpenTelemetry for new instrumentation.

X-Ray shows the latency of an entire request and of each downstream service it traced. With the X-Ray SDKs and daemon in maintenance mode since February 2026, OpenTelemetry through ADOT is the recommended way to instrument containers.

• APartition the table by day and add a scheduled Lambda function that runs ALTER TABLE ADD PARTITION for each new day

  Incorrect

  This prunes partitions, but it is code that must run for every new day, which the team wants to avoid.

• BRecreate the table with partition projection on the date, using the known prefix structure of ALB access logs

  Correct

  Because ALB logs have a known partition scheme, projection lets Athena compute partitions as new data arrives, with no need for ALTER TABLE ADD PARTITION.

• CKeep the table as it is and add a WHERE condition on the request time column to every query

  Incorrect

  Partitions are what restrict the data a query scans. Without them, a condition on a column does not keep Athena from reading the whole year.

• DSend the access logs to CloudWatch Logs instead and query them with CloudWatch Logs Insights

  Incorrect

  ALB access logs are delivered to Amazon S3. Moving them into another service needs a separate pipeline and does not use the existing year of data.

Partition projection calculates partition values and locations from table properties instead of reading them from the Data Catalog. For logs with a predictable date layout, such as ALB access logs, it also removes partition maintenance.

• AA metric filter for each error message text so that counts appear as metrics

  Incorrect

  Writing a filter for every message requires knowing the messages first.

• BLive Tail on the log group so that engineers can read the errors as they arrive

  Incorrect

  Reading events as they arrive does not group millions of them.

• CA Logs Insights query that filters the error lines and appends the pattern command

  Correct

  The pattern command finds shared text structures across the matching events, compressing many events into a few patterns.

• DA subscription filter that sends the errors to a Lambda function that counts identical lines

  Incorrect

  Lines differ by IDs and timestamps, so identical-line counts miss the common message structure.

Logs Insights pattern analysis groups log events with shared structure and variable parts, which makes large error sets easier to understand.

• AA separate dashboard in each account and Region, linked from a wiki page that the operators use as a start page

  Incorrect

  Each team keeps its own dashboard without any sharing setup, but operators still switch accounts and Regions to see them.

• BA cross-account cross-Region dashboard in the monitoring account, with the other accounts set up as sharing accounts

  Correct

  These dashboards summarize CloudWatch data from multiple accounts and Regions in one place, with widgets that read each account's data where it is.

• CA metric stream in each account that sends metrics to an S3 bucket in the monitoring account for Athena queries

  Incorrect

  Metric streams centralize the data for analysis, but they copy it out of CloudWatch and Athena queries are not a live dashboard.

• DA composite alarm in each account that combines the alarms for the key metrics

  Incorrect

  Composite alarms reduce alarm noise by combining alarm states; they do not graph metrics from several accounts.

CloudWatch cross-account cross-Region dashboards give a single view of data from many accounts and Regions, with drill-down into more specific dashboards, once sharing and monitoring accounts are set up.

• AAn Athena table over the flow logs in S3, queried with SQL for rejected traffic

  Correct

  Athena runs standard SQL directly on data in S3, is serverless and charges only for the queries that run.

• BAn Amazon OpenSearch Service domain that Firehose loads with the flow logs, searched from OpenSearch Dashboards

  Incorrect

  OpenSearch Service suits continuous log analytics, but the domain runs and is paid for by the hour, and the logs are copied into it.

• CAn Amazon Redshift provisioned cluster that loads the flow logs every night with COPY

  Incorrect

  Redshift suits a busy data warehouse, but its nodes are billed while the cluster runs, and the logs are loaded into the cluster.

• DReachability Analyzer runs between every pair of addresses

  Incorrect

  Reachability Analyzer checks configured paths; it does not analyze recorded traffic.

Athena can create tables over VPC flow logs stored in S3, including partitioned and Parquet layouts, and run SQL on them on demand, for example to find top talkers or rejected traffic.

• ACloudWatch Internet Monitor for the application's resources

  Correct

  Internet Monitor shows how internet issues affect performance and availability between AWS-hosted applications and end users.

• BVPC Flow Logs on the load balancer subnets

  Incorrect

  Flow logs show traffic inside the VPC, not provider problems on the internet path.

• CX-Ray tracing on the backend services

  Incorrect

  Backend traces do not show internet path issues.

• DA CloudWatch alarm on the load balancer's TargetResponseTime metric

  Incorrect

  Target response time is measured inside AWS and already looks normal.

Internet Monitor uses connectivity data from AWS's global network to set a baseline and raises health events when end users in certain locations and networks are affected.

• ALower the threshold of the average latency alarm to 50 ms

  Incorrect

  A lower average threshold fires on normal traffic and still hides the tail.

• BAlarm on the Maximum statistic of TargetResponseTime above 3 seconds

  Incorrect

  Maximum shows the slowest request, but a single slow request in the period would set off the alarm.

• CAlarm on the trimmed mean tm99 of TargetResponseTime above 1 second

  Incorrect

  A trimmed mean is a robust view of the typical request, but tm99 drops the slowest 1 percent and averages the rest, so the tail barely moves it.

• DAlarm on the p99 statistic of TargetResponseTime above 3 seconds

  Correct

  p99 is the value that 99 percent of requests stay below, so it rises above 3 seconds when more than 1 percent of requests are that slow, and not for one outlier.

Averages hide outliers, and Maximum reacts to any single one. A percentile such as p99 shows how slow the worst experiences are while ignoring the extreme 1 percent, and ALB metrics support percentile statistics.