CCNA Monitoring and Logging Questions

Instrumenting with the AWS X-Ray SDK is the correct approach because X-Ray traces individual requests as they traverse services, generating a trace ID that propagates across HTTP headers and AWS SDK client calls. The X-Ray console provides a service map and trace timelines, segment and subsegment views that break down latency for each downstream call, letting you pinpoint the exact service or resource causing the slowdown. You can also annotate traces with request metadata and set sampling rules to balance overhead and observability.

AWS CloudTrail records all CloudFormation management-plane API calls as event payloads, including the calling identity, request parameters, and timestamp. Amazon CloudWatch Events (now EventBridge) can consume those CloudTrail events using a rule that matches on source: aws.cloudformation and specific event names like UpdateStack or DeleteStack. That rule can then route the matched event to an SNS topic, producing immediate, precise notifications of who performed the stack operation and what operation occurred. This is the native, event-driven pattern for CloudFormation activity monitoring.

Calling PutMetricData with StorageResolution=1 creates a high-resolution custom metric with 1-second granularity, making the data available for CloudWatch alarms in as little as 10 seconds instead of the 60-second standard resolution. This lower storage resolution is the key to detecting critical issues faster because CloudWatch can evaluate alarms at a 10- or 30-second period. Without this parameter, your metrics default to 60-second resolution and alarm latency remains as high as a minute.

Amazon CloudWatch Alarms are the action engine that watches a single CloudWatch metric, a math expression, or an anomaly detection band over a specified time period, then transitions to an ALARM state when the observed value breaches a defined threshold. You can configure the alarm to publish to an SNS topic, trigger Auto Scaling, or execute an EC2 action such as a reboot when the anomaly condition persists. In this solution, the alarm consumes the band produced by CloudWatch Anomaly Detection and calls the monitoring hook when unusual metric behavior is detected.

Amazon EventBridge is a serverless event bus that can natively consume Auto Scaling group state changes such as EC2 instance launch, terminate, and lifecycle hook notifications. Using event patterns that filter on the aws.autoscaling source and detail types like EC2 Instance Launch Successful, EventBridge matches relevant events in near real time and routes them to targets such as SNS topics for email/SMS alerts. It is the correct service because it provides built-in event ingestion, filtering, and routing without requiring custom code or external monitoring agents, making it ideal for health and lifecycle monitoring.

An ALB returns 503 Service Unavailable when it cannot handle incoming requests due to scaling activity or when all targets are unhealthy. During a traffic surge, the ALB nodes scale up by provisioning additional capacity, and during this scaling activity the ALB may temporarily reject or fail to accept new requests, causing clients to receive 503 responses. This matches the scenario described, making it the correct explanation for the issue.

The ECS task definition's memory limit is a hard limit enforced by Docker; when the container's memory utilization consistently exceeds 80%, it is likely approaching or hitting that ceiling, leading to OOM kills or severe performance degradation. Increasing the memory limit lets the container allocate more heap or working set, directly relieving the memory bottleneck. This is a vertical scaling action, and you must also ensure the EC2 instance has enough free memory to support the increased limit.

The CloudWatch Embedded Metric Format encodes custom metric values inside a structured JSON log event; when the Fargate task's awslogs driver sends that log to CloudWatch Logs, CloudWatch automatically extracts the declared metrics into the specified namespace for graphing and alarms. This requires no separate daemon, sidecar, or SDK call—developers only add a serialization layer to application logging, making it the minimal-code path you asked for.

CloudWatch Logs Insights queries multiple log groups in one request using its query syntax, filtering and aggregating events directly within CloudWatch Logs. This satisfies the requirement to search several log groups for an error pattern without exporting data.

Memory exhaustion caused the timeouts while CPU stayed below target, so CPU-based target tracking never scaled out. A second target tracking policy on memory utilisation triggers scaling on the actual bottleneck, preventing garbage collection pauses during future spikes.

Amazon CloudWatch Logs subscription filters can deliver log events in real time to a Kinesis data stream, which then uses a Lambda event source mapping to process each record. The stream acts as a durably buffered, highly scalable ingestion layer that decouples producers from consumers and preserves event ordering per shard. This is a fully supported path for real-time log processing and allows multiple Lambda functions or other consumers to read the same stream independently.

