Monitoring, Logging, and Remediation practice questions

The S3 bucket policy denies write access from CloudTrail for that region.

Why wrong: An S3 bucket policy is a resource policy that applies to all write requests to the bucket regardless of the source region. If CloudTrail is denied write access by the bucket policy, log delivery would fail for every trail using that bucket across all regions, not selectively for one region. A region-specific logging gap is far more likely to be a trail configuration issue than a bucket policy misconfiguration.

CloudTrail log file validation is disabled.

Why wrong: Log file validation is an optional CloudTrail feature that creates a SHA-256 hash chain and periodically publishes digest files so you can confirm the integrity of recorded log files. It operates entirely on delivered logs and does not influence whether CloudTrail captures or delivers events in any region. Disabling validation would merely remove your ability to detect tampering; it would never produce missing log entries.

The IAM role for CloudTrail does not have permissions to write logs from that region.

Why wrong: The IAM role that CloudTrail assumes to write logs to S3 or CloudWatch Logs is an account-level identity with no regional boundaries. If that role lacks the necessary permissions, delivery fails for every region the trail covers, because the same role is used across the trail's configuration. A single region without logs therefore points to a trail that is not enabled in that region, not an IAM permission problem.

Configure an S3 event notification for all object creation events and publish to an Amazon SNS topic that sends an email alert.

Why wrong: S3 event notifications generated on object creation (s3:ObjectCreated:Put) fire for every upload but do not capture subsequent PutObjectAcl calls that modify an object's ACL after upload. They also cannot inspect the uploaded object's ACL or the bucket policy to determine whether a public grant was applied, so they produce alerts for all uploads regardless of actual public exposure. This approach both misses ACL modifications and generates false positives, making it unsuitable for detecting unauthorized public read access.

Use an AWS Config managed rule to detect 's3-bucket-public-read-prohibited' and trigger an SNS notification via Amazon EventBridge.

Why wrong: AWS Config's managed rule 's3-bucket-public-read-prohibited' continuously evaluates bucket policies and flags any bucket that grants public read access to the 'Everyone' group. When a bucket becomes non-compliant, AWS Config emits a configuration item change event that can be routed to an SNS topic through an Amazon EventBridge rule, delivering near-real-time email alerts. This purpose-built managed rule requires no custom code, no data event logging, and captures exactly the risky condition—public read via bucket policy—making it the most efficient and accurate option.

Configure S3 event notifications for 's3:ObjectCreated:Put' and 's3:ObjectCreated:PutObjectAcl' with a suffix/prefix filter for public grants, sending to an SNS topic.

Why wrong: S3 event notifications cannot filter based on the ACL being public; they only trigger on the event type itself, so you'd get alerts for every PutObject or PutObjectAcl, even if the object is not made public.

Enable detailed CloudWatch Logs and search for 'timeout' strings.

Why wrong: Enabling detailed CloudWatch Logs and searching for 'timeout' strings would only confirm that a timeout occurred, not which code path caused it. Lambda's native logging captures stdout/stderr and platform-generated START/END/REPORT messages, but these provide aggregate duration (e.g., 'Duration: 1500.23 ms') rather than per-line timings. A timeout search might reveal the final error, but it cannot break down execution time across individual API calls or computational steps inside the function. This approach lacks the subsegment-level detail that X-Ray's trace data provides.

Set a CloudWatch Metric Filter for 'Duration' and create an alarm.

Why wrong: Setting a CloudWatch Metric Filter for 'Duration' and creating an alarm gives you only aggregate performance statistics, such as average or percentile durations across all invocations. A metric filter would parse the 'Duration' value from Lambda's REPORT log lines, but that represents total function time, not the time spent on individual code statements or SDK calls. The alarm can notify you that a problem exists (e.g., p95 duration exceeded), but it cannot localize the slowness to a specific line or external service. For that, you need per-request trace data like X-Ray's segments, which break down execution into measurable subcomponents.

Enable AWS CloudTrail data events for the Lambda function.

