Troubleshooting practice questions

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.)

Trap 1: Network connectivity issues

Network connectivity issues are classified as system status check failures because they typically originate from AWS-side infrastructure, such as loss of power, network link outages, or routing problems. Instance status checks, on the other hand, monitor the health of the guest OS and applications, so a problem that is purely external to the instance would not trigger a failed instance status check. Therefore, while network issues may make the instance unreachable, they would be indicated by a system status check, not the instance status check the administrator is troubleshooting.

Trap 2: Detached EBS root volume

A detached EBS root volume would prevent the instance from booting or accessing the operating system entirely, but this scenario is detected by AWS as a system status check failure because the problem lies in the underlying storage attachment infrastructure. The instance status check cannot even begin to run if the root volume is not available, as the OS never loads enough to respond to health checks. Thus, a detached root volume is not a valid cause of an instance status check failure, which requires the OS to be running but unhealthy internally.

Trap 3: Insufficient memory for applications

Insufficient memory for applications can cause performance degradation, swapping, or application crashes, but the Linux or Windows kernel typically remains responsive enough to answer the health probes used by instance status checks. These checks depend on basic OS functionality, such as the network stack and process scheduler, which do not necessarily require sufficient memory for user applications. Therefore, while low memory is a serious problem, it would not directly cause an instance status check failure unless it leads to a kernel panic, which is not the typical outcome.

A
Network connectivity issues
Why wrong: Network connectivity issues are classified as system status check failures because they typically originate from AWS-side infrastructure, such as loss of power, network link outages, or routing problems. Instance status checks, on the other hand, monitor the health of the guest OS and applications, so a problem that is purely external to the instance would not trigger a failed instance status check. Therefore, while network issues may make the instance unreachable, they would be indicated by a system status check, not the instance status check the administrator is troubleshooting.
B
Detached EBS root volume
Why wrong: A detached EBS root volume would prevent the instance from booting or accessing the operating system entirely, but this scenario is detected by AWS as a system status check failure because the problem lies in the underlying storage attachment infrastructure. The instance status check cannot even begin to run if the root volume is not available, as the OS never loads enough to respond to health checks. Thus, a detached root volume is not a valid cause of an instance status check failure, which requires the OS to be running but unhealthy internally.
C
Misconfigured firewall or iptables
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.
D
Insufficient memory for applications
Why wrong: Insufficient memory for applications can cause performance degradation, swapping, or application crashes, but the Linux or Windows kernel typically remains responsive enough to answer the health probes used by instance status checks. These checks depend on basic OS functionality, such as the network stack and process scheduler, which do not necessarily require sufficient memory for user applications. Therefore, while low memory is a serious problem, it would not directly cause an instance status check failure unless it leads to a kernel panic, which is not the typical outcome.
E
Corrupted file system
A corrupted file system, particularly on the root volume, can prevent the OS from mounting the disk, cause kernel panics, or result in the entire system becoming unresponsive and unable to process any requests. Since the corruption is within the guest OS environment and does not require AWS-side intervention, it is reported as a failed instance status check. The instance status check detects this because the OS fails to respond to the network-level reachability probe, confirming that a corrupted file system is a valid cause of an instance status check failure.

Question 2hardmulti select

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?

Trap 1: Use PutLogEvents directly from the application.

This bypasses the agent's buffering and retry logic, likely making the problem worse.

Trap 2: Reduce the retry count for failed requests.

Reducing retries increases data loss if transient failures occur.

Trap 3: Increase the batch timeout to 30 seconds.

Longer timeouts increase the risk of buffer overflow and data loss if logs are generated rapidly.

A
Use PutLogEvents directly from the application.
Why wrong: This bypasses the agent's buffering and retry logic, likely making the problem worse.
B
Reduce the retry count for failed requests.
Why wrong: Reducing retries increases data loss if transient failures occur.
C
Increase the batch size to 5 MB.
Larger batches reduce the number of API calls, lowering the chance of hitting rate limits.
D
Increase the batch timeout to 30 seconds.
Why wrong: Longer timeouts increase the risk of buffer overflow and data loss if logs are generated rapidly.
E
Enable log compression in the agent configuration.
Compression reduces the size of data sent per call, helping avoid throttling.

Question 3mediumdrag order

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

5Step 5

Trap 1: Verify health check settings (path, port, protocol), then verify…