Subscription filters apply a filter pattern and forward matching log events to a destination, which can be a CloudWatch Logs destination in another account. This satisfies the cross-account aggregation requirement by streaming each account's logs into the single central logging account.

CloudWatch alarms are the native way to react to metric changes: the CPUUtilization metric for EC2 is published every 5 minutes with basic monitoring, so setting a period of 5 minutes ensures the alarm evaluates the average CPU utilization over each interval. A threshold of 90 means the alarm state becomes ALARM when the CPU utilization statistic exceeds 90%, and you can attach an action such as an SNS notification or Auto Scaling policy. This leverages a built-in metric with a well-established alarm evaluation model, making it the correct and simplest approach.

AWS Config continuously records configuration changes and evaluates them with managed rules, including s3-bucket-logging-enabled, which verifies server access logging is turned on for each bucket. When a bucket is created or its logging configuration changes, AWS Config re-evaluates in near real time and can publish compliance results to an SNS topic, triggering notifications. This provides a fully managed, automated, and near-real-time compliance check, making it the appropriate solution.

This is the correct solution because CloudWatch Logs supports server-side encryption using a customer-managed KMS key that you can associate directly with the log group. When you create a log group or call the AssociateKmsKey API, you supply the key ARN, and CloudWatch Logs uses that key to encrypt all new incoming log events. This gives you full control over key rotation, access auditing, and lifecycle management, which is exactly what a requirement for customer-managed encryption requires. Note that the key must exist in the same AWS Region as the log group and its key policy must grant CloudWatch Logs permission to generate a data key for encryption.

Firehose assumes an IAM role in each source account, and that role's permissions govern delivery. If it lacks an OpenSearch write policy for the domain in the central account, delivery fails only in those accounts, matching the intermittent failures. Cross-account access requires the role plus a domain access policy permitting it.

Metric filters in CloudWatch Logs can parse CloudTrail logs for specific event names, counting occurrences of CreateUser API calls. Since the organization trail delivers logs to a central log group in the management account, a single metric filter can monitor IAM user creation across all member accounts. This provides a real-time, event-driven signal to trigger a CloudWatch alarm, rather than relying on periodic scans or resource configuration evaluations.

Increasing evaluation periods to 3 (with the same period of e.g., 5 minutes) means the alarm triggers only if CPU exceeds 70% for 3 consecutive periods (15 minutes). This filters out short bursts and reduces false alarms while still catching sustained high CPU.

Enabling active tracing with AWS X-Ray gives you end-to-end visibility into requests as they pass through the Lambda function and any downstream AWS services or HTTP APIs. X-Ray automatically records a trace segment for each invocation, captures timing, errors, and subsegments for calls made with the AWS SDK, and supports sampling to control cost. It also propagates trace IDs across services, enabling you to follow a single user request through the entire distributed application.

Origin Shield is an optional intermediate cache layer that sits between CloudFront edge locations and the origin, aggregating requests from all edges. When multiple edges miss their local cache for the same object, Origin Shield consolidates those requests into a single origin fetch and caches the result globally, raising the effective hit ratio for the entire distribution and reducing origin traffic. It also adds resilience by absorbing request spikes and lowering latency for revalidation.

Performance Insights samples the database load and attributes it to individual SQL statements, exposing the top queries by database load during the high-CPU window. This directly identifies the offending statements on the MySQL instance without requiring slow query log parsing.

CloudWatch Logs Insights enables you to run SQL-like queries across log groups that receive application and system logs from EC2 instances via the unified CloudWatch agent. By filtering for messages between 1:55 PM and 2:05 PM and searching for terms such as 'cron,' 'schedule,' or the job name, you can identify a recurring batch process that coincides with the spike. This is a non-invasive, first-step diagnostic that directly associates application behavior with the CPU metric.

The Average statistic computes the mean DatabaseConnections over the 5-minute interval, which inherently dampens short-lived fluctuations and reveals the central tendency of connection concurrency. If the average exceeds the 80% threshold, it means the typical number of connections during the entire window was too high, matching the criterion of sustained usage for more than 5 minutes. This is the most appropriate aggregation for a threshold alarm aimed at detecting prolonged saturation of the connection pool.

