Knowledge + Practice

CCNA Monitoring, Logging, and Remediation Questions

40 questions · Monitoring, Logging, and Remediation · All types, answers revealed

Practice these questions Domain overview All questions

1

MCQmedium

An environment has 12 individual CloudWatch metric alarms covering CPU, memory, disk, and network. When one instance degrades, all 12 alarms fire simultaneously and send 12 separate notifications to the on-call engineer. The team wants a single notification per incident regardless of how many individual alarms trigger. What CloudWatch feature addresses this?

A.Create a composite alarm that enters ALARM state when any of the 12 child alarms is in ALARM state, and configure a single SNS action on the composite alarm only

B.Increase the alarm evaluation period on all 12 alarms to 30 minutes so they fire less frequently

C.Use an SNS topic with a delivery policy that batches notifications sent within a 60-second window

D.Configure all 12 alarms to write to the same CloudWatch Events rule and suppress duplicate events with EventBridge deduplication

AnswerA

The composite alarm's rule expression 'ALARM(alarm1) OR ALARM(alarm2) OR ...' triggers when any child fires. By routing all notifications through the composite alarm's action and removing actions from the child alarms, exactly one notification is sent per incident. Child alarm states remain visible in the console for root cause analysis.

Why this answer

A composite alarm in CloudWatch can aggregate multiple child alarms into a single parent alarm. When any of the 12 child alarms enters the ALARM state, the composite alarm transitions to ALARM and triggers a single SNS notification, thereby reducing alert noise to one notification per incident.

Exam trap

The trap here is that candidates may think SNS batching or EventBridge deduplication can consolidate separate alarm notifications, but those services do not aggregate distinct alarm state changes into a single event; only composite alarms provide that logical grouping.

How to eliminate wrong answers

Option B is wrong because increasing the evaluation period to 30 minutes does not consolidate multiple notifications into one; it merely delays the alarms, and all 12 would still fire individually after the longer period. Option C is wrong because SNS delivery policies control retries and message batching for HTTP/HTTPS endpoints, not deduplication or aggregation of separate alarm notifications; each alarm still sends its own message to the topic. Option D is wrong because CloudWatch Events (now EventBridge) can route alarm state changes to targets, but EventBridge deduplication applies to events based on a deduplication ID and is designed for idempotent event processing, not for collapsing multiple distinct alarm events into a single notification.

Practice this question →

2

MCQmedium

A SysOps administrator needs to monitor the CPU utilization of an Amazon EC2 instance and receive an email notification when the metric exceeds 90% for 5 consecutive minutes. The solution should use the least operational overhead. Which combination of AWS services should be used?

A.Create a CloudWatch alarm on the CPUUtilization metric and configure the alarm to send a notification to an Amazon SNS topic with email subscriptions.

B.Create an Amazon EventBridge rule that triggers an AWS Lambda function to check the CPUUtilization metric and send an email via Amazon SES.

C.Configure the EC2 instance to publish CPU logs to Amazon CloudWatch Logs, then create a metric filter to detect high CPU and trigger an SNS notification.

D.Use AWS CloudTrail to monitor EC2 CPU metrics and send notifications to an Amazon SQS queue.

AnswerA

This is the simplest approach. CloudWatch natively monitors EC2 metrics and can trigger SNS notifications without any custom code.

Why this answer

A CloudWatch alarm directly monitors the CPUUtilization metric for an EC2 instance and can be configured to evaluate whether the metric exceeds 90% for 5 consecutive minutes (e.g., 5 evaluation periods of 1 minute each). The alarm then publishes to an Amazon SNS topic, which sends email notifications to subscribed endpoints, requiring no additional infrastructure or code, thus minimizing operational overhead.

Exam trap

The trap here is that candidates may overcomplicate the solution by introducing Lambda or log-based filters, when the simplest and most direct path—a CloudWatch alarm on the existing CPUUtilization metric with an SNS action—is the correct answer for minimal operational overhead.

How to eliminate wrong answers

Option B is wrong because it introduces unnecessary complexity by using an EventBridge rule and a Lambda function to poll or process metrics, which increases operational overhead and latency compared to a native CloudWatch alarm. Option C is wrong because publishing CPU logs to CloudWatch Logs and creating a metric filter is designed for log-based metrics (e.g., parsing log entries), not for the native CPUUtilization metric, which is already available as a CloudWatch metric without logs. Option D is wrong because AWS CloudTrail records API calls and management events, not EC2 CPU utilization metrics, and cannot monitor or trigger notifications based on performance metrics.

Practice this question →

3

Drag & Dropmedium

Drag and drop the steps to troubleshoot an unhealthy target in an Application Load Balancer target group into the correct order.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

Troubleshooting starts with security group rules, then health check configuration, then instance and application status, then logs, and finally replacement if needed.

Practice this question →

4

Multi-Selecteasy

A SysOps administrator needs to monitor the disk space usage on an EC2 instance running Windows Server. Which actions are required to collect this metric? (Select TWO.)

Select 2 answers

A.Install the CloudWatch Logs agent to monitor disk usage logs.

B.Enable EC2 status checks to monitor disk health.

C.Use Windows Performance Monitor to track disk space and send to CloudWatch.

D.Create an IAM role with permissions to publish custom metrics and attach it to the instance.

E.Install the CloudWatch agent on the instance and configure it to collect disk metrics.

AnswersD, E

The instance needs IAM permissions to publish metrics.

Why this answer

The CloudWatch agent requires permissions to publish custom metrics to CloudWatch. An IAM role with the appropriate policy (e.g., CloudWatchAgentServerPolicy) must be attached to the EC2 instance to allow the agent to send disk space metrics. Option E is correct because the CloudWatch agent must be installed and configured with a JSON configuration file that includes the "disk" section to collect disk space utilization metrics, which are not available by default from EC2.

Exam trap

The trap here is that candidates often confuse the CloudWatch Logs agent with the CloudWatch agent, or assume that EC2 status checks or Performance Monitor can directly send disk metrics to CloudWatch without additional configuration.

Practice this question →

5

MCQeasy

A SysOps administrator needs to monitor the CPU utilization of an Amazon EC2 instance and send an alert when it exceeds 90% for 5 consecutive minutes. Which combination of AWS services should the administrator use to meet this requirement?

A.Amazon CloudWatch metric (CPUUtilization), a CloudWatch alarm, and an Amazon SNS topic.

B.Amazon CloudWatch Logs, a metric filter to extract CPU utilization from logs, and an alarm on that metric.

C.A CloudWatch dashboard and an AWS Lambda function that checks the dashboard periodically.

D.Amazon EventBridge (CloudWatch Events) and a Lambda function that calls the EC2 DescribeInstances API.

AnswerA

EC2 publishes a standard hypervisor-level CPUUtilization metric to CloudWatch every 5 minutes (or 1 minute with detailed monitoring). A CloudWatch alarm can evaluate that metric against a threshold using a period, statistic (e.g., Average), and evaluation periods, then transition to ALARM state and publish a message to an SNS topic, which can fan out to email, SMS, or HTTP endpoints. This is the native, least-effort, and most reliable pattern for triggering on CPU utilization; it requires no custom code, log filtering, or polling.

Why this answer

The correct approach is to use a CloudWatch metric for CPUUtilization, which is automatically published by EC2 instances. A CloudWatch alarm can be configured to evaluate this metric over a period of 5 consecutive minutes with a threshold of 90%, and when the alarm state is triggered, it publishes to an SNS topic to send notifications. This is the native, efficient, and recommended method for monitoring and alerting on EC2 CPU utilization.

Exam trap

The trap here is that candidates may confuse CloudWatch Logs metric filters (used for custom log-based metrics) with the built-in EC2 metrics, or think that EventBridge can directly access CPU utilization data, when in fact CPUUtilization is a CloudWatch metric and must be monitored via CloudWatch alarms.

How to eliminate wrong answers

Option B is wrong because CloudWatch Logs and metric filters are used to extract custom metrics from log data (e.g., application logs), not to monitor the built-in CPUUtilization metric which is already available as a CloudWatch metric without needing log extraction. Option C is wrong because a CloudWatch dashboard is a visualization tool and does not trigger alerts; a Lambda function polling a dashboard periodically is inefficient, introduces latency, and is not a supported pattern for real-time alerting. Option D is wrong because EventBridge and a Lambda function calling DescribeInstances API only retrieves instance metadata and state, not CPU utilization metrics; CPU utilization is a CloudWatch metric, not available via the EC2 DescribeInstances API.

Practice this question →

6

MCQmedium

A SysOps administrator needs to monitor memory utilization on an Amazon EC2 instance. Memory metrics are not available by default in Amazon CloudWatch for EC2 instances. Which action should the administrator take to collect memory utilization metrics?

A.Install the CloudWatch agent on the EC2 instance

B.Enable detailed monitoring on the EC2 instance

C.Use an AWS Lambda function to query the EC2 instance for memory metrics

D.Use Amazon Inspector to collect memory metrics

AnswerA

The CloudWatch agent can collect memory and other system-level metrics from the EC2 instance and publish them to CloudWatch custom metrics.

Why this answer

The CloudWatch agent is the correct solution because it can collect custom metrics, including memory utilization, from EC2 instances. Unlike the default hypervisor-level metrics (CPU, network, disk), memory metrics require an in-guest agent to read the operating system's memory counters and publish them to CloudWatch.

Exam trap

The trap here is that candidates confuse 'detailed monitoring' (which increases metric frequency) with the ability to collect new metric types, assuming it will magically include memory metrics when it only affects existing hypervisor-level metrics.