Starting with health check settings is inefficient and can mislead you because a misconfigured security group can block all traffic from the ALB before the path, port, or protocol ever matter. If the ALB's source security group is not allowed on the target's security group, or the ALB is in a different VPC/subnet, health checks will fail regardless of the HTTP path or TCP port defined. Only after confirming that network paths and security group rules permit the health check traffic should you evaluate whether the health check configuration actually matches the target application's expected endpoint.

Trap 2: Check instance status and application health, then verify security…

Probing instance and application health first is premature because a target instance can pass its EC2 status checks (e.g., 2/2) while still being marked unhealthy by the ALB due to an incorrect security group or health check rule. Without first verifying that the ALB can reach the instance via allowed security group rules and that the health check path is actually served by the application, you risk launching into debugging a healthy application. This ordering wastes time and can lead you to restart or replace an instance that is genuinely functioning but is isolated or misconfigured at the load balancer layer.

Trap 3: Review ALB access logs and CloudWatch metrics, then verify security…

Reviewing ALB access logs and CloudWatch metrics before the basic configuration checks is counterproductive because those logs often lack the context needed to pinpoint the root cause. For instance, an access log might show 5xx responses or failed health checks, but you cannot determine whether the failure is due to a security group block (no log entry at all) or an unhealthy application until you've already confirmed the security group and health check settings. Additionally, if the health check is misconfigured (e.g., pointing to the wrong port), the CloudWatch HealthyHostCount metric will remain at zero even for perfectly healthy instances, making the metrics misleading without that prior knowledge.

A
Verify security group rules allow traffic from the ALB, then verify health check settings (path, port, protocol), then check instance status and application health, then review ALB access logs and CloudWatch metrics, then replace the target instance if necessary.
This order is correct because security group misconfigurations are a common cause of health check failures and should be checked first. Next, health check settings must align with the target application. Then, instance and application health are examined. Logs and metrics provide further insight before considering replacement.
B
Verify health check settings (path, port, protocol), then verify security group rules, then check instance status and application health, then review ALB access logs and CloudWatch metrics, then replace the target instance if necessary.
Why wrong: Starting with health check settings is inefficient and can mislead you because a misconfigured security group can block all traffic from the ALB before the path, port, or protocol ever matter. If the ALB's source security group is not allowed on the target's security group, or the ALB is in a different VPC/subnet, health checks will fail regardless of the HTTP path or TCP port defined. Only after confirming that network paths and security group rules permit the health check traffic should you evaluate whether the health check configuration actually matches the target application's expected endpoint.
C
Check instance status and application health, then verify security group rules, then verify health check settings, then review ALB access logs and CloudWatch metrics, then replace the target instance if necessary.
Why wrong: Probing instance and application health first is premature because a target instance can pass its EC2 status checks (e.g., 2/2) while still being marked unhealthy by the ALB due to an incorrect security group or health check rule. Without first verifying that the ALB can reach the instance via allowed security group rules and that the health check path is actually served by the application, you risk launching into debugging a healthy application. This ordering wastes time and can lead you to restart or replace an instance that is genuinely functioning but is isolated or misconfigured at the load balancer layer.
D
Review ALB access logs and CloudWatch metrics, then verify security group rules, then verify health check settings, then check instance status and application health, then replace the target instance if necessary.
Why wrong: Reviewing ALB access logs and CloudWatch metrics before the basic configuration checks is counterproductive because those logs often lack the context needed to pinpoint the root cause. For instance, an access log might show 5xx responses or failed health checks, but you cannot determine whether the failure is due to a security group block (no log entry at all) or an unhealthy application until you've already confirmed the security group and health check settings. Additionally, if the health check is misconfigured (e.g., pointing to the wrong port), the CloudWatch HealthyHostCount metric will remain at zero even for perfectly healthy instances, making the metrics misleading without that prior knowledge.

Question 4mediumdrag order

Drag and drop the steps to troubleshoot high CPU usage on an Amazon EC2 instance 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

5Step 5

Trap 1: Connect to instance, then Check CloudWatch metrics, then Identify…

Connecting to the instance before checking CloudWatch metrics inverts the troubleshooting sequence because the EC2 CPUUtilization metric first confirms whether the complaint is CPU-related and reveals the pattern (e.g., sustained saturation vs. a brief spike) that guides your investigation. Connecting preemptively wastes time if the actual bottleneck is memory, disk I/O, or network, and you lose the context needed to correlate system behavior with instance-level performance. Only after verifying the metric should you connect to inspect running processes.

