13.1 Networking Operations: Subnets, Static IPs, Cloud DNS & Cloud NAT

Why This Topic Matters on the Exam

Domain 4, "Ensuring successful operation of a cloud solution," is worth 20% of the ACE exam, and networking day-2 operations are one of its most concrete, gcloud-command-heavy corners. You already learned how to plan networks (Chapter 5) and deploy VPCs, subnets, and firewall rules (Chapter 10). This section is about keeping a running network healthy: growing a subnet that is running out of addresses, giving a resource a stable IP it will not lose on reboot, resolving names for internal services, and letting private VMs reach the internet without ever getting a public IP. Expect scenario questions that describe a symptom ("engineers can no longer create VMs — no free IPs" or "a partner needs a fixed IP to allowlist") and ask which single operation fixes it.

Expanding an Existing Subnet

A subnet (subnetwork) is a regional resource that carves a range of internal IP addresses out of a global VPC network. Subnets are created with a primary IPv4 CIDR range (e.g., 10.0.1.0/24 = 256 addresses) and, optionally, one or more secondary ranges used for alias IPs — most commonly GKE Pod and Service ranges in VPC-native clusters.

When a subnet runs out of usable addresses, you do not need to delete and recreate it. Google Cloud supports expanding a subnet's primary IP range in place, with zero downtime for existing resources:

gcloud compute networks subnets expand-ip-range SUBNET_NAME \
  --region=REGION \
  --prefix-length=NEW_PREFIX_LENGTH

Key rules the exam tests:

• You can only increase the range (make the prefix length smaller — e.g., /24 → /22). You cannot shrink a subnet's range.
• The new, larger range must not overlap any other subnet's primary or secondary range in the same network, including ranges reserved (but unused) for future subnets.
• Existing VMs keep their current IPs; the operation only grows the pool of available addresses for new resources.
• This works for both auto mode and custom mode VPC networks, but auto-mode subnets already use large predefined ranges per region, so custom mode is where you will use this in practice.

Common trap: a candidate assumes they must delete the subnet, which would delete every resource's IP assignment and cause an outage. The exam guide explicitly lists "expanding a subnet's IP range" as a distinct, non-disruptive operation.

Reserving Static IP Addresses

By default, a Compute Engine VM's external IP is ephemeral — Google assigns one from a shared pool, and it changes (or disappears) if you stop and restart the VM. An internal IP is normally static for the life of the VM but is still released if the VM is deleted.

A static IP address is one you explicitly reserve so it stays yours until you release it:

• Static external IP — reserve with gcloud compute addresses create, then assign it to a new VM or promote an existing ephemeral IP to static. Needed when an external system (DNS record, partner firewall allowlist, API client) must always reach the same address.
• Static internal IP — reserve a specific address inside a subnet's range so a resource (e.g., a database VM other services depend on by IP) never changes, even across recreation.
• Regional vs. global: addresses used by regional resources (VMs, regional load balancers) are regional; addresses for global external HTTP(S) load balancers are global.

Cost trap the exam loves: a reserved static external IP address that is not attached to a running resource is billed at an hourly rate — the opposite of what most candidates assume. An in-use static IP attached to a running VM is typically free (standard tier); it is the idle, reserved-but-unattached address that costs money. A scenario describing "unexpected charges for IP addresses that aren't attached to anything" is testing this exact rule — the fix is to release the unused reservation.

Cloud DNS

Cloud DNS is Google's managed, authoritative DNS service, offering 100% uptime SLA and global anycast serving.

Cloud DNS supports standard record types (A, AAAA, CNAME, MX, TXT, NS, SOA, SRV) managed via the console, gcloud dns record-sets, or transactions for atomic multi-record changes.

Exam scenario: "A private zone must resolve payroll.corp.internal only for VMs inside vpc-prod, and on-premises engineers connected via Cloud VPN also need to resolve it." → Create a private managed zone visible to vpc-prod, then configure inbound server policy / forwarding so the on-prem resolver can query Cloud DNS over the VPN tunnel.

Cloud NAT

Cloud NAT (Network Address Translation) is a fully managed, software-defined, distributed service that gives Compute Engine VMs, GKE Pods, and other private resources outbound internet connectivity without an external IP address on each resource.

Requirements and behavior to know cold for the exam:

• A Cloud NAT gateway is always attached to a Cloud Router in the same region and network — the router holds the NAT gateway's configuration (you do not need BGP/dynamic routing for NAT-only use).
• NAT IP addresses and ports can be allocated automatically (Google manages a pool) or manually (you assign specific reserved static external IPs — useful when a downstream service needs to allowlist your outbound IP range).
• Cloud NAT is regional — you must configure a NAT gateway in every region where private resources need outbound access, and you scope it to specific subnets/IP ranges or the whole network.
• Cloud NAT supports address translation for established inbound response packets only — it never allows new, unsolicited inbound connections. If you need inbound access, that is a load balancer or firewall rule with an external IP, not NAT.
• Port allocation is per-VM (a default minimum ports-per-VM setting, tunable upward for VMs that open many concurrent connections), and idle/established connections eventually time out.

Exam scenario: "A tier of backend VMs has no external IPs (per security policy) but must call a third-party payment API over HTTPS and download OS security patches." → Attach a Cloud NAT gateway (via a Cloud Router) in that subnet's region. This is one of the most frequently tested single-answer scenarios on the real exam.

Quick Decision Table