CCNA Monitoring and Logging Questions

Amazon CloudWatch Dashboards is the correct choice because it natively integrates with CloudWatch, which collects and stores EC2 standard metrics (CPU, network, disk) and, when the CloudWatch agent is installed on the instance, also collects custom operating-system-level metrics such as memory utilization and disk space. These dashboards can be customized to display multiple metrics in a single graph, aggregated across instances, and automatically refreshed for near-real-time monitoring. Additionally, CloudWatch Dashboards support alarm overlays and anomaly detection, making it purpose-built for visualizing application performance as a monitoring and observability tool.

For Fargate, Container Insights must be enabled to collect infrastructure telemetry such as CPU and memory utilization at the cluster, service, task, and container levels; AWS then ships these metrics to CloudWatch automatically. ServiceLens builds on that by combining CloudWatch metrics, logs, and X-Ray traces into a single service map and console, allowing you to select a trace and see the corresponding CPU/memory metric trends for that underlying container. This native integration is exactly what is required to prove whether a CPU saturation event is causing an observed latency increase in a traced request.

The absence of MFA in a CloudTrail session is a direct security-control failure because AWS relies on multi-factor authentication as a second factor to verify the caller's identity beyond long-term credentials. For sensitive actions like terminating an EC2 instance, missing MFA increases the risk that the request came from compromised keys or a stolen session. This makes the MFA status the key anomaly that warrants investigation, as it violates the security best practice of enforcing MFA for destructive operations.

The recommended approach is to first publish the custom application metric to Amazon CloudWatch using the PutMetricData API, ensuring it has the appropriate ECS service dimensions. Then, in Application Auto Scaling, create a target tracking scaling policy that references that custom metric; the policy automatically calculates the required desired count to maintain the target value, and adjusts the ECS service accordingly. This provides native, automated scaling with built-in cooldowns and no additional compute, making it the most operationally efficient solution.

The CloudWatch Synthetics canary's logs contain detailed request/response records, error stack traces, and screenshots captured during the run, making them essential for pinpointing whether a failure is caused by network errors, timeouts, or the application itself. By reviewing these logs, you can check for DNS resolution failures, TCP handshake timeouts, TLS certificate errors, or 4xx/5xx responses that indicate the problem is not with the client-side script. This is the first diagnostic step because it separates infrastructure-level issues from application-level defects.

Metric math lets a single alarm combine several API Gateway metrics. Summing 4XXError and 5XXError and dividing by Count at a 300-second period yields the stage-level error rate, so one alarm covers the whole API rather than one alarm per method or resource. This directly satisfies the 5% threshold requirement.

X-Ray propagates a trace ID through API Gateway and the downstream Lambda invocation, producing segment-level timings for each component. This granular breakdown isolates API Gateway overhead from Lambda init and execution duration, satisfying the requirement to measure end-to-end latency across both services.

Elastic Beanstalk with enhanced health reporting publishes the 'EnvironmentHealth' metric to CloudWatch, and creating an alarm on this metric allows you to react automatically when the environment transitions to states such as severe or degraded. The alarm can publish to an SNS topic to email or page the team, enabling real-time incident response without any custom code. This approach is the native, supported integration between Elastic Beanstalk health and CloudWatch observability.

DynamoDB natively publishes ConsumedReadCapacityUnits and ProvisionedReadCapacityUnits to CloudWatch at a one-minute granularity. Monitoring these metrics directly gives you a continuous view of how much read capacity is being used relative to what the table has provisioned. This is the foundational data source for any read-capacity alarm or scaling policy, and it lets you detect capacity pressure before throttling begins.

The Average statistic applied to CPUUtilization with the AutoScalingGroupName dimension gives the mean CPU percentage across all instances in the group, which is exactly what the dashboard needs to assess overall load. CloudWatch computes this by taking the CPUUtilization data points from each instance and calculating the arithmetic mean over the selected period. This is the standard and CloudFormation-idiomatic approach for monitoring an Auto Scaling group's aggregate CPU usage, and it directly answers the requirement without mixing units or extrapolating to a nonsensical total.