Trap 2: Check CloudWatch metrics, then Identify high CPU process, then…

This order is impossible to execute correctly because CloudWatch does not expose process-level CPU usage; EC2 metrics like CPUUtilization aggregate the entire instance, so you cannot identify a specific high-CPU process without actually connecting to the instance and running commands such as top, ps aux --sort=-%cpu, or pidstat. Attempting to "identify high CPU process" before establishing a session has no technical basis, since the identification is necessarily the result of an in-instance observation. The correct sequence is to use CloudWatch to confirm the problem, connect, and then identify the process.

Trap 3: Check CloudWatch metrics, then Connect to instance, then Analyze…

Analyzing process behavior before identifying the specific process is functionally backwards because analysis tools like strace, lsof, or checking per-process /proc statistics require a known PID or process name as the target; without first using top, ps, or pidstat to pin down which process is consuming CPU, you have no subject for behavioral analysis. Also, jumping into analysis before identification risks drawing conclusions from unrelated system activity. The logical dependency demands identification first, then behavior analysis, and only then corrective action.

A
Check CloudWatch metrics, then Connect to instance, then Identify high CPU process, then Analyze process behavior, then Take corrective action
This is the correct order because you first verify CPU usage metrics to confirm the issue, then connect to the instance, identify the offending process, analyze its behavior to determine the root cause, and finally take appropriate action.
B
Connect to instance, then Check CloudWatch metrics, then Identify high CPU process, then Analyze process behavior, then Take corrective action
Why wrong: Connecting to the instance before checking CloudWatch metrics inverts the troubleshooting sequence because the EC2 CPUUtilization metric first confirms whether the complaint is CPU-related and reveals the pattern (e.g., sustained saturation vs. a brief spike) that guides your investigation. Connecting preemptively wastes time if the actual bottleneck is memory, disk I/O, or network, and you lose the context needed to correlate system behavior with instance-level performance. Only after verifying the metric should you connect to inspect running processes.
C
Check CloudWatch metrics, then Identify high CPU process, then Connect to instance, then Analyze process behavior, then Take corrective action
Why wrong: This order is impossible to execute correctly because CloudWatch does not expose process-level CPU usage; EC2 metrics like CPUUtilization aggregate the entire instance, so you cannot identify a specific high-CPU process without actually connecting to the instance and running commands such as top, ps aux --sort=-%cpu, or pidstat. Attempting to "identify high CPU process" before establishing a session has no technical basis, since the identification is necessarily the result of an in-instance observation. The correct sequence is to use CloudWatch to confirm the problem, connect, and then identify the process.
D
Check CloudWatch metrics, then Connect to instance, then Analyze process behavior, then Identify high CPU process, then Take corrective action
Why wrong: Analyzing process behavior before identifying the specific process is functionally backwards because analysis tools like strace, lsof, or checking per-process /proc statistics require a known PID or process name as the target; without first using top, ps, or pidstat to pin down which process is consuming CPU, you have no subject for behavioral analysis. Also, jumping into analysis before identification risks drawing conclusions from unrelated system activity. The logical dependency demands identification first, then behavior analysis, and only then corrective action.

Question 5easymultiple choice

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?

Trap 1: CloudWatch metrics from the Detailed Monitoring feature, such as…

Detailed Monitoring changes the collection period of EC2 hypervisor metrics from 5 minutes to 1 minute, but it does not add new metric categories. DiskReadOps is a disk I/O counter measured by the hypervisor (or Nitro controller), and it has no relation to RAM consumption; memory is not accessible to the hypervisor because the guest OS manages its own memory pages. Therefore, even with Detailed Monitoring enabled, CloudWatch still lacks an EC2 memory metric, so relying on DiskReadOps would not diagnose an out-of-memory condition.

Trap 2: CloudWatch metrics for the instance's Elastic Network Interface.

Elastic Network Interface metrics in CloudWatch (e.g., NetworkPacketsIn, NetworkBytesOut) are emitted per ENI and represent traffic counters, not process memory usage. These metrics come from the virtual network adapter and reflect packet-level activity, which has no correlation with the amount of RAM consumed by the application. Using ENI metrics for memory troubleshooting is invalid because they measure I/O throughput of the network path, not the state of the guest OS's memory allocation.

Trap 3: CloudWatch default EC2 metrics, such as CPUUtilization and…

