Monitoring and Logging practice questions

Use JSON format for logs instead of plain text.

Why it fails: Incorrect: Format does not significantly affect CPU.

Set the agent's timezone to UTC.

Why it fails: Incorrect: Timezone setting does not affect CPU.

Change the log group retention policy to 7 days.

Why it fails: Incorrect: Retention does not affect agent CPU usage.

Modify the existing log group to use the KMS key by updating the log group settings.

Why it fails: You cannot modify an existing CloudWatch Logs log group to add or change an AWS KMS key because the kmsKeyId parameter is immutable after the log group is created—the console and API will reject the update. Instead, you must create a new log group with the desired KMS key and then redirect the log source or agent to write to that new group, which makes the existing log group's encryption setting permanently fixed.

Set the log group retention policy to 'Never expire' and use lifecycle policies to transition logs to Amazon S3 Glacier after 30 days.

Why it fails: CloudWatch Logs does not support direct lifecycle policies that transition log events to Amazon S3 Glacier from a log group. A log group retention policy can only expire logs within CloudWatch Logs itself; to use Glacier, you must first export the logs to an S3 bucket and then apply an S3 lifecycle policy with a glacier transition. Therefore, the combination of 'Never expire' and a built-in lifecycle to Glacier is not available in CloudWatch Logs.

AWS X-Ray

Why it fails: Incorrect: X-Ray is for tracing.

AWS Config

Why it fails: Incorrect: Config records configuration changes but not real-time notifications.

Amazon CloudWatch Alarms

Why it fails: Incorrect: Alarms are for metric thresholds, not instance lifecycle events.

Stream logs to Amazon Kinesis Data Firehose for transformation before landing in CloudWatch Logs.

Why it fails: Kinesis Data Firehose is optimized for delivering streaming data to destinations like S3, Redshift, or Splunk, and can invoke Lambda for transformation. However, using it solely to route EKS logs to CloudWatch Logs inserts an unnecessary intermediary that adds per-GB cost, provisioning overhead, and replication lag while CloudWatch Logs already supports direct ingestion from Fluent Bit and native subscription filters for post-processing. For simple log retention and analysis, direct streaming to CloudWatch Logs is the recommended, simpler path.

Enable CloudWatch Container Insights for the EKS cluster.

Why it fails: CloudWatch Container Insights delivers prebuilt dashboards and aggregated metrics for cluster, node, pod, and container resource utilization (CPU, memory, disk, network) from EKS, but it does not expose custom application-level metrics such as request counts, error rates, or service-specific latency. Those require instrumenting your code with a metrics SDK or deploying the CloudWatch agent in Prometheus scrape mode to collect from application endpoints. Container Insights is complementary to application metric monitoring and log-based alerting, not a substitute for either.

Amazon CloudWatch: Records API calls for auditing and compliance.

Why it fails: This statement confuses Amazon CloudWatch with AWS CloudTrail. CloudWatch does not record API calls or function as an audit trail; its core job is collecting and analyzing operational metrics and logs, then setting alarms. While CloudWatch Logs can ingest CloudTrail events, the actual recording of API activity is performed by CloudTrail itself. Attributing API-call auditing to CloudWatch is incorrect.

AWS CloudTrail: Monitors performance metrics and sets alarms.

Why it fails: This statement incorrectly assigns performance-monitoring capabilities to AWS CloudTrail. CloudTrail is an audit and governance service that records API activity; it does not collect metrics such as CPU or memory usage, nor does it evaluate alarm thresholds. Those functions belong to Amazon CloudWatch, which provides operational dashboards and alarms. CloudTrail's value lies in security and compliance, not real-time performance observability.

CloudWatch Logs has a throttling limit on log ingestion per log group.

Why it fails: CloudWatch Logs API throttling (e.g., PutLogEvents) is applied at the account/Region level, not per log group, and the default limits are on the order of 10,000 requests per second—far higher than typical microservice throughput. If throttling were occurring, the agent would receive explicit ThrottlingException errors and retry or back off, not silently drop logs mid-batch. The symptom pattern described matches an agent-side buffering loss, not service-side throttling.

The log group has reached its maximum size and stopped accepting new logs.