How to eliminate wrong answers

Option B is wrong because enabling detailed monitoring only increases the frequency of default EC2 metrics (e.g., CPU, disk I/O) from 5 minutes to 1 minute; it does not add memory metrics. Option C is wrong because AWS Lambda cannot directly query an EC2 instance's OS-level memory metrics without an agent or API endpoint installed inside the instance. Option D is wrong because Amazon Inspector is a vulnerability assessment service that scans for software vulnerabilities and network exposures, not a tool for collecting OS-level performance metrics like memory utilization.

Practice this question →

7

MCQhard

A company is using AWS Lambda functions to process incoming messages from Amazon SQS. The Lambda function sometimes fails due to a transient error, and the message is not processed. The team wants to automatically retry failed messages and send them to a dead-letter queue (DLQ) after three failed attempts. Which configuration meets these requirements?

A.Set the Lambda function's reserved concurrency to 1 and enable 'maximumRetryAttempts' to 2.

B.Create an SQS queue with a visibility timeout that allows three retries before sending to a DLQ.

C.Configure the SQS queue as an event source for Lambda with a DLQ specified in the Lambda function's dead-letter configuration.

D.Configure the SQS queue with a redrive policy that allows three maximum receives before sending to a DLQ.

AnswerD

A redrive policy with maxReceiveCount set to 3 ensures that after the message has been received from the queue three times without successful processing, the message is automatically moved to the configured dead-letter queue. This is the standard SQS mechanism for defining retry limits because each receive attempt by the Lambda consumer counts toward maxReceiveCount. The DLQ is configured on the SQS queue itself, not on the Lambda function, and this behavior is specific to SQS event sources.

Why this answer

When SQS is configured as an event source for Lambda, retries are controlled by the SQS queue's redrive policy. The redrive policy with maxReceiveCount determines how many times a message can be received before it is moved to the DLQ. Setting maxReceiveCount to 3 means after three receive attempts (i.e., three failed processing attempts), the message is sent to the DLQ.

Option C is incorrect because Lambda's dead-letter configuration is used for asynchronous invocations, not for SQS event source mappings. For SQS-triggered functions, the DLQ must be configured on the SQS queue itself using a redrive policy, not on the Lambda function.

Exam trap

The trap is that candidates often assume the Lambda dead-letter configuration applies to SQS event source mappings. However, for SQS triggers, retries and DLQ routing are managed by the SQS queue's redrive policy, not by Lambda's DLQ settings.

How to eliminate wrong answers

Option A is wrong because setting reserved concurrency to 1 does not control retry behavior; 'maximumRetryAttempts' is a property of the Lambda event source mapping, not a direct function configuration, and setting it to 2 would only allow 2 retries (total 3 attempts), but the reserved concurrency limit is irrelevant for retry logic. Option B is wrong because the SQS visibility timeout controls how long a message is hidden after being polled, but it does not inherently trigger retries or send messages to a DLQ after three failures; the redrive policy on the SQS queue is needed for that. Option D is wrong because configuring the SQS queue with a redrive policy that allows three maximum receives sends messages to the DLQ after three receives, but this does not integrate with Lambda's automatic retry mechanism; Lambda would need to delete the message after successful processing, and the redrive policy would only trigger if the message is not deleted, which may not align with the requirement for Lambda to retry on transient errors.

Practice this question →

8

MCQeasy

A SysOps administrator needs to monitor the memory utilization of an EC2 instance running Windows Server. Which steps are required to collect memory metrics?

A.Install and configure the Amazon CloudWatch agent on the instance.

B.Install the AWS Systems Manager Agent (SSM Agent) and use Run Command.

C.Enable detailed monitoring on the EC2 instance.

D.Use the AWS Management Console to enable memory monitoring.

AnswerA

The CloudWatch agent can collect memory and disk metrics.

Why this answer

Amazon CloudWatch does not collect memory metrics from EC2 instances by default; it only captures hypervisor-level metrics such as CPU, network, and disk I/O. To monitor in-guest memory utilization on a Windows Server instance, you must install and configure the Amazon CloudWatch agent, which sends custom metrics (e.g., Memory % Committed Bytes In Use) to CloudWatch. The agent uses the Windows Performance Monitor (PerfMon) counters to gather this data.

Exam trap

The trap here is that candidates assume memory metrics are automatically available or can be enabled via a simple console toggle, when in fact they require the CloudWatch agent to be installed and configured on the instance.

How to eliminate wrong answers

Option B is wrong because the AWS Systems Manager Agent (SSM Agent) and Run Command are used for management tasks like patching or executing scripts, not for collecting and publishing memory metrics to CloudWatch. Option C is wrong because enabling detailed monitoring only increases the frequency of existing hypervisor-level metrics (e.g., CPU, network) from 5 minutes to 1 minute; it does not add in-guest memory metrics. Option D is wrong because the AWS Management Console does not have a built-in toggle to enable memory monitoring; memory metrics require the CloudWatch agent to be installed and configured on the instance.

Practice this question →

9

MCQmedium

A SysOps administrator manages an Amazon RDS for MySQL instance that handles a critical web application. During peak traffic, the number of database connections exceeds 500 for more than 15 minutes, leading to connection timeouts. The administrator wants to automatically increase the DB instance size when the connection count remains high, and decrease it when the load drops, to balance performance and cost. Which combination of AWS services should be used to achieve this automation with the least operational overhead?

A.Configure a CloudWatch alarm on DatabaseConnections that triggers an Amazon CloudWatch Events rule, which directly modifies the DB instance class using a CloudFormation custom resource.

B.Use an AWS Config rule to monitor DatabaseConnections and invoke an AWS Lambda function to scale the RDS instance when the threshold is breached.

C.Set up an Amazon CloudWatch alarm on the DatabaseConnections metric that triggers an AWS Lambda function to modify the DB instance class via the RDS API.

D.Use an AWS Systems Manager Automation runbook to periodically check the DatabaseConnections metric and adjust the RDS instance class if needed.

AnswerC

Correct: you create a CloudWatch alarm on DatabaseConnections with a threshold (e.g., high connections for 5 minutes); when it enters ALARM, it sends a notification to an SNS topic that triggers a Lambda function, or uses an alarm action to invoke Lambda directly. The Lambda function calls the RDS ModifyDBInstance API with the desired DBInstanceClass and the DBInstanceIdentifier, and RDS performs the scaling. This is an event-driven, low-latency pattern that requires no polling and is a supported, commonly used approach for automated RDS instance-class scaling.

Why this answer

It uses a CloudWatch alarm to monitor the DatabaseConnections metric, which triggers an AWS Lambda function that directly calls the RDS ModifyDBInstance API to change the instance class. This approach provides the least operational overhead by leveraging native AWS services without additional infrastructure, custom resources, or periodic polling, and it enables real-time, event-driven scaling based on the specified threshold.

Exam trap

The trap here is that candidates often confuse AWS Config rules (designed for compliance) with CloudWatch alarms (designed for metric monitoring), leading them to choose Option B, or they overcomplicate the solution with CloudFormation custom resources (Option A) or Systems Manager runbooks (Option D) when a simple Lambda function triggered by a CloudWatch alarm is the most direct and low-overhead approach.

How to eliminate wrong answers

Option A is wrong because CloudFormation custom resources require a Lambda-backed provisioning function and are designed for infrastructure provisioning, not for real-time, event-driven scaling of an existing RDS instance; they introduce unnecessary complexity and latency. Option B is wrong because AWS Config rules are designed for compliance and resource configuration auditing, not for monitoring real-time CloudWatch metrics like DatabaseConnections, and they cannot directly invoke a Lambda function for metric-based scaling without additional setup. Option D is wrong because AWS Systems Manager Automation runbooks are intended for operational tasks and remediation workflows, but periodically checking metrics introduces polling overhead and latency, which is less efficient than event-driven triggers and increases operational complexity.

Practice this question →

10

Multi-Selectmedium

A SysOps administrator is troubleshooting an Amazon EC2 instance that is unreachable. The instance passes the system status check but fails the instance status check. Which TWO of the following are likely causes of this issue? (Choose TWO.)

Select 2 answers

A.Network connectivity issues

B.Detached EBS root volume

C.Misconfigured firewall or iptables

D.Insufficient memory for applications

E.Corrupted file system

AnswersC, E

A misconfigured firewall or iptables ruleset can block all inbound and outbound traffic, effectively making the instance unreachable despite the OS running normally. The instance status check performs a network reachability test at the OS level, and if the packet filtering rules prevent the response, the check fails, indicating an instance-level problem. Since the issue stems from guest OS configuration rather than AWS infrastructure, it is correctly identified as an instance status check failure.

Why this answer

An instance status check failure indicates that the operating system or the instance itself is not functioning correctly, even though the underlying hardware (system status check) is healthy. A misconfigured firewall or iptables can block required network traffic, causing the instance to appear unreachable, while a corrupted file system can prevent the OS from booting or operating properly, both of which are detected by the instance status check.

Exam trap

The trap here is that candidates often confuse instance status checks with system status checks, incorrectly attributing network-level issues (like detached volumes or external connectivity) to instance status failures when they actually belong to system status failures.

Practice this question →

11

MCQhard

A SysOps team needs to monitor application logs in Amazon CloudWatch Logs for specific error codes and automatically invoke an AWS Lambda function for remediation within 5 minutes of an error occurring. Which solution involves the least operational overhead?

A.Create a CloudWatch Logs subscription filter to stream logs directly to an AWS Lambda function.

