A VPC was created with a primary IPv4 CIDR block of 10.0.0.0/16. An engineer wants to shrink that primary block to 10.0.0.0/20 to free up address space for a different VPC. Which statement correctly describes what AWS allows here?
- The primary CIDR block can be resized to /20 directly, and AWS automatically shrinks any oversized subnets to fit
- An existing CIDR block, including a VPC's primary CIDR block, can never be resized larger or smaller after it is associated; only additional secondary CIDR blocks can be associated or disassociated
- The resize is allowed only after every subnet in the VPC is deleted first
- The primary CIDR block can be resized, but only by AWS Support and only once per calendar year
Why B? And why not the others?
Correct answer: B. An existing CIDR block, including a VPC's primary CIDR block, can never be resized larger or smaller after it is associated; only additional secondary CIDR blocks can be associated or disassociated
AWS explicitly states that when managing IPv4 CIDR blocks for a VPC, 'you cannot increase or decrease the size of an existing CIDR block,' and a VPC's primary CIDR block additionally can never be disassociated at all — only secondary CIDR blocks can be added later or removed. If the engineer needs a different address range, the only supported path is associating a differently sized secondary CIDR block (subject to the /16-/28 sizing and non-overlap rules) rather than resizing the primary block. Option A is wrong because no automatic subnet-shrinking mechanism exists — subnets are never resized by AWS in response to a CIDR change. Option C is wrong because emptying the VPC of subnets has no bearing on this restriction; the limitation is on the CIDR association itself, not on what is deployed inside it. Option D invents a support-mediated annual resize process that does not exist anywhere in AWS documentation.
Source: AWS VPC docs: VPC CIDR blocks — Manage IPv4 CIDR blocks for a VPC