Why it fails: CloudWatch Logs does not impose a maximum size on log groups; they can ingest and store unlimited amounts of data, subject only to retention and storage account limits. A log group 'filling up' is not a real failure mode—the service is designed for high-volume, continuous log ingestion. If retention were configured, it would delete old events, but it would never stop new events from being accepted.

The log retention policy is set to 1 day, so older logs are automatically deleted.

Why it fails: A log retention policy of 1 day means CloudWatch Logs will automatically delete log events older than 24 hours, but this cleanup operates independently of the ingestion pipeline for new log events. The scenario describes missing recent logs, which would not be affected by retention deletion because those events are within the retention window. Retention-based deletion also runs asynchronously and would produce a gap only in historical data, not in newly generated logs.

AWS Config

Why it fails: AWS Config is a resource compliance service that tracks configuration changes to AWS resources and evaluates them against managed or custom rules. It does not ingest IAM sign-in authentication events or CloudTrail API activity for root user access, so it cannot detect when the root user signs in and trigger an alert.

Amazon S3

Why it fails: Amazon S3 is a durable object storage service, not a monitoring or event-processing service in this context. While S3 can store CloudTrail logs or receive them via bucket policies, it lacks any native rule engine to inspect sign-in events or produce notifications, so it cannot independently alert on root user sign-ins.

AWS IAM

Why it fails: AWS IAM is an identity and access management service that defines users, roles, policies, and permissions, but it is not a monitoring service and does not process authentication event streams in real time. IAM may provide a credentials report showing last sign-in activity, but that is a manual, retrospective snapshot rather than an event-driven notification for an active root sign-in event.

AWS CloudTrail

Why it fails: AWS CloudTrail is a governance, compliance, and auditing service that records only API activity and user actions within an AWS account. It does not ingest application-generated logs, OS-level logs, or service execution logs such as those from Lambda functions or EC2 instances. Therefore, while useful for answering 'who did what,' it cannot satisfy a general log collection and analysis requirement.

Amazon Kinesis Data Firehose

Why it fails: Amazon Kinesis Data Firehose is a fully managed streaming ingestion service that captures and loads real-time data streams into destinations such as Amazon S3, Amazon Redshift, or Amazon OpenSearch Service. It does not provide a persistent log store or native query interface; it only delivers data to other services for storage and processing. Thus, while it can transport logs, it cannot by itself enable the engineer to analyze the collected logs, so it is not the correct primary solution.

Amazon SQS

Why it fails: Amazon Simple Queue Service (SQS) is a message queuing service used to decouple application components and reliably transmit short-lived messages between producers and consumers. SQS does not store logs for analysis—messages are deleted after being consumed or after the retention period, and there is no SQL query capability or log aggregation feature. Because it lacks durable log storage and analytic tools, SQS is fundamentally unsuitable for collecting and analyzing logs across AWS services.

Metric: CPUUtilization, Statistic: Average, Period: 300 seconds, Threshold: 80, Evaluation Periods: 1, Comparison: LessThanThreshold

Why it fails: Comparison should be GreaterThanThreshold.

Metric: CPUUtilization, Statistic: Average, Period: 60 seconds, Threshold: 80, Evaluation Periods: 5

Why it fails: Period should be 300 seconds, not 60.

Metric: CPUUtilization, Statistic: Sum, Period: 60 seconds, Threshold: 80, Evaluation Periods: 5

Why it fails: Sum is incorrect; Average is needed.

Create a CloudWatch alarm on the CPUUtilization metric with a period of 300 seconds and threshold 90

Why it fails: A CPUUtilization alarm with a period of 300 seconds aggregates the metric into a single five-minute average, and the threshold of 90 percent triggers only when that average exceeds the high-water mark. This configuration directly matches the requirement to detect sustained CPU saturation over a five-minute window, avoiding false alarms from brief spikes. Setting the period to 300 with one evaluation period is the standard way to monitor average utilization over a longer interval.

Create a single composite alarm that combines both conditions

