Courseiva

CCNA Monitoring and Logging Questions

38 questions · Monitoring and Logging · All types, answers revealed

1
MCQeasy

A DevOps engineer is setting up an alarm to notify the team when the average CPU utilization of an EC2 instance exceeds 80% for 5 consecutive minutes. Which CloudWatch alarm configuration should be used?

A.Metric: CPUUtilization, Statistic: Average, Period: 300 seconds, Threshold: 80, Evaluation Periods: 1
B.Metric: CPUUtilization, Statistic: Average, Period: 300 seconds, Threshold: 80, Evaluation Periods: 1, Comparison: LessThanThreshold
C.Metric: CPUUtilization, Statistic: Average, Period: 60 seconds, Threshold: 80, Evaluation Periods: 5
D.Metric: CPUUtilization, Statistic: Sum, Period: 60 seconds, Threshold: 80, Evaluation Periods: 5
AnswerA

This matches the requirement: 5 consecutive minutes = 1 evaluation period of 300 seconds.

Why this answer

It configures a CloudWatch alarm with a 300-second (5-minute) period and 1 evaluation period, meaning the alarm triggers when the average CPU utilization exceeds 80% for a single 5-minute data point. This directly matches the requirement of 'exceeds 80% for 5 consecutive minutes' since the metric is evaluated over a 5-minute window.

Exam trap

The trap here is confusing 'Evaluation Periods' with 'Period' — candidates often think 5 evaluation periods with a 60-second period is needed for 5 consecutive minutes, but that actually requires 5 separate 1-minute data points all breaching the threshold, not a single 5-minute average.

How to eliminate wrong answers

Option B is wrong because it uses the comparison operator 'LessThanThreshold', which would trigger the alarm when CPU utilization is below 80%, not above. Option C is wrong because it uses a 60-second period with 5 evaluation periods, which would require the condition to be met for 5 consecutive minutes (5 data points), but the alarm would evaluate each 1-minute data point individually, not a single 5-minute average; this is a common misinterpretation of 'consecutive minutes'. Option D is wrong because it uses the 'Sum' statistic instead of 'Average', which would aggregate CPU utilization over the period rather than providing the mean value, and the threshold of 80 is meaningless for a sum statistic on CPU utilization.

2
MCQhard

A company runs a critical application on Amazon RDS for PostgreSQL. The database experiences periodic slowdowns. The team wants to monitor the number of active connections and the query execution time. Which approach is most cost-effective?

A.Install the CloudWatch agent on the RDS instance to collect custom metrics.
B.Use the RDS console to view the 'DatabaseConnections' and 'QueryExecutionTime' metrics.
C.Enable Performance Insights and set up CloudWatch alarms on the 'DBLoad' metric.
D.Enable Enhanced Monitoring and publish metrics to CloudWatch, then create alarms on relevant metrics.
AnswerC

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.

Why this answer

Performance Insights provides detailed query execution time metrics, enabling monitoring of query performance. It also includes the 'DBLoad' metric which reflects database load from active connections and queries. Combined with CloudWatch alarms, this approach is cost-effective as Performance Insights is included with RDS at no additional cost for up to 7 days of retention (longer retention has a fee).

Options A and B are invalid because the CloudWatch agent cannot be installed on RDS instances, and 'QueryExecutionTime' is not a standard CloudWatch metric for RDS. Option D is less suitable for the specific requirement of query execution time; Enhanced Monitoring provides OS-level metrics like processes and memory but does not track query-level execution time.

Exam trap

Candidates often assume Enhanced Monitoring is the most cost-effective because it is free, but it lacks query-level performance data. The key is that Performance Insights tracks execution time natively and is included at no extra cost for the first 7 days, making it the correct choice for this requirement.

How to eliminate wrong answers

Option A is wrong because the CloudWatch agent cannot be installed on an RDS instance; RDS is a managed service and does not allow direct OS access or agent installation. Option B is wrong because 'QueryExecutionTime' is not a standard metric available in the RDS console; the console provides 'DatabaseConnections' but not query execution time. Option C is wrong because Performance Insights focuses on database load (DBLoad) and query performance analysis, but it does not directly expose the number of active connections as a metric for CloudWatch alarms; additionally, enabling Performance Insights incurs extra costs beyond the basic RDS pricing.

3
MCQeasy

A company is using AWS CloudTrail to track API calls. They want to be notified immediately when an IAM user creates a new access key. Which combination of AWS services should be used?

A.Amazon CloudWatch Logs with a metric filter and alarm.
B.AWS Config with an AWS Lambda function.
C.Amazon CloudWatch Events (Amazon EventBridge) with an AWS Lambda function that sends an email via Amazon SES.
D.Amazon CloudWatch Events (Amazon EventBridge) with an Amazon SNS topic.
AnswerD

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.

Why this answer

To be notified immediately when an IAM user creates a new access key, the most efficient approach is to use Amazon CloudWatch Events (Amazon EventBridge) with an Amazon SNS topic. CloudTrail records the 'CreateAccessKey' API call as an event. An EventBridge rule can be configured to match this specific event pattern and send the event to an SNS topic, which can then send notifications via email, SMS, etc.

This provides real-time notification without additional services. Option A (CloudWatch Logs with metric filter and alarm) requires sending CloudTrail logs to CloudWatch Logs, which adds latency and complexity; it is not as direct as EventBridge. Option B (AWS Config with Lambda) is not designed for real-time event notification.

Option C (EventBridge with Lambda and SES) adds unnecessary Lambda processing since SNS can directly send email when subscribed to the topic.

4
Multi-Selectmedium

A company uses Amazon CloudWatch Logs to store application logs. They have a requirement to retain logs for 90 days for operational analysis and then archive them to Amazon S3 for compliance purposes for an additional 5 years. Which of the following steps are necessary to meet this requirement? (Select TWO.)

Select 2 answers
A.Set the CloudWatch Logs retention policy on the log group to 90 days.
B.Set an S3 lifecycle policy on the destination bucket to transition objects to Glacier after 90 days.
C.Create a CloudWatch Logs subscription filter to stream logs to Amazon S3 in real time.
D.Configure a CloudWatch Logs lifecycle policy to transition logs to Amazon S3 after 90 days.
E.Create a CloudWatch Logs export task to export logs to Amazon S3 before the retention period expires.
AnswersA, E

Setting a CloudWatch Logs retention policy on the log group to 90 days automatically expires and permanently deletes log events after that period, with no additional infrastructure or cost. This is the direct method to enforce the 90-day storage requirement because the retention setting applies to all log streams within the group and overrides any default. It also eliminates the need for separate S3 export or lifecycle configurations if long-term archiving is not required.

Why this answer

Setting the CloudWatch Logs retention policy on the log group to 90 days ensures logs are retained for operational analysis and then automatically expire (deleted) after 90 days. Option E is correct because to archive logs to Amazon S3 for compliance, you must use a CloudWatch Logs export task to export logs to S3 before the retention period expires. Option B is incorrect because an S3 lifecycle policy applies to objects already in S3, not to logs in CloudWatch.

Option C is incorrect because subscription filters can stream logs in real time to destinations like Lambda or Kinesis, but not directly to S3 for archival. Option D is incorrect because CloudWatch Logs does not have a lifecycle policy to transition logs directly to S3; export is required.

Exam trap

Don't confuse CloudWatch Logs retention policies with S3 lifecycle policies. Retention only controls deletion from CloudWatch, not export to S3.

5
MCQmedium

A company runs a web application behind an Application Load Balancer (ALB) in a production AWS account. The DevOps team needs to analyze HTTP request patterns and identify the top IP addresses generating errors. They want to store the data cost-effectively for querying with SQL. Which solution meets these requirements?

A.Use CloudWatch Metrics to monitor error rates and top IPs via custom metrics.
B.Enable CloudWatch Logs for the ALB and use CloudWatch Logs Insights to query the logs.
C.Stream the ALB logs to Amazon Kinesis Data Analytics and use SQL applications.
D.Enable ALB access logs and store them in Amazon S3, then use Amazon Athena to query the logs with SQL.
AnswerD

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.

