Google Cloud Architect: Networking

Networking on the Google Professional Cloud Architect exam is a design problem that spans VPC structure, Shared VPC, routing, peering, load balancing, firewalls, Private Service Connect, container and serverless connectivity, hybrid links, and multicloud integration. The exam guide places networking inside both solution design and infrastructure provisioning, which means candidates must choose a topology and then understand how it behaves operationally.

Use cloud networking fundamentals as the baseline for VPCs, subnets, routing, peering, and gateways. The PCA level adds enterprise ownership, service exposure, failure behavior, and migration constraints. The right answer is usually the architecture that meets the requirement with the smallest amount of avoidable operational complexity.

A good mental model starts with traffic intent: who needs to communicate, across which administrative boundary, with what latency and availability, through which security controls, and under whose operational ownership.

VPC design begins with ownership and address strategy

Google Cloud VPC networks are global, while subnets are regional. That difference matters when designing multi-region workloads and centralized network administration. Decide which teams own network resources, how address ranges are allocated, whether Shared VPC is appropriate, and how projects attach to shared services.

Address planning needs room for growth, hybrid routing, container ranges, managed-service connectivity, and acquisitions or reorganizations. Overlapping address space can turn an otherwise simple migration or peering plan into a long remediation project.

Shared VPC separates workload projects from network administration

Shared VPC is useful when a central network team should manage VPCs, subnets, routes, and related policy while application teams deploy workloads in service projects. This can reduce duplication and help enforce consistent connectivity patterns, but it also creates dependencies on the host project and the central operating process.

Architects should define who can attach projects, use subnets, change firewall rules, and alter routes. Centralization without a clear service model can become a bottleneck, while complete decentralization can create inconsistent address and security decisions.

Choose connectivity by the relationship between networks

Peering, Private Service Connect, VPN, Cloud Interconnect, and other connectivity options solve different problems. Peering creates network-to-network connectivity with specific routing characteristics. Private Service Connect exposes services privately without treating two entire VPCs as one trust domain. VPN offers encrypted connectivity over public networks, while Interconnect provides dedicated connectivity patterns for hybrid environments.

Cloud networking models across AWS, Azure, and Google Cloud expose important provider differences, but exam decisions should remain Google-specific. Match the mechanism to trust, scale, bandwidth, latency, route exchange, and operational ownership.

Hybrid architecture requires routing and failure behavior to be explicit

A hybrid link is not complete when a tunnel or circuit comes up. The architect must understand route advertisement, path preference, redundancy, failover, asymmetric-routing risks, DNS dependencies, and what applications do when one path fails. Migration periods often require old and new environments to coexist, increasing the number of possible paths.

Plan how the network transitions over time. Temporary routes, dual connectivity, and split services should have removal conditions so the migration does not leave permanent complexity behind.

Service exposure and load balancing belong in the topology

Google Cloud load balancing choices, internal versus external reachability, and Private Service Connect all affect the trust boundary around an application. Select based on who the client is, where the service lives, protocol and performance needs, and whether the architecture should expose a network or only a service endpoint.

Health checks and failure domains also matter. A load balancer can only improve availability if healthy backends exist in the right places and dependencies behind those backends can tolerate the same failure. High availability is a system property, not a front-end feature.

Firewall policy should reflect hierarchy and traffic intent

The current exam guide includes firewalls and hierarchical firewall policy. Central policies can enforce organization-wide controls, while lower-level rules handle workload-specific needs. The architecture should make default behavior, exception ownership, logging, and change review clear.

Avoid using broad allow rules as a shortcut for uncertain dependencies. Map the required flows, apply the narrowest rules that work, and use logging or telemetry to validate that legitimate traffic is not being blocked and unexpected paths are not being opened.

GKE and serverless networking change the data path

Container and serverless platforms introduce additional network layers. GKE design can involve pod and service ranges, load balancing, ingress, egress, and policy. Serverless workloads may need controlled access to VPC resources or private services. These paths should be part of the architecture diagram rather than left for implementation teams to discover.