Why it fails: A composite alarm cannot directly evaluate raw CloudWatch metrics; it only combines the states of previously created alarms. Since no CPUUtilization or StatusCheckFailed alarms exist yet, the composite alarm would have no source alarms to reference and is therefore not a valid action at this stage. Even after the individual alarms are created, a composite alarm is typically used to reduce noise by aggregating multiple conditions, not to replace the underlying metric alarms themselves.

The CloudWatch agent is compressing logs before sending, causing some entries to be lost.

Why it fails: Incorrect. The CloudWatch agent can compress logs before sending to reduce bandwidth, but compression does not cause log loss. Missing entries are not due to compression.

The log group retention policy is set to 1 day, and logs older than that are automatically deleted.

Why it fails: Incorrect. A retention policy of 1 day means logs older than 1 day are deleted, but logs are still ingested. Missing entries are not caused by retention; the agent would still send current logs.

The log group's maximum size limit has been exceeded.

Why it fails: Incorrect. CloudWatch Logs does not impose a maximum size limit on log events or log groups. The agent can send events without size restrictions, so this is not a cause for missing entries.

Amazon CloudWatch Synthetics canary to monitor the application endpoint.

Why it fails: Synthetics checks endpoint availability, not internal microservice latency.

Amazon CloudWatch Logs Insights to query application logs for errors.

Why it fails: Logs Insights does not trace request paths or latency.

Amazon CloudWatch ServiceLens to visualize service maps and traces.

Why it fails: ServiceLens uses X-Ray; X-Ray is the direct service for tracing.

Use AWS X-Ray daemon to collect metrics and send them to CloudWatch.

Why it fails: The AWS X-Ray daemon is designed for distributed tracing, not metric collection. It collects trace segments and forwards them to the X-Ray API, never to CloudWatch metrics. Container Insights requires infrastructure and workload metrics like CPU, memory, and network utilization, which X-Ray cannot provide.

Deploy the AWS Distro for OpenTelemetry collector on the EKS cluster.

Why it fails: The AWS Distro for OpenTelemetry (ADOT) collector is a general-purpose telemetry pipeline that can export metrics to CloudWatch, but it requires custom configuration for an exporter and does not automatically enable Container Insights. In contrast, the CloudWatch agent provides a managed, pre-configured experience with ready-made dashboards and log integration for EKS. While technically possible, ADOT is not the preferred or standard solution for this requirement.

Enable Amazon CloudWatch Container Insights using the AWS Management Console.

Why it fails: Enabling Container Insights from the AWS Management Console merely toggles the feature in the console; it does not install any software on the cluster. Container Insights on EKS depends on the CloudWatch agent (or Fluent Bit/Fluentd) being deployed to actually collect and send metrics to CloudWatch. Without an agent running, the console shows no data, so this action alone is insufficient.

Use Amazon Kinesis Data Firehose to stream logs from each log group to Amazon S3 and then to a central CloudWatch Logs group.

Why it fails: This adds latency and cost; unnecessary when subscription filters can do the job directly.

Export each log group to Amazon S3 and use Amazon Athena to query across all exported logs.

Why it fails: This is batch-oriented and not real-time; adds cost and complexity.

Modify the application logging configuration in each container to send logs to a single log group and log stream per container.

Why it fails: This requires code changes and may cause log interleaving.

Stream logs to Amazon OpenSearch Service (Elasticsearch) using a CloudWatch Logs subscription filter.

Why it fails: Streaming logs to Amazon OpenSearch Service via a CloudWatch Logs subscription filter requires you to stand up and operate a separate OpenSearch cluster, including instance provisioning, shard tuning, and ongoing patching. That operational burden runs counter to the serverless, near-zero-administration posture of the existing CloudWatch Logs setup. Even though OpenSearch provides powerful full-text search, for a 3-year retention window you would be paying for always-on compute and storage, making it more expensive and complex than using CloudWatch Logs Insights on the already-existing log groups.

Export logs to Amazon S3 and use Amazon Athena to query them.

Why it fails: Exporting logs to Amazon S3 and querying them with Athena introduces inherent latency because export tasks run on a schedule (often every 5 to 15 minutes) and Athena queries only see data that has already been written. You must also manage partitioning and file formatting that is Athena-friendly, and you pay per query against the full 3-year dataset, which can become expensive for frequent ad-hoc searches. This is not a near real-time solution and is better suited for archived, infrequently-accessed log analysis rather than operational troubleshooting.

