A cloud network team is planning to expand the primary IP range of an existing production … — Google Cloud Associate Cloud Engineer

A cloud network team is planning to expand the primary IP range of an existing production subnet in a custom-mode Google Cloud Virtual Private Cloud (VPC) network from $10.200.1.0/24$ to $10.200.0.0/23$ to accommodate a higher volume of compute instances. To ensure zero service downtime and avoid IP address space collisions, what is the correct chronological sequence of operational steps the team should follow?

1Audit existing VPC routing tables, static routes, and peered network CIDR allocations to confirm that the contiguous block $10.200.0.0/23$ does not conflict with existing subnet ranges or BGP advertised routes.
2Verify that the proposed expansion CIDR ( $10.200.0.0/23$ ) strictly encompasses the current subnet range ( $10.200.1.0/24$ ) and only reduces the prefix length.
3Execute the `gcloud compute networks subnets expand-ip-range` command targeting the subnet and specifying `--prefix-length=23`.
4Confirm uninterrupted connectivity on active virtual machines and verify that newly created instances successfully receive IP addresses from the newly available upper and lower range blocks.

Answer

The correct operational sequence begins with auditing existing routing tables and peered network ranges for IP collisions, followed by confirming that the new prefix (

10.200.0.0/23

) mathematically encompasses the existing primary range (

10.200.1.0/24

). Next, the network engineer executes the non-disruptive `gcloud compute networks subnets expand-ip-range` command with `--prefix-length=23`. Finally, post-expansion verification validates active workload connectivity and new instance IP allocation.

Expanding a primary IP range in a Google Cloud custom-mode VPC subnet requires a systematic approach. First, pre-expansion checks must verify that the target expanded block (

10.200.0.0/23

) does not overlap with any static routes, Cloud Routers, or peered networks. Second, the target CIDR must be verified to mathematically encompass the current range (

10.200.1.0/24

) by decreasing the prefix length (from

/24

/23

). Third, the expansion command `gcloud compute networks subnets expand-ip-range` is run specifying `--prefix-length=23`. Finally, post-deployment testing validates continuous operational status and allocation to new VM instances.

Step-by-Step Solution

Audit routing tables and peered network ranges.

Identified that

10.200.0.0/23

is completely unassigned across all connected environments.

Prevents routing table conflicts and peering non-overlap violations before modifying the live subnet configuration.

Verify mathematical prefix containment.

Confirmed that

10.200.0.0/23

spans

10.200.0.0

10.200.1.255

, strictly containing the current range of

10.200.1.0/24

(

10.200.1.0

10.200.1.255

Google Cloud VPC subnet expansion rules mandate that primary ranges can only be expanded to a larger contiguous CIDR block (smaller prefix mask length) encompassing the original range.

Run the gcloud CLI subnet expansion command.

The VPC primary subnet range updates online without requiring instance reboots or dropping active connections.

Applying changes via `gcloud compute networks subnets expand-ip-range --prefix-length=23` executes the live configuration update.

Perform post-expansion connectivity and allocation validation.

Existing instances maintain active network sessions and newly deployed VMs correctly pull addresses from the

10.200.0.0/24

pool.

Ensures the expanded address range is active and functioning as expected.

Key Concept

VPC Subnet Primary CIDR Range Expansion Rules and Procedure

Question

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Topics

More questions from this topic