CCNA Monitoring and Logging Questions

The central S3 bucket needs a resource-based policy that explicitly grants the source accounts' log-delivery services (e.g., CloudTrail, VPC Flow Logs) permission to write objects and read the bucket ACL. Without this bucket policy, cross-account writes from other accounts will be denied by default. The policy must reference the source account IDs or the organization ID and include conditions like aws:SourceAccount or aws:SourceArn to prevent confused deputy attacks. This is a mandatory step to enable centralized log collection.

EventBridge matches the PutBucketPolicy API call from CloudTrail and routes it to an SNS topic, giving near-real-time notification without polling. This is more efficient than scheduled log analysis or S3 event notifications, which do not cover bucket policy changes.

A CloudWatch Logs metric filter is applied to a log group in near-real time as log events are ingested, and it uses pattern syntax to count occurrences of the string 'ERROR' and emit a custom metric (e.g., ErrorCount) for that log group. The CloudWatch alarm is then configured on that custom metric with an evaluation period of 5 minutes, so if the number of ERROR log lines within a 5-minute interval exceeds the configured threshold, the alarm state changes to ALARM and can trigger an SNS notification. This is the standard, fully managed mechanism for log-pattern-based alerting because it does not require any custom code or additional infrastructure, and it integrates directly with CloudWatch alarm actions.

Placing a single S3 bucket in a centralized logging account with a bucket policy that grants s3:PutObject to principals in all source accounts is the most efficient pattern because CloudTrail, VPC Flow Logs, and similar services can deliver logs cross-account natively without additional moving parts. The bucket policy can restrict writes using aws:SourceArn or aws:SourceAccount conditions to prevent the confused-deputy problem, and the central account owns objects for unified lifecycle and access control. This direct-write model achieves lower latency and zero maintenance compared to middleware or copying mechanisms.

ALB access logs capture full request-level detail for every HTTP request the load balancer receives, including the exact HTTP response code returned to the client (e.g., 503) and the target processing time, which is the time the EC2 instance took to respond. By filtering for 503 responses and correlating them with target IPs and timestamps, you can confirm whether errors originate from unhealthy targets, overloaded instances, or misconfigured routing. This is the most direct diagnostic because access logs are designed to expose the request/response path, rather than merely indicating that a threshold was crossed.

Instance status checks detect OS-level problems such as failed system boot, kernel panic, or filesystem corruption. The instance's system log (console output) shows the boot sequence and kernel messages, while application logs streamed to CloudWatch Logs reveal software-level errors that may have caused the failure. Reviewing both gives the evidence needed to identify the root cause before taking any corrective action.

CloudTrail's built-in log file validation creates hash-chained digest files that are digitally signed with a private key, and you can verify them with the public key published by AWS. The CloudTrail service emits the DigestDeliveryFailed metric to CloudWatch when it cannot deliver a digest file, which is often the first sign of tampering or a delivery problem. Creating a CloudWatch alarm on this metric gives you immediate, proactive notification without building custom code.

AWS CloudTrail records all management API calls in the account, including failed attempts, with metadata such as the IAM principal, source IP, event name, and error codes. Amazon EventBridge can be configured with a rule whose event pattern matches CloudTrail's api_call events and a filter condition on errorCode, routing the matched events to an SNS topic for real-time alerting. This combination is purpose-built for monitoring failed API calls.

fields @timestamp, @message | filter @message like /ERROR/ applies a regular expression filter to the raw message text, returning only the individual log events that contain the substring 'ERROR'. This directly mirrors the behavior of the CloudWatch Logs metric filter pattern "ERROR", allowing you to see the exact events that would increment the metric. It is the appropriate query for testing whether the pattern matches the intended production logs before creating or updating the metric filter.

Increasing the number of evaluation periods to 3 with a 1-minute period means the alarm must observe the replication lag exceeding the threshold for three consecutive datapoints (three consecutive minutes) before entering ALARM state. This creates a temporal smoothing effect that filters out brief, self-correcting spikes in AuroraReplicaLag, which are often caused by momentary write bursts or replica catch-up delays. CloudWatch evaluates all three most recent datapoints when determining alarm state, so sustained high lag triggers the alarm, while isolated outliers do not, directly reducing false positives without changing the sensitivity to genuine long-duration lag.