Default EC2 metrics, such as CPUUtilization and NetworkIn, are collected by the hypervisor (or Nitro security chip) and expose only host-visible resource usage. The hypervisor cannot see the guest OS's free/used pages, so memory is omitted from the standard AWS/EC2 namespace; no default metric covers it. Thus, checking CPUUtilization or NetworkIn may show overall load but will not reveal memory pressure like a kswapd-heavy swap storm or OOM-killer events, making these default metrics inadequate for that troubleshooting scenario.

A
Custom CloudWatch metrics published by the CloudWatch agent, such as mem_used_percent.
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.
B
CloudWatch metrics from the Detailed Monitoring feature, such as DiskReadOps.
Why wrong: Detailed Monitoring changes the collection period of EC2 hypervisor metrics from 5 minutes to 1 minute, but it does not add new metric categories. DiskReadOps is a disk I/O counter measured by the hypervisor (or Nitro controller), and it has no relation to RAM consumption; memory is not accessible to the hypervisor because the guest OS manages its own memory pages. Therefore, even with Detailed Monitoring enabled, CloudWatch still lacks an EC2 memory metric, so relying on DiskReadOps would not diagnose an out-of-memory condition.
C
CloudWatch metrics for the instance's Elastic Network Interface.
Why wrong: Elastic Network Interface metrics in CloudWatch (e.g., NetworkPacketsIn, NetworkBytesOut) are emitted per ENI and represent traffic counters, not process memory usage. These metrics come from the virtual network adapter and reflect packet-level activity, which has no correlation with the amount of RAM consumed by the application. Using ENI metrics for memory troubleshooting is invalid because they measure I/O throughput of the network path, not the state of the guest OS's memory allocation.
D
CloudWatch default EC2 metrics, such as CPUUtilization and NetworkIn.
Why wrong: Default EC2 metrics, such as CPUUtilization and NetworkIn, are collected by the hypervisor (or Nitro security chip) and expose only host-visible resource usage. The hypervisor cannot see the guest OS's free/used pages, so memory is omitted from the standard AWS/EC2 namespace; no default metric covers it. Thus, checking CPUUtilization or NetworkIn may show overall load but will not reveal memory pressure like a kswapd-heavy swap storm or OOM-killer events, making these default metrics inadequate for that troubleshooting scenario.

Question 6mediummultiple choice

A company runs an application on Amazon EC2 instances behind an Application Load Balancer (ALB). The ALB terminates SSL/TLS and forwards traffic to the instances over HTTP. The SysOps administrator needs to capture the original client IP address in the instance logs. How should the administrator configure this?

Trap 1: Enable stickiness on the ALB target group.

Enabling stickiness (session affinity) on the ALB target group uses cookies or the application's session to route all requests from a given client to the same EC2 instance, but it does not alter or inject the client's IP address into the request. The EC2 instance still sees the ALB's private IP as the source address in the TCP connection, so application logs would record the load balancer's IP, not the original client. Stickiness only ensures session consistency; it is unrelated to capturing client IP information for logs.

Trap 2: Configure the ALB to use Proxy Protocol v2.

Proxy Protocol v2 is a transport-level protocol that prepends a human-readable header to preserve the original client IP, but it is a feature supported by Network Load Balancers, not Application Load Balancers. ALBs operate at Layer 7 and use the X-Forwarded-For HTTP header instead, and they do not offer a Proxy Protocol enablement option in their configuration. Since the question specifically involves an ALB, enabling Proxy Protocol is not a valid action; even if it were available, it would not align with ALB's HTTP-based forwarding architecture.

Trap 3: Enable access logs on the ALB and store them in Amazon S3.

Access logs capture detailed information about requests sent to the ALB, including client IP, but they are stored in S3, not available directly on the EC2 instances. The requirement is to capture the IP in instance logs.