AWS X-Ray active tracing on both API Gateway and the Lambda functions provides end-to-end request tracing that captures every segment and subsegment — including Lambda invocation details, function execution time, HTTP status codes, exceptions, and downstream AWS service calls — allowing you to pinpoint the exact component that caused the error. When active tracing is enabled, API Gateway sends trace headers to Lambda, and Lambda automatically records the function's execution, with error details visible in the X-Ray console under the service map and trace list. This lets you filter traces by HTTP 5xx status or Lambda ERROR, drill into the affected trace to see the precise failing segment, and inspect the exception stack trace or error message, directly answering where and why the API request failed. X-Ray is purpose-built for distributed serverless applications, making it the most efficient and comprehensive option for this diagnostic task.

Exporting application logs from CloudWatch Logs to Amazon S3 and applying a lifecycle policy that transitions objects to S3 Glacier Deep Archive is the most cost-efficient way to meet a 5-year retention requirement. CloudWatch Logs storage costs roughly $0.03 per GB-month, while Glacier Deep Archive costs about $0.00099 per GB-month — a savings of nearly 97%. This makes sense for rarely accessed logs where the 12-hour retrieval time of Glacier Deep Archive is acceptable for compliance audits.

CloudWatch Logs metric filters evaluate log events in real time against a filter pattern and can emit a custom metric that increments for every matching event, here 'DuplicateTransaction'. This avoids changing the Lambda function or introducing additional services, and it leverages the transaction logs already being written to CloudWatch. A CloudWatch alarm can then monitor that metric over a 5-minute period and trigger when the count exceeds 10, providing an accurate and low-cost detection mechanism.

CloudWatch cross-account observability supports linking source accounts and Regions to a monitoring account, letting users query metrics, logs, and traces from one place while data stays in the source accounts. IAM roles control who can view the shared data, satisfying governance without copying data to a third party.

The health check grace period tells Auto Scaling how long to wait after an instance launches before it starts evaluating the instance's health status. If this value is set too high, an instance that is already failing health checks will continue running without being terminated because the elapsed time since launch has not yet exceeded the grace period. Extending the grace period can therefore leave unhealthy instances in service, which matches the described issue.

Configuring an SNS topic in the stack's notification options is the native CloudFormation mechanism for sending stack lifecycle events (e.g., CREATE_COMPLETE, UPDATE_FAILED, DELETE_IN_PROGRESS) to a pub/sub channel. You simply provide the topic ARN (up to five) when you create or update the stack, and CloudFormation publishes every stack event to it without requiring any Lambda code, custom resources, or additional infrastructure. This is the simplest and most direct way to get notified about stack changes.

The query filters for events containing 'ERROR' and then performs stats count(*) by bin(5m), which aggregates the matching events into consecutive 5-minute time buckets. The results are ordered by bucket timestamp in descending order and limited to 20 rows, so the output is exactly the count of ERROR messages for each of the 20 most recent 5-minute intervals. The bin(5m) function and the LIMIT clause together determine the time span and number of rows returned.

Creating a metric filter on the log group that extracts ERROR count is the first required action. A metric filter defines a pattern, such as the literal string 'ERROR', and evaluates each incoming log event against that pattern; every match increments a specified CloudWatch metric value. The filter can also output a custom value and unit, producing a metric that can be used for alarms and dashboards. This is the native CloudWatch Logs mechanism to translate unstructured log text into a numerical time-series metric.

Performance Insights for Amazon RDS is the direct diagnostic tool for database performance. It visualizes database load by wait states, SQL statements, and hosts, allowing you to quickly identify slow queries, lock waits, or I/O bottlenecks that are driving the ALB backend latency. This matches the scenario where application instances are healthy but the database is the constraint, making it the correct next step for root-cause analysis.

Performance Insights exposes the DBLoad metric, which represents the average number of active sessions and directly reflects query execution workload, and it can be streamed to CloudWatch for alarm creation. Per-query execution time is visible through the top SQL dashboard, allowing you to correlate load spikes with specific queries. The basic retention is included with RDS at no additional cost, making this a cost-effective and fully managed solution for monitoring query performance.

An EventBridge rule can match event patterns against CloudTrail records, for example source 'aws.ec2', detail-type 'AWS API Call via CloudTrail', and eventName 'RunInstances'. When a matching API call occurs, EventBridge invokes an SNS topic in near real time, and the event payload contains instance IDs, user identity, request parameters, and response elements. This is the native AWS event-driven pattern for reacting to EC2 API activity.

