Troubleshooting practice questions

Asynchronous replication to a secondary cloud with a 30-minute delay

Why it fails: A 30-minute replication delay exceeds the 15-minute RPO, so up to half an hour of data could be lost. Asynchronous replication is tempting because it avoids latency penalties on the primary, and would suit workloads tolerating RPOs of 30 minutes or more.

Pilot light environment that is started manually during a disaster

Why it fails: Manual start-up cannot reliably complete within the one-hour RTO, since detection, decision-making and bootstrapping all consume time. A pilot light is tempting because it minimises ongoing compute cost, and would be correct where RTOs stretch to hours rather than minutes.

Daily backups to object storage in a different region

Why it fails: Daily backups give a 24-hour RPO, far exceeding the 15-minute target, and full restoration typically breaches the one-hour RTO. Backups are tempting because they are cheap and simple, and would be correct for non-critical workloads with relaxed recovery objectives.

DNS resolution settings

Why it fails: Incorrect; DNS affects name resolution, not direct IP connectivity.

Gateway subnet configuration

Why it fails: Incorrect; gateways are not required for VNet peering.

Service endpoint status

Why it fails: Incorrect; service endpoints are for accessing Azure PaaS services.

Ultra Disk (UltraSSD_LRS)

Why it fails: Ultra Disk is a premium SSD tier, not the storage type reported in the command output; the exhibit shows a different SKU. Ultra Disk would be the answer if the output listed UltraSSD_LRS, which suits IO-intensive workloads needing sub-millisecond latency.

Standard HDD (Standard_LRS)

Why it fails: Standard_LRS is HDD-backed storage, so it cannot be the SSD type the administrator wants; the exhibit reports a different SKU. Standard HDD is correct when the output shows Standard_LRS and the workload tolerates higher latency at lower cost.

Standard SSD (StandardSSD_LRS)

Why it fails: StandardSSD_LRS is SSD-backed, but the exhibit reports a different SKU, so it is not the current storage type. Standard SSD is the right answer when the output shows StandardSSD_LRS, matching cost-sensitive workloads needing consistent low latency.

The FORWARD chain policy drops all traffic

Why it fails: The FORWARD chain applies only to traffic routed between interfaces, not to same-subnet communication delivered locally. Traffic to 10.0.0.5 traverses INPUT, so a FORWARD policy is irrelevant here. FORWARD rules would matter when the host acts as a router or gateway between separate networks.

The OUTPUT chain rejects all traffic to the server

Why it fails: The OUTPUT chain governs traffic originating from the local host, not inbound connections to 10.0.0.5. A client connecting to that server is filtered by INPUT on the destination host. OUTPUT rules would be the correct focus when diagnosing failures in outbound requests initiated by this machine.

The DROP rule in INPUT has zero packet count, so it is not effective

Why it fails: A zero packet count merely indicates the rule has not yet matched traffic; it does not disable the rule. If the DROP rule sits above the ACCEPT rule for port 22, it still blocks connections. Packet counters reflect hits, not rule validity, so this reasoning misreads how iptables evaluates chains.

Shrink an existing partition to free space

Why it fails: Shrinking partitions is risky and may not be supported online.

Restore the VM from a recent backup to a larger disk

Why it fails: Restoring from backup causes significant downtime.

Add a new disk and move data to it

Why it fails: Moving data requires application downtime and reconfiguration.

ARP resolution for the destination IP is failing

Why it fails: ARP failure would occur on the source if the destination were on the same subnet; here they are on different subnets.

The network interface on the source VM is disabled

Why it fails: If the NIC were disabled, the ping command would fail with a local error.

A firewall is blocking ICMP on the destination

Why it fails: A firewall block would cause no response or 'Request timed out', not 'Destination Host Unreachable'.

The destination VM is powered off.

Why it fails: While a powered-off VM could cause unreachability, the 'Destination Host Unreachable' message from the gateway suggests the gateway itself cannot resolve the destination MAC, which is more indicative of an ARP failure than a powered-off VM.

The source VM's routing table does not have a default gateway.

Why it fails: Since both VMs are on the same subnet, no routing is needed; the issue is at layer 2, not layer 3 routing.

The destination VM's security group is blocking ICMP.

Why it fails: A security group blocking ICMP would typically result in a timeout (no response) rather than a 'Destination Host Unreachable' message from the gateway.

Reset the virtual machine from the cloud provider's management console.

Why it fails: Resetting reboots the instance without diagnosing why SSH times out despite ping succeeding and firewall rules permitting port 22, likely destroying evidence and leaving the fault. It is tempting as a quick recovery action, but resetting suits a confirmed hung guest, not an undiagnosed connectivity failure.

Create a new virtual machine and migrate the application.

Why it fails: This is a last resort; troubleshooting should first focus on restoring access to the existing VM.

Check the application logs from the cloud provider's monitoring service.