The PCA exam rewards knowing when platform-managed networking removes work and when it adds a boundary that must be designed. Follow the packet and the identity from client to dependency instead of assuming that “managed” means “networking disappears.”

Observability and troubleshooting should be designed with the network

For every important path, identify what evidence proves it works: route visibility, firewall logs, flow data, load-balancer health, DNS answers, connectivity tests, application telemetry, and hybrid-link state. Without that evidence, a complex topology can be correct but operationally opaque.

Use PCA scenario-based preparation to practice choosing the smallest test that distinguishes routing, policy, DNS, service exposure, and application failures. The architect’s job includes making those failures diagnosable by the team that will operate the system.

Cost is also part of network design. Inter-region traffic, internet egress, hybrid links, load balancing, inspection, and cross-zone patterns can materially affect the bill. Architects should know which traffic paths are expected at steady state and during failover so that a design does not meet latency and resilience goals while quietly violating cost constraints.

DNS deserves architectural treatment because many hybrid and private-service failures appear first as name-resolution problems. Define which resolvers answer which zones, how on-premises and cloud names are forwarded, how private records are associated with networks, and what happens during migration when old and new environments both serve names. A clean routing diagram can still fail in production if clients resolve the wrong endpoint.

Network design should also account for platform limits and quotas. The current exam guide explicitly calls out flexibility, scalability, and quotas in solution design. Large Shared VPC, load-balancing, NAT, or hybrid architectures can hit scale boundaries that were irrelevant in a proof of concept. Capacity reviews should include address ranges, route count, connection scale, throughput, health-check behavior, and expected growth.

Private service consumption needs a deliberate trust model. If an application should consume a service without gaining broad network reachability, a service-oriented mechanism can be preferable to connecting entire networks. Conversely, if many services share a stable trust relationship and routing domain, a network-to-network pattern may be simpler. Choose based on the relationship you intend to create, not only the easiest initial configuration.

Operational ownership should be visible in the topology. A central team may own Shared VPC, interconnect, DNS, and firewall hierarchy while application teams own load balancers or service endpoints. Document those boundaries so incident responders know who can change which layer. This becomes especially important when a service outage crosses project or organizational teams.

During architecture review, trace both the normal and failure path. If a primary link, zone, backend, or resolver fails, which route or endpoint becomes active, and will security policy still permit the alternate path? Failover that has never been evaluated end-to-end can create an outage precisely when redundancy is expected to help.

NAT and egress design deserve attention because many private workloads still need controlled outbound connectivity. Define whether workloads receive public addresses, use centralized or regional NAT, require fixed source addresses, or must traverse inspection. The egress model affects security, logging, cost, scale, and how external systems allowlist traffic.

Private Google access and managed-service connectivity should also be planned from the workload perspective. A subnet without public IPs can still need access to Google APIs, managed databases, or internal services. Map those paths explicitly and confirm DNS, routes, service endpoints, and policy support the intended private access pattern.

Multi-region networking adds a second layer of failure design. Decide how clients reach the healthy region, how stateful dependencies move, whether address or DNS changes are required, and whether the alternate path has the same inspection and firewall behavior. A network failover that bypasses security or depends on an untested DNS assumption is not a complete resilience design.

Architecture choices should also consider administrative blast radius. A route, DNS, firewall, NAT, or shared-network change made at a central layer can affect many service projects at once. Use change controls, staged validation, and clear rollback for shared components, while allowing lower-risk workload changes to remain delegated. This balance keeps the network consistent without forcing every application change through a central bottleneck.

Finally, document the intended traffic path in both directions. Asymmetric paths can appear through hybrid routing, multiple egress points, inspection appliances, or failover mechanisms and can break stateful controls even when each individual route looks valid. A packet-path review should cover forward and return routing, DNS, policy, load balancing, and any address translation that changes the observed source or destination.

Network documentation should include the operational source of truth for routes, firewall policy, DNS zones, load-balancer configuration, and hybrid connectivity. If different teams maintain conflicting diagrams or tools, troubleshooting time expands because responders first have to discover which representation is current.