Use Amazon Kinesis Data Firehose to deliver logs to Amazon S3 with a 3-year lifecycle policy.

Why it fails: Amazon Kinesis Data Firehose can reliably buffer and deliver logs to S3 with a lifecycle policy, but it is fundamentally a data delivery service, not a search engine. After the logs land in S3, you have no native way to query them; you would need to layer Athena, OpenSearch, or another analytics service on top, which replicates the complexity you were trying to avoid. Firehose also adds ~60 seconds of buffering delay, and you must design the S3 prefix and data format for later queryability, so it is an inferior fit for the stated need of searchable logs.

Amazon Kinesis Data Streams

Why it fails: Kinesis Data Streams is wrong for log centralization because it is a real-time streaming ingestion service, not a log destination; producers like the CloudWatch Logs subscription or the Kinesis agent push records into shards, and you must build and run consumer applications (e.g., Lambda or KCL workers) to read and forward those records downstream. This adds operational complexity around shard provisioning, scaling limits, and 24-hour (up to 365-day if extended) data retention, when the task simply requires central collection. If the goal were real-time streaming analytics, Kinesis might be justified, but for basic log centralization it is unnecessary.

Amazon OpenSearch Service

Why it fails: Amazon OpenSearch Service also fails as a simple centralized logging solution because while it removes server management, you still configure clusters, instance types, storage volumes, shard strategy, and index lifecycle policies, and you must build an ingestion pipeline (e.g., Logstash, Fluent Bit, or a CloudWatch Logs subscription) to get logs in. It is designed for full-text search and interactive analytics, not as the first-tier aggregation point in a multi-account logging architecture. The added operational overhead and cost of running a cluster make it inappropriate for a scenario that seeks just to centralize logs.

AWS CloudTrail

Why it fails: AWS CloudTrail is not a centralized logging service for all logs; it records only AWS management API calls (read/write events) across your accounts, such as CreateBucket or RunInstances, and it can deliver those audit trails to a central S3 bucket or CloudWatch Logs. It cannot ingest other categories of logs like VPC Flow Logs, application logs, or database logs, because those services generate logs through their own delivery mechanisms. Thus, CloudTrail is a governance and compliance data source, not the hub that aggregates a diverse set of multi-account logs.

Deploy a Prometheus server on Amazon EC2 and scrape metrics from the ECS tasks.

Why it fails: Deploying Prometheus on EC2 to scrape Fargate tasks is problematic for 1-second granularity due to Fargate's ephemeral nature and dynamic IP addresses, which complicate reliable target discovery and consistent scraping without significant additional service discovery infrastructure. While Prometheus excels at time-series monitoring, particularly for custom metrics in stable EC2 or Kubernetes environments, its pull-based model is not natively optimised for the highly dynamic and transient lifecycle of Fargate tasks, especially when requiring such high-resolution data collection.

Enable CloudWatch detailed monitoring on the ECS service.

Why it fails: CloudWatch detailed monitoring is an Amazon EC2 feature that changes instance metric collection from 5-minute to 1-minute intervals; it is not an ECS service setting. ECS services do not expose a detailed monitoring option, and even if you enabled it on the EC2 instances that make up your cluster, it would only provide instance-level CPU/disk/network metrics—not the application or container-level performance granularity you need. Therefore, this action cannot produce 1-second metrics for the ECS service.

Enable VPC Flow Logs and analyze the logs with Amazon Athena.

Why it fails: VPC Flow Logs capture metadata about IP traffic traversing your VPC—such as source and destination addresses, ports, and packet counts—but they contain no information about CPU, memory, or disk utilization of your ECS tasks. Analyzing them with Amazon Athena can help with network troubleshooting and security auditing (e.g., detecting unwanted connections or traffic patterns), but it cannot tell you how the application is performing. Additionally, Flow Logs are typically aggregated and delivered with a delay of up to 10 minutes, making them far too coarse for 1-second application performance monitoring. Thus, this choice addresses network observability, not performance granularity.