B.Create a CloudWatch metric filter on the log group, create a CloudWatch alarm on the metric, and configure the alarm to post to an SNS topic that triggers the Lambda function.

C.Use a third-party log aggregation tool that sends webhook notifications to an API Gateway endpoint to invoke the Lambda function.

D.Write a custom script that runs on an EC2 instance to poll CloudWatch Logs every minute and invoke the Lambda function.

AnswerB

Correct. This uses native CloudWatch features with minimal overhead, meeting the 5-minute requirement through alarm evaluation intervals.

Why this answer

It uses CloudWatch metric filters and alarms to detect error codes in logs and trigger remediation via SNS and Lambda, all within a fully managed AWS pipeline. This approach requires no custom code or infrastructure to maintain, and the alarm can be configured to evaluate logs within a 1-minute period, easily meeting the 5-minute requirement with minimal operational overhead.

Exam trap

The trap here is that candidates often assume a subscription filter (Option A) is the simplest because it directly streams logs to Lambda, but they overlook that it lacks native filtering for specific error codes and requires the Lambda to process all log events, increasing complexity and cost compared to a metric filter and alarm.

How to eliminate wrong answers

Option A is wrong because CloudWatch Logs subscription filters stream logs in near real-time but do not provide a built-in mechanism to filter for specific error codes before invoking Lambda; the Lambda function would have to parse every log event, increasing cost and complexity, and there is no native alarm or retry logic for missed events. Option C is wrong because introducing a third-party log aggregation tool and an API Gateway endpoint adds significant operational overhead for setup, maintenance, and cost, and it violates the 'least operational overhead' requirement. Option D is wrong because writing a custom script on an EC2 instance to poll CloudWatch Logs every minute introduces unnecessary compute resources, potential single points of failure, and ongoing maintenance overhead, which is far from the least operational overhead solution.

Practice this question →

12

Multi-Selecthard

A company uses CloudWatch Logs to collect application logs from EC2 instances. The logs are critical for troubleshooting. The operations team notices that some log entries are missing during peak hours. The CloudWatch Logs agent is configured with a batch size of 1 MB and a batch timeout of 10 seconds. Which TWO actions should the administrator take to reduce the chance of missing log events?

Select 2 answers

A.Use PutLogEvents directly from the application.

B.Reduce the retry count for failed requests.

C.Increase the batch size to 5 MB.

D.Increase the batch timeout to 30 seconds.

E.Enable log compression in the agent configuration.

AnswersC, E

Larger batches reduce the number of API calls, lowering the chance of hitting rate limits.

Why this answer

Increasing the batch size from 1 MB to 5 MB allows the CloudWatch Logs agent to buffer more log data before sending a request. During peak hours, log volume spikes can cause the agent to drop events if the batch fills up faster than it can be transmitted. A larger batch size reduces the frequency of API calls and helps ensure that all log entries are successfully delivered.

Exam trap

The trap here is that candidates often think increasing the batch timeout (Option D) will help, but in reality, a longer timeout increases the risk of buffer overflow during peak traffic, whereas increasing batch size and enabling compression directly address throughput and payload limits.

Practice this question →

13

MCQhard

The security team requires that no S3 bucket in the account ever has public read or write ACLs enabled. They want non-compliant buckets automatically remediated within 5 minutes of detection without any manual intervention. What is the correct implementation?

A.Create an AWS Config rule for s3-bucket-public-read-prohibited; configure auto-remediation using the AWS-DisableS3BucketPublicReadWrite SSM Automation document

B.Create an EventBridge rule that matches S3 PutBucketAcl API calls and triggers a Lambda function to re-apply a private ACL

C.Enable S3 Block Public Access at the account level to prevent public ACLs from being set in the first place

D.Schedule a daily Lambda function that lists all buckets, checks ACLs, and removes public grants if found

AnswerA

Config evaluates the rule within seconds of a bucket ACL change. The auto-remediation action invokes the SSM document automatically when compliance status changes to NON_COMPLIANT. The SSM document calls PutBucketAcl to remove public grants. The entire cycle completes in 1-3 minutes under normal conditions.

Why this answer

AWS Config can evaluate S3 bucket ACLs against the `s3-bucket-public-read-prohibited` managed rule and automatically trigger an AWS Systems Manager (SSM) Automation document (`AWS-DisableS3BucketPublicReadWrite`) as a remediation action. This ensures non-compliant buckets are fixed within minutes without manual intervention, meeting the 5-minute requirement.

Exam trap

The trap here is that candidates often choose Option C (Block Public Access) thinking it prevents all public access, but it does not remediate existing non-compliant buckets, which is explicitly required by the question.

How to eliminate wrong answers

Option B is wrong because EventBridge rules matching `PutBucketAcl` API calls only trigger on new ACL changes, not on existing buckets that already have public ACLs; it also cannot detect public ACLs set via other methods (e.g., S3 console or SDK) and does not provide a 5-minute remediation guarantee for all non-compliant buckets. Option C is wrong because S3 Block Public Access at the account level prevents new public ACLs from being set but does not automatically remediate existing buckets that already have public ACLs; it also does not meet the requirement for automatic remediation within 5 minutes of detection. Option D is wrong because a daily Lambda function runs only once per day, which violates the 5-minute remediation requirement; it also relies on a custom script that may miss edge cases or fail to handle all ACL configurations.

Practice this question →

14

MCQmedium

A web application publishes a custom metric 'FailedLoginAttempts' to Amazon CloudWatch. The SysOps administrator needs to be notified via Amazon SNS when the number of failed login attempts exceeds 100 within a 5-minute period. Which AWS service or feature should be used to create this notification?

A.Amazon CloudWatch Logs metric filter

B.Amazon CloudWatch alarm

C.Amazon CloudWatch dashboard

D.AWS Config rule

AnswerB

A CloudWatch alarm continuously evaluates a single metric against a defined threshold over a specified number of evaluation periods. When the metric crosses the threshold (for example, failedloginattempts exceeding a certain count within 5 minutes), the alarm state changes to ALARM and triggers an action such as publishing to an Amazon SNS topic, which can then send email or SMS notifications. This is the only option that directly monitors the existing custom metric and initiates a notification with built-in alerting logic.

Why this answer

An Amazon CloudWatch alarm is the correct service because it monitors a specific CloudWatch metric (such as 'FailedLoginAttempts') and triggers an action (such as sending an SNS notification) when the metric crosses a defined threshold over a specified period. In this case, the alarm evaluates whether the sum of 'FailedLoginAttempts' exceeds 100 within a 5-minute period, and upon breaching, it publishes to the SNS topic to notify the SysOps administrator.

Exam trap

The trap here is that candidates often confuse CloudWatch Logs metric filters (which extract metrics from logs) with CloudWatch alarms (which evaluate metrics and trigger actions), leading them to choose Option A even though the custom metric is already published to CloudWatch and does not require log extraction.

How to eliminate wrong answers

Option A is wrong because Amazon CloudWatch Logs metric filters are used to extract metric data from log events (e.g., from CloudWatch Logs), not to monitor a custom metric that is already published directly to CloudWatch; they cannot directly trigger SNS notifications without an alarm. Option C is wrong because an Amazon CloudWatch dashboard is a visualization tool for displaying metrics and alarms, not a service that evaluates metric thresholds or triggers notifications. Option D is wrong because AWS Config rules evaluate resource configurations for compliance against desired policies, not real-time metric values like failed login attempts, and they cannot directly trigger SNS notifications based on metric thresholds.

Practice this question →

15

MCQmedium

A SysOps administrator needs to monitor the CPU utilization of an Amazon RDS for PostgreSQL instance and receive an alert if the usage exceeds 80% for 5 consecutive minutes. The database is in a production environment. What is the MOST efficient way to achieve this?

A.Configure an Amazon Simple Notification Service (SNS) topic to subscribe to CloudWatch alarms for all RDS metrics and filter for CPUUtilization.

B.Create an AWS Lambda function that queries the RDS performance schema every minute and publishes a custom metric to CloudWatch, then set an alarm.

C.Create an Amazon CloudWatch alarm on the CPUUtilization metric with a threshold of 80 and an evaluation period of 5 minutes.

D.Use a third-party monitoring tool such as Datadog because CloudWatch cannot monitor RDS CPU utilization.

AnswerC

CloudWatch directly monitors RDS metrics and can trigger an alarm based on the metric's value over a specified period.

Why this answer

Amazon CloudWatch natively publishes the CPUUtilization metric for RDS instances every minute (standard monitoring) or every 5 minutes (enhanced monitoring). Creating a CloudWatch alarm with a threshold of 80% and an evaluation period of 5 consecutive minutes directly meets the requirement without additional infrastructure. This is the most efficient approach as it uses built-in RDS monitoring capabilities with no custom code or third-party tools.

Exam trap

The trap here is that candidates may overcomplicate the solution by assuming CloudWatch cannot natively monitor RDS CPU utilization or that custom code is required, when in fact RDS automatically publishes CPUUtilization to CloudWatch and alarms can be configured directly.

How to eliminate wrong answers

Option A is wrong because subscribing an SNS topic to all CloudWatch alarms for RDS metrics would require filtering at the SNS level, which is inefficient and does not directly create the alarm; the alarm must be created first, and SNS is a notification target, not a monitoring configuration tool. Option B is wrong because querying the RDS performance schema every minute via Lambda is unnecessarily complex, introduces latency, and incurs additional cost; CloudWatch already provides the CPUUtilization metric natively for RDS without custom instrumentation. Option D is wrong because CloudWatch fully supports monitoring RDS CPU utilization; a third-party tool like Datadog adds cost and complexity without solving the stated requirement.