Why wrong: AWS CloudTrail data events for Lambda record management and invoke API actions made against the Lambda service, such as 'Invoke' or 'UpdateFunctionCode', but they do not inspect the internal execution of your function. Even if you enable data events for the specific function, you will see that an invocation occurred and from which principal, but you will not get any timing breakdown of the code that ran inside the container. CloudTrail's logs are designed for auditing API activity and security analysis, not for profiling application performance. X-Ray, by contrast, runs inside the execution environment and can capture the duration of every code block and downstream interaction.

VolumeReadOps

Why wrong: VolumeReadOps counts the number of completed read operations in a one-minute period, not the number of I/O requests waiting to be serviced. A high read ops value simply indicates a busy volume with many successful reads, but the metric does not measure latency, contention, or backlog. In the context of diagnosing a bottleneck, you need a metric that captures pending requests, which is exactly what VolumeQueueLength does—read ops alone cannot show whether requests are queuing up.

VolumeIdleTime

Why wrong: VolumeIdleTime represents the total number of seconds during the interval when no read or write I/O was occurring. A low idle time indicates the volume is continuously active, but this does not tell you whether requests are waiting in a queue—it only shows that the device is busy. Although related to utilization, idle time cannot reveal backlog or pending operations, whereas VolumeQueueLength explicitly tracks the number of I/O requests in the wait state. Therefore, it cannot be used to confirm a bottleneck.

VolumeTotalReadTime

Why wrong: VolumeTotalReadTime measures the total number of seconds spent by the volume completing read operations during the period, which is a cumulative service time. This metric reflects the actual time the device is processing reads, not the time requests spend waiting in the queue before being serviced. A high total read time indicates the volume is spending a lot of time doing read work, but it does not show whether requests are piling up unserviced. Because it ignores the queueing component, it is not a valid indicator of a pending-I/O bottleneck.

Configure CloudFront access logs to be delivered to an Amazon S3 bucket, and use Amazon Athena to query logs for IPs with many 403 errors. Then manually add those IPs to a WAF IP set.

Why wrong: While Athena can query access logs stored in S3, it is an interactive, batch-oriented query service, not a real-time detection or enforcement mechanism. The log delivery from CloudFront to S3 is typically delayed by up to an hour, and Athena queries must be manually triggered after ingestion. Moreover, manually adding IPs to a WAF IP set creates a slow, human-in-the-loop process that fails to block malicious traffic promptly, leaving the distribution exposed during the analysis window. A fully automated, near-real-time pipeline is required, so this option does not meet the stated security requirement.

Enable AWS CloudTrail for CloudFront and create a CloudWatch metric filter for 'Forbidden' events. Use a CloudWatch alarm to notify the administrator via email, who then manually updates the WAF IP set.

Why wrong: CloudTrail records management-plane API calls made against CloudFront, such as CreateDistribution or UpdateDistribution, not the data-plane HTTP requests that flow through the distribution. Therefore, a CloudTrail event is never generated when a viewer receives a 403 Forbidden response from CloudFront, meaning the metric filter for 'Forbidden' events would simply have no relevant data to match. Even if the alarm could trigger, relying on an email notification to an administrator who then manually updates the WAF IP set introduces significant latency and does not provide the immediate, automated blocking needed to mitigate an active attack.

Use AWS Config to monitor CloudFront distributions and trigger an AWS Lambda function when a high number of 403 errors is detected by evaluating access logs stored in S3.

Why wrong: AWS Config is designed to evaluate resource configurations against compliance rules, not to analyze application request logs or dynamic metrics such as error rates. CloudFront access logs stored in S3 are data files, not configuration items, and Config does not have a native mechanism to parse, correlate, or evaluate those logs for 403 status counts. Even if a Lambda function were triggered by a Config rule, the rule evaluation would only occur during periodic or configuration-change-triggered evaluations, not in real time per request; therefore, it cannot respond quickly enough to a surge in malicious 403 errors and is architecturally misaligned with the problem.

Enable AWS CloudTrail logging for the ALB and create a CloudWatch metric filter for 'UnHealthyHostCount' events. Then create an alarm on that metric to notify via SNS.

Why wrong: CloudTrail records API calls made to the ALB service, such as CreateLoadBalancer or ModifyTargetGroup, but it does not capture the health-check metric UnHealthyHostCount, which is continuously emitted by the ALB as a CloudWatch metric. A CloudWatch metric filter can parse log events, but CloudTrail logs do not contain the health-check values, so no metric would be generated from this filter. Therefore this approach would produce no notifications and is based on a fundamental misunderstanding of the data sources.

