Troubleshooting Scenario Questions

Enable SSL offloading on the load balancer

Why it fails: SSL offloading shifts TLS decryption to the load balancer, reducing backend CPU load but not addressing peak-hour latency caused by insufficient capacity or scaling lag. It is tempting because TLS handshakes are expensive, and offloading is the right fix when backend instances are CPU-bound by cryptographic operations rather than demand.

Verify the load balancer's health check interval

Why it fails: Health check interval governs how quickly unhealthy instances are removed from rotation; it does not throttle request distribution or add capacity during peak demand. It is tempting because aggressive intervals speed failover, and tuning them is correct when latency stems from traffic reaching failed or unresponsive backends.

Check DNS resolution times for the application domain

Why it fails: DNS resolution occurs before connections reach the load balancer, so its latency would affect all requests uniformly rather than intermittently at peak hours. It is tempting because slow DNS causes user-visible delays, and checking resolution times is correct when failures affect initial connection establishment regardless of load.

Increase the VM's vCPU count to 8 to improve processing capacity.

Why it fails: Adding vCPUs addresses compute contention, but CPU utilisation stays below 50 percent during peaks, so processing capacity is not the bottleneck. Extra vCPUs would be correct when sustained CPU saturation, not network spikes, causes the latency.

Configure the firewall to allow all traffic to reduce processing overhead.

Why it fails: Allowing all traffic does not raise the 1 Gbps interface cap or address the 500 Mbps outbound spikes causing latency; firewall rule processing is not the bottleneck here. It is tempting because permissive rules genuinely reduce stateful inspection overhead in firewall-bound workloads, but the stem points to network throttling, not filtering.

Enable DDoS protection on the public IP to filter malicious traffic.

Why it fails: DDoS protection scrubs volumetric attack traffic, yet the stem shows legitimate outbound spikes to 500 Mbps against a 1 Gbps cap with no attack signature. It would be right when malicious floods saturate the public IP, not for this throughput pattern.

ping: Traces the route packets take to a destination

Why it fails: Incorrect: this describes traceroute, not ping. Ping tests connectivity, not path.

traceroute: Queries DNS to resolve domain names to IP addresses

Why it fails: Incorrect: traceroute maps the network path; DNS resolution is done by nslookup.

nslookup: Tests network connectivity to a remote host

Why it fails: Incorrect: nslookup resolves DNS; testing connectivity is the role of ping.

The web server is not configured to listen on port 443, so iptables rules are irrelevant.

Why it fails: The stem states the web server is configured to listen on both 80 and 443, so a missing listener contradicts the given facts; iptables filtering remains the relevant layer. It is tempting because a service not bound to a port is a common cause of connection refusals, and would be correct if netstat showed no listener on 443.

The iptables default policy is ACCEPT, but the rule for port 443 explicitly drops traffic from external sources.

Why it fails: A default ACCEPT policy applies only when no rule matches; it does not override an explicit DROP or REJECT rule for port 443, which would still block HTTPS. It is tempting because a permissive default suggests traffic should flow, and would be correct if the exhibit showed no matching rule for port 443.

The rule for port 80 is placed before the rule for port 443, causing all HTTPS traffic to be evaluated as HTTP and dropped.

Why it fails: Iptables evaluates rules sequentially, but a port 80 rule matches only destination port 80 traffic; packets to port 443 never match it, so no reclassification as HTTP occurs. It is tempting because rule order genuinely matters in iptables, and would be correct if an earlier broad DROP or REJECT rule shadowed the port 443 rule.

AWS CloudTrail

Why it fails: AWS CloudTrail records API activity and management events for auditing who did what in the account, but it is not designed to ingest and query arbitrary application or operating system logs from EC2 instances. Using CloudTrail for this purpose would not capture application log content or provide the ad hoc log querying the administrator requires.

AWS Trusted Advisor

Why it fails: AWS Trusted Advisor inspects an account and provides recommendations across cost, security, fault tolerance, performance, and service quotas. It does not collect or store application or system logs from EC2 instances and provides no mechanism to query log data, so it is unrelated to the centralized logging requirement.

AWS Config

Why it fails: AWS Config evaluates and records resource configuration changes against desired rules, helping with compliance of resource state. It does not ingest application or system log streams from EC2 instances, and it lacks a general-purpose log query language for troubleshooting application events, so it cannot fulfill the log aggregation requirement.

