Managing VPC Networking: Subnets, Static IPs, Cloud DNS, and Cloud NAT

You resize a subnet by expanding its primary IPv4 range with a single command — and expansion is the only direction allowed. Google Cloud lets you decrease the prefix length (a /24 can become a /20), which adds addresses, but you can never increase it to shrink the range, because addresses already assigned inside it could become invalid. The command is:

gcloud compute networks subnets expand-ip-range web-subnet \
  --region=us-central1 \
  --prefix-length=20

The expansion happens in place with no downtime — existing VMs keep their addresses and the subnet simply gains room. The new, larger range must not overlap the primary or secondary range of any other subnet in the VPC network, or any range in a peered network or on-premises network connected over VPN or Interconnect. Plan expansions so the grown CIDR still fits your address plan.

Two constraints show up as exam discriminators. First, subnets that were auto-created in an auto mode VPC start at /20 and can only be expanded as far as /16; converting the network to custom mode removes that ceiling. Second, if you truly need a smaller range, there is no shrink operation — the answer is to create a new subnet with the desired range, migrate workloads, and delete the old one. When a question says a subnet is running out of IPs and workloads must keep running, expand-ip-range is the answer; recreating the subnet is the distractor.

You reserve a static IP address so an endpoint keeps the same address across instance stops, restarts, and re-creations — ephemeral addresses are released whenever the resource stops or is deleted. Google Cloud has two kinds, reserved with the same command family:

For an external address used by a global external Application Load Balancer, add --global; VMs and regional forwarding rules use regional addresses. To keep an address a running VM already has, promote the ephemeral address: pass the in-use address to --addresses and it becomes static without any interruption — the exam's answer to "the team whitelisted our VM's IP and we must not lose it."

Operationally, remember that external IPv4 addresses are billed, and a reserved external address that is not attached to anything bills at a higher rate than one in use — release addresses you no longer need with gcloud compute addresses delete. Internal static addresses simply consume an address from the subnet range. Assign a reserved external address at creation with gcloud compute instances create ... --address=app-ip.

You add a custom static route when the system-generated routes are not enough — typically to send traffic for a destination range through a network virtual appliance, a VPN tunnel, or an internal load balancer, or to give a specific route to the internet gateway. Every VPC already has subnet routes (one per subnet range, created automatically) and usually a default route (0.0.0.0/0 to the default internet gateway). Custom static routes layer on top:

gcloud compute routes create to-onprem \
  --network=prod-vpc \
  --destination-range=192.168.0.0/16 \
  --next-hop-vpn-tunnel=onprem-tunnel \
  --next-hop-vpn-tunnel-region=us-central1 \
  --priority=100

The next hop can be --next-hop-gateway=default-internet-gateway, --next-hop-instance (an appliance VM, which must have IP forwarding enabled at creation with --can-ip-forward), --next-hop-address (an internal IP), --next-hop-ilb (an internal passthrough load balancer, the pattern for highly available appliances), or a VPN tunnel. You can scope a route to only some VMs with --tags, so only tagged instances use it.

Route selection follows two rules the exam loves. First, most specific destination wins: a /24 route beats a /16 for addresses in both. Second, among routes with the same destination, lower priority value wins (priorities run 0 to 65535, default 1000). And one rule outranks everything: subnet routes can never be overridden by a custom route — you cannot create a static route that hijacks traffic destined for a subnet's own range. Dynamic routes learned by Cloud Router via BGP sit alongside static ones and compete under the same specificity-then-priority logic.

Cloud DNS is Google Cloud's managed, authoritative DNS service, and the operational unit is the managed zone — a container for the records of a DNS suffix. A public zone answers queries from the internet for a domain you own; a private zone answers only queries that originate from the VPC networks you authorize, which is how you give internal services friendly names like db.corp.internal without exposing them.

gcloud dns managed-zones create corp-internal \
  --dns-name=corp.internal. \
  --description="Internal names" \
  --visibility=private \
  --networks=prod-vpc

Omit --visibility (or set public) for a public zone; after creating one you must delegate the domain by pointing your registrar at the Google name servers listed on the zone. Records live in record sets — a name, a type (A, AAAA, CNAME, MX, TXT, and so on), a TTL, and one or more values:

gcloud dns record-sets create www.example.com. \
  --zone=example-public \
  --type=A --ttl=300 \
  --rrdatas=203.0.113.10

Matching update and delete commands manage the lifecycle, and the older transaction workflow (gcloud dns record-sets transaction start/add/execute) batches multiple changes atomically. Beyond plain zones, know the supporting pieces at name-drop depth: forwarding zones send queries for a suffix to on-premises DNS servers, peering zones let one VPC resolve using another VPC's Cloud DNS configuration, and Cloud DNS also offers split-horizon setups where a private zone shadows a public name with internal answers. If a scenario says VMs in a VPC must resolve internal names that the internet must never see, the answer is a private zone attached to that network.

Cloud NAT gives VMs (and GKE nodes, and other private resources) outbound internet access without external IP addresses — the standard fix when private instances need to pull OS patches, container images, or external APIs while remaining unreachable from the internet. It is a fully managed, software-defined service: there is no NAT appliance VM to size, patch, or fail over, and it performs source NAT for egress only — it never admits unsolicited inbound connections, so your instances stay private.

Cloud NAT is configured on a Cloud Router in the same region and VPC network as the instances it serves:

gcloud compute routers create nat-router \
  --network=prod-vpc --region=us-central1