Use an AWS Config rule to evaluate the health of the ALB target group and trigger an SNS notification when non-compliant.

Why wrong: AWS Config rules assess resource configurations against desired policies, such as whether a target group has the correct protocol or health-check path, and are evaluated on a periodic or configuration-change basis. The UnHealthyHostCount is a dynamic operational metric that reflects the current state of target health at a given moment, not a static configuration attribute. Since Config does not ingest real-time CloudWatch metrics into its compliance evaluation, this rule would either fail to evaluate the desired condition or require custom remediation, making it unsuitable for real-time alerting.

Create an Amazon EventBridge rule that triggers every minute to call the AWS CLI command describe-target-health and send a notification via Lambda if unhealthy count exceeds 2.

Why wrong: Creating an EventBridge scheduled rule that invokes a Lambda function every minute to call describe-target-health and then parse the output to count unhealthy hosts adds unnecessary complexity and cost. This approach places a custom polling workload on the ALB's API, risks hitting rate limits, and depends on additional IAM permissions and Lambda code to interpret the response. In contrast, CloudWatch already collects the UnHealthyHostCount metric and can directly trigger an SNS alarm, eliminating the need for custom logic and infrastructure.

Amazon Simple Notification Service (SNS)

Why wrong: Amazon Simple Notification Service is a fully managed pub/sub message delivery service, not a monitoring or metrics service. It cannot sample RDS metrics, evaluate thresholds, or execute logic on its own. Its role is limited to receiving alarm notifications from CloudWatch and fanning them out to subscribers via email, SMS, Lambda, or HTTP endpoints. Using SNS alone would leave you blind to the actual connection count until someone manually checks.

AWS CloudTrail

Why wrong: AWS CloudTrail records a history of API calls made by users, roles, or AWS services, producing an auditable event log. It captures actions like CreateDBInstance or ModifyDBInstance, but it does not expose performance counters like DatabaseConnections from within a database. While CloudTrail can help forensically investigate who changed an RDS config, it cannot serve as a real-time health monitor for connection saturation.

AWS Config

Why wrong: AWS Config tracks changes to resource configuration over time and evaluates that configuration against managed or custom rules, such as checking whether RDS instances have deletion protection enabled. It is not designed to ingest numeric performance metrics or runtime operational health indicators like the number of active connections. Therefore, AWS Config could confirm the desired setup but cannot alarm on a connection spike.

[error, HTTP, 500]

Why wrong: The square brackets in a CloudWatch Logs metric filter pattern define a space-delimited token sequence, not a literal substring search. This pattern would attempt to match three separate space-separated fields named 'error', 'HTTP', and '500' (with commas being interpreted as part of the token names), so it will not match a log line containing the contiguous string 'HTTP 500'.

"HTTP" && "500"

Why wrong: The '&&' operator is not supported in CloudWatch Logs metric filter patterns. This pattern would be treated as invalid syntax, or the parser would attempt to match a literal ampersand sequence, rather than logically requiring both 'HTTP' and '500' to appear. To match multiple terms anywhere in the line, use a space-separated pattern like 'HTTP' '500'.

[HTTP, 500, ...]

Why wrong: This pattern uses square brackets, which are intended for token-based parsing of space-delimited fields, not for literal string matching. In addition, the comma and ellipsis are not valid tokens in a metric filter pattern, so the entire expression is syntactically invalid. It would not match the literal string 'HTTP 500' at all.

AWS CloudTrail

Why wrong: AWS CloudTrail is incorrect because it records API activity and actions taken by users, roles, or AWS services, producing event history logs for auditing and governance. CloudTrail does not ingest or store performance metrics like CPU utilization, nor does it provide any graphing or visualization capabilities. If you need to see CPU usage, you must use CloudWatch metrics, not CloudTrail logs. CloudTrail would only show the API calls that started or stopped an instance, not the instance's resource consumption over time.

Amazon QuickSight