Practice this question →

16

Drag & Dropmedium

Drag and drop the steps to migrate an on-premises application to AWS using AWS Application Migration Service (MGN) into the correct order.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

The correct sequence for migrating an on-premises application to AWS using AWS Application Migration Service is: first install the AWS Replication Agent on the source server, then configure the replication settings including launch settings and target VPC, then start the initial sync to replicate the entire server volume, then perform a test launch to validate the replicated environment, and finally initiate the cutover to redirect production traffic to the new AWS instance. Each step builds on the previous one to ensure a successful migration with minimal downtime.

Practice this question →

17

Multi-Selectmedium

A company wants to monitor AWS API calls for suspicious activity. Which TWO AWS services can be used together to achieve this?

Select 2 answers

A.VPC Flow Logs

B.Amazon CloudWatch Logs

C.Amazon Inspector

D.AWS Config

E.AWS CloudTrail

AnswersB, E

CloudWatch Logs can analyze CloudTrail logs for suspicious patterns.

Why this answer

Options B and E are correct. AWS CloudTrail logs all API calls made to the AWS environment, providing an audit trail. Amazon CloudWatch Logs can ingest CloudTrail logs and use metric filters to detect patterns indicative of suspicious activity.

Option A (VPC Flow Logs) captures IP traffic information, not API calls. Option C (Amazon Inspector) is a vulnerability assessment service. Option D (AWS Config) records resource configuration changes, not API calls.

Practice this question →

18

Multi-Selecthard

A SysOps administrator is designing a monitoring solution for a critical application running on EC2 instances. The application requires that all API calls to the environment are logged for security analysis. Which TWO services should the administrator use to meet this requirement?

Select 2 answers

A.Amazon GuardDuty

B.Amazon CloudWatch Logs

C.AWS CloudTrail

D.AWS Config

E.VPC Flow Logs

AnswersB, C

CloudWatch Logs can store and monitor CloudTrail log files.

Why this answer

AWS CloudTrail is the correct service because it records all API calls made to the AWS environment, including calls made via the AWS Management Console, AWS CLI, SDKs, and other services. CloudTrail logs provide the identity of the caller, the time of the call, the source IP address, and the request parameters, which are essential for security analysis. Option B (Amazon CloudWatch Logs) is also correct because CloudTrail logs can be delivered to CloudWatch Logs for centralized monitoring, alerting, and retention, enabling real-time analysis and integration with other AWS services.

Exam trap

The trap here is confusing AWS CloudTrail (which logs API calls) with VPC Flow Logs (which log network traffic) or GuardDuty (which detects threats but does not generate logs), leading candidates to select services that analyze logs rather than capture them.

Practice this question →

19

MCQmedium

A company runs a REST API on Amazon EC2 instances behind an Application Load Balancer. The SysOps administrator needs to monitor the API endpoint from multiple geographic locations and receive an alarm if the p90 latency exceeds 2 seconds for two consecutive checks. The solution must use AWS managed services and not require custom code running on EC2. Which approach should the administrator use?

A.Set up Amazon CloudWatch Synthetics canaries to run from multiple AWS Regions and publish custom metrics. Create a CloudWatch alarm on the p90 latency metric.

B.Configure VPC Flow Logs on the Application Load Balancer and use Amazon CloudWatch Logs Insights to query for high-latency requests.

C.Enable Amazon CloudWatch RUM (Real User Monitoring) on the client side and create a CloudWatch alarm on the Duration metric.

D.Use AWS CloudTrail to log API calls and set a CloudWatch alarm on the event count for errors.

AnswerA

CloudWatch Synthetics canaries execute Node.js or Python scripts on AWS-managed Lambda functions, and by configuring them in multiple Regions you can actively probe the REST API from geographically distributed vantage points. Each canary can record HTTP response time and success/failure, then publish those measurements as custom metrics to CloudWatch. Because the metric supports percentile statistics, you can create an alarm on the p90 latency (e.g., p90 over 5 minutes) to detect regional or global slowdowns, making this the only option that provides synthetic, multi-region, application-level latency monitoring.

Why this answer

Amazon CloudWatch Synthetics canaries are AWS-managed Node.js scripts that run on a schedule to monitor endpoints from multiple AWS Regions, capturing metrics like duration and latency. By configuring canaries to report p90 latency as a custom metric, you can create a CloudWatch alarm that triggers when p90 exceeds 2 seconds for two consecutive data points, meeting all requirements without custom EC2 code.

Exam trap

The trap here is that candidates may confuse VPC Flow Logs or CloudTrail with application-layer monitoring, but neither provides request-level latency metrics; CloudWatch Synthetics is the only AWS-managed service that can synthetically test an HTTP endpoint from multiple geographic locations and publish percentile latency metrics without custom EC2 code.

How to eliminate wrong answers

Option B is wrong because VPC Flow Logs capture network-level metadata (IPs, ports, protocols) but do not measure application-layer latency like p90; they cannot be used to query for request duration or percentile latencies. Option C is wrong because Amazon CloudWatch RUM collects client-side performance data from actual user browsers, which introduces variability from network conditions and device performance, and it requires client-side JavaScript injection, not a pure AWS-managed service for synthetic monitoring from multiple geographic locations. Option D is wrong because AWS CloudTrail logs API calls to the AWS management plane (e.g., EC2 API calls), not the application-layer REST API requests; it cannot measure p90 latency or trigger alarms on performance metrics.

Practice this question →

20

MCQhard

A SysOps administrator is investigating a security breach. An IAM user 'Bob' is suspected of performing unauthorized actions. The administrator needs to determine the source IP addresses from which Bob's access keys were used in the last 30 days. Which AWS service or feature should be used?

A.AWS CloudTrail event history.

B.VPC Flow Logs.

C.Amazon CloudWatch Logs.

D.AWS IAM credential report.

AnswerA

CloudTrail records API calls with source IP.

Why this answer

AWS CloudTrail event history provides a record of all API calls made by IAM users, including the source IP address from which the request originated. By filtering the event history for the IAM user 'Bob' and the time range of the last 30 days, the administrator can identify the source IP addresses associated with each API call made using Bob's access keys. This directly meets the requirement to determine the source IP addresses of unauthorized actions.

Exam trap

The trap here is that candidates may confuse the IAM credential report (which shows credential metadata) with CloudTrail (which records actual API call details), leading them to choose the credential report for investigating source IPs when it only provides static credential status, not historical usage data.

How to eliminate wrong answers

Option B is wrong because VPC Flow Logs capture network traffic at the IP level (source/destination IPs, ports, protocols) but do not log IAM user identity or access key usage; they are used for analyzing network traffic patterns, not for tracking API calls by specific IAM users. Option C is wrong because Amazon CloudWatch Logs can store log data from various sources (e.g., application logs, system logs) but does not natively capture IAM user API call details or source IPs unless custom logging is configured; it is not the primary service for auditing IAM user activity. Option D is wrong because AWS IAM credential report provides information about the status of IAM user credentials (e.g., password last used, access key age, rotation status) but does not include source IP addresses or a history of API calls; it is used for credential auditing, not for investigating specific actions or source IPs.

Practice this question →

21

MCQeasy

A SysOps administrator is troubleshooting an application that runs on an EC2 instance. The application is experiencing high latency, and the administrator suspects a memory leak. Which metrics should the administrator examine first?

A.Custom CloudWatch metrics published by the CloudWatch agent, such as mem_used_percent.

B.CloudWatch metrics from the Detailed Monitoring feature, such as DiskReadOps.

C.CloudWatch metrics for the instance's Elastic Network Interface.

D.CloudWatch default EC2 metrics, such as CPUUtilization and NetworkIn.

AnswerA

The CloudWatch agent runs inside the EC2 instance as an OS-level service, so it can read the guest operating system's /proc/meminfo and report memory utilization as a custom metric in the CWAgent namespace (e.g., mem_used_percent). It uses the PutMetricData API and requires an IAM role with CloudWatchAgentServerPolicy to publish metrics. Default hypervisor-level EC2 metrics never expose guest memory, which is why installing the agent is the standard way to get memory utilization in CloudWatch.

Why this answer

A memory leak causes the application to consume increasing amounts of memory over time, leading to high latency as the OS begins swapping or the kernel reclaims memory. The CloudWatch agent can publish custom metrics like `mem_used_percent`, which directly tracks memory usage percentage and is the most relevant metric to confirm a memory leak. Default EC2 metrics do not include memory utilization, so the administrator must rely on custom metrics from the CloudWatch agent.

Exam trap

The trap here is that candidates assume default EC2 metrics include memory utilization, but AWS does not provide guest OS memory metrics by default; you must install the CloudWatch agent to capture them.

How to eliminate wrong answers

Option B is wrong because DiskReadOps measures disk I/O operations, not memory usage; it would not help identify a memory leak. Option C is wrong because Elastic Network Interface metrics track network throughput and packet counts, which are unrelated to memory consumption. Option D is wrong because default EC2 metrics like CPUUtilization and NetworkIn do not include memory metrics; EC2 does not expose guest OS memory usage without the CloudWatch agent.

Practice this question →

22

MCQmedium

A SysOps administrator needs to monitor application logs stored in Amazon CloudWatch Logs for the term 'CRITICAL'. When more than 5 'CRITICAL' entries appear in a 5-minute window, the administrator wants to automatically restart the underlying Amazon EC2 instance. Which solution should the administrator implement?