A CloudWatch Logs subscription filter can be configured with a Lambda function as its destination, enabling real-time processing of log events as they arrive. When a log event matches the filter pattern, CloudWatch Logs invokes the Lambda function asynchronously, passing the event payload (base64-encoded and gzipped) for your custom logic to parse and forward. This is a native, low-latency pattern that satisfies the requirement to filter and stream logs in real time, and it is a widely recommended approach for building log-processing pipelines.

Amazon Kinesis Data Firehose is a fully managed streaming ingestion service that can receive log events directly from a CloudWatch Logs subscription and deliver them near-real-time to centralized destinations such as Amazon S3, Amazon Redshift, or Amazon OpenSearch Service. It automatically handles buffering, compression, and encryption, which reduces cost and operational overhead. This makes it the ideal component for aggregating logs from multiple AWS accounts into a single, queryable data lake for centralized analysis.

CloudWatch automatically emits the CPUUtilization metric for each EC2 instance, expressed as a percentage, so an alarm can directly evaluate it. Configuring the alarm with a threshold of 90% for five consecutive evaluation periods (5-minute periods, or 1-minute if detailed monitoring is enabled) ensures the alert only fires on sustained load, not transient spikes. The action sends an SNS notification to a topic with an email subscription, which is the canonical AWS approach for metric-based alerting.

The AWS X-Ray trace map is the correct tool because it visualizes each service as a node and the connections between them as edges, with latency metrics for each edge. This directly reveals whether the identified slowness stems from network communication between services (for example, high I/O wait or retries) rather than from code execution inside a single service, allowing the DevOps team to pinpoint the exact segment of the request path that is underperforming.

The IAM user must have the cloudwatch:GetMetricStatistics permission to call the CloudWatch API and retrieve metric statistics. If the IAM policy attached to the user does not explicitly allow this action, the request is denied and no CPUUtilization data points are returned. Since the namespace, metric name, dimensions, and period are all valid, the most plausible reason for the lack of data is that the IAM permission is missing.

AWS X-Ray traces requests end-to-end from API Gateway to Lambda and downstream services like DynamoDB, capturing segments, sub-segments, and annotations that reveal where latency is consumed and which component is returning errors. By enabling X-Ray on API Gateway and Lambda, the DevOps engineer can inspect trace timelines, service maps, and error rates per operation to pinpoint performance bottlenecks and failed invocations. This provides correlated, request-level observability that CloudWatch aggregate metrics alone cannot offer, making it a correct component of a comprehensive monitoring solution.

Enabling ALB access logs and storing them in Amazon S3 records every request with fields such as elb_status_code, target_status_code, request_processing_time, target_processing_time, and response_processing_time, as well as the exact request path and user agent. By querying these logs, you can identify the specific HTTP response codes (including the 503s), observe patterns by path or client, and determine whether the timeouts occur in the load balancer or at the target. This is the definitive diagnostic step to isolate the cause of intermittent 503s.

High-resolution metrics allow one-second granularity, and combining a short evaluation period with M-out-of-N datapoints to alarm makes the alarm evaluate recent error data quickly. This directly addresses the delay and sparsity of custom metrics during rapid spikes, improving alarm responsiveness.

Lambda's execution role needs `logs:CreateLogGroup` and `logs:CreateLogStream` before `logs:PutLogEvents` can succeed, since the log group and stream must exist first. Without these actions, the function cannot create its destination, so writes fail regardless of the PutLogEvents permission. This satisfies the stem's requirement for the missing write-enabling actions.

Amazon CloudWatch natively ingests the `ApproximateNumberOfMessagesVisible` metric that SQS publishes every minute, making queue depth directly measurable. A CloudWatch alarm that transitions to ALARM state based on this metric can be attached to a scaling policy in EC2 Auto Scaling (for step or simple scaling), or you can use a target tracking policy with a custom metric. This is the standard, supported mechanism for scaling compute resources based on queue backlog.

The query results show a sharp upward spike in the error count in the most recent time bins, jumping from 1 to 12, which is a clear and significant acceleration in the error rate over the last 15 minutes. This trend is not random fluctuation; the consistent climb in the final bins indicates an emerging incident that requires immediate attention. The slope of the line in the visualization confirms the error rate is increasing, not just an isolated outlier.