Why this answer

ALB access logs provide detailed HTTP request data (including source IP, request URI, response code, etc.) and are stored in Amazon S3, which is cost-effective for long-term storage. Amazon Athena allows querying these logs directly with standard SQL without needing to load data into a database, meeting the requirement for SQL-based analysis of top IP addresses generating errors.

Exam trap

The trap here is that candidates often confuse CloudWatch Logs (which for ALB only contain error logs, not full request details) with ALB access logs (which are stored in S3 and contain all request data), leading them to choose Option B instead of D.

How to eliminate wrong answers

Option A is wrong because CloudWatch Metrics cannot capture individual HTTP request details like source IP addresses; custom metrics are aggregated and cannot be used to identify top IPs generating errors. Option B is wrong because CloudWatch Logs for ALB capture only error-level logs (e.g., 5xx responses) and do not include request-level details such as source IP; CloudWatch Logs Insights cannot query for top IP addresses from these logs. Option C is wrong because Kinesis Data Analytics is designed for real-time stream processing with SQL, but the requirement is to store data cost-effectively for querying, not real-time analysis; streaming logs to Kinesis incurs ongoing costs and is overkill for batch querying of historical patterns.

6
MCQhard

A DevOps team is using Amazon CloudWatch Logs to collect application logs from multiple EC2 instances. They notice that some log entries are missing and that the CloudWatch agent is consuming high CPU. The log group has a retention policy of 30 days. Which action should the team take to reduce CPU usage without losing log data?

A.Increase the batch size in the CloudWatch agent configuration.
B.Use JSON format for logs instead of plain text.
C.Set the agent's timezone to UTC.
D.Change the log group retention policy to 7 days.
AnswerA

Correct: Larger batch size reduces API calls and CPU usage.

Why this answer

Increasing the batch size in the CloudWatch agent configuration reduces the number of HTTP API calls made to CloudWatch Logs, which lowers CPU overhead from frequent network I/O and serialization. The agent buffers log events and sends them in larger, less frequent batches, directly addressing high CPU consumption without discarding any log data.

Exam trap

The trap here is that candidates may confuse log retention policies with operational performance tuning, incorrectly assuming that reducing retention frees resources, when in fact it only deletes historical data and has no impact on agent CPU usage.

How to eliminate wrong answers

Option B is wrong because using JSON format instead of plain text does not reduce CPU usage; it may increase parsing overhead and does not affect the agent's batching or transmission behavior. Option C is wrong because setting the agent's timezone to UTC only affects timestamp interpretation, not CPU consumption or log delivery efficiency. Option D is wrong because reducing the log group retention policy from 30 to 7 days deletes older log data permanently, which violates the requirement to not lose log data and does not reduce CPU usage.

7
MCQmedium

A company is running a critical web application on Amazon EC2 instances behind an Application Load Balancer (ALB). The DevOps team wants to monitor HTTP 5xx errors and receive alerts when the error rate exceeds 5% over a 5-minute period. Which combination of services and configurations should be used to meet these requirements?

A.Enable CloudWatch Logs for the ALB and use CloudWatch Logs Insights to query 5xx logs, then create a metric filter and alarm.
B.Configure AWS Config rules to check ALB 5xx error counts and trigger alarms.
C.Use CloudWatch ALB metrics (HTTPCode_ELB_5XX_Count) and create a CloudWatch Alarm on the Sum statistic with a threshold based on total request count.
D.Use AWS X-Ray to trace requests and create a CloudWatch alarm based on X-Ray error rate.
AnswerC

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.

Why this answer

ALB automatically publishes the `HTTPCode_ELB_5XX_Count` metric to CloudWatch, and you can create a CloudWatch alarm using the `Sum` statistic over a 5-minute period. To detect when the error rate exceeds 5%, you need to combine this metric with the `RequestCount` metric in a math expression (e.g., `m1/m2*100 > 5`) or use a composite alarm, as the alarm threshold must be based on the ratio of 5xx errors to total requests, not just the raw count.

Exam trap

The trap here is that candidates often assume they need to parse logs (Option A) or use a separate tracing service (Option D) for error rate monitoring, when in fact the ALB's built-in CloudWatch metrics and metric math provide a simpler, real-time, and cost-effective solution without additional log ingestion or query overhead.

How to eliminate wrong answers

Option A is wrong because CloudWatch Logs Insights is a query tool for analyzing log data, not a real-time alerting mechanism; while you can create a metric filter from ALB logs to count 5xx errors, this approach introduces latency and additional cost, and it is not the simplest or most direct method when ALB metrics are already available. Option B is wrong because AWS Config rules are designed for compliance and resource configuration auditing (e.g., checking if ALB is configured with a specific security policy), not for monitoring real-time error rates or triggering alarms on metric thresholds. Option D is wrong because AWS X-Ray traces individual requests to identify latency and errors, but it does not aggregate HTTP 5xx error rates over a time window or natively publish a metric that can be used directly in a CloudWatch alarm for this specific requirement.

8
MCQmedium

A company runs a production web application on Amazon EC2 instances in an Auto Scaling group behind an Application Load Balancer (ALB). The application is deployed across three Availability Zones. The DevOps team recently noticed that the application's error rate is spiking periodically, but they cannot correlate the spikes with any known deployments or changes. The team has enabled detailed CloudWatch metrics for the ALB and EC2, and they are using CloudWatch Logs for application logs. They also have AWS X-Ray enabled for tracing. The team observes that during error spikes, the ALB's 5XX count increases, but the EC2 instance-level CPU and memory metrics remain normal. The application logs show 'Connection timed out' errors. The team suspects the issue is related to network connectivity but is not sure. Which course of action should the DevOps team take to identify the root cause of the periodic error spikes?

A.Enable VPC Flow Logs for the subnets and analyze the logs to identify dropped connections during the error spikes.
B.Increase the EC2 instance size to handle higher traffic and reduce timeouts.
C.Configure a step scaling policy for the Auto Scaling group based on ALB 5XX count.
D.Enable ALB access logs and analyze the 5xx response patterns.
AnswerA

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.

Why this answer

VPC Flow Logs capture metadata about IP traffic going to and from network interfaces in a VPC, including whether the traffic was accepted or rejected. Since the application logs show 'Connection timed out' errors and instance-level metrics are normal, the issue likely lies in the network path (e.g., security groups, NACLs, or subnet routing) rather than the application or compute layer. Analyzing VPC Flow Logs during the error spikes will reveal if connections are being dropped or rejected, pinpointing the root cause of the timeouts.

Exam trap

The trap here is that candidates often jump to scaling or access logs (options C or D) because they focus on the 5XX error symptom, but the question specifically points to network-level timeouts, making VPC Flow Logs the only diagnostic tool that can reveal dropped or rejected packets at the network layer.

How to eliminate wrong answers

Option B is wrong because increasing EC2 instance size addresses compute resource constraints (CPU/memory), but the metrics show those are normal, so the timeouts are not due to resource exhaustion. Option C is wrong because configuring a step scaling policy based on ALB 5XX count would only react to the symptom (error rate) by adding instances, but it does not diagnose the underlying network connectivity issue causing the timeouts. Option D is wrong because ALB access logs record HTTP request/response details (e.g., status codes, timestamps) but do not capture network-level drops or rejections; they would show 5xx errors but not explain why connections are timing out at the network layer.

9
MCQeasy

An organization wants to ensure that all API calls made in their AWS account are logged for security analysis. Which AWS service should be enabled to meet this requirement?

A.AWS CloudTrail
B.AWS Config
C.Amazon CloudWatch Logs
D.VPC Flow Logs
AnswerA

CloudTrail records API activity for governance and audit.

Why this answer

(AWS CloudTrail) is correct because it records all API calls made in the AWS account, providing a log of actions for security analysis. Option B (AWS Config) is incorrect because it tracks resource configuration changes, not API calls. Option C (Amazon CloudWatch Logs) is incorrect because it stores logs from various sources but does not natively capture API calls; CloudTrail is the service designed for that purpose.

