CCNA Cloud Troubleshooting Questions

Misconfigured health checks can cause the load balancer to incorrectly mark healthy instances as unhealthy and remove them from the target group. This results in fewer instances handling traffic, leading to a buildup of pending requests even though the remaining instances have low CPU utilization. Option A is incorrect because API rate limiting would affect API calls, not HTTP traffic to the web servers.

Option B is incorrect because an incorrect DNS IP would prevent users from reaching the application entirely, not cause pending requests. Option C is incorrect because blocking inbound traffic on port 80 would cause connection timeouts or failures, not a high number of pending requests.

503 errors typically indicate that the application is not passing health checks, causing the load balancer or Kubernetes service to stop routing traffic to the affected pods. Option B is incorrect because an incorrect ingress configuration usually results in 404 errors or connection timeouts, not 503. Option C is incorrect because insufficient pod resources lead to OOM kills or CPU throttling, which may cause 503s only indirectly if health checks fail, but the more direct cause is failed health checks.

Option D is incorrect because node port exhaustion is rare and would cause connection refused, not 503.

The cooldown period settings determine how long the auto-scaling group waits before initiating another scaling activity after a previous scaling event. If the cooldown period is too long, new scaling events may be suppressed even when the CPU threshold is exceeded for the required duration. The administrator should review and potentially reduce the cooldown period to allow the auto-scaling group to respond more quickly to high CPU utilization.

Option A is wrong because manual scaling is a temporary workaround and does not address the underlying auto-scaling configuration issue. Option B is wrong because increasing the CPU threshold to 95% would make scaling less sensitive, likely worsening performance during peak hours. Option D is wrong because health check configuration affects load balancer traffic routing, not the triggering of scaling events based on CPU metrics.

Console logs provide detailed error messages during the boot process, helping identify the root cause of boot failure. Option C is correct because incorrect boot order (e.g., trying to boot from a non-bootable device) can prevent the VM from starting; verifying and adjusting boot order is a standard troubleshooting step. Option B is incorrect because while verifying the root disk is attached is a basic check, it alone does not address other common boot issues (e.g., corrupted OS, incorrect boot configuration).

Option D is incorrect because rebooting the hypervisor host affects multiple VMs and is not a targeted troubleshooting step for a single VM failing to boot. Option E is incorrect because deleting and recreating the VM is a drastic measure that results in data loss and should only be considered after all other troubleshooting steps have failed.

During peak hours, CPU utilization may spike quickly, but the scaling policy requires CPU to exceed 70% for 5 minutes before triggering a scale-out. If the scale-out cooldown period is too long, additional instances are delayed, causing the existing instances to become overloaded and leading to timeouts. Option A is incorrect because the maximum of 10 instances is likely sufficient; the problem is the speed of scaling.

Option B is incorrect because health check failures would cause instance replacement, not timeouts from overload. Option C is incorrect because a 70% threshold is not too low; a lower threshold would cause premature scaling, not timeouts.

Firewall rules are evaluated in order; the first rule (rule #1) drops all SSH traffic from any source, and the second rule (rule #2) permits SSH traffic only from the internal network (10.0.0.0/16). Since the remote location is outside this network, the packet matches the first rule and is dropped before reaching the second rule. Option B is incorrect because the firewall is not dropping all packets on port 22; it only drops those from external sources due to the rule order.

Option C is incorrect because a host key change would cause a different SSH warning, not a connection timeout. Option D is incorrect because if the SSH service were not running, the error would be 'connection refused' rather than a timeout.

The role's permissions policy is an IAM policy attached to the role that defines what actions the role can perform. If this policy includes a condition key such as `ipAddress` or `SourceIp`, it can restrict access to requests coming from specific IP addresses. If the EC2 instance's public IP address is not within the allowed range, the `s3:GetObject` call will be denied, even though the permission is granted.

Option A is incorrect because the stem does not mention any bucket policy, and the question asks for the most likely cause; a bucket policy denying access would be less common than a condition on the role's policy. Option B is incorrect because if the trust policy did not allow EC2 to assume the role, the instance would not receive temporary credentials at all, and the administrator would likely see errors during association. Option D is incorrect because security groups by default allow all outbound traffic, and S3 access uses HTTPS over the internet or VPC endpoints, so outbound blocking is unlikely unless explicitly configured.

The load balancer health checks are failing intermittently because the security group rules are blocking the health check traffic from the load balancer. When the health checks are blocked, the instances appear unhealthy. Manual testing from the admin's workstation works because the workstation is not subject to those security group rules.

Option A (short interval) would cause more frequent health checks, not intermittent failures. Option C (memory exhaustion) would cause persistent failures. Option D (incorrect IP binding) would also cause persistent failures.

Therefore, the most likely cause is B.

The REJECT entry in the VPC flow log indicates that traffic is being blocked by a network ACL (NACL), which is stateless. Security groups are stateful and do not produce REJECT entries; they either allow or silently drop traffic. To resolve the issue, the administrator must add an inbound rule to the network ACL associated with the subnet of the web server (10.0.2.10) to allow TCP port 80 from the source IP 10.0.1.5.

Option C is correct. Option A is incorrect because increasing the MTU does not affect firewall blocking. Option B is incorrect because a security group rule would not generate a REJECT; the REJECT indicates a NACL blockage.

Option D is incorrect because adding a route does not address firewall filtering.

Intermittent connectivity with the VPN tunnel appearing up is a classic sign of packet loss or misconfiguration in IPSec parameters (e.g., mismatched phase 1/phase 2 settings, encryption algorithms, or Diffie-Hellman groups). This causes some packets to fail while others pass, leading to intermittent issues. Option A is incorrect because while the on-premises firewall blocking outbound ICMP could cause ping failures, it would not cause intermittent connectivity for all applications; also, the issue is likely VPN-related.

Option B is incorrect because a security group blocking ICMP would cause consistent ping failure, not intermittent. Option C is incorrect because missing routes would cause complete failure for all traffic, not intermittent.

If the custom image was created on a newer version of the hypervisor, it may include features or configuration that are not supported by the older hypervisor version on the host, causing the 'Incompatible hypervisor version' error. Option B is incorrect because virtual hardware version typically relates to compatibility within the same hypervisor, but the error is specifically about hypervisor version mismatch. Option C is incorrect because a corrupt image would typically cause different errors (e.g., file read failure).

Option D is incorrect because the error is about hypervisor compatibility, not storage backend support.

Correct options are B, C, and E. Option B is correct because DNS resolution delays caused by an on-premises DNS server can increase response times without appearing as a resource bottleneck on the cloud provider's dashboard. Option C is correct because geographic latency between the cloud region and the users' location is a network issue, not a resource bottleneck, so it won't show on the dashboard.

Option E is correct because a TCP window scaling mismatch can degrade network throughput transparently, without affecting resource metrics. Option A is incorrect because an application not optimized for the cloud would typically cause high resource usage, which would appear as a bottleneck on the dashboard. Option D is incorrect because insufficient CPU cores would result in high CPU utilization, visible as a resource bottleneck on the dashboard.