A.Create a CloudWatch Logs metric filter, then a CloudWatch alarm that triggers an AWS Systems Manager Automation document to restart the instance.

B.Create a CloudWatch Logs metric filter, then a CloudWatch alarm that triggers an EC2 Reboot Instances action.

C.Create a CloudWatch Logs metric filter, then use Amazon CloudWatch Events (Amazon EventBridge) to trigger an AWS Lambda function that restarts the instance.

D.Use Amazon CloudWatch Synthetics canary to monitor the logs and automatically stop the instance.

AnswerB

A CloudWatch Logs metric filter parses each log event and publishes a custom metric whenever a 'CRITICAL' pattern is matched. A CloudWatch alarm then evaluates that metric over a specified period and, when it enters the ALARM state, can directly trigger the built-in 'Reboot Instances' EC2 action. This is the most direct and reliable solution because it uses a native CloudWatch alarm action to restart the instance, requiring no custom code, Lambda functions, or extra orchestration layers.

Why this answer

CloudWatch Logs metric filters can count occurrences of the term 'CRITICAL' in log data, and a CloudWatch alarm can be configured to trigger an EC2 Reboot Instances action directly when the metric exceeds a threshold of 5 in a 5-minute period. This provides a native, simple, and fully managed solution without requiring additional services like Lambda or Systems Manager.

Exam trap

The trap here is that candidates may overcomplicate the solution by choosing Lambda or Systems Manager, not realizing that CloudWatch alarms have a built-in EC2 action for reboot, stop, terminate, or recover, which is the simplest and most cost-effective method for this use case.

How to eliminate wrong answers

Option A is wrong because while a CloudWatch alarm can trigger an AWS Systems Automation document, the EC2 Reboot Instances action is a direct alarm target and does not require Systems Manager Automation, which adds unnecessary complexity and potential latency. Option C is wrong because using CloudWatch Events (EventBridge) to invoke a Lambda function to restart the instance is an over-engineered approach; the EC2 Reboot Instances action is a built-in alarm target that eliminates the need for custom code. Option D is wrong because CloudWatch Synthetics canaries are designed for synthetic monitoring of endpoints and web applications, not for analyzing existing CloudWatch Logs for specific terms like 'CRITICAL'.

Practice this question →

23

MCQhard

An application running on EC2 instances behind an Application Load Balancer (ALB) sends custom metrics to CloudWatch. The team wants to set an alarm that triggers when the error rate exceeds 5% over a 5-minute period. The alarm must evaluate the metric every minute. Which configuration is required?

A.Period = 300 seconds, Statistic = Average, Evaluation Periods = 1, Datapoints to Alarm = 1

B.Period = 300 seconds, Statistic = Sum, Evaluation Periods = 1, Datapoints to Alarm = 1

C.Period = 60 seconds, Statistic = Average, Evaluation Periods = 5, Datapoints to Alarm = 5

D.Period = 60 seconds, Statistic = Sum, Evaluation Periods = 5, Datapoints to Alarm = 5

AnswerC

This checks that all 5 datapoints exceed 5% over 5 minutes.

Why this answer

The alarm must evaluate the error rate every minute (period = 60 seconds) over a 5-minute window. With evaluation periods = 5 and datapoints to alarm = 5, the alarm requires all five 1-minute datapoints to exceed the 5% threshold, ensuring the error rate is sustained for the full 5-minute period. The Average statistic is appropriate because the error rate is a percentage metric that should be averaged over each period.

Exam trap

The trap here is that candidates often confuse 'period' with the total evaluation window, selecting period = 300 seconds (option A or B) thinking it covers the 5-minute window, but this fails the requirement to evaluate every minute, and they may also incorrectly choose Sum instead of Average for a percentage metric.

How to eliminate wrong answers

Option A is wrong because period = 300 seconds means the metric is evaluated only once every 5 minutes, not every minute as required, and evaluation periods = 1 would trigger the alarm on a single 5-minute datapoint, not a sustained condition. Option B is wrong because period = 300 seconds again fails the 1-minute evaluation requirement, and using Sum for a percentage metric would incorrectly aggregate error counts rather than averaging the rate. Option D is wrong because while period = 60 seconds and evaluation periods = 5 are correct, using Sum instead of Average would sum the error rate values across datapoints, which is meaningless for a percentage metric and would not correctly reflect the 5% threshold.

Practice this question →

24

MCQmedium

A SysOps administrator needs to monitor AWS CloudTrail logs for any calls to the 'CreateUser' API in AWS Identity and Access Management (IAM). When such an API call is detected, the administrator wants to receive a notification within a few minutes and also log the event to a central log group in Amazon CloudWatch Logs. The solution should use minimal custom code. Which combination of services should be used?

A.Configure AWS CloudTrail to deliver logs to Amazon CloudWatch Logs, create a metric filter for the 'CreateUser' API call, and set up a CloudWatch alarm that sends an Amazon SNS notification.

B.Use AWS CloudTrail with Amazon EventBridge by creating an event rule that matches the 'CreateUser' API call via the 'aws.cloudtrail' event source, and set the targets to an Amazon SNS topic and a CloudWatch Logs log group.

C.Write an AWS Lambda function that is triggered by Amazon S3 events when a new CloudTrail log is delivered to S3. The Lambda parses the log file for 'CreateUser' and if found, sends an SNS notification.

D.Enable AWS Config and create a custom rule that evaluates CloudTrail trail configurations for events.

AnswerB

Amazon EventBridge natively listens for AWS service events, including CloudTrail API calls. By creating a rule with a custom event pattern that matches the specific API call, you can directly send the event to multiple targets (SNS, CloudWatch Logs, Lambda, etc.) without needing metric filters or alarms. This is the recommended low-overhead solution.

Why this answer

Amazon EventBridge can directly consume CloudTrail events in near-real time via the 'aws.cloudtrail' event source, allowing you to create a rule that matches the 'CreateUser' API call. This rule can then target both an Amazon SNS topic for immediate notification and a CloudWatch Logs log group for centralized logging, all without custom code.

Exam trap

The trap here is that candidates often assume CloudTrail-to-CloudWatch Logs delivery is the fastest method, but they overlook the inherent delivery latency and the fact that EventBridge provides a more immediate, event-driven path for real-time monitoring.

How to eliminate wrong answers

Option A is wrong because while CloudTrail can deliver logs to CloudWatch Logs, this delivery has a latency of up to 15 minutes, which does not meet the 'within a few minutes' requirement; also, metric filters and alarms operate on the delivered logs, not on the event stream. Option C is wrong because it requires custom Lambda code to parse S3-delivered CloudTrail logs, which violates the 'minimal custom code' requirement and introduces additional latency and complexity. Option D is wrong because AWS Config evaluates resource configurations, not real-time API call events; a custom Config rule cannot detect individual 'CreateUser' API calls as they occur.

Practice this question →

25

MCQmedium

A company has an S3 bucket that stores sensitive data. The security team requires an alert whenever an object in the bucket is deleted. What is the MOST efficient way to achieve this?

A.Configure S3 access logs and stream them to CloudWatch Logs, then create a metric filter.

B.Use S3 Inventory to generate a daily report and check for deletes.

C.Enable AWS CloudTrail data events for the S3 bucket and create a CloudWatch metric filter.

D.Enable S3 event notifications and send them to Amazon EventBridge, then create a rule to publish to SNS.

AnswerD

S3 events can be sent to EventBridge with low overhead and trigger notifications.

Why this answer

S3 event notifications can be sent directly to Amazon EventBridge, which allows you to create a rule that triggers an SNS topic for real-time alerts on object deletions. This approach is the most efficient as it avoids the overhead of log analysis or polling, providing immediate notification with minimal latency.

Exam trap

The trap here is that candidates often assume CloudTrail data events (Option C) are the best for monitoring S3 operations, but they overlook the latency and cost implications, whereas S3 event notifications via EventBridge provide the most efficient real-time alerting for object deletions.

How to eliminate wrong answers

Option A is wrong because S3 access logs are delivered on a best-effort basis, typically with a delay of several hours, making them unsuitable for real-time alerting on deletions. Option B is wrong because S3 Inventory generates daily or weekly CSV reports, which are not real-time and cannot trigger immediate alerts for individual delete events. Option C is wrong because while CloudTrail data events can capture S3 object-level operations, they are not the most efficient due to the overhead of enabling data events across all objects and the potential cost of CloudTrail logs; moreover, CloudTrail logs are typically delivered with a delay of up to 15 minutes, whereas EventBridge provides near-instantaneous notification.

Practice this question →

26

MCQeasy

Refer to the exhibit. The command returns no datapoints for CPUUtilization for the specified instance. What is the most likely reason?

A.The instance was stopped or did not emit metrics during the specified time range.

B.The metric name is incorrect.

C.The instance does not have detailed monitoring enabled.

D.The period of 300 seconds is too short.

AnswerA

If the instance is stopped, no metrics are emitted.

Why this answer

The most likely reason for no datapoints is that the instance was stopped or did not emit metrics during the specified time range. CloudWatch only retains and returns metric data when the instance is running and the CloudWatch agent or EC2 hypervisor is actively publishing CPUUtilization. If the instance was in a stopped state, no metrics are generated, resulting in an empty response from the GetMetricStatistics API call.

Exam trap

The trap here is that candidates often assume missing datapoints are due to a configuration issue (like detailed monitoring not enabled or wrong period), when in fact the instance simply wasn't running during the queried time window.

How to eliminate wrong answers