Lambda automatically emits a set of standard metrics to CloudWatch, including 'Invocations', 'Errors', and 'ErrorCount' (via enhanced metrics if enabled), so you can directly build an error-rate expression without additional setup. The correct approach is to use a CloudWatch math expression, such as 'm1/m2*100' where m1 is ErrorCount and m2 is Invocations, and then create an alarm on that expression to alert when the error rate exceeds a threshold. This leverages the native, low-latency monitoring pipeline and avoids the overhead of log-based or third-party tooling, making it the simplest and most operationally sound solution.

Publishing CloudWatch alarms to an SNS topic and applying subscription filter policies is a valid approach because SNS supports content-based filtering on message attributes. When an alarm transitions to ALARM state, it publishes a message with attributes like `state` and `severity`; each subscriber can define filter policies that match only their desired subset (e.g., `state = ALARM` with high severity). This effectively routes critical notifications to the right team while suppressing non-critical messages at the subscription level, without altering the alarm logic itself.

The Lambda service enforces a configurable timeout that caps how long a single invocation can run, with a default of 3 seconds. If the function calls a downstream HTTP endpoint that is slower than the remaining execution time, the runtime terminates the invocation and returns a timeout error to the caller. Raising the timeout to 30 seconds grants the HTTP request enough time to return a response, directly resolving the symptom described in the troubleshooting scenario.

Auto Scaling groups have a built-in notification feature that publishes messages to an SNS topic on lifecycle events like ec2-instance-launch and ec2-instance-terminate. This provides immediate, event-driven delivery of the instance ID, the Auto Scaling group name, and the event type to all subscribers (email, SMS, Lambda, HTTP endpoints). It is the simplest native way to receive real-time notifications for the exact scaling actions the company cares about.

CloudFormation natively supports an SNS topic as a stack notification option: when you specify an SNS topic ARN in the stack's NotificationARNs property, CloudFormation publishes every stack event—such as CREATE_FAILED and ROLLBACK_COMPLETE—to that topic. Subscribing an email endpoint to the topic delivers these events in near real time, giving operations teams immediate insight into resource limit failures or any other stack error. This is the only answer that directly leverages CloudFormation's built-in notification channel without needing extra services to infer failure.

An Amazon SNS topic acts as the delivery channel for CloudWatch alarm actions. By creating a topic, subscribing the team's email address, and confirming the subscription, the alarm can publish messages to that topic whenever it transitions to the ALARM state. This is the standard method to send email notifications and is a required component for the team to be alerted. Without this, the alarm would only change state and not proactively reach the team.

Amazon EventBridge is the native event router for CloudTrail API activity: CloudTrail automatically delivers every call to an event bus, and a rule with a JSON pattern can match the specific API (e.g., an unauthorized or sensitive call). The rule immediately invokes an Amazon SNS topic, which then fans out notifications via email, SMS, or other subscribers. This event-driven flow provides sub-second, real-time alerts with no polling, no custom code, and direct integration, making it the correct architecture.

Amazon Managed Service for Prometheus is a scalable, fully managed service compatible with Prometheus query language (PromQL) and remote write. It eliminates the operational overhead of running Prometheus at scale, provides durable storage, and integrates with Amazon Managed Grafana for dashboards. This is the recommended AWS-native approach for long-term metrics retention on EKS.

Enabling access logs on the Application Load Balancer is the foundational step; it delivers a raw, per-request log file containing the client IP, request URI, User-Agent, and HTTP status code for every request handled by the ALB. These logs are written in gzip-compressed files to an S3 bucket you specify, and S3 provides durable, queryable storage. Without this first step, no HTTP-level transaction data exists in S3, making any subsequent log analysis or querying impossible. This is why enabling ALB access logs is the correct primary action.

Container Insights automatically collects CPU, memory, network, and log data from EKS nodes and pods without installing custom agents beyond the CloudWatch agent DaemonSet. CloudWatch alarms evaluate the CPUUtilization metric over 5-minute periods, and CloudWatch dashboards can display both metrics and log insights queries together, satisfying the monitoring and alerting needs with minimal operational effort.

Amazon CloudWatch natively ingests Amazon RDS performance metrics—including CPU utilization, freeable memory, database connections, read/write IOPS, and replica lag—through the AWS/RDS metric namespace. These metrics are published automatically and can be visualized in CloudWatch dashboards or used to trigger alarms for proactive alerting and auto scaling actions. CloudWatch also supports publishing custom metrics and streaming RDS logs, making it the comprehensive monitoring service for RDS PostgreSQL.