Why wrong: Amazon QuickSight is a business intelligence (BI) service designed for interactive dashboards, ad-hoc analysis, and rich data visualizations from various data sources such as S3, Redshift, or RDS. While QuickSight can connect to CloudWatch via the QuickSight SPICE or Athena, it is an over-engineered and indirect solution for viewing a simple average CPU graph. QuickSight is not integrated as a native CloudWatch metrics viewer; setting it up would require importing or querying metric data through additional services, adding unnecessary complexity and latency. For a direct, immediate graph of EC2 CPU utilization, CloudWatch Dashboards are the appropriate tool.

AWS Trusted Advisor

Why wrong: AWS Trusted Advisor is incorrect because it is an advisory service that inspects your AWS environment and provides recommendations based on AWS best practices, such as cost optimization, security, fault tolerance, and service limits. It does not collect or visualize CloudWatch metrics like CPU utilization; it merely reports on configuration and usage patterns against best practices. While Trusted Advisor may mention underutilized EC2 instances (e.g., consistently low CPU), it does not provide the granular, time-series graph requested. To view a graph of average CPU, you must use CloudWatch, not Trusted Advisor.

Create a CloudWatch Logs metric filter and a Lambda function that sends email via SES

Why wrong: CPUUtilization is published as a numerical metric by the EC2 instance, not as a log event, so a CloudWatch Logs metric filter cannot parse it from actual log data. Even if you attempted to bridge the gap by having an agent send logs, you would still need a metric filter and an alarm on the resulting custom metric to trigger the Lambda, making the SES/Lambda pipeline redundant and more costly. The native alarm-to-SNS path eliminates Lambda cold starts, IAM permission complexity, and SES email configuration overhead.

Create a CloudWatch Events rule that matches EC2 instance state changes and sends to SQS with a Lambda consumer

Why wrong: CloudWatch Events—now offered through Amazon EventBridge—reacts to event patterns such as EC2 instance state-change notifications (e.g., 'running' or 'stopped'), not to metric thresholds or CPU utilization levels. A rule matching instance state changes would never fire for a CPU spike, so the SQS queue would receive no messages and the Lambda consumer would never trigger an email. This approach also introduces unnecessary asynchronous components that require separate configuration for queue polling, dead-letter queues, and Lambda permissions, adding latency and operational complexity.

Configure a CloudWatch dashboard that displays CPU utilization and share it with the team

Why wrong: A CloudWatch dashboard provides a real-time graphical view of CPUUtilization and can be shared via a console link, but it only displays data when someone actively opens it. It does not evaluate thresholds, generate alerts, or initiate any delivery mechanism such as email or SMS. Relying on a dashboard means a human must continuously watch the screen to notice a spike, which is not automated and directly fails the requirement for proactive notification when CPU utilization exceeds a threshold.

Use Amazon CloudWatch Events to match S3 API calls from CloudTrail and route to an SQS queue.

Why wrong: Amazon CloudWatch Events (now EventBridge) can match S3 API calls logged by CloudTrail, but CloudTrail logs are delivered on an asynchronous, batched basis—typically 5–15 minutes after the API call—so the event stream is not near-real-time. You would also need to build a rule with an event pattern and a target to SQS, which adds unnecessary infrastructure compared to the native S3 event notification. Since S3 already publishes lifecycle events (e.g., s3:ObjectCreated:*) directly to SQS within seconds, relying on CloudTrail as a proxy introduces avoidable latency and operational complexity.

Deploy an application that periodically polls S3 for changes using ListObjects.

Why wrong: Polling for changes with ListObjects (or ListObjectsV2) requires continuously comparing snapshots of the bucket to infer what changed, but the API returns only a current listing—it does not produce an event or identify which object changed between calls. Each comparison cycle needs to store state from the previous scan, and frequent polling of large buckets generates massive request costs, throttling risk, and delayed detection. This approach is inherently non-event-driven and scales poorly compared to S3's push-based notification to SQS.

Use AWS CloudTrail to deliver logs to CloudWatch Logs, then create a metric filter and trigger a Lambda function to send to SQS.