Option B is wrong because CPUUtilization is a standard EC2 metric name; if the metric name were incorrect, the API would return an error message (e.g., 'InvalidParameterValue') rather than an empty dataset. Option C is wrong because basic monitoring (5-minute granularity) still emits CPUUtilization datapoints; detailed monitoring only affects the frequency (1-minute granularity), not the existence of data. Option D is wrong because a period of 300 seconds is a valid and common value for basic monitoring (matching the default 5-minute interval) and does not cause missing datapoints.

Practice this question →

27

MCQmedium

A SysOps administrator needs to automatically restart an Amazon RDS DB instance when the 'DatabaseConnections' metric exceeds a threshold of 200 for 5 consecutive minutes. The administrator wants a solution that uses minimal custom code and leverages AWS managed services. Which combination of services should be used?

A.Amazon CloudWatch alarm with an Auto Scaling policy.

B.Amazon CloudWatch alarm with an Amazon Simple Notification Service (SNS) topic that triggers an AWS Lambda function to restart the instance.

C.Amazon CloudWatch alarm with an AWS Systems Manager Automation action.

D.Amazon RDS event subscription that triggers an AWS Lambda function.

AnswerC

CloudWatch alarms support a native 'Systems Manager Automation' action that directly invokes an SSM automation runbook, such as the pre-built AWS-RestartRDSInstance runbook, when the alarm enters an alarm state. This runbook encapsulates the RDS reboot API call and includes appropriate wait/verify steps, all without requiring you to write or maintain any custom code. The integration is purpose-built for metric-driven remediation and is the minimal-effort, fully managed way to automatically restart an RDS DB instance.

Why this answer

AWS Systems Manager Automation provides a built-in 'AWSSupport-StartRDSInstance' or 'AWSSystemsManager-RestartRDSInstance' runbook that can be triggered directly by a CloudWatch alarm action, requiring no custom code. This leverages a managed service to restart the RDS instance automatically when the 'DatabaseConnections' metric exceeds 200 for 5 consecutive minutes, meeting the minimal custom code requirement.

Exam trap

The trap here is that candidates often assume a Lambda function is always required for custom remediation actions, but AWS Systems Manager Automation provides a no-code alternative for many common operations like restarting RDS instances, which directly meets the 'minimal custom code' constraint.

How to eliminate wrong answers

Option A is wrong because Auto Scaling policies are designed to scale EC2 instances or other Auto Scaling group resources, not to restart RDS instances; they cannot directly trigger a database restart. Option B is wrong because while it uses a Lambda function to restart the instance, it introduces custom code (the Lambda function logic) which violates the 'minimal custom code' requirement. Option D is wrong because RDS event subscriptions are for notification of events like instance creation or failure, not for triggering automated remediation based on CloudWatch metric thresholds; they lack the direct integration with CloudWatch alarms needed for this metric-based condition.

Practice this question →

28

MCQmedium

Refer to the exhibit. A SysOps administrator runs this CloudWatch Logs Insights query against an application log group. The query returns no results, even though the administrator knows that errors occurred in the last hour. What is the most likely cause?

A.The 'stats' command requires a 'by' clause with a field name, but 'bin(5m)' is invalid.

B.The log group contains too many log events, causing the query to time out.

C.The @message field is not a valid field in CloudWatch Logs Insights.

D.The log group's retention policy is set to 1 day and the data is older than the retention period.

AnswerB

CloudWatch Logs Insights queries have a maximum execution time of 60 seconds, and when a log group contains a very high volume of log events within the queried time range, the query engine may exceed that limit. A timeout causes the query to return no results, even though the data exists. This matches the symptom described in the question, making it the correct explanation.

Why this answer

In CloudWatch Logs Insights, `stats count() by bin(5m)` is valid syntax; `bin()` does not require a preceding field. Therefore option A is not the cause. The most likely cause among the options is that the log group contains too many log events, causing the query to time out before results are returned.

Retention policy does not affect events from the last hour, and `@message` is a valid field.

Exam trap

Candidates often assume a query returning no results is due to a syntax error. However, CloudWatch Logs Insights queries can time out on very large log groups, and a timeout may produce no results; `bin(5m)` is valid syntax.

How to eliminate wrong answers

Option A is wrong because the 'stats' command in CloudWatch Logs Insights does not require a 'by' clause; 'bin(5m)' is a valid function that groups timestamps into 5-minute intervals, so the syntax is correct. Option B is wrong because CloudWatch Logs Insights queries have a 10,000-event limit per query, but they do not time out due to too many log events; instead, they return partial results or a message indicating the limit was reached. Option C is wrong because @message is a reserved field in CloudWatch Logs Insights that contains the raw log event text, and it is always available for querying.

Practice this question →

29

MCQeasy

A company needs to retain API call logs for 7 years for compliance. Which AWS service should be used to store these logs?

A.AWS CloudTrail

B.AWS Config

C.Amazon CloudWatch Logs

D.Amazon VPC Flow Logs

AnswerA

CloudTrail records API activity and can deliver logs to S3 for long-term retention.

Why this answer

AWS CloudTrail is the correct service because it records API activity across your AWS infrastructure and can be configured to store logs in an S3 bucket with lifecycle policies that retain data for 7 years. CloudTrail is specifically designed for auditing and compliance, capturing management and data plane API calls, and supports long-term retention via S3 object locking or lifecycle rules.

Exam trap

The trap here is that candidates confuse CloudTrail (API auditing) with CloudWatch Logs (operational logs) or Config (configuration history), but only CloudTrail captures the specific API call logs required for compliance retention.

How to eliminate wrong answers

Option B (AWS Config) is wrong because it tracks resource configuration changes and compliance over time, not API call logs; it stores configuration history, not API activity. Option C (Amazon CloudWatch Logs) is wrong because it is intended for real-time monitoring and operational logging from applications and services, with a default retention of indefinite but not optimized for 7-year compliance archiving; it lacks native long-term retention controls like S3 lifecycle policies. Option D (Amazon VPC Flow Logs) is wrong because it captures IP traffic metadata (source/destination IPs, ports, protocols) for network analysis, not API call logs; it is not designed for auditing API-level actions.

Practice this question →

30

MCQhard

The monitoring team needs to collect per-process CPU and memory utilization for a specific Java process (named 'app.jar') running on EC2 Linux instances. Standard EC2 metrics show aggregate CPU but not per-process details. Which CloudWatch agent configuration section enables this?

A.Add a procstat section under metrics_collected in the CloudWatch agent config, specifying process_name = 'app.jar' to collect per-process CPU and memory

B.Enable enhanced monitoring on the EC2 instance and select 'per-process metrics' from the console

C.Configure a CloudWatch Logs metric filter on the Java GC log output to derive CPU and memory figures

D.Use the aws ec2 describe-instance-status API on a schedule to pull process metrics from the instance's system status checks

AnswerA

The procstat plugin uses the Linux /proc filesystem to sample per-process resource usage. With process_name set to 'app.jar', the agent matches the running JVM process and publishes metrics like procstat_cpu_usage and procstat_memory_rss to CloudWatch every collection interval. These metrics carry instance ID and process name dimensions.

Why this answer

The CloudWatch agent's `procstat` plugin is specifically designed to collect per-process metrics such as CPU and memory utilization. By adding a `procstat` section under `metrics_collected` in the agent configuration file and specifying the process name (e.g., `process_name = 'app.jar'`), the agent will gather the required per-process metrics and send them to CloudWatch. This is the only native method within the CloudWatch ecosystem to achieve per-process monitoring on EC2 Linux instances.

Exam trap

The trap here is that candidates may confuse 'enhanced monitoring' (a hypervisor-level feature) with OS-level per-process monitoring, or incorrectly assume that CloudWatch Logs metric filters can derive CPU/memory metrics from application logs, when in fact only the CloudWatch agent's `procstat` plugin can collect actual OS-level per-process resource utilization.

How to eliminate wrong answers

Option B is wrong because 'enhanced monitoring' is a feature of EC2 that provides additional hypervisor-level metrics (e.g., CPU credit usage, network throughput) but does not expose per-process metrics; it cannot see inside the guest OS. Option C is wrong because CloudWatch Logs metric filters can parse log patterns and create numerical metrics from log data, but Java GC logs do not contain CPU or memory utilization figures for the process; they only contain garbage collection timing and heap usage, not OS-level resource consumption. Option D is wrong because the `aws ec2 describe-instance-status` API returns instance health and status checks (e.g., system reachability, instance status) and has no capability to retrieve per-process metrics from within the instance.

Practice this question →

31

MCQhard

A company runs a critical web application on a fleet of EC2 instances behind an Application Load Balancer (ALB). The instances are in an Auto Scaling group. The operations team uses CloudWatch alarms to monitor the application's health. Recently, they noticed that the application's error rate has increased sporadically, but the CPU utilization and memory usage remain normal. The team suspects that the issue is related to a specific HTTP endpoint returning 5xx errors. They want to set up monitoring that will alert them when the error rate exceeds 5% of total requests over a 5-minute period. The application logs are already sent to CloudWatch Logs. Which combination of steps should the SysOps administrator take to meet this requirement?

A.Create a metric filter in CloudWatch Logs to extract error codes and total requests from the application logs. Create two custom metrics: one for error count and one for total requests. Then create a CloudWatch alarm using a math expression that calculates error rate (error count / total requests) and triggers when >0.05 for 5 minutes.

B.Enable AWS X-Ray on the application to trace requests and identify error patterns. Create a CloudWatch alarm on the X-Ray error rate metric.

C.Install the CloudWatch agent on the EC2 instances to collect application-level metrics. Configure the agent to emit a custom metric for error rate. Then create an alarm on that metric.