Enabling ALB access logs to be delivered to Amazon S3 creates immutable, row-based log files that are ideal for large-scale retrospective analysis. Amazon Athena lets you run standard SQL directly on that S3 data using a serverless engine that charges only for the bytes scanned, and you can further optimize costs and performance by partitioning S3 objects by date or using compression. This combination is the industry-standard cost-effective approach when the goal is to perform flexible SQL queries over historical ALB logs without pre-provisioning infrastructure or paying for continuous ingestion.

Amazon CloudWatch Alarms are the correct choice because they continuously monitor a specified CloudWatch metric—such as ApproximateNumberOfMessagesVisible for an SQS queue—against a defined threshold over a configured period. When the metric crosses the threshold, the alarm changes state (OK, ALARM, or INSUFFICIENT_DATA) and can trigger an action like an SNS notification, EC2 Auto Scaling, or an arbitrary EC2 stop/terminate action. This provides the exact metric-threshold monitoring required.

Amazon CloudWatch Alarms are the correct service because they directly evaluate CloudWatch metrics, and CPUUtilization is a built-in metric emitted by EC2 instances. You can configure an alarm to transition to an ALARM state when the average CPU utilization exceeds a threshold, and then trigger actions like Auto Scaling, Amazon SNS notifications, or EC2 actions (reboot, stop, terminate). Alarm evaluation periods and statistic types (e.g., average, maximum) allow precise control over when an alarm fires, making it the natural choice for CPU monitoring.

Monitoring the 'InitDuration' metric is the direct, built-in approach because CloudWatch automatically receives this metric for every Lambda invocation that experiences a cold start. This metric reports the time the runtime spends initializing the execution environment (downloading the code, starting the runtime, and running initialization code) before the handler is invoked. It requires no custom instrumentation or querying, making it the simplest and most authoritative source for cold start duration.

Granting cloudwatch:PutMetricData only authorizes the API call; it does not construct or complete it. The Lambda function must send a MetricDatum object that includes both a MetricName and a numeric Value (or StatisticValues/Values), along with other optional fields like Dimensions and Timestamp. If these required fields are missing or empty, the API call cannot create a metric data point, regardless of how permissive the attached IAM policy is.

Amazon CloudWatch Container Insights automatically discovers and collects pod-level metrics from Amazon EKS, including CPU, memory, network, and disk utilization, and presents them through pre-built dashboards. By defining CloudWatch Alarms on these metrics, operators receive proactive notifications when thresholds are breached, making this a fully managed, integrated solution for monitoring and alerting on container resource usage.

A CloudWatch alarm is the correct mechanism because it continuously evaluates an EC2 instance's time-series metrics, such as CPUUtilization or StatusCheckFailed, against a defined threshold. When the metric crosses the threshold, the alarm state transitions to ALARM and automatically publishes a message to an SNS topic, which can deliver email, SMS, or invoke a Lambda function. Alarms can also be configured to perform EC2 actions like stop or reboot, making them the native AWS service for threshold-based metric notification.

Correct: The Application Load Balancer natively emits the HTTPCode_ELB_5XX_Count metric to CloudWatch, representing the number of 5xx responses returned by the load balancer itself. Create a CloudWatch Alarm on this metric using the Sum statistic over a period (e.g., 5 minutes) and set a threshold, optionally using a math expression to divide by RequestCount to track the error ratio. This is the simplest and most direct method because it uses existing metrics with no additional setup, latency, or cost.

Correct. When the alarm evaluates at 10:10, it considers the two most recent consecutive periods—10:05 and 10:10—both of which have CPU utilization above 80%. Since the alarm is configured with two evaluation periods and the threshold of 80%, both consecutive periods satisfy the condition, causing the alarm to enter ALARM state. At 10:05, only one period had breached, so the alarm was still OK.

Configuring CloudTrail to stream events to CloudWatch Logs provides near-real-time delivery of management events, including DeleteBucket. A CloudWatch Events (EventBridge) rule can use an event pattern to match the specific DeleteBucket API call and directly target a Lambda function as its target. This creates a low-latency, event-driven pipeline that automatically invokes the Lambda function without polling or human intervention, enabling immediate remediation or alerting.

