GCP Associate Cloud Engineer Practice Question 8: Expand Subnet IP Range
Google Cloud Associate Cloud Engineer · Test 1 · question 8 of 10
A subnet named prod-us-east1 in a custom-mode VPC has the primary IPv4 range 10.10.0.0/24 and is almost out of addresses. Roughly 200 VMs are running in it and serving production traffic. You must make several thousand more addresses available to instances in that subnet. Existing VMs must keep their current internal IP addresses and must not be restarted, and the change must not interrupt subnet traffic.
What should you do?
Show answer and explanation
Answer:
A subnet's primary IPv4 range can be expanded in place by supplying a *smaller* prefix length, here /24 to /20, taking the subnet from 256 to 4096 addresses. Expansion is non-disruptive: existing instances keep their assigned internal addresses, no restart is required, and traffic within the subnet is not interrupted. The one thing to know going in is that the operation is one-way, a primary range can never be shrunk again, and the expanded range must not overlap any other subnet range in the VPC or its peers.
Option A works around the problem instead of solving it. A VM's internal IP comes from the subnet its network interface is attached to, so moving instances to a different subnet means recreating them with new addresses, precisely what the stem rules out.
Option B is the most disruptive choice available. A subnet cannot be deleted while resources use it, so every VM would have to be destroyed first, taking production down and changing every internal IP.
Option C misapplies secondary ranges. A secondary IPv4 range is used for alias IP ranges, most commonly GKE Pod and Service ranges, and is not drawn on for the primary internal address of a VM network interface, so it does not relieve exhaustion of the primary range.
Reference: Create and modify VPC networks