gcloud compute routers nats create prod-nat \
  --router=nat-router --region=us-central1 \
  --auto-allocate-nat-external-ips \
  --nat-all-subnet-ip-ranges

The two decisions in that command matter. NAT IP allocation is either automatic (Google adds and removes external IPs as demand grows) or manual (--nat-external-ip-pool with reserved static addresses — choose this when a partner must allowlist your egress IPs, a recurring exam scenario). Scope is either all subnet ranges in the region or specific subnets and ranges. Instances still need a route to the internet gateway (the default route suffices) and, for a fully private posture, teams commonly pair Cloud NAT with Private Google Access, the per-subnet setting that lets internal-only VMs reach Google APIs and services without traversing NAT at all.

Gotchas: Cloud NAT is regional — one gateway does not serve VMs in another region; a VM that has its own external IP bypasses NAT entirely; and each NAT IP supports a limited number of concurrent connections per VM governed by allocated ports, so sustained port-exhaustion errors are solved by adding NAT IPs or raising minimum ports per VM. NAT logging can record translation and drop events into Cloud Logging for troubleshooting.

VPC firewall rules control which connections may reach or leave your instances, and managing them is routine day-2 work. Rules are defined at the network level but enforced per instance, and connection tracking is stateful — allow the inbound request and the response is automatically allowed back. Every VPC carries two implied rules you cannot delete: allow all egress and deny all ingress, both at the lowest priority (65535), so any traffic you want to admit needs an explicit allow rule.

gcloud compute firewall-rules create allow-web \
  --network=prod-vpc \
  --direction=INGRESS --action=ALLOW \
  --rules=tcp:80,tcp:443 \
  --source-ranges=0.0.0.0/0 \
  --target-tags=web

Each rule has a direction (ingress or egress), an action (allow or deny), a protocol and port list, a source or destination filter, a priority from 0 to 65535 where the lower number wins (default 1000), and a target — all instances in the network, instances with a network tag, or instances running as a service account. Service-account targeting is the more robust choice because changing a VM's tags takes only compute.instances.setTags permission, while changing its service account is a tightly controlled operation.

Operational habits the exam rewards: scope source ranges tightly instead of 0.0.0.0/0 wherever possible; use a higher-priority deny rule to carve exceptions out of a broader allow; enable Firewall Rules Logging (--enable-logging) on a rule to record the connections it allows or denies when debugging why traffic is blocked — noting that the implied rules cannot log, so create an explicit low-priority deny rule if you need to see denied traffic. To answer "why can't I SSH to this VM," check that an ingress allow for tcp:22 exists, matches the VM's tags or service account, and is not shadowed by a higher-priority deny.

Cloud NGFW (Next Generation Firewall) is the evolution of Google Cloud's firewalling into policy-based management: instead of individual rules attached to one network, you build firewall policies — containers of rules — and associate them where they should apply. There are three kinds. Hierarchical firewall policies attach to an organization or folder and cascade to every VPC beneath, letting a security team enforce non-negotiable rules (for example, always allow the health-check ranges, always deny a known-bad range) that project teams cannot override. Global network firewall policies and regional network firewall policies attach to a single VPC network, either everywhere or in one region.

Evaluation order is the exam-relevant mechanic: hierarchical policies evaluate first, top-down — organization, then folder — and only if they neither allow nor deny does evaluation continue to the VPC's own rules: by default the classic per-network VPC firewall rules, then the global network firewall policy, then regional policies. A hierarchical rule can also explicitly delegate a decision downward with a goto_next action. The practical consequence: a hierarchical deny can never be undone by a project-level allow, which is exactly the guarantee central security teams want.

Cloud NGFW also modernizes targeting and inspection. Policy rules can match on secure tags (IAM-governed resource tags, stronger than freeform network tags), FQDN and geolocation objects, and Google-maintained threat-intelligence lists. The service is tiered — NGFW Essentials covers the policy model, NGFW Standard adds the richer matching objects, and NGFW Enterprise adds intrusion prevention with TLS inspection for deep packet inspection. At associate depth: know the three policy attachment points, that hierarchical wins first, and that NGFW policies coexist with (and are evaluated around) classic VPC firewall rules.

Tie the tasks together with a scenario the exam could lift verbatim. Your team runs a fleet of internal-only VMs (no external IPs) in app-subnet, a /24 in us-central1 on prod-vpc. Three problems arrive at once: the managed instance group cannot scale because the subnet is out of addresses; the VMs fail to download OS security updates; and a partner needs to allowlist the fixed IP your traffic will come from.

Work them in order. First, the address shortage: gcloud compute networks subnets expand-ip-range app-subnet --region=us-central1 --prefix-length=22 quadruples the space in place, with no downtime and no changes to running VMs — verifying first that 10.x.x.x/22 collides with no other subnet or on-premises range. Second, the failed updates: the VMs have no external IPs and therefore no internet path, so create a Cloud Router and a Cloud NAT gateway in us-central1 on prod-vpc. Third, the allowlist: reserve a static external IP and configure the NAT gateway with manual NAT IP allocation pointing at it, so egress always presents that address — automatic allocation would hand Google-chosen addresses that can change as capacity scales.

Finish with the guardrails: an ingress firewall rule allowing only the load balancer and health-check ranges to reach the fleet's service account, Firewall Rules Logging enabled while you verify, and a private Cloud DNS zone so other internal services reach the fleet by name rather than by addresses that the expansion may reshuffle over time. Every step is a gcloud command against live infrastructure with zero rebuilds — which is precisely what this exam topic is checking you can do.