CloudWatch alarm actions publish notifications to the configured SNS topic, but the publish operation only succeeds if the topic has at least one active, confirmed subscriber endpoint, such as an email address that has clicked the confirmation link. When subscriptions are still in PendingConfirmation state or no subscription exists, the message is silently dropped while the alarm continues to show ALARM. Therefore, even though the alarm is firing correctly, no notification reaches the engineer because the delivery path lacks a confirmed subscriber. This is the root cause.

AWS X-Ray tracing on the Lambda function provides an end-to-end view of the invocation, showing each subsegment's duration, including the time spent in external HTTP calls, AWS SDK operations, and service integrations. It automatically captures the trace for every invocation without requiring code changes (unless you need custom subsegments), and the trace timeline reveals exactly which downstream call or code block is consuming the most time. This makes X-Ray the correct tool to diagnose performance bottlenecks in a production Lambda, as it gives the per-invocation, subsegment-level detail that the other options lack.

CloudWatch Logs Insights parses JSON log events automatically, so a query can filter on the request ID field and return matching lines in seconds across the entire log group. This requires no additional infrastructure, making it the lowest-effort solution for the stated search requirement.

These CloudWatch metrics are emitted specifically for responses returned by the registred targets, such as EC2 instances or ECS tasks, after the load balancer forwards the request. By applying a Sum statistic over your monitoring window, you get the exact number of 4xx and 5xx status codes produced by your backend application, which is precisely what you need to detect target-side errors. Unlike ELB-level metrics, these don't include errors generated by the load balancer itself.

To use a customer-managed KMS key, the key policy must explicitly grant the CloudWatch Logs service principal (logs.<region>.amazonaws.com) the required cryptographic permissions: kms:Encrypt, kms:Decrypt, kms:ReEncrypt, kms:GenerateDataKey, and kms:DescribeKey. Without an Allow statement, CloudWatch Logs cannot decrypt the key for the log group, and the association or ingest operations will fail. The key policy is the sole authorization mechanism for this integration.

RDS Performance Insights computes a Database Load metric in 'average active sessions' and breaks it down by wait state, host, and individual SQL statement, so you can immediately rank queries by their contribution to the bottleneck. Enhanced Monitoring supplements this by gathering hypervisor and operating-system metrics (CPU, memory, file descriptor pressure, and network throughput) at one-second to one-minute intervals through a separate agent on the RDS instance. Together they reveal not only which query is responsible, but whether the root cause is CPU saturation, memory contention, or disk I/O, enabling a targeted fix such as adding an index or scaling the instance class.

The CloudWatch agent runs inside the guest OS and reads disk space metrics such as disk_used_percent, disk_free, and disk_used from the filesystem, then publishes them as custom metrics under the System/Linux namespace (or appropriate custom namespace) to CloudWatch. You configure the agent via the amazon-cloudwatch-agent-config.json file or AWS Systems Manager Parameter Store, and once installed it can deliver both default host metrics and in-guest disk metrics. This is the only option that actually exposes the guest-OS-level disk space data to CloudWatch, enabling you to create alarms and dashboards on values like available disk capacity.

The CloudWatch agent logs its own operational activity—including configuration errors, permission issues, network timeouts, and partial failures—to `/var/log/amazon/amazon-cloudwatch-agent/amazon-cloudwatch-agent.log`. When log events are not appearing in CloudWatch Logs, this file is the authoritative source for finding the root cause. It records detailed error messages and stack traces that are not available in the agent status output or anywhere else, making it the first place to look when troubleshooting a missing log delivery.

Fluent Bit shipping pod logs to a centralized CloudWatch Logs log group provides a single destination across accounts when combined with cross-account log sharing. CloudWatch Logs Insights supports a structured query language with fields, filter, stats, and parse commands, meeting the structured-query requirement for application logs.

The Amazon CloudWatch agent runs inside the guest OS and collects memory metrics such as mem_used_percent, mem_available, and mem_total, publishing them as custom metrics under the CWAgent namespace. It uses an IAM role for secure PutMetricData calls, can be configured via JSON, and can be centrally managed with AWS Systems Manager, making it the standard solution for OS-level metric collection.

The sampling rate directly controls the proportion of incoming requests that produce trace data. If the X-Ray SDK is configured with a low sampling rate (e.g., a small fixed percentage or a small reservoir per second), the majority of requests are intentionally skipped, resulting in sparse and often incomplete trace coverage. This matches the symptom of 'some requests traced, others not,' and is a common root cause for missing segments. Adjusting the sampling rule to a higher rate, or using a rate-based strategy tailored to traffic volume, would capture more complete traces.

