During an outage, a city network team must determine whether traffic is blackholed by a Transit Gateway route table misconfiguration, a network ACL deny, or a security group rule. Which troubleshooting approach is most appropriate?
Select an answer to reveal the explanation.
Short Explanation
Black holes have layers: wrong TGW route, subnet NACL, then security group. Walk the path in order and let flow logs tell you where packets vanish. Rebuilding the whole city network first is panic, not troubleshooting.
Full Explanation
During an outage, isolating whether Transit Gateway routing, a network ACL, or a security group is blackholing traffic requires an ordered path walk—not rebuild theater. Start with Transit Gateway and VPC route tables to confirm the destination prefix is present and points to the expected attachment or ENI path. Next evaluate network ACLs along the subnet path for explicit denies or missing ephemeral return rules. Then inspect security groups on the source and destination ENIs for missing allows. Flow logs and Reachability Analyzer (or equivalent) corroborate where packets stop so the city network team fixes the failing control instead of guessing.
Immediately recreating all VPCs and Transit Gateways without inspection destroys evidence, extends downtime, and may redeploy the same misconfiguration. Assuming DNS is always the cause and changing only public Route 53 records ignores L3/L4 controls that commonly blackhole hybrid and east-west flows. Disabling CloudTrail organization-wide to “reduce noise” removes audit visibility while the team makes undiagnosed firewall changes—an operational and compliance failure.
Exam caveat: remember stateful security groups versus stateless NACLs—NACL troubleshooting often hinges on ephemeral return ports; TGW issues often hinge on which route table an attachment associates with. Operational check: capture the failing 5-tuple, verify TGW route table associations and propagations, check NACL inbound/outbound for both directions, compare security group rules, and use flow-log REJECT/ACCEPT entries to confirm which layer dropped the packet before applying a minimal fix.