A county organization has many VPCs (parks, courts, utilities, shared services) that need scalable transitive connectivity without a brittle peering mesh. Which hub service should they use?
Select an answer to reveal the explanation.
Short Explanation
Transit Gateway is the county roundabout: every VPC attaches once to the hub instead of paving a private road to every other VPC. Meshes get messy; hubs stay sane.
Full Explanation
A county organization with many VPCs—parks, courts, utilities, shared services—needs scalable transitive connectivity without a brittle peering mesh. AWS Transit Gateway acts as a hub: VPCs attach to the transit gateway and can route to each other through centralized route tables rather than N×N peering relationships. That hub-and-spoke model matches growing municipal network topologies where new departments appear over time and peering spreadsheets become unmanageable.
Individual Internet Gateways on each VPC as the only inter-VPC path force public hairpinning and are not a private inter-VPC fabric. Security group references alone cannot connect unconnected VPCs—security groups do not create routes between isolated networks. Amazon S3 buckets shared by name are object storage, not a network transit fabric for VPC-to-VPC traffic.
Exam caveat: Transit Gateway route tables control isolation (for example, segregating courts from parks while both reach shared services). Peering can still be valid for simple two-VPC cases; the stem’s many-VPC transitive requirement is the Transit Gateway signal. Remember attachment quotas and CIDR planning still apply.
Operational check: attach representative VPCs to a transit gateway with intentional route table separations; verify transitive paths that peering mesh would have struggled to maintain; add a new department VPC with a single attachment; and audit routes so sensitive court systems are not accidentally opened to every utility subnet.