Amazon RDS Performance Insights is the correct choice because it provides a database-focused dashboard that visualizes the DB Load metric in units of Average Active Sessions (AAS), directly correlating temporal load spikes with the specific SQL statements, waits, hosts, and users responsible. This enables you to drill down into individual slow queries and diagnose performance degradation without needing to manually parse slow query logs or instrument application code.

Amazon CloudWatch Dashboards are the native solution for building customizable operational views that aggregate metrics from AWS services, including EC2 auto scaling groups, load balancers, and custom application metrics. They support real-time graphing with automatic refresh, can combine multiple metrics, alarms, and logs into a single pane of glass, and allow cross-account or cross-region aggregation. With built-in integration for Auto Scaling group metrics like average CPU utilization and healthy host counts, CloudWatch Dashboards are the appropriate choice for a critical application's real-time operational monitoring.

AWS X-Ray traces requests as they flow through a distributed application, providing end-to-end visibility into latencies, errors, and dependencies across microservices running on Amazon EKS. By instrumenting the application with the X-Ray SDK, you can identify the specific service or database call causing performance degradation. X-Ray's service graph and trace timelines reveal exactly where requests are spending time, making it the correct choice for troubleshooting application-level performance issues.

The awslogs driver natively ships ECS container logs to CloudWatch Logs, where Logs Insights queries across all 50 services and metric filters trigger alerts on error patterns. This satisfies centralised querying and alerting without managing extra infrastructure.

The Throttles metric is the definitive CloudWatch counter for how many invocation requests Lambda rejected because the function had no available concurrency capacity. Each time Lambda receives a request while the function or account is over its concurrency limit, it increments Throttles and returns a 429 TooManyRequestsException, prompting SDK retries or event-source retry logic. For a slow-running function, elevated Throttles explains intermittent delays caused by client-side retries, making this the correct metric to inspect when troubleshooting such issues.

HTTPCode_Target_5XX_Count is the correct choice because it represents the number of HTTP responses with a 5xx status code that were returned by registered targets (e.g., EC2 instances) to the Application Load Balancer. This metric excludes 5xx errors generated by the ALB itself, such as 502 Bad Gateway or 503 Service Unavailable from the load balancer when no healthy targets exist. By checking this metric with a Sum statistic, the engineer can directly quantify application-level server errors and distinguish them from load-balancer-level failures.

Amazon CloudWatch Logs cross-account subscriptions let you forward log events from multiple source accounts to a central destination (via a Kinesis Data Stream or Data Firehose) using subscription filters, enabling near-real-time aggregation of application logs. This is the correct pattern because it directly receives application log streams from existing CloudWatch Logs agents and routes them to a central account for storage and analysis.

Correct. The Lambda runtime (for both the AWS-provided runtimes and custom runtimes that use the Runtime API) intercepts all output written to stdout and stderr and automatically streams it to CloudWatch Logs under the log group /aws/lambda/<function-name>. This happens regardless of whether the function completes successfully or crashes, so logging to stdout/stderr is the standard, documented way to generate logs. Each invocation gets a unique log stream, and the exact log line format can include request IDs if you also log the Lambda context object, but the capture itself requires no extra configuration beyond the Lambda service execution role's CloudWatch Logs permissions.

Synchronous dependencies like database queries and external API calls are the classic cause of elevated application latency; the end-user response time becomes the sum of all blocking calls in the request path, and a single slow query (e.g., missing index, lock contention, or throttled API) holds up the entire page. This pattern usually shows as high response times with low CPU and network utilization on the application instances, because threads are parked waiting for the downstream I/O to complete. In an Auto Scaling environment, simply adding instances won't help while the database or API service remains the bottleneck.

A CloudWatch Logs metric filter continuously scans new log events as they arrive in the log group and increments a custom metric whenever a pattern such as 'ERROR' or a specific error code appears. This metric can then drive a CloudWatch alarm with an associated SNS topic, providing a near-real-time notification without building any separate ingestion pipeline. Metric filters are the native, low-latency mechanism for monitoring textual patterns in logs.

