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

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?

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 3hardmultiple choice

A SysOps Administrator manages a VPC with public and private subnets. The private subnets need to access the internet for software updates. The Administrator creates a NAT Gateway in a public subnet and updates the private subnet route table to point 0.0.0.0/0 to the NAT Gateway. However, instances in the private subnet still cannot reach the internet. What is the MOST likely reason?

A
The security group on the private instances blocks outbound HTTPS traffic.
Why wrong: By default, security groups allow all outbound traffic; unless explicitly removed, outbound is allowed.
B
The internet gateway is not attached to the NAT Gateway.
Why wrong: The internet gateway is attached to the VPC, not to individual resources like NAT Gateways.
C
The NAT Gateway does not have an Elastic IP address assigned.
A NAT Gateway requires an Elastic IP to communicate with the internet; without one, it cannot route traffic.
D
The NAT Gateway's security group is blocking inbound traffic from the private subnet.
Why wrong: NAT Gateways do not have security groups; they use network ACLs and route tables.

Question 4hardmultiple choice

A company has a VPC with public and private subnets. A NAT Gateway is deployed in the public subnet to allow instances in the private subnet to access the internet. However, private instances cannot reach an external service at 203.0.113.50:443. What should be checked first?

A
The route table for the private subnet has a route 0.0.0.0/0 pointing to the NAT Gateway.
Without this route, traffic from private instances cannot reach the NAT Gateway, so they cannot access the internet.
B
The NAT Gateway has an Elastic IP assigned.
Why wrong: The NAT Gateway must have an EIP, but that is typically configured at creation. Lack of EIP would prevent outbound traffic, but routing is checked first.
C
The security group for the NAT Gateway allows inbound traffic from the private subnet.
Why wrong: NAT Gateway security groups are not configurable; it uses security groups only for the ENI, but the default allows all traffic. NACLs may block, but routing is more likely.
D
The internet gateway is attached to the VPC.
Why wrong: If the NAT Gateway itself can't reach the internet, the IGW might be missing, but the immediate issue is routing from private subnet to NAT Gateway.

Question 5mediumdrag 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

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 6mediumdrag 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

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 7hardmultiple choice

An organization has a VPC with public and private subnets. The private subnets need to access the internet for software updates. A NAT gateway is deployed in a public subnet and the private subnet route table has a route for 0.0.0.0/0 pointing to the NAT gateway. However, instances in the private subnet cannot reach the internet. What could be the issue?

A
The NAT gateway's subnet does not have a route to an internet gateway
For the NAT gateway to successfully forward traffic from private subnets to the internet, the subnet where the NAT gateway resides must have a route to an internet gateway (IGW). Without a route to the IGW in that subnet's route table, the NAT gateway cannot send or receive traffic from the internet, even though it has a public Elastic IP. This is the most common reason for failed outbound internet access from private instances when a NAT gateway is present.
B
The private subnet's network ACL blocks outbound HTTPS traffic
Why wrong: While a private subnet's network ACL (NACL) blocking outbound HTTPS (destination port 443) would indeed prevent HTTPS traffic from leaving the subnet, this is a less likely cause because NACLs are stateless and often configured to allow outbound traffic on ephemeral ports as well. Moreover, if the NAT gateway itself lacks a route to the IGW, then even if the NACL permits outbound HTTPS, the traffic will never reach the internet. Thus, routing for the NAT gateway is the more fundamental issue.
C
The security group attached to the NAT gateway does not allow outbound traffic
Why wrong: Security groups are not applicable to NAT gateways; AWS does not allow you to attach a security group to a NAT gateway. NAT gateways are managed by AWS and are inherently controlled by the network ACLs of the subnet in which they are placed. If anything, you would verify the NACL settings for the subnet, not a security group, when diagnosing outbound connectivity through a NAT gateway.
D
The private instances do not have a public IP address assigned
Why wrong: Private instances in a private subnet intentionally do not have public IP addresses; they rely on the NAT gateway to provide outbound internet connectivity by translating their private source IP to the NAT gateway's Elastic IP. The absence of a public IP on these instances is expected and is not a cause of connectivity failure. If the NAT gateway's routing is properly configured, these instances can still access the internet.

Question 8easymultiple 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?

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 9mediummultiple 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?

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

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 11mediummultiple 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?

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.

Question 12mediummultiple choice

A SysOps administrator is configuring a VPC with a public subnet and a private subnet. The private subnet needs to access the internet to download patches. The administrator creates a NAT Gateway in the public subnet and updates the private subnet route table. However, instances in the private subnet cannot reach the internet. What is the most likely cause?

A
The network ACL for the private subnet blocks outbound traffic.
Why wrong: While a network ACL could block traffic, the most likely cause is missing Internet Gateway route, not NACL configuration.
B
The route table for the public subnet does not have a route to an Internet Gateway.
This is correct: the public subnet's route table must have a route to an Internet Gateway for the NAT Gateway to send traffic to the internet.
C
The NAT Gateway does not have an Elastic IP address attached.
Why wrong: A NAT Gateway does need an Elastic IP, but the problem states the administrator created the NAT Gateway; the missing IGW route is the more common oversight.
D
The security group associated with the NAT Gateway blocks outbound traffic.
Why wrong: Security groups do not apply to NAT Gateways; they apply to instances. This is not the cause.

Question 13hardmultiple choice

A company has a VPC with public and private subnets. The public subnet has a NAT Gateway. The private subnet has an EC2 instance that needs to download patches from the internet. The route table for the private subnet has a default route (0.0.0.0/0) pointing to the NAT Gateway. However, the instance cannot reach the internet. What is the most likely cause?

A
The network ACL for the private subnet blocks outbound HTTP traffic.
Why wrong: The network ACL for the private subnet by default allows all outbound traffic. Even if outbound HTTP were blocked, the instance might still reach other services, but the core issue here is the NAT Gateway placement.
B
The security group of the EC2 instance blocks outbound traffic.
Why wrong: Security groups by default allow all outbound traffic. Unless the outbound rule was explicitly removed, this is not the cause.
C
The NAT Gateway is deployed in a private subnet.
Correct. A NAT Gateway must be deployed in a public subnet with a route to an Internet Gateway. If it is in a private subnet, it cannot access the internet, breaking the connectivity for instances using it.
D
The NAT Gateway does not have an Elastic IP address.
Why wrong: Incorrect. While a NAT Gateway does require an Elastic IP address to communicate with the internet, the more fundamental and likely cause is that the NAT Gateway is deployed in a private subnet, which renders it non-functional regardless of having an Elastic IP.