A
Enable stickiness on the ALB target group.
Why wrong: Enabling stickiness (session affinity) on the ALB target group uses cookies or the application's session to route all requests from a given client to the same EC2 instance, but it does not alter or inject the client's IP address into the request. The EC2 instance still sees the ALB's private IP as the source address in the TCP connection, so application logs would record the load balancer's IP, not the original client. Stickiness only ensures session consistency; it is unrelated to capturing client IP information for logs.
B
Enable the X-Forwarded-For header on the ALB.
The ALB automatically adds the X-Forwarded-For header to each HTTP/HTTPS request as it passes through, containing the original client IP address in a comma-separated list. Since the ALB terminates the client's TLS connection and opens a new connection to the target, the EC2 instance must read this header to record the client IP in its logs. By default, the ALB overwrites any existing X-Forwarded-For header to prevent client spoofing, and you should configure your web server or application to log the first IP in the header, which is the true client IP.
C
Configure the ALB to use Proxy Protocol v2.
Why wrong: Proxy Protocol v2 is a transport-level protocol that prepends a human-readable header to preserve the original client IP, but it is a feature supported by Network Load Balancers, not Application Load Balancers. ALBs operate at Layer 7 and use the X-Forwarded-For HTTP header instead, and they do not offer a Proxy Protocol enablement option in their configuration. Since the question specifically involves an ALB, enabling Proxy Protocol is not a valid action; even if it were available, it would not align with ALB's HTTP-based forwarding architecture.
D
Enable access logs on the ALB and store them in Amazon S3.
Why wrong: Access logs capture detailed information about requests sent to the ALB, including client IP, but they are stored in S3, not available directly on the EC2 instances. The requirement is to capture the IP in instance logs.

Question 7mediummultiple choice

A SysOps administrator is troubleshooting an issue where an IAM user can launch EC2 instances but cannot terminate them. The user's permissions are based on an IAM group policy. Which action should the administrator take to resolve this?

Trap 1: Attach a managed policy that includes ec2:TerminateInstances…

Attaching a managed policy directly to the user would grant the required permission, but this bypasses IAM's recommended group-based access management and does not address the underlying group policy defect. It also creates a maintenance burden because future users in the same group will still be unable to terminate instances, and any cross-group explicit denies would still apply.

Trap 2: Add the user to a different IAM group that has the required…

Adding the user to a different IAM group is unreliable because the new group's policies may also lack ec2:TerminateInstances, and doing so grants the user the aggregate permissions of both groups, potentially violating least privilege. It shifts the user out of the intended group rather than fixing the actual misconfiguration in the original group's policy, so the root cause remains.

Trap 3: Check the user's permissions boundary for any restrictions

A permissions boundary is an advanced IAM feature that sets the maximum permissions a principal can receive, but it is not the first thing to check when a user cannot perform an action because a group policy is typically the source. Even if a boundary is present, the explicit issue is that the group policy does not include the terminate action; reviewing the effective permissions would confirm the boundary only narrows, not trivially blocks, unless a specific deny exists.

A
Attach a managed policy that includes ec2:TerminateInstances directly to the user
Why wrong: Attaching a managed policy directly to the user would grant the required permission, but this bypasses IAM's recommended group-based access management and does not address the underlying group policy defect. It also creates a maintenance burden because future users in the same group will still be unable to terminate instances, and any cross-group explicit denies would still apply.
B
Add the user to a different IAM group that has the required permissions
Why wrong: Adding the user to a different IAM group is unreliable because the new group's policies may also lack ec2:TerminateInstances, and doing so grants the user the aggregate permissions of both groups, potentially violating least privilege. It shifts the user out of the intended group rather than fixing the actual misconfiguration in the original group's policy, so the root cause remains.
C
Check the user's permissions boundary for any restrictions
Why wrong: A permissions boundary is an advanced IAM feature that sets the maximum permissions a principal can receive, but it is not the first thing to check when a user cannot perform an action because a group policy is typically the source. Even if a boundary is present, the explicit issue is that the group policy does not include the terminate action; reviewing the effective permissions would confirm the boundary only narrows, not trivially blocks, unless a specific deny exists.
D
Review and modify the IAM group policy to include ec2:TerminateInstances action
The most likely root cause is that the IAM group policy attached to the user's group does not include an ec2:TerminateInstances action, so modifying that policy to allow the API call resolves the issue for every member of the group. Use a statement with "Effect": "Allow" for ec2:TerminateInstances on the appropriate resource, then test with the IAM policy simulator to verify effective access.

Question 8mediummulti select

A SysOps administrator is troubleshooting an issue where an Application Load Balancer (ALB) is returning 503 errors to clients. The target group has healthy EC2 instances. Which THREE possible causes should the administrator investigate? (Choose three.)

Trap 1: The target group has no registered targets.

Incorrect because the stem explicitly states the target group has healthy EC2 instances, meaning registered targets exist; 'no registered targets' directly contradicts the given information.

Trap 2: The target group health check is misconfigured.

Correct because a misconfigured health check can cause the ALB to consider all targets unhealthy, even if the instances are healthy, leading to 503 errors.