CloudWatch dashboards are not region-bound artifacts: each widget can explicitly specify a different source region, and metric math can combine those cross-region metrics within a single expression, for example summing SuccessPercent or averaging Duration across all canary regions. This natively aggregates the existing Synthetics metrics without duplicating canaries, running Lambda functions, or parsing logs. It is the intended, low-operational-overhead mechanism for a consolidated cross-region view and requires no custom infrastructure.

Configuring an SNS topic as a stack notification option delivers every CloudFormation stack event, including ResourceStatusReason for the specific resource that failed, satisfying the requirement to identify the failing resource. Subscribing an email or Lambda endpoint to that topic then surfaces the failure notification automatically.

The ALB emits TargetResponseTime only when it actually processes requests. For any 5-minute interval in which no request was routed through the load balancer, CloudWatch receives no samples and therefore publishes no datapoint. The get-metric-statistics output contains a datapoint only for each period with at least one request, so periods with no traffic are simply missing from the result rather than appearing as zero. This exactly explains why fewer datapoints than expected are returned.

Removing the count() and bin() aggregation and running a query that returns the raw @timestamp and @message fields around 12:00 will display the actual error strings, stack traces, and exception types that caused the spike. This is the definitive method for root-cause analysis because it lets you see exactly what the application logged at the moment of failure, such as a TimeoutException, a 500 Internal Server Error, or a specific failed database call. You can then filter further using regular expressions or parse commands to isolate the common pattern.

CloudTrail writes log files to S3 as compressed JSON objects, and S3 Event Notifications fire as soon as each object is created, triggering a Lambda function in near-real-time. The Lambda can decompress the log file, parse individual events, and apply precise filters—such as specific event names, source IPs, or IAM principals—before publishing only the high-risk actions to SNS. This serverless, event-driven pattern scales automatically with account activity and avoids the cost and noise of notifying on every raw CloudTrail event, making it both efficient and cost-effective for high-volume accounts.

CloudFormation emits stack status change events to CloudWatch Events (Amazon EventBridge) whenever a stack transitions to a terminal state. A rule can filter for detail-type 'CloudFormation Stack Status Change' and the 'status-detail' of 'CREATE_FAILED', then route the event to an SNS topic. This is the native, event-driven mechanism for receiving notifications about stack creation failures, and it includes the stack name and status in the event payload.

SCPs set the maximum permissions for member accounts, so denying retention changes except for a governance role prevents developers from shortening retention. Combined with a StackSet or Config rule that establishes the 400-day baseline, this gives centralized, drift-resistant enforcement across all accounts, including future ones, which matches the requirement.

Instrumenting the application with AWS X-Ray creates an end-to-end trace for each user request as it traverses your application, generating a service map and detailed segments/subsegments for each downstream call (e.g., web APIs, SQL queries, external HTTP calls). This lets you pinpoint which specific operation contributes the most latency on EC2, including CPU-bound code vs. I/O wait, and correlate trace data with host metrics. Unlike other options, X-Ray provides the distributed tracing needed to identify and reason about internal request bottlenecks in a complex application.

Amazon CloudWatch Logs is the correct choice because it can centrally aggregate logs from multiple AWS accounts, Regions, and on-premises sources via the CloudWatch Logs agent, Kinesis Data Firehose, or subscription filters. It provides native log analytics with Logs Insights, metric filters to create custom metrics, and CloudWatch Dashboards to visualize log-derived data in real time. This directly satisfies the need for centralized collection, analysis, and dashboard visualization without requiring additional services.

AWS CloudTrail is the correct service for auditing IAM policy changes because it records every API call as an event, including the identity of the requesting principal, the timestamp, source IP, request parameters, and response elements. You can view these events directly in the CloudTrail event history or create a trail for long-term storage in S3 and analysis via CloudWatch Logs or Athena, making it the authoritative audit source.

IteratorAge is the correct metric to monitor for Kinesis-triggered Lambda because it directly measures the age of the oldest unprocessed record, reported in milliseconds. When the Lambda consumer can't keep up with the shard's data rate, the iterator age grows, indicating that stream records are sitting unprocessed for longer — a clear sign of a processing bottleneck or backlog. A sustained increase in IteratorAge typically drives alarms for scaling out the Lambda function or increasing the number of shards, making it the definitive indicator of stream processing lag.