Option D (VPC Flow Logs) is incorrect because it captures IP traffic information for network interfaces, not API calls.

10
Multi-Selecthard

A DevOps engineer needs to set up a monitoring solution for an application running on Amazon EKS. The application emits custom metrics that need to be stored in Amazon CloudWatch and visualized on a dashboard. Which THREE steps should the engineer take? (Choose THREE.)

Select 3 answers
A.Configure the CloudWatch agent to emit custom metrics to CloudWatch.
B.Use CloudWatch Logs Insights to analyze the custom metrics.
C.Create a CloudWatch dashboard to visualize the collected metrics.
D.Install the CloudWatch agent on the EKS cluster using a DaemonSet.
E.Use Amazon Managed Service for Prometheus to scrape the metrics.
AnswersA, C, D

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.

Why this answer

The CloudWatch agent can be configured to emit custom application metrics to Amazon CloudWatch, which is the required destination for storing the metrics. The agent uses the CloudWatch PutMetricData API to send these metrics, enabling centralized monitoring and alerting within CloudWatch.

Exam trap

The trap here is that candidates may confuse CloudWatch Logs Insights (for logs) with CloudWatch Metrics (for numeric data), or assume Amazon Managed Service for Prometheus is a direct replacement for CloudWatch metrics, when the question specifically requires storing custom metrics in CloudWatch.

11
MCQmedium

Your company runs a multi-tier web application on AWS. The application consists of an Application Load Balancer (ALB) that distributes traffic to a fleet of Amazon EC2 instances running a web server. The web servers write access logs to a shared Amazon EFS filesystem. The operations team needs to monitor the web server logs in real-time to detect and alert on 5xx error spikes. Currently, the team manually SSHes into instances to tail logs, which is inefficient and doesn't provide real-time alerting. The team wants a centralized, near-real-time logging solution with minimal operational overhead. They have asked you to design a solution that ingests logs from the EFS filesystem into a centralized log analytics platform. Which solution would you recommend?

A.Enable AWS CloudTrail data events for the EC2 instances to capture log file modifications.
B.Configure an Amazon EventBridge scheduled rule to invoke an AWS Lambda function that reads new log lines from EFS and publishes them to Amazon CloudWatch Logs.
C.Stream the log files to Amazon Kinesis Data Streams using a custom producer, then use a Lambda function to analyze and alert on 5xx errors.
D.Install and configure the Amazon CloudWatch Logs agent on each EC2 instance to tail the log files from the EFS mount and send them to CloudWatch Logs. Create a metric filter and alarm for 5xx errors.
AnswerD

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.

Why this answer

Installing the CloudWatch Logs agent on each EC2 instance allows it to tail the log files from the shared EFS mount point and stream them to CloudWatch Logs in near real-time. This provides centralized log ingestion with minimal operational overhead, and you can create a metric filter and alarm to detect and alert on 5xx error spikes without manual SSH access.

Exam trap

The trap here is that candidates may overcomplicate the solution by choosing Kinesis or Lambda-based approaches (Options B and C) when a simple agent-based solution (Option D) is sufficient, or they may confuse CloudTrail data events (Option A) with log file monitoring, not realizing CloudTrail captures API activity, not file content changes.

How to eliminate wrong answers

Option A is wrong because CloudTrail data events for EC2 instances capture API calls (e.g., RunInstances, TerminateInstances), not log file modifications on EFS; they cannot ingest or analyze web server log content. Option B is wrong because an EventBridge scheduled rule with a Lambda function that reads new log lines from EFS would introduce latency (scheduled intervals) and complexity in tracking file offsets, making it unsuitable for near-real-time monitoring. Option C is wrong because streaming logs to Kinesis Data Streams requires a custom producer to be deployed and managed, adding significant operational overhead compared to the agent-based approach, and it does not directly integrate with CloudWatch Logs for metric filtering and alerting without additional Lambda processing.

12
MCQhard

A company is migrating its on-premises applications to AWS and wants to maintain the same level of monitoring for its Linux-based EC2 instances. They currently use Nagios for monitoring. They want a managed AWS service that can monitor instance health, system metrics, and application logs. Which solution should they use?

A.Install the Amazon CloudWatch agent on each EC2 instance to collect system metrics and logs, and send them to CloudWatch.
B.Use AWS CloudTrail to monitor instance activity and capture log files.
C.Use AWS Systems Manager Inventory to collect system configuration and log files.
D.Use AWS Config to track instance configuration changes and trigger alerts.
AnswerA

The CloudWatch agent can collect both metrics and logs, replacing Nagios.

Why this answer

The Amazon CloudWatch agent (unified CloudWatch agent) can collect system metrics (CPU, memory, disk) and logs from EC2 instances and send them to CloudWatch, providing a managed monitoring solution similar to Nagios. Option B is incorrect because AWS CloudTrail is for auditing API calls, not for monitoring system metrics or logs. Option C is incorrect because AWS Systems Manager Inventory collects software inventory and configuration data, not real-time metrics or logs.

Option D is incorrect because AWS Config tracks resource configuration changes for compliance, not for monitoring system health.

13
Multi-Selecteasy

A DevOps team is designing a centralized logging solution for multiple AWS accounts. The team needs to collect logs from EC2 instances, Lambda functions, and VPC Flow Logs, and store them in a central account for analysis. The solution must be cost-effective and support near real-time log aggregation. Which THREE steps should the team take? (Choose three.)

Select 3 answers
A.Configure VPC Flow Logs to deliver to a Lambda function in each account, which forwards logs to the central account.
B.Deliver logs from the central account's CloudWatch Logs to Amazon Kinesis Data Firehose, which writes to Amazon S3.
C.Use Amazon OpenSearch Service to index and search the logs in near real time.
D.Use Amazon Athena to query the logs stored in S3 for analysis.
E.Use CloudWatch cross-account subscription to stream logs from source accounts to a central account's CloudWatch Logs.
AnswersB, D, E

Kinesis Data Firehose provides near real-time delivery to S3 at low cost.

Why this answer

Options B, D, and E are correct. CloudWatch cross-account subscription (Option E) allows streaming logs from source accounts to a central account's CloudWatch Logs for near real-time aggregation. From the central account, logs can be delivered to Amazon Kinesis Data Firehose (Option B), which buffers and writes them to Amazon S3 at low cost.

Amazon Athena (Option D) can then query the S3 logs for analysis, supporting cost-effective ad-hoc queries. Option A is incorrect because VPC Flow Logs cannot be delivered directly to a Lambda function; they are delivered to CloudWatch Logs or S3. Option C (Amazon OpenSearch Service) is not one of the three required steps because the question specifies cost-effective storage and near real-time aggregation, and OpenSearch adds unnecessary cost and complexity for storage; the proposed solution uses S3 for cost-effective storage and Athena for querying.

14
MCQhard

A Lambda function is unable to write logs to CloudWatch Logs. The IAM policy attached to the function's execution role is shown above. What is the issue?

A.The resource ARN is incorrect; it should include the log stream name.
B.The region in the ARN does not match the Lambda function's region.
C.The action should be 'logs:PutLogEvents' but the resource is too restrictive.
D.The policy is missing the 'logs:CreateLogGroup' and 'logs:CreateLogStream' actions.
AnswerD

Lambda needs to create the log group and stream before writing events.

Why this answer

The Lambda function's execution role must include permissions for 'logs:CreateLogGroup' and 'logs:CreateLogStream' in addition to 'logs:PutLogEvents' to write logs to CloudWatch. The provided policy likely only grants 'logs:PutLogEvents', which allows writing to existing log streams but not creating the log group or stream. Option A is incorrect because the resource ARN can be generalized to the log group or stream without specifying the stream name.

Option B is incorrect because the region mismatch would cause a different error. Option C is incorrect because the action 'logs:PutLogEvents' is necessary but not sufficient; the missing create actions are the issue.

15
MCQhard

A company has a microservices architecture with 50 services running on Amazon ECS. The DevOps team wants to collect and analyze logs from all services centrally. They need to query logs across services and set up alerts for error patterns. Which solution is the most scalable and cost-effective?