A
The load balancer is not attached to a subnet.
Incorrect because the load balancer must be attached to subnets to function; if not, it would fail to provision, but the ALB is already running and returning 503, so this is not a likely cause.
B
The security group for the load balancer is blocking traffic.
Correct because the load balancer's security group must allow inbound traffic from clients. If it blocks HTTP/HTTPS traffic, the ALB cannot forward requests and returns 503 errors.
C
The load balancer has reached its capacity limit.
Correct because an ALB has a capacity limit; once reached, it cannot handle new requests and returns 503 errors.
D
The target group has no registered targets.
Why wrong: Incorrect because the stem explicitly states the target group has healthy EC2 instances, meaning registered targets exist; 'no registered targets' directly contradicts the given information.
E
The target group health check is misconfigured.
Why wrong: Correct because a misconfigured health check can cause the ALB to consider all targets unhealthy, even if the instances are healthy, leading to 503 errors.

Question 9mediummultiple choice

A SysOps administrator is troubleshooting slow application performance. The application runs on Amazon EC2 instances in an Auto Scaling group behind an Application Load Balancer. Amazon CloudWatch metrics show that the average CPU utilization across the instances is below 20%, but the application is still slow. What is the MOST likely cause of the performance issue?

Trap 1: The Auto Scaling group is scaling too aggressively, causing…

Auto Scaling thrashing occurs when scaling policies overreact to short-lived spikes, causing frequent launch and termination cycles. This would show up as volatile CPU utilization, repeated CloudWatch Alarm state flapping, and a constantly changing instance count, rather than a steady sub-20% average CPU. Since the problem describes consistently low CPU, a thrashing Auto Scaling group is not the cause, and the symptom would instead be tied to a resource the application is waiting on.

Trap 2: The Application Load Balancer has a sticky session configuration…

Sticky sessions (session affinity) pin a client to a specific target for the life of a session, which can cause uneven load distribution if session durations are long or clients are concentrated. However, such imbalance would typically produce a mix of instances with high CPU utilization and others with near-idle CPU, so the fleet-wide average would not uniformly sit below 20%. The scenario gives no indication of skewed per-instance metrics or hot spots, so this configuration is unlikely to explain the persistent slow performance across all application nodes.

Trap 3: The EC2 instances are using burstable performance and have…

Incorrect. If burstable instances exhaust CPU credits, they are throttled to baseline performance, which would still result in low CPU utilization but might explain slow performance. However, the most likely cause given common scenarios is a database bottleneck, not CPU credit exhaustion, because low CPU is more typically associated with waiting on external resources.

A
The Auto Scaling group is scaling too aggressively, causing thrashing.
Why wrong: Auto Scaling thrashing occurs when scaling policies overreact to short-lived spikes, causing frequent launch and termination cycles. This would show up as volatile CPU utilization, repeated CloudWatch Alarm state flapping, and a constantly changing instance count, rather than a steady sub-20% average CPU. Since the problem describes consistently low CPU, a thrashing Auto Scaling group is not the cause, and the symptom would instead be tied to a resource the application is waiting on.
B
The Application Load Balancer has a sticky session configuration that is not distributing traffic evenly.
Why wrong: Sticky sessions (session affinity) pin a client to a specific target for the life of a session, which can cause uneven load distribution if session durations are long or clients are concentrated. However, such imbalance would typically produce a mix of instances with high CPU utilization and others with near-idle CPU, so the fleet-wide average would not uniformly sit below 20%. The scenario gives no indication of skewed per-instance metrics or hot spots, so this configuration is unlikely to explain the persistent slow performance across all application nodes.
C
The application database is under-provisioned and is causing slow query responses.
An under-provisioned database can directly cause slow application responses while keeping EC2 CPU low because the application nodes spend most of their time blocked on database queries. Inadequate IOPS, insufficient memory for the buffer cache, or a suboptimal schema can lead to high query latency and connection queueing, which is not reflected in the web-tier CloudWatch CPU metric. The low average CPU is a classic sign of an external dependency bottleneck, making the database the most plausible root cause for the degraded user experience.
D
The EC2 instances are using burstable performance and have exhausted their CPU credits.
Why wrong: Incorrect. If burstable instances exhaust CPU credits, they are throttled to baseline performance, which would still result in low CPU utilization but might explain slow performance. However, the most likely cause given common scenarios is a database bottleneck, not CPU credit exhaustion, because low CPU is more typically associated with waiting on external resources.