A city's hub-and-spoke Transit Gateway design accidentally allows a sandbox account VPC to reach production courts systems through transitive routes. Which control best remediates this?

When a hub-and-spoke Transit Gateway accidentally lets a sandbox VPC reach production courts through transitive routes, the remediation is route-table segmentation—not more openness. Place sandbox attachments on Transit Gateway route tables that do not learn production courts prefixes, while shared-services attachments receive only the paths those spokes are meant to use. Separate prod and non-prod route tables are the control that stops accidental transitive reachability at the routing layer before security groups become the last line of defense.

Enabling full transitive routing among all attachments makes troubleshooting briefly easier and makes the compromise permanent; it is the opposite of remediation. Deleting the Transit Gateway and replacing it with unrestricted VPC peering from sandbox to production recreates direct paths the city needs to forbid. Opening all security groups in production courts to 0.0.0.0/0 bypasses routing concerns by destroying instance-level controls and is never an acceptable “fix.”

Exam caveat: Transit Gateway is not automatically microsegmented—route tables define which attachments learn which CIDRs; appliance mode and inspection patterns are separate topics from basic spoke isolation. Operational check: inspect the sandbox association route table for absent courts prefixes, attempt a connection from sandbox to a courts test endpoint and expect failure, confirm shared services still resolve from approved spokes, and log the change in the network CAB so future attachments follow the same prod/non-prod table pattern.