Cloud-init is not installed on the VM

Why it fails: Cloud-init ships in most cloud images and its absence would not explain the exhibit's specific failure. It is tempting because a missing cloud-init package does prevent user-data execution entirely, which is the correct diagnosis only when the image genuinely lacks the agent and no initialisation logs exist.

The cloud-init user data script contains a syntax error

Why it fails: A syntax error would still produce cloud-init log entries showing the script starting and failing, whereas the exhibit indicates initialisation never ran. It is tempting because malformed user data is a common cause of failed bootstrapping, and it would be correct if logs showed execution beginning then erroring.

The VM does not have internet access

Why it fails: Internet access is not required for cloud-init to fetch and run user data, since metadata is served from the local link-local endpoint. It is tempting because missing internet access does break package installs and API calls inside scripts, but that would surface as script errors, not absent initialisation.

Incorrect route tables on the virtual network gateway

Why it fails: The stem already states routing tables are correct, so a gateway route-table error contradicts the given evidence. Gateway route tables are the correct focus when traffic traverses a VPN or ExpressRoute gateway rather than direct virtual network peering, which bypasses gateways.

A physical cable disconnection in the datacenter

Why it fails: Cloud providers abstract the physical underlay, so a single cable fault cannot selectively break one peering while other traffic flows; provider redundancy masks it. Physical cabling is the correct consideration for on-premises cross-connects or dedicated interconnect circuits, not provider-managed regional peering.

Incorrect DNS resolution

Why it fails: DNS resolution affects name-to-address mapping, not packet forwarding; if routes and peering are correct, IP-level connectivity still works and name lookups would fail separately. DNS is the right suspect when hosts resolve incorrectly while raw IP reachability succeeds.

Swap file usage

Why it fails: Swap file usage reflects memory pressure inside a guest operating system, not contention between virtual machines on the hypervisor. It is tempting because swapping indicates a resource shortage, but it suits diagnosing an individual VM's memory exhaustion, whereas host-level metrics such as CPU ready time reveal contention.

Network latency

Why it fails: Network latency measures round-trip delay across the network path, not contention for CPU, memory or storage on the virtualisation host. It is tempting because latency spikes accompany many performance problems, but it suits diagnosing network congestion or WAN issues rather than host resource contention.

The VPN tunnel is misconfigured and not passing traffic.

Why it fails: The tunnel is demonstrably passing traffic, since the EC2 instance successfully pings the on-premises VPN gateway IP, so misconfiguration is contradicted by the evidence. It tempts because a down tunnel is the usual cause of silent hybrid connectivity, but here the drop occurs at the on-premises firewall.

The security group attached to the EC2 instance is blocking inbound ICMP.

Why it fails: Security groups are stated to allow all traffic, and the on-premises firewall logs show packets arriving from the VPC before being dropped, so the block is not at the instance. It tempts because security groups commonly block ICMP, but the evidence places the failure on-premises.

The VPC route table does not have a route to the on-premises network.

Why it fails: The VPC route table already contains a route to the on-premises network via the virtual private gateway, and the EC2 instance reaches the on-premises gateway, proving return routing works. It tempts because missing routes are a frequent hybrid fault, but the drop is logged on-premises.

Low memory usage on the hypervisor

Why it fails: Low hypervisor memory usage says nothing about disk throughput or latency; a SAN bottleneck shows as high disk queue depth or elevated read/write latency. Memory metrics are tempting because they are easy to collect, but they belong to a capacity-planning scenario for RAM, not storage contention.

High network utilization on storage network links

Why it fails: Storage network utilisation measures the fabric carrying I/O, so saturation there indicates a network bottleneck rather than the SAN's disk tier. High link utilisation is the correct signal when the interconnect is the constraint, but the stem asks about the storage subsystem's own drives.

High CPU utilization on all application servers

Why it fails: Application server CPU utilisation reflects compute demand, not storage latency; a saturated SAN can leave CPUs idle waiting on I/O. CPU is the right metric when the bottleneck is processing, whereas the stem asks which measurement isolates the storage subsystem itself.

Migrate the VM to a different availability zone.