VPC Flow Logs capture interface-level metadata for all IP traffic, including source and destination IPs, ports, protocol, and whether the action was accepted or rejected. During error spikes, analyzing Flow Logs via CloudWatch Logs Insights or Athena can reveal if connections to the instances are being blocked by security group rules or network ACLs, or if packets are being dropped before reaching the target. This directly identifies the root cause of ALB 5xx errors caused by network connectivity failures, rather than application-level issues.

S3 event notifications are the most direct service for this use case: they emit near-real-time events for object-level operations such as s3:ObjectCreated:*, s3:ObjectRemoved:*, and s3:ObjectRestore:*, and can deliver them to an SNS topic without any polling or forensic analysis. By configuring an SNS topic as the destination, the DevOps engineer can receive immediate notifications for each action on objects, with optional prefix/suffix filtering to reduce noise. This provides operational awareness of who/what performed an operation, which CloudTrail and Config cannot do in real time.

This is correct because Amazon EventBridge (formerly CloudWatch Events) can natively capture EMR cluster state-change events, such as the transition to TERMINATED, and invoke a Lambda function without any polling or custom code. The Lambda function can call emr:describeCluster to obtain the cluster's start and end times, compute the total runtime, and post an SNS message only when the duration exceeds three hours. This event-driven architecture is cost-effective, serverless, and decoupled, making it the recommended pattern for alerting on abnormal job completion times.

Amazon CloudWatch Logs Insights is a native query engine that runs SQL-like queries directly against log data already ingested into CloudWatch Logs, without requiring any data movement or additional infrastructure. It automatically parses structured JSON log events, discovers fields, and lets you use commands such as filter, stats, sort, and time-based aggregation for interactive troubleshooting and pattern analysis. As the logs are already collected in CloudWatch, this is the most immediate and cost-effective way to analyze application log data.

AWS CloudTrail records API activity across the account, capturing the identity, time, source IP and request details for each call. Enabling it satisfies the stem's requirement that all API calls be logged for security analysis, providing the audit trail other services do not.

The Amazon CloudWatch Agent is a software component installed inside the EC2 instance that collects operational metrics such as memory utilization, disk space and inode usage, and per-disk I/O statistics from the guest operating system. It can also collect custom application metrics and logs, and it sends them to CloudWatch via the PutMetricData API. This is the standard solution for monitoring metrics that are not exposed by the hypervisor, like memory usage, and it is the correct approach here.

The application itself can read its memory usage from the container's cgroup files (e.g., /sys/fs/cgroup/memory/memory.usage_in_bytes) or from runtime APIs, and then call CloudWatch PutMetricData to publish a custom metric. This gives you full control over the metric's namespace, dimensions (e.g., service, task ARN), and granularity. Unlike built-in or container-level metrics, custom metrics are the only way to capture memory from within the Fargate task process.

AWS CloudTrail is the correct primary service for multi-account log aggregation because it supports organization trails, which automatically capture API activity from every account in an AWS Organization and deliver the event history to a single centralized S3 bucket. This eliminates the need to configure individual trails per account, making it the native and most efficient solution for aggregating AWS API logs across accounts.

AWS X-Ray can trace Lambda requests and annotate cold starts when tracing is enabled, but it requires the function to use the X-Ray SDK and sampling to be active. X-Ray focuses on distributed request flows across services, not on measuring the execution performance of the Lambda function itself in aggregate. For an initial performance investigation, CloudWatch Logs and Metrics give the definitive invocation and duration data without extra instrumentation.

The CloudWatch agent can run as a sidecar container in the same ECS task, and with the default awsvpc network mode all containers share a localhost network namespace. Configure the agent with a StatsD stanza so it listens on port 8125, and the application simply sends UDP messages in the StatsD format—no SDK, no logging changes, and no application code modifications. The agent buffers, batches, and forwards these metric points to CloudWatch as a single API consumer, preserving the existing application behavior.

The CloudWatch agent is the correct mechanism for collecting custom metrics from an EKS cluster and emitting them to CloudWatch. By configuring the agent with a metrics collection interval and a custom namespace, you can send application and cluster-level metrics (e.g., pod CPU, memory, or custom application counters) via the PutMetricData API. This is the foundational step that makes those metrics available for dashboards, alarms, and further analysis within CloudWatch, so it is a required part of a CloudWatch-centric monitoring solution.