Amazon Kinesis Agent on the on-premises servers to send logs to Amazon Kinesis Data Firehose, then to Amazon S3.

Why it fails: While the Kinesis Agent can tail logs on an on-premises host and push them to Kinesis Data Firehose, that pipeline terminates at an Amazon S3 bucket (or similar destination) rather than CloudWatch Logs. This adds architectural complexity—another agent, a delivery stream, and S3 storage—and forfeits CloudWatch's native log-analysis features like metric filters, subscription filters, and Logs Insights. It is a valid data-lake pattern but not the direct, purpose-built answer for CloudWatch Logs analytics.

Amazon CloudWatch Agent with the awslogs configuration to send logs to Amazon CloudWatch Logs.

Why it fails: The CloudWatch Agent does support an awslogs-style configuration schema, but that schema is a legacy compatibility mode inherited from the older standalone CloudWatch Logs agent. This answer is functionally equivalent to the correct option yet less precise: it over-specifies an implementation detail and points to a deprecated configuration style rather than the modern, unified agent configuration. In a single-best-answer question, the broader, directly named solution—simply 'Amazon CloudWatch Agent'—is the more accurate and recommended choice.

AWS Systems Manager Agent to collect logs and send to Amazon CloudWatch Logs.

Why it fails: The AWS Systems Manager Agent (SSM Agent) is designed for management and automation tasks such as running commands, applying patches, collecting inventory, and configuring State Manager associations. It does not have a built-in capability to tail arbitrary log files and forward them to CloudWatch Logs; any log collection via SSM would require using Run Command to manually install and invoke the CloudWatch Agent. Thus it is an orchestration mechanism, not a log-collection agent itself—making it fundamentally unsuitable as the direct answer.

DynamoDB read and write capacity metrics and Lambda error count.

Why it fails: Read and write capacity metrics show average utilization of provisioned throughput, but they don't tell you how many requests were actually throttled; a table can show high utilization without any throttled events, depending on burst capacity and request patterns. Lambda error count is an aggregate that mixes all exception types, including timeouts, code errors, and exhausted retries, so it cannot isolate DynamoDB throttling as the root cause. These metrics provide general health indicators, but lack the specificity needed to pinpoint the source of throttling behavior.

CloudWatch metrics for Lambda invocations and duration.

Why it fails: Invocations and duration describe Lambda's operational throughput and execution time, but they don't contain any signal about throttling events; a function can have steady invocations and low duration while still experiencing DynamoDB throttles on writes. Duration specifically reflects compute time, which is unrelated to database write capacity or concurrency limits, so it cannot help identify throttling. Monitoring these alone would leave you blind to the specific reason your workload is being denied service.

CloudWatch Logs for Lambda function logs and Lambda memory utilization.

Why it fails: CloudWatch Logs for Lambda functions require manual searching through execution traces and don't provide a quantitative, aggregate throttling metric, making them inefficient for real-time alerting. Lambda memory utilization measures memory pressure on the execution environment, which affects function outages or timeouts, but it has no bearing on DynamoDB's ability to accept write requests. As a result, logs and memory metrics might explain why a function fails to complete, but they cannot explain why DynamoDB rejects a request before the function even executes.

Enable VPC Flow Logs to capture traffic patterns.

Why it fails: VPC Flow Logs capture only network-layer metadata about IP traffic, such as source/destination addresses, ports, protocol, and packet/byte counts. They do not inspect or record application-layer payloads, so HTTP request paths, status codes, and per-request latencies are entirely absent. Without these details, Flow Logs cannot explain why users see 5xx errors or experience slow responses, making them ineffective for application-level troubleshooting.

Enable AWS CloudTrail to log API calls made to the load balancer.

Why it fails: AWS CloudTrail records management-plane (control-plane) API actions such as CreateLoadBalancer, ModifyTargetGroup, or SetSecurityGroups, along with the identity of the caller and the timestamp. It does not capture the data-plane HTTP requests that clients send through the load balancer, nor does it include application-layer details like status codes, paths, or response times. Thus CloudTrail is useful for auditing configuration changes and security events, but it cannot help diagnose application-level failures or performance degradation.