Enabling CloudWatch Logs is the correct approach because every Lambda invocation automatically emits a REPORT log entry containing a Duration field, for example 123.45 ms, along with billed duration and memory usage. This is generated by the Lambda managed runtime, so there is no need to instrument the application code. You can use CloudWatch Logs Insights with a filter such as filter @type = 'REPORT' to query and parse these entries across all invocations, making it an efficient and fully managed solution for extracting execution duration.

DynamoDB on-demand capacity protects against table-level throttling but still enforces a per-partition limit of about 1,000 write capacity units. When access patterns are uneven, such as a single partition key receiving a disproportionate share of writes from the Kinesis stream, that partition hits its limit and throttles requests even though the overall table has plenty of capacity. Adaptive capacity can redistribute some of this load, but it is not instantaneous and does not fully prevent throttling during sharp spikes.

This is the correct solution because CloudWatch natively supports creating dashboards that display multiple operational metrics, and alarms on DynamoDB consumed capacity can be configured to trigger SNS notifications (e.g., email) when thresholds are exceeded. The dashboard can be shared as a public read-only dashboard using the CloudWatch console's 'Share' feature, which generates a URL that grants view-only access without requiring IAM credentials or Cognito. This directly addresses both the need for at-a-glance monitoring and threshold-based alerting on DynamoDB capacity, making it the most operationally sound and low-overhead option.

Enabling S3 Object Lock on the destination S3 bucket is the correct way to make CloudTrail logs immutable. In governance mode, you can set a retention period and object lock protects objects from being deleted or overwritten by any user—including the AWS account root user—unless they have the `s3:BypassGovernanceRetention` permission. This ensures that the audit log remains intact for the duration of the retention period, satisfying compliance mandates that require unauditable log preservation.

Associating the KMS key with the CloudWatch log group is the required and sufficient step to encrypt log data at rest. When you use the console or the associate-kms-key AWS CLI command, CloudWatch Logs begins encrypting all log events in that group with the specified key and uses the same key to decrypt them when you view or export them. This association applies to the log group's data, including all log streams inside it, and is the only way to apply customer-managed KMS encryption to CloudWatch Logs at rest.

In the RDS DB parameter group for MySQL, set slow_query_log to 1 or ON and define long_query_time with the desired threshold (for example, 2 seconds) — these parameters control which queries are written to the slow query log. This log records the exact SQL text, query execution time, and timestamp for every query exceeding the threshold, giving you the raw data needed to calculate SLO metrics like the ratio of slow queries to total queries. Because slow_query_log is a dynamic parameter for MySQL in RDS, you can apply the change immediately without rebooting the database instance.

A metric filter on the CloudWatch Logs group can count occurrences of the pattern 'ERROR', creating a custom metric. A CloudWatch alarm on that metric with a threshold of 100 and a 5-minute period will trigger when the error count exceeds 100.

By returning a meaningful error object (e.g., throwing an exception) within the Lambda handler, the error details and stack trace are automatically written to CloudWatch Logs. This gives the most comprehensive information for debugging application errors.

Amazon OpenSearch Service ingests CloudWatch Logs via a subscription filter and Lambda, indexing them for real-time full-text search, aggregations, and Kibana visualization. This makes it purpose-built for interactive log analytics and operational dashboards, directly querying the live stream without S3 export latency. It also scales to handle massive log volumes with open-source Elasticsearch-compatible APIs.

Sending VPC Flow Logs from each account to a centralized Amazon S3 bucket is correct because it creates a single, durable, cost-effective data lake that scales to petabytes. You configure each account's VPC Flow Logs to deliver to the same S3 bucket (with a bucket policy allowing cross-account delivery, ideally scoped to your AWS Organization ID). Then Amazon Athena can query these logs directly using standard SQL, with per-query pricing and no server to manage; using partition projection on account, region, and date drastically reduces scan costs and speeds up investigations.