CloudWatch Logs Insights runs a query like `fields @timestamp, @logGroup | filter @message like /ERROR/ | stats count(*) by @logGroup` across all specified log groups in the selected time range, and the exact same query can be added as a dashboard widget using the 'Add to dashboard' option. This gives real-time results without any per-group configuration, and the dashboard automatically reflects the current set of log groups as long as they are included in the query scope. It is the intended native mechanism for interactive multi-group log analysis, making it the correct choice for this scenario.

The correct action is to explicitly associate your customer-managed AWS KMS key with the CloudWatch Logs log group, either through the console or by calling the `AssociateKmsKey` API. This association defines the encryption boundary at the log group level and applies to all existing and future log streams within that group. The key-policy prerequisites must already be in place, but the actual enabling step is this association.

NumberOfMessagesPublished is the correct Amazon SNS CloudWatch metric for monitoring message volume. It increments for every successful publish operation to an SNS topic, including individual messages sent via the Publish API and each message within a PublishBatch request. This metric provides the exact count of messages accepted by the topic, making it the appropriate choice for tracking publication activity.

Amazon CloudWatch is the native monitoring service for AWS, collecting metrics, logs, and events from AWS resources and applications. The CloudWatch Agent, installed on EC2 instances or on-premises servers, can collect memory utilization metrics (such as mem_used_percent) and publish them as custom metrics to CloudWatch, enabling alarms and dashboards. Without the agent, standard EC2 metrics include CPU, disk, and network but not memory, so using CloudWatch with the agent is the appropriate solution.

The metric filter pattern is the core of the extraction process: it defines exactly which log events should be matched and how the metric value is derived, such as counting occurrences of a 4xx or 5xx status code. For example, a pattern like "[*, _, _, status_code]" or a JSON pattern like "{ $.status_code = 4* }" is needed to parse the relevant field correctly from the log entry. If the pattern is not defined, CloudWatch Logs has no way to know which log lines correspond to an HTTP status code or what value to emit for the CloudWatch metric.

Pod memory utilization directly shows memory usage per pod compared to its configured limit, which is the exact condition that triggers the kernel's out-of-memory killer. When a container's working set (container_memory_working_set_bytes) exceeds its memory limit, the OOM killer terminates it with exit code 137, so plotting this metric against the limit surfaces the specific pod(s) at fault and helps correlate with OOMKilled events in kubectl get pods.

CloudWatch Logs cross-account subscription allows a central (destination) account to create a destination policy and use subscription filters in source accounts to forward log events in real time to a central log group or a Kinesis Data Streams/Firehose pipeline. This feature natively supports aggregating logs from multiple AWS accounts into a single location, providing centralized monitoring and analysis. It directly meets the requirement to centralize logs from multiple AWS accounts, making it the correct choice.

ApproximateNumberOfMessagesVisible is the correct CloudWatch metric for monitoring queue depth because it reports the number of messages available in the SQS queue for immediate retrieval by consumers. This value directly reflects the backlog of work waiting to be processed, making it the standard metric used for autoscaling consumers or triggering alarms. It is approximate due to SQS's distributed architecture, but it is polled frequently enough to provide a reliable real-time indicator of queue pressure.

A CloudWatch alarm on CPUUtilization with a five-minute period and 80% threshold, notifying via Amazon SNS, directly matches the stated requirement to alert when utilisation exceeds 80% for more than five minutes, enabling investigation of the daily 10:00 AM spike.

The ApproximateNumberOfMessagesVisible metric of the dead-letter queue is a native SQS metric that reports the number of messages available for retrieval. When the redrive policy moves messages from the source queue to the DLQ after the maximum receive count is exceeded, this metric immediately increases. Creating a CloudWatch alarm on this metric provides a direct, near-real-time signal that messages are failing processing, and you can trigger an SNS notification or other action from the alarm.

Custom metrics are not emitted by default by EC2; they require an explicit mechanism such as the CloudWatch agent or direct PutMetricData calls from the application. If the agent is not installed or its configuration file (common for statsd or collectd) is missing/invalid, no metric data will be sent even though the application is running. This is the most common root cause when an application expects to send custom metrics but nothing appears in CloudWatch, because without the agent’s collection loop, nothing triggers the metric submission.