A.Use AWS CloudTrail to capture all log events and store them in an S3 bucket for analysis
B.Deploy an Amazon Elasticsearch cluster and configure the ECS Fargate agent to send logs directly to Elasticsearch
C.Use the awslogs driver to send logs to Amazon CloudWatch Logs and use CloudWatch Logs Insights for querying and metric filters for alerts
D.Send logs to Amazon S3 and use Amazon Athena for querying, with scheduled queries for alerts
AnswerC

Correct. This is scalable, integrates with ECS, and provides real-time alerts.

Why this answer

Using the awslogs driver to send logs to Amazon CloudWatch Logs provides a fully managed, scalable, and cost-effective solution. CloudWatch Logs Insights enables querying across all services, and metric filters can trigger alarms for error patterns. Option A (CloudTrail) captures API activity, not application logs.

Option B (Elasticsearch) requires managing infrastructure and is more expensive. Option D (S3 + Athena) is cheaper but lacks real-time alerting and has slower query performance.

16
MCQmedium

A DevOps engineer is troubleshooting a production issue where an application's response time has increased. The application is deployed on Amazon ECS with Fargate. The engineer wants to identify which microservice is causing the latency. Which AWS service should be used?

A.Amazon CloudWatch Synthetics canary to monitor the application endpoint.
B.AWS X-Ray to trace requests and analyze service latency.
C.Amazon CloudWatch Logs Insights to query application logs for errors.
D.Amazon CloudWatch ServiceLens to visualize service maps and traces.
AnswerB

X-Ray provides detailed traces and service maps to pinpoint latency.

Why this answer

AWS X-Ray is the correct service because it provides end-to-end tracing of requests as they travel through microservices, allowing the engineer to pinpoint which service is introducing latency. By analyzing trace segments and subsegments, X-Ray can break down response times for each component in the application, directly addressing the need to identify the specific microservice causing the delay.

Exam trap

The trap here is that candidates often confuse CloudWatch ServiceLens (which visualizes traces) with the actual tracing service itself, forgetting that ServiceLens depends on X-Ray to collect the trace data in the first place.

How to eliminate wrong answers

Option A is wrong because CloudWatch Synthetics canaries monitor endpoint availability and performance from the outside, but they cannot trace internal request paths across microservices to identify which specific service is causing latency. Option C is wrong because CloudWatch Logs Insights is designed for querying and analyzing log data, not for tracing request flows or measuring per-service latency; it would require manual correlation of timestamps across services. Option D is wrong because CloudWatch ServiceLens is a visualization layer that combines traces from X-Ray and metrics from CloudWatch, but it is not the primary service for tracing; the engineer must first use X-Ray to collect the trace data that ServiceLens visualizes.

17
MCQmedium

A company is using AWS CloudFormation to deploy infrastructure. They want to receive notifications when a stack operation fails, including the specific resource that caused the failure. Which approach should they use?

A.Create a CloudWatch alarm on the 'StackFailure' metric.
B.Configure an SNS topic as a notification option in the CloudFormation stack and subscribe to receive stack events.
C.Create an AWS Lambda function that polls the CloudFormation DescribeStackEvents API every minute and sends an email on failure.
D.Enable AWS CloudTrail to log CloudFormation API calls and configure an SNS notification on the trail.
AnswerB

CloudFormation can send stack events (including failures) to SNS.

Why this answer

CloudFormation allows you to specify an SNS topic ARN as a notification option when creating or updating a stack. When a stack operation fails, CloudFormation publishes a notification to that SNS topic, and the notification includes the logical resource ID and the status reason for the failure. This provides real-time, event-driven notifications without requiring polling or additional services.

Exam trap

The trap here is that candidates may confuse CloudWatch metrics or CloudTrail with CloudFormation's native notification capability, assuming that failure events are exposed as metrics or logs rather than through SNS topic subscriptions.

How to eliminate wrong answers

Option A is wrong because CloudFormation does not emit a 'StackFailure' metric to CloudWatch; CloudFormation publishes stack events to SNS topics, not CloudWatch metrics. Option C is wrong because polling the DescribeStackEvents API every minute introduces latency, unnecessary cost, and complexity compared to the native SNS notification mechanism; it also violates the principle of event-driven architecture. Option D is wrong because AWS CloudTrail logs API calls for auditing, but it does not provide real-time notifications on stack operation failures; configuring SNS on a trail only delivers log file delivery notifications, not stack failure events.

18
MCQmedium

A company is using Amazon RDS for MySQL and needs to monitor slow queries to optimize database performance. The team has enabled slow query logs and wants to centralize logging in Amazon CloudWatch Logs for real-time analysis and alerting. Which solution meets these requirements with minimal operational overhead?

A.Enable Performance Insights on the RDS instance and use the Performance Insights dashboard to view slow queries.
B.Enable Enhanced Monitoring on the RDS instance and configure CloudWatch alarms based on the metrics.
C.Modify the DB parameter group to enable slow_query_log and set log_output to FILE, then configure the RDS instance to publish the slowquery log file to CloudWatch Logs.
D.Configure the RDS instance to export slow query logs to an S3 bucket, then set up a Lambda function to read the logs and send them to CloudWatch Logs.
AnswerC

RDS can natively publish slow query logs to CloudWatch Logs via the 'slowquery' log export.

Why this answer

RDS for MySQL can natively stream slow query logs to CloudWatch Logs. This is achieved by modifying the DB parameter group to set 'slow_query_log' to 1 and 'log_output' to 'FILE', then enabling the 'slowquery' log export in the RDS console or CLI. This approach requires no additional infrastructure, minimizing operational overhead.

Option A is incorrect because Performance Insights focuses on database performance metrics and schema analysis, not slow query log streaming to CloudWatch. Option B is incorrect because Enhanced Monitoring provides OS-level metrics (CPU, memory, etc.), not slow query logs. Option D is incorrect because exporting logs to S3 and using Lambda adds unnecessary complexity and latency; the native CloudWatch integration is more efficient.

19
MCQmedium

A DevOps engineer needs to audit changes to IAM policies over the past 90 days. The engineer wants to see who made the change, what the change was, and when it occurred. Which AWS tool should be used?

A.AWS Config
B.Amazon CloudWatch Logs
C.AWS CloudTrail
D.IAM Access Analyzer
AnswerC

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.

Why this answer

AWS CloudTrail is the correct choice because it records all API calls made to the AWS environment, including IAM policy changes, and stores them as events with details such as the identity of the caller (IAM user or role), the time of the request, and the request parameters. By querying CloudTrail logs over the past 90 days, the DevOps engineer can audit who made the change, what the change was (e.g., the specific IAM policy document modification), and when it occurred.

Exam trap

The trap here is that candidates often confuse AWS Config's ability to track configuration changes with CloudTrail's ability to provide a detailed audit trail of API calls, leading them to choose AWS Config for auditing who made a change, when in fact Config only shows the state change, not the identity of the actor.

How to eliminate wrong answers

Option A is wrong because AWS Config is a configuration management and compliance service that tracks resource configuration changes and evaluates them against rules, but it does not record who made the change or the exact API call details; it focuses on the state of resources, not the audit trail of actions. Option B is wrong because Amazon CloudWatch Logs is used to monitor, store, and access log files from AWS resources and applications, but it does not natively capture IAM API calls; it would require custom logging or integration with CloudTrail to obtain such data. Option D is wrong because IAM Access Analyzer is designed to identify resources shared with external entities and analyze access policies for unintended public or cross-account access, not to provide a historical audit trail of who made changes to IAM policies.

20
MCQmedium

A company uses Amazon CloudWatch Logs to store application logs. A DevOps engineer needs to create a real-time dashboard that displays the count of ERROR-level log entries across all instances. Which approach is the MOST efficient and cost-effective?

A.Create a CloudWatch Logs metric filter for each log group to count ERROR entries, and then create a CloudWatch dashboard
B.Use CloudWatch Logs Insights to run a query that counts ERROR entries across all log groups and add the query to a CloudWatch dashboard
C.Export logs to Amazon S3 and use Amazon Athena to query and visualize in Amazon QuickSight
D.Create a Kinesis Data Firehose delivery stream to stream logs to Amazon OpenSearch Service and build a dashboard in OpenSearch Dashboards
AnswerB

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.