AWS X-Ray provides distributed tracing by propagating a trace ID across instrumented services and recording segments and subsegments for each component. Enabling X-Ray on API Gateway and Lambda functions (e.g., via active tracing on the API Gateway stage and the Lambda execution role with X-Ray permissions) captures the full lifecycle of a request, including the API Gateway frontend, Lambda invocation, and any downstream SDK calls or HTTP requests. This allows you to follow a specific request through the entire architecture, view a service map, and drill into per-service latency, errors, and annotations, making it the correct solution for end-to-end tracing.

Amazon SNS is a fully managed pub/sub messaging service that supports multiple subscription protocols, including email (as well as HTTP, Lambda, SQS, etc.). To receive CloudFormation stack event notifications, you create an SNS topic, subscribe an email address to it, and specify the topic ARN in the CloudFormation stack's `NotificationARNs` property. When the stack state changes, CloudFormation publishes the event to the topic, and SNS delivers an email to every confirmed subscriber.

If the timeout is too low, increasing it may resolve false positives.

CloudWatch anomaly detection builds a model from up to two weeks of metric data and creates a band of expected values, alarming when the metric falls outside it. Applying it to a metric filter derived from the log group lets CloudWatch learn normal error patterns and notify on spikes without manual thresholds, matching the requirement.

Amazon VPC Flow Logs is the native service that captures IP traffic metadata for network interfaces in a VPC, including source and destination IPs, ports, protocol, and packet/byte counts for both accepted and rejected traffic. These logs can be published to Amazon S3 or CloudWatch Logs for long-term retention and analysis with services like Athena. As a result, VPC Flow Logs provides the flow-level visibility needed to monitor network traffic to and from a VPC.

X-Ray traces individual requests across microservices, producing segment and subsegment timings that break latency down per API endpoint and downstream call. Container Insights only aggregates task and service metrics, so it cannot satisfy the stem's requirement for granular per-endpoint latency visibility.

Instrumenting the application with the X-Ray SDK adds tracing headers to each incoming HTTP request and tracks the request as it flows through the EC2-hosted application and any downstream calls to databases or other services. X-Ray segments and subsegments capture the exact service, operation, and any exceptions or faults that occur, enabling a trace map that pinpoints the failing component or code path. This gives per-request context and error stack traces needed to resolve application-level errors definitively.

Enabling the RDS slow query log captures every SQL statement whose execution exceeds the configured long_query_time threshold, recording details like query text, execution duration, rows examined, and timestamps. By publishing these log events to CloudWatch Logs, you gain a searchable, historical record that can be queried with CloudWatch Logs Insights to filter for the slowest statements, identify patterns, and correlate with other metrics. This directly exposes the exact SQL causing performance issues, making it a definitive diagnostic method for slow query analysis.

The correct diagnosis is that the function's timeout setting is too low. The 3000 ms Duration exactly matches the default Lambda timeout of 3 seconds, and the 'Task timed out' error means Lambda terminated the handler at its configured limit. Raising the timeout, after reviewing the code for inefficiencies, would allow the function to complete successfully.

Amazon OpenSearch Service provides the interactive search and visualization layer for a centralized logging solution. Logs ingested from Firehose, CloudWatch Logs subscriptions, or Logstash are indexed and available for real-time queries, aggregations, and Kibana dashboards, making it the correct target for log analytics. Unlike object storage or API audit trails, OpenSearch supports full-text search, ad hoc filtering, and anomaly detection across massive log volumes.

CloudWatch Logs Insights provides a queryable index of live application logs, so you can run interactive queries that filter for ERROR, FATAL, or exception patterns within the exact time window of a memory spike. Using the parse command on structured logs and grouping by timestamp or host, you can quickly identify a correlated error or log burst, making it the appropriate tool for real-time operational correlation between CloudWatch metrics and log data.

HTTPCode_Target_5XX_Count is the definitive metric for monitoring application health because it directly counts HTTP 5xx responses returned by the registered targets (EC2 instances, containers, or Lambda). This value reflects actual application failures—unhandled exceptions, internal server errors, or gateway timeouts—making it the most precise indicator of unhealthy application logic. It is the recommended metric to alarm on for detecting when your web application is returning server-side errors to users.