DatabaseConnections reports the count of client sessions currently connected to the RDS PostgreSQL instance, so an alarm threshold set at 80% of max_connections with a five-minute evaluation period detects sustained connection saturation, exactly the condition the DevOps team must monitor.

The Amazon CloudWatch Logs agent (now part of the unified CloudWatch agent) can be installed on each EC2 instance to monitor the EFS-mounted log file and push new lines to CloudWatch Logs in near-real-time. After the log group receives the entries, a metric filter can extract the '5xx' HTTP status code pattern to create a custom metric, and a CloudWatch alarm on that metric will page the team when the error rate breaches a threshold. This is the purpose-built, low-overhead solution that supports tailing, rotation, and automatic delivery.

ALB access logs are the authoritative source for request-level diagnostics because they capture every HTTP request processed by the load balancer, including the target processing time, request processing time, HTTP status, and client/user-agent data. Analyzing these logs lets you identify exactly which requests experienced slow responses or timeouts, isolate problematic targets by IP or URL pattern, and correlate with backend health. Unlike aggregated metrics, access logs provide per-request granularity that is essential for root-causing intermittent timeout issues.

The CloudWatch alarm is configured with `EvaluationPeriods: 3` and `DatapointsToAlarm: 2`. During the monitoring window, the CPU utilization never produces two breaching datapoints within any three consecutive periods, so the alarm condition remains unsatisfied. Consequently, the alarm never leaves the OK state and thus never enters ALARM.

For asynchronous invocations, Lambda can be configured with a dead-letter queue (an SQS queue or SNS topic) to receive event payloads that could not be processed after a function fails or exhausts retry attempts. The DLQ preserves the exact original event data, allowing you to inspect, replay, or archive failed records in a durable buffer. Monitoring the DLQ (for example, with a CloudWatch alarm on SQS ApproximateNumberOfMessagesVisible) directly alerts you to the presence of undelivered events. This is why the correct answer combines a DLQ with active monitoring of that queue.

The Application Load Balancer publishes the HTTPCode_ELB_5XX_Count metric to CloudWatch. Creating an alarm directly on this metric with a 5-minute period and a threshold of 100, then attaching an SNS topic for email or SMS notifications, is the simplest and most direct way to meet the requirement. No additional agents or complex configurations are needed.

The target group health check path must exactly match the application endpoint that is designed to return an HTTP 200 OK when healthy. If the path is incorrectly set to something like '/' instead of '/health', the application may return a different status code, such as a redirect or a default page, which can cause intermittent health check failures as the application's behavior changes under load. Confirming the path resolves the root cause because the health check will then probe a purpose-built endpoint that consistently returns 200.

AWS Config is the correct service for this requirement because it continuously records and evaluates the configuration of AWS resources, including S3 bucket policies, and maintains a detailed configuration timeline. It can compare the recorded configuration against desired compliance rules (e.g., ensuring a bucket is not public). With AWS Config, you can see exactly when a bucket policy was last changed and what the previous configuration was, making it ideal for auditing and compliance.

Amazon Athena is the correct service for interactively querying ALB access logs directly from S3 without loading data into a database. The logs are stored as gzipped text files in a partitionable layout (AWSLogs/account-id/elasticloadbalancing/region/yyyy/mm/dd), which can be registered as a table in Athena using JSON or CSV SerDe. With Athena's SQL, you can analyze request patterns, error rates, latency, and client behavior by writing queries against the log fields, and partitioning or partition projection keeps query costs low. This makes Athena the natural final step after enabling ALB access logs and storing them in S3.

The CloudWatch agent runs on each instance to collect system metrics and application logs, then ships them to CloudWatch. This delivers the managed monitoring service the company requires, replacing Nagios without self-managed infrastructure, and satisfies the instance health, metrics and logs monitoring requirement.

Checking the backend service's application logs in CloudWatch Logs is the correct initial action because it provides direct visibility into application errors, database query execution times, and slow transactional paths. These logs, combined with ECS task metrics and ALB access logs, help isolate whether the high latency is due to application code, database contention, or an upstream dependency. Logs are the least intrusive and most informative diagnostic step, enabling an evidence-based decision before changing infrastructure.