Why it fails: Moving the VM to another availability zone relocates it without changing vCPU allocation or identifying the workload consuming CPU, so the 90% saturation persists. It is tempting because availability zones address host-level faults and resilience, and would be correct after a zone outage or hardware failure, not sustained business-hours load.

Reboot the VM to reset resource usage.

Why it fails: Rebooting clears the current process state temporarily, but the underlying workload resumes and CPU returns to 90% during business hours, leaving the cause unidentified. It is tempting because restarts resolve stuck processes and memory leaks, and would be correct for a hung service rather than recurring, predictable daily saturation.

Scale up the VM to a larger instance size.

Why it fails: Resizing to a larger instance raises vCPU capacity but skips diagnosis, so an inefficient query, runaway process or code loop simply consumes the extra cores. It is tempting because vertical scaling genuinely relieves sustained CPU pressure, and would be correct once monitoring confirms demand legitimately exceeds the current instance size.

The template has a syntax error in the JSON.

Why it fails: Malformed JSON produces parse or validation errors before any resource is evaluated, so it cannot trigger a limit message. The limit error means the template's declared resource counts breach a per-region or per-type cap. A syntax error would be the likely cause of a template rejected at parse time.

The custom image used is corrupted.

Why it fails: A corrupted custom image causes image-validation or provisioning failures, not a resource-count error. 'Resource limit exceeded' arises when the template requests more instances of a resource type than the subscription permits per region. A corrupted image would be the likely cause of a deployment failing during image import or instance boot.

The IAM role used does not have permission to create resources.

Why it fails: Missing IAM permissions yield authorisation failures such as access denied or forbidden, not a resource limit error. The limit message indicates the template exceeds a service quota or per-region resource cap. Insufficient permissions would be the likely cause of a deployment failing when creating the first resource.

A misconfigured load balancer sending traffic to the VM

Why it fails: A load balancer distributing traffic to the VM would appear as network activity and connections, so it is a plausible source of hidden load. However, the stem specifies no apparent workload, and the administrator should first inspect the VM's own processes and guest-level activity before blaming external traffic sources.

CPU hotplug settings on the hypervisor

Why it fails: CPU hotplug governs whether vCPUs can be added or removed while the VM runs; it does not generate sustained CPU load. It is relevant when resizing a running VM without downtime, but the symptom here is unexplained consumption, so the administrator should first check what process or traffic is driving it.

Memory overcommitment ratio

Why it fails: Memory overcommitment causes swapping, ballooning and memory pressure, which inflates CPU through paging overhead, but it is a secondary effect rather than the direct cause to check first. It is the right suspect when hosts are memory-constrained and VMs show swap activity, not when a single VM spikes with no workload.

Firewall rules for outbound traffic.

Why it fails: Firewall rules for outbound traffic govern egress filtering, not tunnel integrity, so they cannot explain intermittent drops on an established VPN. It is tempting because outbound rules are a routine first check when traffic fails entirely. They would be correct if the VPN were down or specific destinations were blocked, rather than the connection flapping.

Public IP address of the VPN gateway.

Why it fails: A public IP address is static configuration; if it were wrong the VPN would never establish, yet the stem confirms it is established. Verifying gateway addressing suits initial tunnel setup failures, not intermittent drops on an existing connection.

DNS resolution of cloud endpoints.

Why it fails: The VPN tunnel is already established, so name resolution is not the transport fault; intermittent drops point to tunnel stability, MTU or routing. DNS checks suit scenarios where names fail to resolve while connectivity otherwise works.

The OS is paging memory to disk due to insufficient RAM.

Why it fails: Paging occurs when RAM is exhausted, but memory usage is below 50%, so the OS has no pressure to swap to disk. It is tempting because paging generates heavy disk I/O, yet it would coincide with high memory consumption, which the metrics contradict.

The virtual machine's network bandwidth is saturated.

Why it fails: Network saturation degrades throughput and increases response times, but it does not raise disk I/O latency on premium SSDs. It is tempting because peak-hour contention often implicates bandwidth, yet the reported symptom is specifically disk I/O latency with CPU and memory idle.

The database application is CPU-bound.

Why it fails: CPU-bound workloads saturate processor utilisation, yet the metrics show CPU below 50%, so the application cannot be the source of the disk latency. It is tempting because CPU contention does cause latency, but that would appear as high CPU usage rather than isolated disk I/O spikes.