D.Enable detailed monitoring on the ALB and create a CloudWatch alarm on the HTTPCode_ELB_5XX metric with a threshold of 5% of the request count. Use the ALB's RequestCount metric to compute the percentage.

AnswerA

This is the correct approach because the application logs are already flowing into CloudWatch Logs, and a metric filter can parse them in real time to extract both the number of error codes (e.g., status codes or application-specific errors) and the total request count. By creating two custom metrics—ErrorCount and TotalRequests—you can then define a CloudWatch alarm using a metrics math expression such as e1/e2, with the alarm triggering when the ratio exceeds 0.05 for a 5-minute period. This leverages the existing log data without requiring additional instrumentation or external services, and it accurately reflects application-level error rates as observed in the logs.

Why this answer

It creates a metric filter on the log group to count errors and total requests, then an alarm on the error rate. Option B is wrong because AWS X-Ray is for tracing, not for error rate monitoring from logs. Option C is wrong because it relies on the CloudWatch agent to generate metrics, which is not already set up.

Option D is wrong because it uses the ALB's HTTPCode_ELB_5XX metric, but the issue is application-specific, not ALB-level.

Practice this question →

32

MCQmedium

Refer to the exhibit. The alarm has been in INSUFFICIENT_DATA state for several hours. What is the most likely cause?

A.The alarm evaluation period is too long.

B.The EC2 instance is stopped or terminated.

C.The instance has no CloudWatch agent installed.

D.The instance is running but the CPU utilization is below the threshold.

AnswerB

If the instance is stopped, no metrics are emitted.

Why this answer

The INSUFFICIENT_DATA state for several hours indicates that CloudWatch has not received any metric data points for the specified period. If the EC2 instance is stopped or terminated, the CloudWatch agent stops sending metrics, and the default CPU utilization metric (which is published by AWS, not the agent) also ceases because the instance is no longer running. This causes the alarm to remain in INSUFFICIENT_DATA indefinitely until the instance is started again or the metric resumes.

Exam trap

The trap here is that candidates often confuse INSUFFICIENT_DATA with ALARM or OK states, mistakenly thinking low CPU utilization or missing CloudWatch agent would cause this state, when in fact INSUFFICIENT_DATA strictly means no metric data has been received at all for the evaluation period.

How to eliminate wrong answers

Option A is wrong because the alarm evaluation period being too long would only delay transitions between states, but it would not cause a permanent INSUFFICIENT_DATA state; data would still be collected and eventually evaluated. Option C is wrong because the CPU utilization metric is a default EC2 metric published by AWS automatically without requiring the CloudWatch agent; the agent is only needed for custom or OS-level metrics. Option D is wrong because if the instance is running and CPU utilization is below the threshold, the alarm would be in ALARM or OK state (depending on the comparison operator), not INSUFFICIENT_DATA; INSUFFICIENT_DATA specifically means no data points are available, not that data exists but is below a threshold.

Practice this question →

33

MCQhard

A company has a production environment with multiple EC2 instances running a web application. The SysOps administrator wants to automate the remediation of instances that fail the EC2 status check. Which approach should the administrator use?

A.Create a CloudWatch alarm on the StatusCheckFailed metric and configure an SNS notification to alert the team.

B.Use AWS Systems Manager Automation to create a document that runs a script on the instance to fix the issue.

C.Create an Amazon EventBridge rule that matches EC2 status check failures and triggers an AWS Lambda function to terminate the instance and launch a new one.

D.Configure the Auto Scaling group's health check to use EC2 status checks and set a custom termination policy.

AnswerC

EventBridge can detect failures and Lambda can automate replacement.

Why this answer

It provides a fully automated, event-driven remediation workflow. When an EC2 instance fails a status check, an EventBridge rule detects the state change and triggers a Lambda function that terminates the unhealthy instance and launches a replacement. This approach directly addresses the requirement to automate remediation without manual intervention.

Exam trap

The trap here is that candidates often choose Option A (SNS alerting) because they think notification is sufficient, but the question explicitly asks for 'automate the remediation,' which requires an action beyond alerting.

How to eliminate wrong answers

Option A is wrong because SNS notifications only alert the team; they do not automate any remediation action. Option B is wrong because Systems Manager Automation documents can run scripts on an instance, but if the instance has failed a status check (e.g., impaired networking or OS-level failure), the SSM agent may be unreachable or unable to execute commands, making this approach unreliable for remediation. Option D is wrong because while Auto Scaling group health checks can use EC2 status checks, a custom termination policy does not exist as a native feature; termination policies are predefined (e.g., OldestInstance, NewestInstance) and cannot be custom-coded to trigger instance replacement based on status check failures alone.

Practice this question →

34

MCQmedium

A company is running a web application on EC2 instances behind an Application Load Balancer. The application experiences intermittent latency spikes. The SysOps administrator needs to identify the root cause. Which set of CloudWatch metrics should be analyzed first?

A.ALB TargetResponseTime and EC2 CPUUtilization

B.EC2 CPUUtilization and NetworkIn

C.EC2 StatusCheckFailed and ALB UnhealthyHostCount

D.ALB RequestCount and HealthyHostCount

AnswerA

TargetResponseTime directly measures latency; CPUUtilization may indicate resource contention.

Why this answer

Intermittent latency spikes in a web application behind an Application Load Balancer (ALB) are most directly investigated by correlating ALB TargetResponseTime (which measures the time taken for the target to respond to the ALB) with EC2 CPUUtilization (which indicates whether the instance is under compute pressure). A spike in TargetResponseTime alongside high CPUUtilization suggests the EC2 instance is struggling to process requests, pointing to a compute bottleneck as the root cause.

Exam trap

The trap here is that candidates often confuse latency metrics with availability metrics, choosing options like C or D that indicate failures or traffic volume, rather than the performance-specific metrics needed to diagnose intermittent slowness.

How to eliminate wrong answers

Option B is wrong because while EC2 CPUUtilization is relevant, NetworkIn alone does not directly indicate latency; high network input could be normal traffic and does not measure response time or processing delays. Option C is wrong because EC2 StatusCheckFailed and ALB UnhealthyHostCount indicate instance or health check failures, not intermittent latency spikes; these metrics would show binary health states, not gradual performance degradation. Option D is wrong because ALB RequestCount and HealthyHostCount measure traffic volume and target health, not response latency; high request count alone does not explain why responses are slow.

Practice this question →

35

MCQeasy

An EC2 instance runs a Java application. The operations team wants to monitor heap memory utilization in CloudWatch and set alarms when it exceeds 85 percent. EC2 does not natively publish memory metrics to CloudWatch. What is the simplest way to get this metric into CloudWatch?

A.Install the CloudWatch agent on the instance and configure it to collect mem_used_percent; publish JVM heap metrics from the application using PutMetricData

B.Enable detailed monitoring on the EC2 instance to increase metric resolution to 1-minute intervals

C.Configure a CloudWatch Logs metric filter on the application log stream to count lines containing 'OutOfMemoryError'

D.Use AWS Systems Manager Inventory to collect memory data and sync it to CloudWatch

AnswerA

The CloudWatch agent handles OS-level memory automatically once configured. For JVM heap, the application publishes a custom namespace metric via PutMetricData. Both appear in CloudWatch within minutes and can be graphed and alarmed like any native metric.

Why this answer

The CloudWatch agent can collect custom metrics like memory utilization from the EC2 instance, and the Java application can directly publish JVM heap metrics to CloudWatch using the PutMetricData API. This combination provides the simplest and most direct way to monitor heap memory utilization and set alarms at the 85% threshold, as EC2 does not natively expose memory metrics.

Exam trap

The trap here is that candidates often assume detailed monitoring or Systems Manager Inventory can provide memory metrics, but neither feature collects or publishes memory utilization data to CloudWatch.

How to eliminate wrong answers

Option B is wrong because enabling detailed monitoring increases the resolution of standard EC2 metrics (like CPU, network) to 1-minute intervals, but it does not add memory or JVM heap metrics, which are not published by EC2 at all. Option C is wrong because a CloudWatch Logs metric filter on 'OutOfMemoryError' only detects when the application has already crashed, not proactive heap utilization levels, and it cannot measure the percentage of heap memory used. Option D is wrong because AWS Systems Manager Inventory collects software inventory and configuration data, not real-time memory utilization metrics, and it does not sync data to CloudWatch as a metric for alarm purposes.

Practice this question →

36

MCQhard

A SysOps administrator manages a fleet of EC2 instances that run a batch processing job. The job runs every hour and takes about 45 minutes to complete. The administrator wants to be notified if any job takes longer than 1 hour. Currently, the administrator uses CloudWatch Logs to capture job start and end times from application logs. The job writes a log message at start with 'JOB_START' and at end with 'JOB_END'. The administrator wants to create a metric filter that counts jobs that exceed 1 hour. However, the administrator is unsure how to achieve this with CloudWatch Logs. What should the administrator do?

A.Use CloudWatch Logs Insights to run a query every hour and check the duration.

B.Use CloudWatch Events to capture the log events and trigger a Lambda function to compute duration.

C.Create a metric filter that extracts the timestamp of JOB_START and JOB_END and computes the duration in a custom metric.

D.Create a Lambda function that is triggered by S3 to process the logs and publish a custom metric.

AnswerB

CloudWatch Events (EventBridge) can deliver CloudWatch Log events to a Lambda function in near real-time via a subscription filter, enabling event-driven processing. The Lambda function can parse the JOB_START and JOB_END entries, correlate them by job ID, calculate the duration, and publish a custom metric or trigger an alarm. This serverless architecture avoids polling and reacts immediately to each logged job, making it the recommended pattern.