Why this answer

CloudWatch Logs Insights allows you to run a query across all log groups in real time using a single query, and you can add that query directly to a CloudWatch dashboard. This approach is both efficient (no need to create per-log-group metric filters) and cost-effective (you pay only for the data scanned by the query, not for ongoing metric filter evaluation).

Exam trap

The trap here is that candidates often assume metric filters (Option A) are the only native way to get counts into a dashboard, overlooking that CloudWatch Logs Insights queries can be embedded directly into dashboards for real-time, cross-log-group analysis without the overhead of per-group filters.

How to eliminate wrong answers

Option A is wrong because creating a metric filter for each log group incurs ongoing costs for each filter evaluation, and managing filters across many log groups is inefficient compared to a single cross-group query. Option C is wrong because exporting logs to S3 and using Athena/QuickSight introduces latency (logs are not real-time) and additional costs for S3 storage, Athena queries, and QuickSight subscriptions, making it less efficient and more expensive for a real-time dashboard. Option D is wrong because streaming logs to OpenSearch Service via Kinesis Data Firehose adds complexity, latency, and cost for the delivery stream, OpenSearch cluster, and dashboard, which is overkill for a simple count of ERROR entries.

21
Multi-Selectmedium

A company is using Amazon CloudWatch Logs to store application logs. The security team requires that logs are encrypted at rest using a customer-managed AWS KMS key. Which TWO steps are necessary to achieve this?

Select 2 answers
A.Use the CloudWatch Logs console or API to associate the KMS key with the log group
B.Enable default encryption for CloudWatch Logs in the AWS account settings
C.Update the log group's resource policy to reference the KMS key
D.Associate the KMS key with each log stream individually
E.Create a customer-managed KMS key with appropriate key policy that allows CloudWatch Logs to use the key
AnswersA, E

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.

Why this answer

Options A and E are correct. To encrypt CloudWatch Logs with a customer-managed KMS key, you must first create a customer-managed KMS key with a key policy that grants CloudWatch Logs permission to use the key (option E). Then, you associate the key with the log group using the CloudWatch Logs console or API (option A).

Option B is wrong because CloudWatch Logs does not support default encryption at the account level. Option C is wrong because you do not update the log group's resource policy; the key policy is set on the KMS key itself. Option D is wrong because encryption is at the log group level, not per log stream.

22
MCQmedium

A company's DevOps team notices that their Amazon RDS for PostgreSQL instance's CPU utilization spikes to 90% every day at 10:00 AM, causing application latency. They want to be notified when the CPU utilization exceeds 80% for more than 5 minutes to investigate the cause. Which solution should they implement?

A.Use Amazon CloudWatch Logs Insights to query the RDS logs and trigger an SNS notification when CPU utilization is high.
B.Enable AWS Trusted Advisor to automatically create a CloudWatch alarm on the CPU utilization metric.
C.Create an Amazon CloudWatch alarm on the CPUUtilization metric with a period of 5 minutes and a threshold of 80, and set the alarm action to send a notification to an Amazon SNS topic.
D.Create an AWS CloudTrail trail to monitor CPU utilization and trigger an AWS Lambda function to send an email notification.
AnswerC

This directly monitors the metric and triggers notification when the threshold is breached for the specified duration.

Why this answer

An Amazon CloudWatch alarm on the CPUUtilization metric with a period of 5 minutes and a threshold of 80% will evaluate the average CPU utilization over 5-minute intervals. When the average exceeds 80% for a single 5-minute period, the alarm triggers and sends a notification to an SNS topic, meeting the requirement of being alerted when CPU exceeds 80% for more than 5 minutes. Option A is incorrect because CloudWatch Logs Insights is used for querying and analyzing log data, not for triggering alarms on metrics like CPU utilization.

Option B is incorrect because AWS Trusted Advisor provides best practice recommendations and does not create custom CloudWatch alarms. Option D is incorrect because AWS CloudTrail records API activity and does not monitor CPU utilization metrics; it cannot trigger notifications based on performance thresholds.

23
MCQeasy

A DevOps engineer needs to set up a monitoring solution for an AWS Lambda function that processes messages from an Amazon SQS queue. The engineer wants to be alerted if the function fails to process a message (i.e., the message ends up in the dead-letter queue). Which approach should they use?

A.Create a CloudWatch alarm on the ApproximateNumberOfMessagesVisible metric of the dead-letter queue.
B.Enable CloudTrail to log SQS API calls and create a metric filter for SendMessage to the DLQ.
C.Create a CloudWatch Events rule to monitor the Lambda function errors.
D.Configure the Lambda function's dead-letter queue to send notifications via Amazon SNS.
AnswerA

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.

Why this answer

The `ApproximateNumberOfMessagesVisible` metric on the dead-letter queue (DLQ) directly reflects the number of messages that have failed processing and been moved there. By creating a CloudWatch alarm on this metric (e.g., when it exceeds 0 for a period), the engineer receives an alert precisely when messages are failing, without needing to parse logs or rely on indirect indicators.

Exam trap

The trap here is that candidates often confuse monitoring Lambda function errors (Option C) with monitoring DLQ messages, not realizing that a message can end up in the DLQ due to exhaustion of retries (configured in the SQS event source mapping) without the Lambda function itself throwing an error.

How to eliminate wrong answers

Option B is wrong because CloudTrail logs SQS API calls (like SendMessage) but does not provide a real-time metric for DLQ message count; creating a metric filter on SendMessage to the DLQ would require parsing every API call and does not natively aggregate to a simple alarm threshold. Option C is wrong because monitoring Lambda function errors (e.g., via CloudWatch Events or Lambda metrics) captures function invocation failures but does not specifically indicate that a message was sent to the DLQ—messages can fail processing without a Lambda error (e.g., if the function returns an error but the SQS trigger retries and eventually sends to DLQ). Option D is wrong because configuring the Lambda function's DLQ to send notifications via SNS would require custom code or configuration to publish a notification each time a message is moved to the DLQ, which is not a built-in feature of SQS or Lambda; SNS can be used as a target for DLQ messages only if the DLQ itself is an SNS topic, but SQS DLQs are queues, not topics, and SNS does not automatically emit notifications when messages are added to an SQS queue.

24
MCQeasy

A company uses AWS CloudTrail to log API activity in their AWS account. They need to ensure that any changes to CloudTrail configuration itself are detected and alerted upon in real time. Which service should they use?

A.Use Amazon CloudWatch Events (EventBridge) to create a rule matching the StopLogging or UpdateTrail API calls.
B.Enable AWS Config rules to monitor CloudTrail configuration changes.
C.Use Amazon CloudWatch Logs Insights to query CloudTrail logs for changes.
D.Enable Amazon GuardDuty to detect changes to CloudTrail.
AnswerA

CloudWatch Events can trigger notifications in real time for specific API calls.

Why this answer

Amazon CloudWatch Events (EventBridge) can monitor CloudTrail API calls in real time by creating a rule that matches specific API calls such as StopLogging or UpdateTrail. When these calls are made, the rule triggers an action (e.g., SNS notification or Lambda function) to alert administrators immediately. This provides the real-time detection required for changes to CloudTrail configuration itself.

Exam trap

The trap here is that candidates often confuse AWS Config (which is for compliance and configuration history) with real-time event-driven alerting, or they think GuardDuty covers all security monitoring, but neither provides the specific real-time API call detection that EventBridge offers.

How to eliminate wrong answers

Option B is wrong because AWS Config rules are designed for continuous compliance assessment and configuration auditing, not real-time event-driven alerting; they evaluate resources periodically or on configuration changes but do not provide instantaneous alerts. Option C is wrong because CloudWatch Logs Insights is a query tool for analyzing historical log data, not a real-time alerting mechanism; it cannot proactively detect changes as they occur. Option D is wrong because Amazon GuardDuty is a threat detection service that focuses on malicious activity and anomalies (e.g., unusual API calls or compromised credentials), not specifically on monitoring CloudTrail configuration changes for compliance or operational awareness.

