Troubleshooting Scenario Questions

Amazon Inspector.

Why it fails: Amazon Inspector scans EC2 instances and container images for software vulnerabilities and unintended network exposure; it does not trace packet paths or reachability between instances. It is tempting because it reports network-related findings, and would be correct for vulnerability assessment, not for diagnosing connectivity failures.

AWS CloudTrail.

Why it fails: CloudTrail records API activity and management events in the account; it captures no packet-level or flow-level data between EC2 instances, so it cannot show where connectivity breaks. It is tempting because it is a core monitoring service, and would be correct for auditing who changed security groups or routes, not for tracing live traffic.

AWS Config.

Why it fails: AWS Config records resource configuration changes and evaluates compliance against rules; it does not capture packet-level flow logs or reachability paths between instances. It is tempting because it inventories network resources such as security groups, which is useful for auditing drift, but connectivity troubleshooting requires VPC Flow Logs and Reachability Analyzer.

The internet gateway is not attached to the VPC

Why it fails: The stem states the internet gateway is already attached to the VPC, so this contradicts the given facts. An unattached gateway would indeed block internet access, making this the right diagnosis only when the attachment is genuinely absent.

The subnet needs a NAT gateway for internet access

Why it fails: A NAT gateway is required for instances in private subnets to reach the internet, but the route table here points directly at an internet gateway, indicating a public subnet. NAT gateways are correct when instances must initiate outbound traffic without inbound exposure.

The subnet's route table does not have a route to the internet gateway

Why it fails: The stem explicitly states the route table already contains a 0.0.0.0/0 route to the internet gateway, so this contradicts the given facts. A missing default route would block access, making this correct only when no such route exists.

Increase the deployment timeout in the CodeDeploy deployment group to allow more time for validation.

Why it fails: Extending the deployment timeout only lets failing validation scripts run longer before the deployment aborts; the scripts still fail. It is tempting because timeouts do cause deployment failures, so raising the value is correct when validation legitimately needs more time than the configured window.

Configure an Auto Scaling lifecycle hook to perform health checks before the instance is placed in service.

Why it fails: A lifecycle hook delays instance termination or launch; it cannot fix validation scripts failing on already-running, in-service instances. It is tempting because lifecycle hooks genuinely gate instance health during scale-in and scale-out events, which is the right control when instances enter service unhealthy.

Check the RDS console for any database events.

Why it fails: RDS console events may show database-level activity, but a DBInstance that never provisioned typically produces no events there; the failure reason appears in the CloudFormation stack events for that resource. Console event review is appropriate when investigating an existing running database's operational incidents, not a failed creation.

Delete the stack and deploy again with the same parameters.

Why it fails: Redeploying with identical parameters reproduces the same failure and discards the stack's event history, which records the underlying resource error. It is tempting as a quick reset, but the RDS events or CloudFormation stack events already identify the cause. Redeployment is appropriate only after the fault has been corrected.

Use AWS CloudTrail to view the CreateStack API call.

Why it fails: CloudTrail records the CreateStack API call and who made it, not the RDS-side reason the DBInstance failed, such as an invalid parameter or unavailable engine version. CloudTrail is the correct choice when the requirement is auditing API activity or attributing changes to an identity, not diagnosing resource provisioning errors.

Check network ACLs, then security groups, then public IP, then system status, then console output.

Why it fails: Incorrect because network ACLs are evaluated after security groups for inbound traffic; checking them first may waste time if security groups are blocking traffic.

Check public IP, then security groups, then network ACLs, then console output, then system status.

Why it fails: Incorrect because you should verify security groups before checking public IP; also, console output should be last after system status to avoid premature OS-level investigation.

Check system status, then console output, then security groups, then network ACLs, then public IP.

Why it fails: Incorrect because system status checks should come after network configuration is confirmed; console output is a last resort for OS issues, not an early step.

The security group for the EC2 instances does not allow outbound traffic to the RDS instance.

Why it fails: The stem explicitly states the security groups are configured correctly, so outbound rules cannot be the cause. It tempts because security group misconfiguration is the most common cause of EC2-to-RDS connection failures, and would be correct if the EC2 security group lacked an outbound rule permitting MySQL traffic to the database.

The RDS Multi-AZ failover took longer than expected, exceeding the RTO.

Why it fails: The stem states failover completed in about 2 minutes, so the 30-minute outage cannot stem from failover duration; the RTO was already met on that axis. It tempts because Multi-AZ failover time is a genuine RTO consideration, and would be the answer if the drill had shown failover itself exceeding 15 minutes.

The RDS endpoint DNS record did not update to point to the new primary.

Why it fails: Multi-AZ failover updates the RDS DNS endpoint to the new primary automatically, and the stem's 2-minute failover confirms this succeeded; the 30-minute gap points elsewhere. It tempts because stale DNS is a real failure mode, and would be correct if clients had cached the old IP beyond the TTL.