Why it fails: Application logs explain the 500 error but not why SSH times out, since the failure occurs before the application layer. It is tempting because logs are the natural first stop for errors, yet the priority is the network or host-level cause blocking port 22.

The web servers are throttled by the cloud provider's API rate limiting.

Why it fails: API rate limiting affects API calls, not web traffic.

The DNS records point to an incorrect IP address.

Why it fails: DNS would cause total inaccessibility, not just slowness.

The security group is blocking inbound traffic on port 80.

Why it fails: Blocking port 80 would cause connection failures, not pending requests.

Add more RAM to the virtual machine.

Why it fails: Adding RAM may reduce disk hits but does not directly fix queue length.

Increase the size of the disk.

Why it fails: Increasing size does not guarantee higher IOPS.

Enable compression on the database.

Why it fails: Compression may reduce I/O but does not directly address queue length.

The maximum number of instances is too low.

Why it fails: Max is 10, which is typically sufficient; the issue is that scaling is not triggered quickly enough.

The health checks are marking healthy instances as unhealthy.

Why it fails: This would cause instance termination, not timeouts.

The CPU threshold is too low, causing premature scaling.

Why it fails: The threshold is 70%, which is not low; average CPU is 40%.

The on-premises firewall is blocking outbound ICMP.

Why it fails: This would cause consistent failure for ping, but not necessarily for other applications.

The security group on the cloud instance is blocking ICMP.

Why it fails: Blocking ICMP would cause consistent failure, not intermittent.

The routing tables on the cloud VPC are missing routes for the on-premises network.

Why it fails: Missing routes would cause complete failure, not intermittent.

Increase the volume size to gain higher baseline IOPS.

Why it fails: Increasing size increases baseline IOPS but still uses burst credits which can deplete.

Move the logs to an object storage service.

Why it fails: Object storage is not block-level and may require application changes.

Enable write caching on the volume.

Why it fails: Write caching can cause data loss and is not recommended for data volumes.

The S3 bucket policy denies access to the role.

Why it fails: A bucket policy could deny, but the question does not mention a bucket policy; typically, bucket policies are used for cross-account access.

The role's trust policy does not allow the EC2 service to assume the role.

Why it fails: If trust policy were wrong, the instance would not be able to assume the role; the administrator verified association.

The instance's security group is blocking outbound traffic to S3.

Why it fails: Security groups default to all outbound; S3 APIs use HTTPS, and outbound to S3 endpoints is typically allowed.

Disk I/O wait

Why it fails: Disk I/O wait indicates disk performance issues, not memory.

Page fault rate

Why it fails: Page fault rate can indicate memory pressure but is less direct than available memory and swap usage.

CPU ready time

Why it fails: CPU ready time is a metric for CPU contention, not memory.

Use a multi-region bucket to reduce latency.

Why it fails: Multi-region buckets replicate data across regions, increasing write latency.

Enable versioning to avoid overwrites.

Why it fails: Versioning adds overhead and does not improve performance.

The /dev/shm partition is full.

Why it fails: The /dev/shm partition is shown as 0% used.

The filesystem is corrupt.

Why it fails: Filesystem corruption would typically produce I/O errors or force a fsck, not the specific capacity symptom shown in df output. Corruption is the right diagnosis when metadata is damaged and reads fail, but here the reported usage figures point to a space or inode exhaustion condition instead.

The inode usage on the root filesystem is exhausted.

Why it fails: Inode exhaustion prevents new file creation while df -h still reports free blocks, so the exhibit would need to show inode usage rather than block capacity. Inode depletion is the right cause when df -i is full, but the displayed output indicates block-level consumption on the filesystem.

The web server on the target is not listening on port 443.

Why it fails: The target is healthy on port 443, so the web server is listening.

The load balancer is in a different VPC.

Why it fails: Same target group implies same VPC.

The health check path is incorrect.

Why it fails: An incorrect path would affect both ports if the same path is used, but the health check is on different ports.

Increase the MTU on the instance to 9001.

Why it fails: MTU issues would cause different symptoms, not REJECT.

Add a security group rule allowing inbound TCP/80 from 10.0.1.5.

Why it fails: Security groups are stateful and allow return traffic; the REJECT in flow logs indicates a NACL, not a security group.

Add a route to the VPC route table for 10.0.1.5.

Why it fails: Routes determine the path, not filtering; the flow logs show traffic reaching the target, so routing is fine.

Replace the virtual routers

Why it fails: Virtual routers are abstracted in the cloud and replacement is not a typical first step.

Increase the bandwidth between subnets

Why it fails: Bandwidth increase would not resolve intermittent connectivity caused by firewall rules.

Check the physical cabling

Why it fails: The subnets are cloud-hosted, so no physical cabling exists between them for the engineer to inspect; the fault lies in virtual routing, security groups or NACLs. It is tempting because cabling is a classic first check on-premises, and it would be correct when diagnosing a link between two physical switches in a local data centre.