Why wrong: This pipeline uses CloudTrail logs, which are delivered to CloudWatch Logs only after a significant delay and for data events can be sparse if not explicitly enabled. A metric filter merely counts log occurrences; it does not extract the full event payload, so you would need a Lambda function to parse the JSON and reconstruct the object key—adding brittle custom code. Even after those hops, the end-to-end latency is dominated by CloudTrail and Logs ingestion, so it cannot match the sub-second to few-second delivery of a direct S3 event notification to SQS.

CloudTrail, Amazon SNS, and AWS Lambda

Why wrong: While this combination can technically notify on IAM user creation, it requires a custom Lambda function to parse the CloudTrail event, filter for the `iam:CreateUser` API call, and then publish a message to SNS. This introduces code maintenance, deployment overhead, and potential delays or failure points compared to a fully managed integration. EventBridge provides built-in pattern matching for CloudTrail events, making it the simpler and more reliable choice.

CloudTrail, Amazon CloudWatch Logs, and a metric filter with an alarm

Why wrong: CloudTrail, CloudWatch Logs, and a metric filter correctly identify the logging and event detection mechanisms for IAM user creation. However, a CloudWatch Alarm, while excellent for monitoring metric filter matches, cannot directly send email notifications. It requires an Amazon SNS topic as an action to deliver emails, which is omitted here, thus failing to meet the 'email notification' requirement. This setup is otherwise fundamental for real-time operational monitoring and triggering automated responses based on specific log events.

AWS Config and Amazon SNS

Why wrong: AWS Config is a configuration tracking service that evaluates changes to resource settings, not a real-time API activity logger. While it can detect that an IAM user resource was created via configuration changes, it does so on its own compliance timeline and is not intended for per-API-call notification. The scenario specifically requires notification on an 'api activity' event, which CloudTrail provides but AWS Config does not.

CloudWatch Logs Insights scheduled query with SNS action.

Why wrong: CloudWatch Logs Insights is an interactive query engine for analyzing log data retrospectively, not a real-time monitoring service. While you can schedule a query through an EventBridge rule to run periodically, the schedule has no built-in integration with CloudWatch Alarms—you would need a Lambda intermediary to evaluate results and publish to SNS. Moreover, scheduled queries often run on intervals of minutes and incur per-GB scan costs, so they lack the low-latency, threshold-based alerting that metric filters and alarms provide natively.

Use a Lambda function that reads the log stream and sends an email via Amazon Simple Email Service (SES) when errors exceed 100.

Why wrong: This option requires you to build and operate a custom log‑processing pipeline: you must create a Lambda function, subscribe it to the log group as a CloudWatch Logs subscription, parse incoming log events, and maintain state to track the count of 'ERROR' messages over time—then trigger SES only after exceeding your threshold. That logic duplicates the metric filter and alarm functionality that CloudWatch already offers, adds significant development and maintenance overhead, and risks missing alerts if the Lambda function fails or throttles. You also lose the built-in alarm evaluation and SNS integration, making this far more fragile and complex than the native solution.

Install an agent on the application server that sends logs to Amazon SQS, then poll the queue with a Lambda function to trigger an email.

Why wrong: This architecture introduces an unnecessary chain of components: you would have to install an agent on the application server to forward logs to SQS, then run a Lambda function that polls the queue, parses log events, and calls SES to send an email when errors exceed a threshold. Such a design adds multiple failure points (agent, SQS, Lambda, SES) and duplicated effort—CloudWatch Logs already has an agentless ingestion path and native filtering/alarming capabilities. It also lacks the integrated, automatic retries and state machine of CloudWatch Alarms, so you would need to manually handle poller timeouts, queue retention, and idempotency for duplicate messages.

CloudWatch Logs metric filter

Why wrong: CloudWatch Logs metric filters parse log streams and emit numeric values by applying pattern matching and filters to extract metrics from log entries. This option works only when the data you want to monitor is available as textual log records, not when you already have a custom metric being published to CloudWatch. It also does not provide adaptive thresholds; you would still have to define static alarm limits against the extracted metric.

CloudWatch Metric Math with standard deviation

Why wrong: CloudWatch Metric Math lets you write expressions that combine existing metrics, such as computing a rolling average plus a multiple of the standard deviation, to produce a calculated time series. You must manually choose the number of standard deviations and periodically update the expression as the underlying business behavior changes, since the threshold value is derived from static arithmetic rather than learned from long-term patterns. This approach is labor-intensive and does not automatically adjust to seasonal or irregular changes the way an ML-based anomaly detection model does.