25
MCQhard

A media company runs a video transcoding pipeline on AWS. The pipeline uses AWS Step Functions to orchestrate multiple Lambda functions that transcode video files stored in Amazon S3. The company wants to implement a monitoring solution to track the progress of each workflow execution, including which step is currently running, the duration of each step, and any errors. The solution should provide near real-time visibility and allow the team to troubleshoot failed executions quickly. Which solution meets these requirements?

A.Create custom CloudWatch metrics from Lambda functions for each step, and build a CloudWatch dashboard.
B.Use Amazon EventBridge to capture Step Functions execution status changes and build a custom dashboard in CloudWatch.
C.Configure each Lambda function to write logs to CloudWatch Logs with the execution ID, and use CloudWatch Logs Insights to query and visualize.
D.Enable AWS X-Ray tracing on the Step Functions and Lambda functions to get a service map and trace details.
AnswerB

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.

Why this answer

Amazon EventBridge (formerly CloudWatch Events) can capture Step Functions execution state changes (e.g., step started, succeeded, failed). These events can be used to build a custom dashboard in CloudWatch, providing near real-time visibility into workflow progress, step durations, and errors. Option A is incorrect because creating custom metrics from Lambda functions requires additional instrumentation and does not provide workflow-level context easily.

Option C is incorrect because CloudWatch Logs Insights queries are not near real-time; they require searching through logs, and the solution needs real-time visibility. Option D is incorrect because AWS X-Ray provides distributed tracing for individual requests, but it does not offer high-level workflow step tracking with durations and errors aggregated across executions in near real-time.

26
MCQhard

A DevOps team is implementing a comprehensive logging strategy for a microservices architecture running on Amazon EKS. They need to collect logs from all containers and send them to a centralized log analytics platform. The solution must be agentless and support multi-line log events. Which approach should the team use?

A.Deploy a Fluent Bit DaemonSet on the EKS cluster and configure it to send logs to Amazon CloudWatch Logs.
B.Use the Amazon CloudWatch agent as a sidecar container in each pod to forward logs to CloudWatch Logs.
C.Install the Amazon Kinesis Agent on each EC2 instance and configure it to stream logs to Amazon Kinesis Data Firehose.
D.Deploy a Fluentd DaemonSet on the EKS cluster and configure it to send logs to Amazon S3.
AnswerA

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.

Why this answer

Fluent Bit is a lightweight, CNCF-graduated log processor that can be deployed as a DaemonSet on EKS to collect logs from all nodes without requiring sidecar containers. It supports multi-line log events natively via its multiline filter plugin, and it can output directly to Amazon CloudWatch Logs using the cloudwatch_logs output plugin, meeting the agentless requirement since it runs as a Kubernetes DaemonSet rather than as a per-pod sidecar.

Exam trap

The trap here is that candidates often confuse 'agentless' with 'no software at all,' but in Kubernetes, agentless means no sidecar injection per pod; a DaemonSet is considered agentless because it runs as a cluster-level service, not as part of the application deployment.

How to eliminate wrong answers

Option B is wrong because deploying the CloudWatch agent as a sidecar container in each pod is not agentless; it requires modifying every pod definition and increases resource overhead, whereas the requirement specifies an agentless solution. Option C is wrong because the Amazon Kinesis Agent is an EC2-level agent that must be installed on each underlying EC2 instance, which is not agentless and does not integrate with EKS pod-level log collection; it also does not natively support multi-line log events without custom configuration. Option D is wrong because Fluentd is a heavier log collector compared to Fluent Bit, and while it can send logs to Amazon S3, S3 is a storage service, not a centralized log analytics platform; the requirement specifies sending logs to a centralized log analytics platform, which CloudWatch Logs fulfills.

27
MCQhard

A company uses AWS CloudFormation to deploy infrastructure. The security team wants to be notified whenever a stack is created, updated, or deleted. They also want to track who made the change. Which combination of services should be used to achieve this?

A.AWS Config rules and Amazon SNS
B.AWS CloudTrail and Amazon CloudWatch Events (now Events) with SNS
C.Amazon S3 event notifications and AWS Lambda
D.AWS Lambda and Amazon DynamoDB
AnswerB

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.

Why this answer

CloudTrail captures CloudFormation API calls (CreateStack, UpdateStack, DeleteStack) and CloudWatch Events can trigger SNS notifications based on those API calls. Option A is wrong because Config rules evaluate resource compliance, not API events. Option C is wrong because S3 event notifications are for S3 objects.

Option D is wrong because Lambda alone cannot capture who made the change without CloudTrail integration.

28
MCQhard

A company runs a web application on EC2 instances behind an Application Load Balancer. They use Amazon CloudFront for content delivery. The DevOps team notices that some requests are returning HTTP 503 errors intermittently. After checking the CloudFront and ALB logs, they find that the errors originate from the ALB. What is the most likely cause?

A.The SSL certificate on the ALB is expired.
B.The security group for the ALB is blocking traffic from CloudFront.
C.CloudFront is configured to forward an HTTP method that the ALB does not support.
D.The ALB is experiencing a surge in traffic and is scaling up, but during the scaling activity, some requests are rejected.
AnswerD

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.

Why this answer

When an Application Load Balancer (ALB) experiences a sudden surge in traffic that exceeds its current capacity, it may temporarily reject requests with HTTP 503 errors while it scales up. During the scaling activity, the ALB's target group might not have enough healthy registered targets to handle the load, causing the ALB to return 503 responses until new instances are provisioned and pass health checks. This matches the intermittent nature of the errors described in the scenario.

Exam trap

The trap here is that candidates often confuse 503 errors with SSL certificate issues or security group misconfigurations, but the intermittent nature of the errors and the fact that they originate from the ALB (not CloudFront) points directly to capacity scaling limitations rather than configuration errors.

How to eliminate wrong answers

Option A is wrong because an expired SSL certificate on the ALB would cause SSL/TLS handshake failures (e.g., ERR_CERT_DATE_INVALID) and result in 502 Bad Gateway errors from CloudFront, not 503 errors from the ALB. Option B is wrong because if the security group for the ALB were blocking traffic from CloudFront, the ALB would not receive the requests at all, and CloudFront would return 502 errors (or connection timeouts) instead of the ALB returning 503 errors. Option C is wrong because CloudFront forwarding an unsupported HTTP method would cause the ALB to return a 405 Method Not Allowed error, not a 503 Service Unavailable error.

29
Multi-Selectmedium

A company uses Amazon CloudWatch Logs to store application logs. The DevOps team wants to search across multiple log groups for a specific error pattern. Which TWO options can be used to achieve this? (Choose TWO.)

Select 2 answers
A.Use CloudWatch Logs Insights to run queries across multiple log groups.
B.Export the logs to Amazon S3 and use Amazon Athena to query the logs.
C.Install the CloudWatch Logs agent on an EC2 instance and tail the logs.
D.Create a Lambda function that reads logs from each log group and searches for the pattern.
E.Use Amazon Kinesis Data Analytics to process the log streams.
AnswersA, B

CloudWatch Logs Insights can query multiple log groups simultaneously.

Why this answer

CloudWatch Logs Insights is purpose-built for querying log data across multiple log groups. It uses a query language to search, filter, and aggregate log events, making it ideal for identifying error patterns across different sources. This option is correct because it directly supports cross-log-group queries without additional data movement or infrastructure.

Exam trap

The trap here is that candidates may think Lambda or Kinesis are suitable for ad-hoc log searching, but they are designed for real-time processing or custom workflows, not for efficient cross-log-group querying like CloudWatch Logs Insights or Athena.

30
MCQhard