Amazon RDS Performance Insights is the correct choice because it is a dedicated database performance tuning feature that visualizes database load and provides granular, per-query metrics. It breaks down DB load by wait events, SQL statements, and hosts, directly surfacing the exact query text and execution statistics (e.g., rows returned, latency) causing high load. This allows a DevOps engineer to identify problematic queries quickly, unlike network or API-level logs.

RDS Performance Insights is the correct approach because it provides a database-load dashboard that correlates wait events, SQL statements, and hosts in real time, allowing you to pinpoint the exact queries causing bottlenecks. Enhanced Monitoring complements this by delivering OS-level metrics—including CPU, memory, file I/O, and process lists—from the underlying hypervisor, which helps identify resource saturation that affects query performance. Together, these services give both the query-level and system-level telemetry required to diagnose slow PostgreSQL performance.

EventBridge rules match CloudTrail management events by API name, so a rule filtering StopLogging and UpdateTrail invokes a target such as SNS within seconds of the call. This delivers the real-time detection of tampering with CloudTrail's own configuration that the scenario requires.

AWS CloudTrail records all API calls made by IAM users as events, and CloudWatch Events (now Amazon EventBridge) can be configured with event patterns to match specific actions. This integration enables real-time notifications by routing matched events to an SNS topic or Lambda function. Thus, CloudTrail provides the audit log while CloudWatch Events performs the filtering and alerting.

Amazon EventBridge is the correct service because it is a serverless event bus that natively captures AWS service events, including CloudFormation stack lifecycle changes (CREATE, UPDATE, DELETE), and delivers them to targets like SNS, Lambda, or SQS for immediate action. EventBridge rules filter on resource type, event detail type, and other JSON fields, allowing you to build precise event-driven workflows without custom polling. This makes it the standard, low-latency solution for reacting to CloudFormation events in real time.

Amazon EventBridge can natively consume CloudTrail management events and evaluate them against a rule with an event pattern that matches specific API calls such as StopLogging or UpdateTrail. Because the rule is event-driven, it triggers an SNS topic within seconds of the incident, enabling immediate notification to security operations. This approach requires no polling or configuration state evaluation, making it the most direct real-time mechanism for responding to changes to CloudTrail itself.

The X-Ray daemon must be deployed as a sidecar container in the ECS task definition when using the Fargate launch type. The SDK only emits UDP trace data to localhost:2000; without the daemon listening, those UDP packets are silently dropped and no segments ever reach the X-Ray service. Fargate does not run a host-level X-Ray agent, so the task definition must explicitly include the daemon container and the application must be configured to communicate with it via the daemon's port.

The source account's CloudWatch Logs subscription filter is the mechanism that continuously streams matching log events to a destination such as an OpenSearch ingestion pipeline or a Kinesis stream. If this filter was accidentally removed, disabled, or its destination ARN changed, log forwarding for that account ceases even though the logs remain in CloudWatch Logs. Verifying and if necessary recreating the subscription filter and its destination policy is the correct first step to restore the flow.

An EventBridge rule with an event pattern that matches the AWS API-call event for 'CreateAccessKey' (specifically detail.eventSource for iam.amazonaws.com and detail.eventName) synchronously triggers an SNS topic, delivering email or other notifications in near-real-time. This is the natively supported pattern for reacting to CloudTrail API activity, as CloudTrail forwards events to EventBridge, and it is fully serverless with no polling or log-parsing required.

EventBridge is a serverless event bus that captures AWS service events, including CloudFormation stack status changes. You can create an event rule with a pattern matching CloudFormation events such as CREATE_FAILED or UPDATE_COMPLETE, and route them to targets like SNS, Lambda, or Step Functions. This provides near real-time, event-driven notifications for CloudFormation lifecycle changes, making it the correct service to detect and act on these events.

For a three-tier web application behind an ALB, the correct metric to alarm on for backend errors is HTTPCode_Target_5XX_Count, which counts the number of HTTP 5xx responses sent by registered targets. You must verify that the alarm uses this metric and that the threshold is aligned with your accepted error budget—for example, alarm after 10 errors in 5 minutes—to avoid noisy alerts from transient issues. This metric directly reflects the health of your EC2 instances as the target group, making it the appropriate signal for detecting application failures.