AWS CloudTrail Insights

Why wrong: AWS CloudTrail Insights is designed to detect unusual operational activity in your AWS account by analyzing API call patterns, such as spikes in access or errors, from CloudTrail logs. It does not ingest or evaluate custom business metrics that you publish to CloudWatch; rather, it focuses on governance, security, and operational health of AWS services. Therefore it is not a mechanism for monitoring a custom application-level metric.

Amazon Kinesis Data Firehose and AWS Lambda

Why wrong: Amazon Kinesis Data Firehose is a streaming ingestion service designed to load high-volume data into destinations like S3, Redshift, or OpenSearch; it does not natively evaluate log content or trigger alarms. To detect keywords, you would need an AWS Lambda function to inspect each record, extract metrics, and publish them to CloudWatch, and then you still must add a CloudWatch alarm and SNS topic for notification. This adds significant cost, complexity, and end-to-end latency compared to a simple metric filter, and is therefore over-engineered for this need.

AWS CloudTrail and Amazon EventBridge

Why wrong: AWS CloudTrail records API actions performed on AWS resources, such as CreateInstance or DeleteBucket, and those events can be routed to Amazon EventBridge for event-driven automation. However, CloudTrail does not see the application logs generated inside EC2 instances, containers, or Lambda functions—it only captures control-plane operations. Using CloudTrail and EventBridge would monitor AWS account activity, not the content of application log files, so it cannot satisfy the requirement of reacting to application log patterns.

AWS Config managed rule and Amazon SNS

Why wrong: AWS Config managed rules are prebuilt rules that evaluate the configuration settings of AWS resources against best practices, such as checking whether an S3 bucket has encryption enabled or whether a security group is overly permissive. Amazon SNS would only be used to notify you when a rule evaluates a resource as NON_COMPLIANT, but the rule has no awareness of application log contents. Because Config does not parse or analyze log streams, combining a Config managed rule with SNS cannot monitor application log errors or patterns, making this option fundamentally unsuited to the use case.

Enable CloudTrail log file validation.

Why wrong: Enabling CloudTrail log file validation adds a SHA-256 hash and digital signature to each log file, but it only helps detect tampering after the fact. It does not mandate a minimum retention period, nor does it prevent an IAM user or root account from deleting log objects. Therefore, it cannot satisfy the 5-year retention requirement.

Enable CloudTrail data events for S3.

Why wrong: Enabling CloudTrail data events for S3 records object-level API operations such as GetObject and PutObject, but it does not alter how existing CloudTrail logs are stored or protected. Data events are about auditing access and actions, not about enforcing immutable retention or preventing deletion. This option neither protects log files nor preserves them for a specified compliance duration.

Apply an S3 bucket policy that prohibits deletion of log files.

Why wrong: Applying an S3 bucket policy that denies s3:DeleteObject and s3:DeleteObjectVersion may stop regular IAM principals, but an account root user or a user with s3:PutBucketPolicy can alter the policy itself to circumvent it. Additionally, a bucket policy cannot prevent object overwrite via PutObject, and it does not impose a time-based WORM retention. Without Object Lock, protection is not immutable or enforceable against privileged administrators.

Use the EC2 detailed monitoring feature to collect disk metrics.

Why wrong: EC2 detailed monitoring enables 1-minute CloudWatch metrics at the hypervisor level, such as CPU utilization, network throughput, and EBS volume read/write behavior. However, these metrics do not expose guest-OS filesystem statistics like total disk space, free space, or usage percentage, because the hypervisor cannot see the operating system's filesystems. To access such in-guest data, you must install an agent inside the OS.

Use AWS Systems Manager Patch Manager to check disk space.

Why wrong: AWS Systems Manager Patch Manager automates the process of scanning EC2 instances for missing patches and installing them, but it is not a monitoring tool and does not emit periodic CloudWatch metrics for disk space. While you could run an SSM document such as AWS-RunShellScript to execute a df command on demand, that gives a one-time snapshot rather than continuous monitoring and alarming. Real-time or scheduled disk-usage monitoring requires a custom script or the CloudWatch agent, not Patch Manager.