Why this answer

CloudWatch Events (now part of Amazon EventBridge) can capture log events in real-time and trigger a Lambda function. The Lambda function can then compute job duration by correlating JOB_START and JOB_END events (e.g., using a DynamoDB table to store start times) and publish a custom metric or trigger an alarm if duration exceeds 1 hour. This approach handles the per-job correlation that metric filters cannot achieve.

Exam trap

Candidates often think metric filters can compute duration by extracting timestamps from JOB_START and JOB_END, but metric filters operate on individual log events and cannot correlate two events for the same job. The correct solution uses CloudWatch Events with Lambda for stateful computation.

How to eliminate wrong answers

Option A is wrong because CloudWatch Logs Insights is a query-based analysis tool for ad-hoc or scheduled queries, but it cannot directly trigger alarms or continuously monitor for durations exceeding 1 hour without custom scripting and additional services. Option B is wrong because CloudWatch Events (now Amazon EventBridge) can capture log events and trigger a Lambda function, but this approach adds unnecessary complexity and cost compared to a native metric filter, and it requires custom code to compute duration and publish metrics. Option D is wrong because S3 is not involved in the described workflow; the logs are in CloudWatch Logs, not S3, and using S3 triggers would require exporting logs to S3 first, adding latency and complexity.

Practice this question →

37

MCQeasy

A SysOps administrator wants to receive a notification when an EC2 instance's status check fails. Which AWS service should be used to achieve this?

A.Amazon CloudWatch Alarms

B.AWS Config

C.AWS CloudTrail

D.AWS Trusted Advisor

AnswerA

Amazon CloudWatch Alarms is the correct service because it directly consumes the EC2 StatusCheckFailed metric, which is emitted every minute by the instance hypervisor. You can configure an alarm on this metric with a threshold (e.g., >=1 for one or more consecutive evaluation periods) to transition to ALARM state, and then invoke an SNS topic to send notifications via email, SMS, or Lambda. CloudWatch also supports separate alarms for StatusCheckFailed_System (host-level issues) and StatusCheckFailed_Instance (guest-OS level issues), giving you granular, near-real-time health monitoring.

Why this answer

Amazon CloudWatch Alarms can monitor EC2 instance status checks (both system and instance checks) and trigger an action, such as sending a notification via Amazon SNS, when a status check fails. This is the native AWS service designed for real-time monitoring and alerting on metric thresholds, making it the correct choice for this use case.

Exam trap

The trap here is that candidates often confuse AWS Config (which evaluates configuration compliance) with CloudWatch Alarms (which monitor metric thresholds), leading them to select AWS Config for real-time health alerts instead of the correct monitoring service.

How to eliminate wrong answers

Option B (AWS Config) is wrong because it is used for evaluating and recording resource configurations against desired policies, not for monitoring real-time status check failures. Option C (AWS CloudTrail) is wrong because it captures API activity and management events, not instance-level health metrics like status checks. Option D (AWS Trusted Advisor) is wrong because it provides best-practice recommendations and cost optimization checks, not real-time monitoring or alerting on EC2 status checks.

Practice this question →

38

MCQhard

An application writes logs to a file on an EC2 instance. The SysOps team needs to send these logs to Amazon CloudWatch Logs in real time. The logs must be encrypted at rest in CloudWatch Logs using a customer-managed KMS key. Which steps are required?

A.Use AWS CloudTrail to deliver logs to CloudWatch Logs with KMS encryption.

B.Store logs in S3 with KMS encryption and use S3 event notifications to trigger Lambda to put logs in CloudWatch Logs.

C.Install the CloudWatch Logs agent and enable encryption on the EC2 instance volume using KMS.

D.Install the CloudWatch Logs agent and associate a KMS key with the log group using the 'associate-kms-key' API.

AnswerD

This enables encryption at rest with a customer-managed key.

Why this answer

The CloudWatch Logs agent can send log data from an EC2 instance to CloudWatch Logs in real time, and the 'associate-kms-key' API (or the equivalent AWS CLI command 'put-log-group-encryption') allows you to associate a customer-managed KMS key with a log group, encrypting the logs at rest. This meets both the real-time delivery and customer-managed KMS encryption requirements without additional services or workarounds.

Exam trap

The trap here is that candidates often confuse encrypting the log file on the EC2 instance volume (Option C) with encrypting the logs at rest in CloudWatch Logs, or they overcomplicate the solution by introducing unnecessary services like S3 and Lambda (Option B) instead of using the native KMS integration with CloudWatch Logs.

How to eliminate wrong answers

Option A is wrong because AWS CloudTrail delivers API activity logs, not application log files from an EC2 instance, and it cannot be used to send arbitrary application logs to CloudWatch Logs in real time. Option B is wrong because storing logs in S3 and using S3 event notifications to trigger a Lambda function introduces latency and complexity, and does not provide real-time streaming to CloudWatch Logs; it also requires additional services and is not the standard method for real-time log ingestion. Option C is wrong because enabling encryption on the EC2 instance volume using KMS encrypts the log file at rest on the instance, but does not encrypt the logs at rest in CloudWatch Logs; the CloudWatch Logs agent sends data over the network, and the log group itself must be encrypted with a KMS key to meet the requirement.

Practice this question →

39

MCQmedium

A SysOps administrator needs to monitor the CPU utilization of an Amazon EC2 instance fleet and send an alert when the average CPU utilization exceeds 80% for 10 consecutive minutes. The administrator also wants to automatically stop the instance if the CPU utilization remains above 90% for 30 minutes to prevent runaway costs. Which combination of AWS services should be used?

A.Amazon CloudWatch alarm + AWS Lambda + AWS Systems Manager Automation

B.Amazon CloudWatch alarm + Amazon Simple Notification Service (SNS) + AWS Lambda

C.Amazon CloudWatch Logs + Amazon EventBridge + AWS Step Functions

D.AWS CloudTrail + Amazon EventBridge + AWS CodePipeline

AnswerB

A CloudWatch alarm monitors the CPU metric and publishes to an SNS topic when the threshold is breached. The SNS topic triggers a Lambda function that calls the EC2 StopInstances API to stop the instance. This is a clean, low-overhead solution.

Why this answer

It uses Amazon CloudWatch alarms to monitor CPU utilization metrics and trigger an SNS topic, which then invokes an AWS Lambda function. The Lambda function can execute the logic to stop the EC2 instance when the alarm state indicates CPU utilization above 90% for 30 minutes, providing automated cost control without manual intervention.

Exam trap

The trap here is that candidates may assume Systems Manager Automation (Option A) is required for instance stop actions, but Lambda is simpler and directly triggered by SNS, while Automation is better suited for complex multi-step workflows like patching or AMI creation.

How to eliminate wrong answers

Option A is wrong because AWS Systems Manager Automation is designed for predefined runbook-style remediation (e.g., patching, configuration changes) and is not directly triggered by CloudWatch alarms to stop an instance based on a metric threshold; it requires additional orchestration and does not natively support the stop action from an alarm. Option C is wrong because Amazon CloudWatch Logs is for log data, not metric monitoring, and Amazon EventBridge with Step Functions is overkill for a simple stop action; CloudWatch Logs cannot directly trigger alarms on CPU utilization metrics. Option D is wrong because AWS CloudTrail records API activity, not CPU metrics, and Amazon EventBridge with CodePipeline is for CI/CD pipelines, not for monitoring or stopping instances based on utilization thresholds.

Practice this question →

40

MCQhard

An application running on EC2 instances occasionally throws 'Connection refused' errors when connecting to an RDS database. The SysOps administrator needs to determine if the issue is due to database connection limits or network security groups. Which metrics and logs should the administrator examine?

A.Check CloudWatch RDS CPUUtilization and CloudTrail logs for RDS API calls.

B.Review RDS error logs in CloudWatch Logs and check the EC2 instance's system log.

C.Look at the EC2 instance's CloudWatch NetworkIn and NetworkOut metrics and RDS FreeableMemory metric.

D.Examine the RDS CloudWatch metric DatabaseConnections and analyze VPC Flow Logs for the EC2 instance's network interface.

AnswerD

DatabaseConnections shows active connections; VPC Flow Logs can show if traffic is allowed or denied.

Why this answer

'Connection refused' errors typically stem from either the database exhausting its maximum connections or network-level security groups blocking traffic. The RDS CloudWatch metric `DatabaseConnections` directly shows the current number of active connections against the instance's `max_connections` limit, while VPC Flow Logs capture whether packets are being accepted or rejected by security groups or network ACLs, pinpointing network blockages.

Exam trap

The trap here is that candidates confuse aggregate network metrics (like NetworkIn/NetworkOut) or CPU metrics with the specific indicators needed to differentiate between connection limits and security group denials, leading them to choose options that measure volume rather than connection state or packet acceptance.

How to eliminate wrong answers

Option A is wrong because `CPUUtilization` does not indicate connection limits or security group blocks, and CloudTrail logs record API calls (e.g., creating DB instances) not real-time connection or network failures. Option B is wrong because RDS error logs in CloudWatch Logs may show authentication or query errors but not connection limit exhaustion or network-level rejections, and the EC2 instance's system log (console output) does not capture network flow data. Option C is wrong because `NetworkIn`/`NetworkOut` show aggregate traffic volume, not whether connections are accepted or rejected, and `FreeableMemory` indicates memory pressure but not connection count or security group rules.

Practice this question →

Ready to test yourself?

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

Start 20-question session