An architect associates a new secondary IPv4 CIDR block, 10.2.0.0/16, with an existing VPC whose primary CIDR is 10.0.0.0/16, intending to build a new subnet inside the secondary range. What does AWS do automatically as part of this association?
- Nothing changes until the engineer manually adds a route for 10.2.0.0/16 to every route table
- AWS automatically adds a route with destination 10.2.0.0/16 and target 'local' to the VPC's route tables
- AWS automatically provisions a NAT gateway to translate traffic between the two CIDR ranges
- AWS merges 10.0.0.0/16 and 10.2.0.0/16 into a single contiguous 10.0.0.0/15 block
Why B? And why not the others?
Correct answer: B. AWS automatically adds a route with destination 10.2.0.0/16 and target 'local' to the VPC's route tables
AWS documentation states plainly that 'when you associate a CIDR block with your VPC, a route is automatically added to your VPC route tables to enable routing within the VPC (the destination is the CIDR block and the target is local),' so intra-VPC routing to the new range works immediately without manual route entries. Option A is wrong because it contradicts this automatic behavior. Option C is wrong because NAT gateways translate addresses only for internet-bound traffic leaving the VPC; they play no role in routing between two CIDR ranges that already belong to the same VPC, and none is created automatically. Option D is wrong because the two CIDR blocks remain two separate, independently associated and disassociated ranges — AWS tracks and can later disassociate the secondary block on its own, which would be impossible if it had been merged into one supernet with the primary.
Source: AWS VPC docs: VPC CIDR blocks — Manage IPv4 CIDR blocks for a VPC