Configure an Amazon CloudWatch metric filter on the system log.

Why wrong: Amazon CloudWatch metric filters are designed to parse log event patterns and extract numeric values or counts from structured or unstructured log lines, but they only operate on data that is actually written to log streams. Standard system logs (like /var/log/messages or Windows Event Logs) do not contain periodic disk utilization figures at a useful granularity. Unless you explicitly configure your OS to log disk usage, a metric filter would have nothing to evaluate, making this an indirect and unreliable approach for monitoring filesystem capacity.

Enable detailed monitoring on the EC2 instance

Why wrong: Enabling detailed monitoring only changes the frequency of the default EC2 metrics (CPU, network, disk I/O) from every 5 minutes to every 1 minute. The default metric set still does not include in-guest memory utilization, so even with 1-minute data, no memory values appear. To monitor memory, an in-guest agent must be installed and configured to emit custom metrics.

Use AWS Systems Manager Patch Manager to report memory usage

Why wrong: AWS Systems Manager Patch Manager automates scanning and installation of patches on managed instances; it does not collect or send performance telemetry such as memory utilization. Even though the SSM agent runs on the instance, Patch Manager's role is strictly patching and patch compliance, not metric reporting. Therefore, Patch Manager cannot help you monitor memory usage in CloudWatch.

Use AWS CloudTrail to log memory events

Why wrong: AWS CloudTrail records API activity in the AWS control plane, such as EC2 RunInstances or DescribeInstances calls, for security and auditing purposes. It does not capture guest OS events or internal metrics like memory utilization from inside an instance. Because memory usage is an in-guest metric rather than an API activity, CloudTrail logs are irrelevant to this monitoring need.

Amazon CloudWatch custom metrics

Why wrong: Amazon CloudWatch custom metrics require you to call the PutMetricData API or configure the CloudWatch agent to emit your own application-defined metrics, and you must manually design dimensions, namespaces, and dashboards. They do not automatically capture container resource utilization or provide prebuilt container-oriented views. Because the question asks for a solution with minimal setup and no custom instrumentation, custom metrics are not the intended answer.

Amazon CloudWatch Logs

Why wrong: Amazon CloudWatch Logs is where ECS container stdout, stderr, and logs collected via the awslogs log driver are shipped; it is excellent for searching, filtering, and creating alarms on log events. However, it does not inherently provide container-level performance metrics or prebuilt dashboards for CPU/memory/network utilization. Any metrics from logs would require you to build metric filters or other custom processing, which does not meet the out-of-the-box requirement.

Amazon CloudWatch Synthetics

Why wrong: Amazon CloudWatch Synthetics is designed for canary monitoring of web endpoints using Node.js or Python scripts that simulate user traffic and measure availability, latency, and UI behavior. It is not related to infrastructure or container metrics for ECS workloads. Because the question concerns containerized application metrics on ECS, Synthetics is irrelevant and does not offer prebuilt ECS dashboards or resource utilization data.

AWS CloudTrail

Why wrong: CloudTrail records API actions performed by users, roles, or services, capturing event history for governance and audit purposes. It does not ingest or expose infrastructure performance counters such as CPU utilization, and it lacks any alarm or threshold evaluation capability for operational metrics. Consequently, CloudTrail cannot trigger notifications when an RDS instance's CPU crosses a threshold.

AWS Config

Why wrong: AWS Config evaluates resource configurations against managed or custom rules to assess compliance and track changes over time, such as detecting when an RDS instance is publicly accessible. It does not collect performance data or store time-series utilization metrics, so it cannot see current or historical CPU utilization. Therefore Config cannot be used to create CPU-based performance alarms.

AWS Trusted Advisor

Why wrong: AWS Trusted Advisor inspects your account and delivers best-practice recommendations in categories like cost optimization, fault tolerance, and performance, including flags for underutilized RDS instances. However, its checks are periodic advisory reports, not a real-time monitoring service, and it does not allow you to define custom alarms with thresholds for specific metrics such as CPU utilization. As a result, Trusted Advisor cannot directly notify you when CPU exceeds a configured limit.