A company runs a containerized web application on Amazon ECS with AWS Fargate. The application is critical and requires high availability. The DevOps team has set up an Amazon CloudWatch alarm that triggers an auto scaling action when the average CPU utilization exceeds 75% for 5 minutes. However, during a recent traffic spike, the application became slow and some requests timed out, even though the CloudWatch alarm did not fire. The team checked the ECS service auto scaling configuration and found that the target tracking scaling policy based on average CPU utilization is set with a target value of 75%. The ECS service is configured with a minimum of 2 tasks and a maximum of 10 tasks. Upon investigation, they noticed that the CPU utilization metric for the service remained below 75% during the spike, but the memory utilization was high (over 90%). The application logs show that the tasks were running out of memory, causing garbage collection pauses and slow responses. Which course of action should the DevOps engineer take to prevent this issue in the future?

A.Add a second target tracking scaling policy based on average memory utilization with a target value of 75%.
B.Decrease the CPU target value to 50% to trigger scaling earlier.
C.Increase the minimum number of tasks from 2 to 5 to provide more capacity upfront.
D.Increase the task memory limit in the task definition to 8 GB.
AnswerA

Memory-based scaling will add tasks when memory is high, preventing memory exhaustion.

Why this answer

The issue is memory pressure, not CPU. Adding a target tracking scaling policy based on average memory utilization with a target value of 75% will cause the ECS service to automatically scale out when memory utilization exceeds the target, preventing performance degradation due to high memory usage. Option B (decreasing CPU target to 50%) is incorrect because CPU utilization was not the bottleneck.

Option C (increasing minimum tasks to 5) provides static capacity but does not dynamically respond to memory spikes, leading to wasted resources or insufficient scaling. Option D (increasing task memory limit) is a static change that may help temporarily but does not provide dynamic scaling; auto scaling based on memory is the recommended approach.

31
MCQhard

A DevOps engineer is configuring a centralized logging solution using Amazon CloudWatch Logs. They need to ensure that logs from multiple AWS accounts are aggregated into a single CloudWatch Logs account. Which approach meets this requirement?

A.Use Amazon Kinesis Data Firehose in each account to stream logs to a central Amazon S3 bucket, then use Amazon Athena to query.
B.Create a subscription filter in each account that delivers log events to a CloudWatch Logs destination in the central account.
C.Set up a cross-account destination using an Amazon Kinesis Data Streams stream in the central account and configure each account to send logs to that stream.
D.Configure each application to use the PutLogEvents API to send logs directly to the central account's log group.
AnswerB

Cross-account subscription filters allow real-time log aggregation from multiple accounts to a central account.

Why this answer

CloudWatch Logs supports cross-account subscription filters that can deliver log events to a CloudWatch Logs destination in a central account. The destination is a logical resource that points to a Kinesis Data Stream or Lambda function in the central account, and the source account creates a subscription filter that sends matching log events to that destination. This allows centralized aggregation without requiring each account to manage separate streaming infrastructure.

Exam trap

The trap here is that candidates confuse the CloudWatch Logs destination (which is a cross-account subscription mechanism) with directly writing to a Kinesis stream or using PutLogEvents across accounts, both of which are not supported for cross-account log aggregation.

How to eliminate wrong answers

Option A is wrong because Amazon Kinesis Data Firehose cannot directly stream logs from CloudWatch Logs in multiple accounts to a central S3 bucket without additional cross-account permissions and intermediate services; it also introduces unnecessary complexity and latency for real-time log aggregation. Option C is wrong because while a cross-account Kinesis Data Streams destination can be used, the correct implementation requires creating a CloudWatch Logs destination in the central account that points to the Kinesis stream, not configuring each account to send logs directly to the stream via PutRecord. Option D is wrong because the PutLogEvents API requires the log group and log stream to exist in the same account as the API call; cross-account PutLogEvents is not supported, and applications cannot send logs directly to a central account's log group.

32
MCQhard

A DevOps engineer is tasked with centralizing logs from multiple AWS accounts into a single Amazon OpenSearch Service domain. The engineer sets up Amazon Kinesis Data Firehose to deliver logs from each account to the OpenSearch domain. However, some accounts show failed deliveries in the Firehose console. Which configuration is MOST likely causing the failures?

A.The IAM role assumed by Firehose in each account does not have permissions to write to the cross-account OpenSearch domain
B.The source accounts do not have a CloudWatch Logs subscription filter to send logs to Firehose
C.The Kinesis Data Streams used as the Firehose source is not encrypted
D.The OpenSearch domain's access policy does not allow access from the S3 bucket used by Firehose
AnswerA

Firehose needs an IAM role with sts:AssumeRole and es:HttpPut permissions for the destination OpenSearch domain.

Why this answer

The most likely cause of failed deliveries is that the IAM role assumed by Kinesis Data Firehose in each source account lacks the necessary permissions to write to the cross-account Amazon OpenSearch Service domain. Firehose uses a service-linked or custom IAM role to perform actions such as `es:ESHttpPut` and `es:ESHttpPost` against the OpenSearch domain endpoint. Without explicit cross-account trust and resource-based policy allowing the Firehose role's ARN, the delivery will fail with an authorization error.

Exam trap

The trap here is that candidates often assume the failure is due to missing CloudWatch subscription filters or S3 bucket permissions, but the real issue is the missing cross-account IAM trust between the Firehose role and the OpenSearch domain's access policy.

How to eliminate wrong answers

Option B is wrong because CloudWatch Logs subscription filters are used to stream log data to Firehose, but the question states that logs are being delivered from multiple accounts; the failure is at the Firehose-to-OpenSearch stage, not at the ingestion stage. Option C is wrong because Kinesis Data Streams encryption (whether server-side or client-side) does not affect Firehose's ability to write to OpenSearch; Firehose can read encrypted streams as long as it has the proper KMS permissions. Option D is wrong because Firehose writes directly to the OpenSearch domain via HTTP/HTTPS, not through an S3 bucket; the OpenSearch domain's access policy must grant access to the Firehose IAM role or the source account's principal, not to an S3 bucket.

33
MCQmedium

A DevOps engineer notices that an Amazon RDS for MySQL instance's CPU is consistently high during business hours. The engineer wants to identify the specific queries causing the high CPU. Which combination of services should be used to capture and analyze the queries? (Choose the best answer.)

A.Enable RDS Performance Insights and analyze the top SQL queries
B.Enable RDS Enhanced Monitoring and view metrics in CloudWatch
C.Enable AWS X-Ray tracing on the application and database
D.Enable RDS audit logs and stream them to Amazon CloudWatch Logs
AnswerA

Performance Insights identifies the top queries by CPU usage.

Why this answer

RDS Performance Insights provides a database performance tuning feature that visualizes database load and identifies the specific SQL queries causing high CPU. It captures query-level metrics such as wait events, SQL digest, and host/user information, allowing the DevOps engineer to pinpoint the exact queries responsible for the CPU spike during business hours.

Exam trap

The trap here is that candidates often confuse Enhanced Monitoring (OS-level metrics) with Performance Insights (query-level analysis), or assume audit logs or X-Ray can provide SQL-level performance data, when in fact they serve different purposes (compliance and tracing, respectively).

How to eliminate wrong answers

Option B is wrong because Enhanced Monitoring provides OS-level metrics (e.g., CPU, memory, disk I/O) but does not capture or identify individual SQL queries; it cannot show which specific queries are causing high CPU. Option C is wrong because AWS X-Ray traces application requests and can trace calls to the database, but it does not capture the actual SQL queries executed on the RDS instance; it is designed for distributed tracing, not query-level analysis. Option D is wrong because RDS audit logs record database activities (e.g., logins, schema changes) for compliance, not query performance metrics; streaming them to CloudWatch Logs does not provide the query-level CPU impact analysis needed to identify high-CPU queries.

34
MCQeasy

A company is using Amazon RDS for MySQL and wants to monitor database connections. They need to set up an alarm when the number of connections exceeds 80% of the maximum connections for more than 5 minutes. Which CloudWatch metric and statistic should be used?

A.DatabaseConnections metric with Maximum statistic
B.DatabaseConnections metric with Average statistic
C.DatabaseConnections metric with Sum and then divide by the number of data points
D.DatabaseConnections metric with Sum statistic
AnswerB

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.

Why this answer