This bucket policy must explicitly grant the CloudTrail service principal from each source account permission to write objects, typically via s3:PutObject, and also add s3:GetBucketAcl to allow CloudTrail to verify ownership. Without these cross-account permissions, CloudTrail in other accounts cannot deliver logs to the bucket, so this step is a mandatory prerequisite for any centralized log aggregation. The policy should also include a condition that restricts access to specific CloudTrail resources or source accounts to prevent unauthorized writes.

A CloudWatch Logs metric filter parses each incoming log event in real time, incrementing a custom (or extracted) metric whenever a log line matches a pattern (e.g., contains "ERROR" or a JSON field). You can then create a CloudWatch Alarm on that metric with an appropriate threshold, period, and statistic (e.g., Sum of errors over 5 minutes). This approach provides native, serverless, low-latency alerting without additional compute, and it is exactly the intended use case for detecting error rates from logs.

CloudWatch Synthetics enforces a maximum execution time per canary run (default 2 minutes, configurable up to 14 minutes). If the script's code, including any synchronous HTTP requests or Puppeteer operations, exceeds this limit, the run is terminated with a timeout error. Similarly, if the memory allocated to the canary's Lambda function is exceeded, the process can be killed, which also surfaces as a timeout or failure. Monitoring these metrics directly identifies whether the script itself is the bottleneck.

A CloudWatch Dashboard is a customizable operational view that consolidates CloudWatch Logs insights, metric graphs, and alarm states into a single pane. For an ECS workload, you can combine ECS service-level metrics, container instance metrics, and log-group-based insights to visualize application health and troubleshoot in near real time. This directly satisfies the requirement to display logs and metrics, making it a valid monitoring component.

RDS automatically emits the CPUUtilization metric to CloudWatch in the AWS/RDS namespace for every database instance, with no setup or configuration required. This metric is collected from the hypervisor at the instance level and is available in the CloudWatch console, enabling alarms and dashboards immediately after the database is provisioned. Basic monitoring is included as part of the service, and you can optionally use detailed monitoring or Enhanced Monitoring for faster granularity.

Enhanced Monitoring delivers OS-level metrics for the RDS host at up to one-second granularity, while Performance Insights provides database load per wait event, per SQL, and per host, enabling you to link slow API calls to specific queries and bottlenecks. Together they let you determine whether the issue is CPU saturation, storage I/O, lock waits, or a poorly performing statement, and then drill into the top SQL contributing to database load. This is the targeted diagnostic combination for an RDS-backed API performance problem.

The ALB routes requests only to targets that have successfully passed their configured health checks. If health check failures occur—due to an incorrect health check path, a timeout threshold being too low, or an application dependency failing—the corresponding instances are marked unhealthy and removed from the rotation. When the number of healthy targets drops below the minimum needed (typically zero healthy targets in a target group), the ALB returns HTTP 503 Service Unavailable. This can happen without CPU or memory utilization rising, because health checks validate application-level readiness, not just resource utilization.

Correct. Amazon EventBridge captures Step Functions execution state changes (e.g., 'ExecutionStarted', 'TaskStateEntered', 'ExecutionFailed') in near real-time. These events can be used to build a CloudWatch dashboard that shows the current step, duration per step, and errors, meeting all requirements without custom instrumentation.

The correct approach is to enable the RDS MySQL slow query log by setting slow_query_log=1 and long_query_time in the DB parameter group, then configure RDS to stream those logs to a CloudWatch Logs log group. Once the log events are flowing, you create a CloudWatch Logs metric filter—patterned to match the slow query log format, such as lines containing 'Query_time'—to count matching events as a custom metric, and then set a CloudWatch alarm to trigger when the count exceeds a threshold.

Fluent Bit is a lightweight, high-throughput log processor that runs as a DaemonSet, placing one pod on every cluster node. It automatically discovers and collects container stdout/stderr logs without requiring application-side changes, making it effectively agentless for application teams. It supports multi-line log parsing and its native CloudWatch Logs output plugin streams logs directly to CloudWatch Logs for real-time aggregation. This is the recommended pattern for comprehensive logging on EKS.