The Average statistic of the DatabaseConnections metric over a 5-minute period provides a smoothed representation of connection usage, which is appropriate for detecting sustained breaches of the 80% threshold. Using Average reduces sensitivity to transient spikes, ensuring the alarm triggers only when the average number of connections remains above the threshold for the entire evaluation period, aligning with the requirement of 'more than 5 minutes'.

Exam trap

The trap here is that candidates often choose Maximum because they think it is the most conservative for detecting high usage, but they overlook that the requirement is for sustained breaches over 5 minutes, not instantaneous spikes, making Average the correct choice for avoiding false alarms.

How to eliminate wrong answers

Option A is wrong because the Maximum statistic captures the highest single data point within the period, which would trigger alarms on brief spikes even if the average stays below 80%, causing false positives. Option C is wrong because dividing the Sum by the number of data points is mathematically equivalent to the Average statistic, but this approach is unnecessarily complex and not a standard CloudWatch metric statistic; CloudWatch directly supports Average. Option D is wrong because the Sum statistic aggregates the total number of connections over the period, which is not meaningful for comparing against a percentage of maximum connections—Sum values scale with the number of data points and do not represent a per-moment connection count.

35
MCQhard

A DevOps team uses AWS Lambda functions to process events from an SQS queue. The Lambda function occasionally fails due to transient errors, and the team wants to capture and analyze the full error details, including stack traces, for debugging. The errors are not always related to invocation failures (e.g., timeouts) but include exceptions thrown within the function code. Which approach will capture the MOST comprehensive error information?

A.Configure a DLQ on the SQS queue to capture failed messages and inspect them.
B.Enable CloudWatch Logs and rely on the automatic logging of invocation results.
C.Ensure the Lambda function code returns a meaningful error object (e.g., throws an exception) so that the error is logged in CloudWatch Logs with a stack trace.
D.Use AWS X-Ray to trace the function execution and analyze the traces.
AnswerC

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.

Why this answer

When a Lambda function throws an exception or returns an error object, AWS Lambda automatically logs the error details, including the stack trace, to CloudWatch Logs. This captures the full error information necessary for debugging transient errors. Option A is incorrect because a Dead Letter Queue (DLQ) on SQS captures the failed messages themselves, not the error details or stack traces of the function execution.

Option B is incorrect because CloudWatch Logs automatic invocation logging provides only basic information such as invocation time, duration, and status; it does not include the function's stack trace unless explicitly logged by the code. Option D is incorrect because AWS X-Ray provides tracing of requests and can show service maps and latency, but it does not necessarily capture the full stack trace of application-level exceptions; it focuses on request flow rather than detailed error logs.

36
MCQhard

A company has a multi-account AWS environment using AWS Organizations. The security team needs to centrally monitor and analyze VPC Flow Logs from all accounts. The solution must be cost-effective and allow querying across accounts. Which approach should they take?

A.Use Amazon Elasticsearch Service (Amazon OpenSearch Service) with a cross-account ingestion pipeline.
B.Stream VPC Flow Logs from each account to Amazon Kinesis Data Analytics for real-time analysis.
C.Send VPC Flow Logs from each account to a centralized Amazon S3 bucket, then use Amazon Athena to query the logs.
D.Configure each account to send VPC Flow Logs to a central CloudWatch Logs group using cross-account subscription.
AnswerC

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.

Why this answer

It uses a centralized Amazon S3 bucket to aggregate VPC Flow Logs from all accounts, which is cost-effective (S3 storage costs are low) and enables cross-account querying via Amazon Athena using standard SQL. This approach avoids per-ingestion costs of services like CloudWatch Logs or Kinesis and provides a serverless, scalable query engine for analyzing logs across accounts.

Exam trap

The trap here is that candidates may overestimate the complexity of cross-account S3 access or underestimate the cost of CloudWatch Logs ingestion, leading them to choose Option D (central CloudWatch Logs group) which seems simpler but is actually more expensive and less query-friendly than S3+Athena.

How to eliminate wrong answers

Option A is wrong because Amazon OpenSearch Service (formerly Elasticsearch Service) incurs significant costs for ingestion and storage, and cross-account ingestion pipelines require complex setup with Lambda or Kinesis, making it less cost-effective than S3+Athena. Option B is wrong because Amazon Kinesis Data Analytics is designed for real-time stream processing, not for cost-effective historical querying across accounts; it would be overkill and expensive for periodic analysis of VPC Flow Logs. Option D is wrong because CloudWatch Logs cross-account subscriptions require each account to send logs to a central account's CloudWatch Logs group, which incurs per-ingestion costs and does not natively support SQL-based querying like Athena; querying across accounts would require additional tools or cross-account log group access, increasing complexity and cost.

37
Multi-Selecthard

A company is using Amazon CloudWatch Synthetics canaries to monitor its web application endpoints. The canaries are failing intermittently with timeout errors. The DevOps team needs to troubleshoot the root cause. Which THREE actions should they take? (Select THREE.)

Select 3 answers
A.Use AWS CloudTrail to review Canary API calls.
B.Increase the canary timeout configuration to allow more time for the endpoint to respond.
C.Check the EC2 instance CPU utilization in the VPC where the canaries run.
D.Review VPC Flow Logs to see if requests are being dropped or denied.
E.Examine the canary logs in CloudWatch Logs for error messages.
AnswersB, D, E

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

Why this answer

Options B, D, and E are correct. B: Increasing the canary timeout configuration can resolve timeout errors if the endpoint is slow but still functional. D: Reviewing VPC Flow Logs helps identify network issues such as dropped or denied requests that could cause timeouts.

E: Examining canary logs in CloudWatch Logs provides detailed error messages and execution traces to pinpoint the failure cause. Option A is incorrect because CloudTrail records API calls, not canary execution details; canary logs are in CloudWatch Logs. Option C is incorrect because canaries run in AWS Lambda, not on EC2 instances, so EC2 CPU utilization is irrelevant.

38
MCQmedium

A company is running a microservices application on Amazon ECS with AWS Fargate. The operations team needs to monitor application performance and troubleshoot slow API responses. They currently use Amazon CloudWatch Logs for container logs and have enabled Container Insights. However, they are unable to see detailed latency breakdowns per API endpoint. Which solution would provide the most granular visibility into API performance?

A.Enable detailed CloudWatch metrics for ECS and Fargate, including CPU and memory.
B.Enable CloudWatch Logs Insights to query API logs for slow requests.
C.Use AWS X-Ray to instrument the application and collect trace data.
D.Deploy the AWS Distro for OpenTelemetry collector on each task to send metrics to CloudWatch.
E.Set up VPC Flow Logs to analyze network latency between services.
AnswerC

AWS X-Ray provides end-to-end tracing with segment details, allowing you to see latency per API endpoint and downstream dependencies.

Why this answer

AWS X-Ray provides end-to-end tracing of requests as they travel through microservices, capturing detailed latency breakdowns per API endpoint, including downstream calls, database queries, and external HTTP requests. This gives the operations team the granular visibility needed to pinpoint exactly where slow responses occur, unlike aggregated metrics or log-based queries.

Exam trap

The trap here is that candidates confuse infrastructure-level metrics (CPU, memory, network) or log-based querying with the distributed tracing capability needed to break down latency per API endpoint, overlooking that only X-Ray provides end-to-end trace segments with sub-millisecond timing per service call.

How to eliminate wrong answers

Option A is wrong because enabling detailed CloudWatch metrics for ECS and Fargate (CPU, memory, network) provides infrastructure-level metrics, not per-endpoint latency breakdowns. Option B is wrong because CloudWatch Logs Insights can query logs for slow requests but cannot trace a single request across multiple services or show the latency contributed by each downstream call. Option D is wrong because the AWS Distro for OpenTelemetry collector sends metrics and traces to CloudWatch, but without X-Ray integration or trace sampling, it does not provide the per-endpoint latency breakdowns that X-Ray's service map and trace segments offer.

Option E is wrong because VPC Flow Logs capture network-level metadata (packet headers, timestamps) and can indicate network latency between ENIs, but they cannot reveal application-level latency per API endpoint or trace a request through microservices.

Ready to test yourself?

Try a timed practice session using only Monitoring and Logging questions.