Google Cloud PCA Study Guide
Section 2: Networking and Connectivity
Service selection guide focused on why an organization would choose each network option
PCA study frame For PCA-style networking questions, the right answer usually comes from matching the business requirement to the network pattern: centralized control, private service access, outbound-only egress, hybrid connectivity, global delivery, or troubleshooting. Most wrong answers confuse DNS, routing, firewall policy, and service exposure. |
Services and Concepts Covered
Core VPC and private access | Hybrid / multicloud | Edge, DNS, security, and troubleshooting |
|---|---|---|
VPC | Cloud Router | Cloud Load Balancing |
Subnets | Cloud VPN | External HTTP(S) / Application Load Balancer |
Routes | HA VPN | Internal Load Balancer |
Firewall rules | Classic VPN | SSL Proxy / TCP Proxy Load Balancing |
Hierarchical firewall policies | Cloud Interconnect | Cloud DNS |
Shared VPC | Dedicated Interconnect | Cloud DNS private zones / forwarding |
Service projects | Partner Interconnect | Cloud CDN |
VPC Network Peering | Network Connectivity Center / NCC | Media CDN |
Private Service Connect / PSC | Hybrid networking patterns | Cloud Armor |
Private Google Access | Multicloud networking patterns | Network Intelligence Center |
Cloud NAT | Connectivity Tests | |
Firewall Insights | ||
Cloud IDS | ||
Container networking |
Fast PCA Decision Matrix
Use this table when a practice question gives you a business requirement and asks what the architect should recommend.
If the organization needs... | Likely PCA answer |
|---|---|
Need the main private network foundation for Google Cloud workloads | VPC |
Need regional IP segmentation and capacity planning | Subnets |
Need packet steering to default internet, VPN, Interconnect, or appliances | Routes |
Need workload-level packet allow/deny controls | Firewall rules |
Need centralized org/folder-level network guardrails | Hierarchical firewall policies |
Need centralized network control with app teams in separate projects | Shared VPC |
Need two VPCs to communicate privately, non-transitively | VPC Network Peering |
Need private access to Google/third-party/producer services | Private Service Connect |
Private VMs need Google APIs without external IPs | Private Google Access |
Private VMs/GKE nodes need outbound internet without public IPs | Cloud NAT |
Need dynamic BGP routing for VPN/Interconnect | Cloud Router |
Need encrypted lower-volume hybrid connectivity over the internet | Cloud VPN / HA VPN |
Need private high-bandwidth, low-latency enterprise connectivity | Cloud Interconnect |
Need provider-managed private connectivity to Google | Partner Interconnect |
Need hub-and-spoke connectivity across many sites/VPCs/clouds | Network Connectivity Center |
Need public web/API frontend with L7 routing, Armor, or CDN | External HTTP(S) / Application Load Balancer |
Need private service frontend inside the VPC | Internal Load Balancer |
Need private/internal DNS or hybrid name resolution | Cloud DNS private zones / forwarding |
Need global caching for static/cacheable web content | Cloud CDN |
Need video/large media/high-throughput distribution | Media CDN |
Need WAF, DDoS, edge request filtering, geoblocking, rate limiting | Cloud Armor |
Need to diagnose route/firewall reachability | Connectivity Tests |
Need to find stale or risky firewall rules | Firewall Insights |
Need managed intrusion detection for network traffic | Cloud IDS |
Service Deep Dives
Each card is written in PCA language: what the service/concept is, why an organization would use it, the exam trigger, and the common wrong turn.
Core VPC design
VPC (Virtual Private Cloud) What it is: The global, software-defined private network foundation for Google Cloud resources. Why an organization would use it: Use VPC to isolate workloads, define IP space, place regional subnets, control routing, attach firewall policy, and connect services across regions. For PCA, VPC is the base design object for almost every enterprise architecture. PCA exam trigger: Private networking, workload isolation, subnet planning, custom routes, firewall control, hybrid connectivity, or centralized network architecture. Watch out: Do not think of a Google Cloud VPC as region-bound. The VPC is global, while subnets are regional. |
Subnets What it is: Regional IP ranges inside a VPC where resources receive internal addresses. Why an organization would use it: Use subnets to separate environments, regions, tiers, and IP ranges. Subnet planning matters for GKE pod/service ranges, hybrid routing, private access, and future growth. PCA exam trigger: Regional design, IP range planning, private workloads, GKE secondary ranges, or segmentation by environment/tier. Watch out: Do not create too-small ranges for workloads that will autoscale, especially GKE clusters or large VM fleets. |
Routes What it is: Rules that determine where network traffic is sent inside or outside a VPC. Why an organization would use it: Use routes to steer traffic to default internet gateways, VPNs, Interconnect, next-hop appliances, peering, or privately reachable networks. They are central to hybrid and hub-and-spoke troubleshooting. PCA exam trigger: Traffic is not reaching the right network, traffic must be forced through inspection, or hybrid networks need dynamic/custom routing. Watch out: Do not assume DNS or firewall changes create reachability. Routing, firewall, and DNS are separate layers. |
Firewall rules What it is: Stateful network rules that allow or deny traffic to Google Cloud resources. Why an organization would use it: Use firewall rules to enforce least-privilege network access between tiers, workloads, and external clients. They are commonly attached by tags, service accounts, IP ranges, protocols, and ports. PCA exam trigger: Allow only required ports, block broad access, enable app-to-db tier traffic, or troubleshoot connectivity that routing says should work. Watch out: Do not confuse IAM with firewall rules. IAM controls who can manage or use resources. Firewalls control packets. |
Hierarchical firewall policies What it is: Firewall policies enforced at organization or folder level instead of only at a VPC. Why an organization would use it: Use hierarchical firewall policies when a central security/network team needs consistent guardrails across many projects and VPCs. They help enforce enterprise-wide network controls without relying on every project team to configure rules correctly. PCA exam trigger: Centralized security policy, org-wide deny/allow rules, folder-level governance, or enforcing consistent network controls across projects. Watch out: Do not use only project-level firewall rules when the requirement says central governance or organization-wide enforcement. |
Shared and private connectivity
Shared VPC What it is: A model where a host project shares VPC networks and subnets with service projects. Why an organization would use it: Use Shared VPC so a central networking team controls network design, routes, firewall policy, and subnets while application teams deploy resources in separate service projects. This is a major enterprise governance pattern. PCA exam trigger: Central network administration, many app teams/projects, separation of duties, shared network with decentralized workload ownership. Watch out: Do not use VPC Peering just to centralize network administration. Shared VPC is built for centralized control with service projects. |
Service projects What it is: Projects attached to a Shared VPC host project that consume shared network resources. Why an organization would use it: Use service projects to let application teams own compute, GKE, serverless, and other resources while consuming centrally governed network subnets from the host project. PCA exam trigger: App teams need separate projects for IAM/billing/lifecycle, but network teams must control subnets and firewall policy. Watch out: Do not forget that workload resources live in service projects while the network lives in the host project. |
VPC Network Peering What it is: Private connectivity between two VPC networks using internal IP addresses. Why an organization would use it: Use VPC Peering when two VPCs need private communication without public IPs, VPNs, or internet traversal. It is useful for direct private connectivity between separate networks, projects, organizations, or service producer/consumer patterns. PCA exam trigger: Two VPCs need private communication, but the question does not require centralized control or transitive routing. Watch out: Peering is not transitive. If A peers with B and B peers with C, A does not automatically reach C through B. |
Private Service Connect / PSC What it is: Private, endpoint-based access to Google APIs, managed services, or producer services from inside a VPC. Why an organization would use it: Use PSC when consumers need private access to services without exposing traffic to the public internet and without tightly coupling entire networks. It is common for private access to Google services, third-party services, producer services, and managed service endpoints. PCA exam trigger: Privately consume Google/third-party/producer services, avoid public exposure, simplify service access, or publish a private service to consumers. Watch out: Do not assume PSC is the same as VPC Peering. PSC is service-oriented/private endpoint connectivity, while peering connects networks. |
Private Google Access What it is: Allows VMs without external IPs to reach supported Google APIs and services using internal/private paths. Why an organization would use it: Use it when private VMs need to access services like Cloud Storage, BigQuery, or Artifact Registry without assigning external IP addresses. It supports security requirements that remove public IPs from workloads. PCA exam trigger: A VM has no external IP but must reach Google APIs/services. Security wants private instances and no public internet exposure. Watch out: Do not use Cloud NAT for private access to Google APIs when the requirement is specifically private Google API access. NAT is for outbound internet access. |
Cloud NAT What it is: Managed outbound NAT for resources without external IP addresses. Why an organization would use it: Use Cloud NAT when private VMs or GKE nodes need outbound internet access for updates, package downloads, container pulls, APIs, or egress to external services without exposing inbound access. PCA exam trigger: Private instances need outbound internet but must not have external IPs or accept inbound connections. Watch out: Cloud NAT does not allow inbound connections from the internet. It is outbound-only NAT. |
Hybrid and multicloud connectivity
Cloud Router What it is: A managed BGP service that dynamically exchanges routes between VPCs and external networks. Why an organization would use it: Use Cloud Router with HA VPN, Cloud Interconnect, and router appliances to avoid static route management and automatically adapt to topology changes. It is the routing brain for most production hybrid designs. PCA exam trigger: Dynamic routing, BGP, VPN/Interconnect route exchange, failover, or avoiding manual static route updates. Watch out: Cloud Router does not forward data traffic. It exchanges routes; the VPN, Interconnect, or appliance carries traffic. |
Cloud VPN What it is: IPsec VPN connectivity between Google Cloud and on-premises, another cloud, or another network over the public internet. Why an organization would use it: Use Cloud VPN for encrypted hybrid connectivity when dedicated private connectivity is not required or not yet available. It is common for lower-volume, quick-to-deploy, or backup connectivity scenarios. PCA exam trigger: Encrypted connection over the internet, lower-cost hybrid connectivity, backup link, or fast connectivity setup. Watch out: Do not pick VPN for large predictable bandwidth, strict latency, or high-throughput enterprise connectivity when Interconnect is the better fit. |
HA VPN What it is: The high-availability Cloud VPN option using redundant interfaces and dynamic routing. Why an organization would use it: Use HA VPN for production-grade VPN connectivity with redundancy and BGP. It is the preferred VPN answer when the question mentions availability, SLA, or resilient hybrid connectivity. PCA exam trigger: Production VPN, 99.99% availability design, redundant tunnels, BGP, or dynamic route failover. Watch out: Do not choose Classic VPN for new production architecture when HA VPN is available and availability matters. |
Classic VPN What it is: Older Cloud VPN model with more limited availability and routing patterns. Why an organization would use it: Know it mostly as a legacy or lower-priority option. An organization may still have it for older environments, but PCA questions usually prefer HA VPN for resilient designs. PCA exam trigger: Legacy/static VPN scenario or recognizing that HA VPN is the modern recommended answer for production. Watch out: Do not pick Classic VPN for high-availability requirements. |
Cloud Interconnect What it is: Private connectivity that extends an external network to Google over high-availability, low-latency links. Why an organization would use it: Use Cloud Interconnect when an organization needs reliable, high-bandwidth, private connectivity between on-premises or colocation networks and Google Cloud. It is often chosen for predictable traffic, lower latency, compliance, or high-volume migration/data transfer. PCA exam trigger: High bandwidth, low latency, private enterprise connectivity, predictable hybrid traffic, or avoiding internet-based VPN for primary connectivity. Watch out: Do not pick Interconnect for quick, low-volume, temporary connectivity when VPN is enough. |
Dedicated Interconnect What it is: A direct physical connection between the organization network and Google. Why an organization would use it: Use Dedicated Interconnect when the organization needs direct physical connectivity, high capacity, and has the ability to connect at a supported colocation facility. PCA exam trigger: Direct physical link, large enterprise bandwidth, colocation presence, or maximum control over the connection to Google. Watch out: Do not choose Dedicated Interconnect if the customer cannot access a supported colocation facility or wants a provider-managed option. |
Partner Interconnect What it is: Private connectivity to Google through a supported service provider. Why an organization would use it: Use Partner Interconnect when an organization wants private connectivity but does not want or cannot support direct physical connectivity to Google. The provider handles part of the connectivity path. PCA exam trigger: Private connectivity through a carrier/service provider, no direct colocation with Google, or smaller/private enterprise connection needs. Watch out: Do not choose Partner Interconnect when the requirement explicitly says direct physical connection to Google. |
Network Connectivity Center / NCC What it is: A hub-and-spoke framework for connecting VPCs, on-premises networks, branch sites, and other networks. Why an organization would use it: Use NCC to simplify complex hybrid and multicloud topologies. It helps centralize connectivity management when many sites, VPCs, VPNs, Interconnects, or router appliances need to participate in a broader network design. PCA exam trigger: Hub-and-spoke network design, many branches/sites/VPCs, full-mesh style connectivity, or centralized hybrid/multicloud connectivity management. Watch out: Do not overuse one-off peering/VPN links when the scenario clearly describes a large hub-and-spoke enterprise network. |
Load balancing and edge delivery
Cloud Load Balancing What it is: Google Cloud managed load balancing for distributing traffic to backends using internal or external IPs. Why an organization would use it: Use Cloud Load Balancing to provide a stable frontend, distribute traffic, perform health-based routing, support global or regional architectures, and integrate with Cloud Armor, Cloud CDN, serverless, GKE, MIGs, and hybrid backends. PCA exam trigger: High availability, autoscaled backends, health checks, global users, internal tier balancing, serverless/GKE/MIG frontend, or edge security/caching integration. Watch out: Do not treat all load balancers the same. PCA often tests global vs regional, external vs internal, and Layer 7 vs Layer 4. |
External HTTP(S) / Application Load Balancer What it is: Layer 7 external load balancing for HTTP and HTTPS applications. Why an organization would use it: Use it for internet-facing web apps, APIs, URL-based routing, TLS termination, global anycast frontend, Cloud Armor policies, CDN integration, and routing to MIGs, GKE, Cloud Run, App Engine, or functions. PCA exam trigger: Global web application, URL/path routing, HTTPS termination, WAF/CDN integration, or serverless/GKE/MIG web frontend. Watch out: Do not choose a TCP/UDP load balancer when the requirement is HTTP-specific routing or Layer 7 policy. |
Internal Load Balancer What it is: Private load balancing for traffic inside a VPC or connected networks. Why an organization would use it: Use internal load balancers when backend services should be reachable privately by internal clients, application tiers, hybrid clients, or service consumers without a public frontend. PCA exam trigger: Private app-to-app traffic, internal service frontend, database/app tier access, or no public exposure requirement. Watch out: Do not expose an external load balancer when the users are internal workloads only. |
SSL Proxy / TCP Proxy Load Balancing What it is: Proxy-based load balancing for non-HTTP TCP/SSL workloads. Why an organization would use it: Use these when the application is not HTTP but still benefits from Google-managed proxy load balancing, global frontend behavior, and TLS/TCP handling. PCA exam trigger: Non-HTTP global TCP/SSL service where application-level HTTP routing is not required. Watch out: Do not use HTTP(S) load balancing for protocols that are not HTTP/HTTPS. |
DNS and service discovery
Cloud DNS What it is: Google Cloud managed authoritative DNS for public and private zones. Why an organization would use it: Use Cloud DNS for highly available DNS management, public domain records, private internal name resolution, split-horizon designs, and hybrid name resolution with forwarding/peering patterns. PCA exam trigger: Managed DNS, private DNS, custom domain records, internal service resolution, or hybrid DNS integration. Watch out: Do not confuse DNS resolution with network reachability. DNS can point to a private IP, but routing/firewall must still allow traffic. |
Cloud DNS private zones / forwarding What it is: Private DNS zones and forwarding policies for internal and hybrid name resolution. Why an organization would use it: Use private zones to resolve internal service names only inside selected VPCs. Use forwarding/peering to integrate on-premises DNS with Google Cloud DNS for hybrid environments. PCA exam trigger: Private service names, hybrid DNS, on-prem-to-cloud resolution, cloud-to-on-prem resolution, or split-horizon DNS. Watch out: Do not fix a DNS problem with VPC Peering alone. Name resolution and network connectivity are separate. |
Load balancing and edge delivery
Cloud CDN What it is: Content delivery network integrated with Google Cloud load balancing. Why an organization would use it: Use Cloud CDN to cache static or cacheable content near users, reduce latency, offload origin traffic, and improve global web performance for content served through supported load balancers and backends. PCA exam trigger: Static content, global users, latency reduction, origin offload, cacheable assets, or web performance improvement. Watch out: Do not use CDN as a fix for dynamic personalized content that cannot be cached. |
Media CDN What it is: Specialized CDN for large-scale video, streaming, and high-throughput media delivery. Why an organization would use it: Use Media CDN when the organization is distributing video streams, large files, software downloads, or media workloads that need high throughput and large-scale edge delivery. PCA exam trigger: Video streaming, massive download distribution, media delivery, or high-throughput content distribution. Watch out: Do not choose Media CDN for a normal web app with standard static assets; Cloud CDN is usually the simpler answer. |
Network security and observability
Cloud Armor What it is: Edge security service for WAF rules, DDoS protection, rate limiting, and request filtering. Why an organization would use it: Use Cloud Armor to protect internet-facing applications behind supported load balancers. It is the PCA answer for blocking malicious traffic at the edge, geoblocking, IP allow/deny lists, bot/rate controls, and WAF-style policy. PCA exam trigger: Protect public web app, block OWASP-style attacks, DDoS mitigation, geoblocking, rate limiting, or edge security policy on load-balanced apps. Watch out: Do not rely only on VM firewalls for application-layer attacks. Use Cloud Armor at the load balancer edge. |
Network Intelligence Center What it is: A network observability and troubleshooting suite for Google Cloud networks. Why an organization would use it: Use it to troubleshoot, validate, visualize, and optimize network behavior. PCA questions may point to it when the architect needs to prove reachability, understand firewall behavior, or identify network configuration issues. PCA exam trigger: Troubleshoot routing/firewalls, validate connectivity, identify unused rules, or improve network observability. Watch out: Do not immediately change routes or firewalls without validating the path when the question asks for diagnosis. |
Connectivity Tests What it is: A Network Intelligence Center tool that analyzes whether traffic can flow from a source to a destination. Why an organization would use it: Use Connectivity Tests when the organization needs to verify if a packet should reach a destination based on routing, firewall rules, policies, and network configuration. PCA exam trigger: Troubleshoot why a VM, GKE node, load balancer, or hybrid endpoint cannot connect to another resource. Watch out: Do not guess whether firewall or routing is the issue. Connectivity Tests help identify the failing layer. |
Firewall Insights What it is: A Network Intelligence Center capability for analyzing firewall rule usage and risk. Why an organization would use it: Use Firewall Insights to find overly permissive, shadowed, unused, or misconfigured firewall rules. It supports cleanup and risk reduction in large environments. PCA exam trigger: Find stale firewall rules, reduce firewall risk, identify shadowed rules, or clean up network policy at scale. Watch out: Do not manually audit hundreds of rules when the requirement is scalable firewall optimization. |
Cloud IDS What it is: Managed intrusion detection service for inspecting mirrored network traffic. Why an organization would use it: Use Cloud IDS when the organization needs managed threat detection for network traffic without deploying and operating its own IDS appliances. PCA exam trigger: Intrusion detection, threat signatures, suspicious network traffic monitoring, or managed IDS requirement. Watch out: Do not confuse IDS with firewall enforcement. IDS detects; firewall/Armor/policies enforce blocking. |
Design patterns and exam concepts
Container networking What it is: The networking model for GKE pods, services, ingress/gateway, IP ranges, and network policies. Why an organization would use it: Understand it because GKE networking questions often combine VPC-native clusters, alias IPs, service exposure, private clusters, load balancers, NAT, DNS, and firewall rules. PCA exam trigger: GKE pods cannot reach services, private cluster design, exposing services, pod/service CIDR planning, ingress/gateway, or network policy. Watch out: Do not only think in VM networking terms. Pod IPs, service IPs, nodes, and load balancers all matter. |
Hybrid networking patterns What it is: Architectural patterns that connect Google Cloud with on-premises networks. Why an organization would use it: Use the pattern decision tree: VPN for encrypted lower-volume/quick setup, Interconnect for private high-bandwidth connectivity, Cloud Router for dynamic routing, NCC for large hub-and-spoke designs, and DNS forwarding for name resolution. PCA exam trigger: Connect data center to Google Cloud, route on-prem to cloud, private hybrid access, migration traffic, DR connectivity, or enterprise network modernization. Watch out: Do not pick a single product blindly. Hybrid questions usually require matching bandwidth, latency, availability, routing, DNS, and cost. |
Multicloud networking patterns What it is: Architectural patterns for connecting Google Cloud with other public clouds. Why an organization would use it: Use multicloud networking patterns when an organization runs workloads across clouds and needs private connectivity, consistent routing, service access, DNS design, or centralized connectivity management. Options may include VPN, Interconnect variants, NCC, PSC/service exposure patterns, and third-party appliances. PCA exam trigger: GCP-to-AWS/Azure connectivity, multicloud migration, shared services across clouds, or central network hub for multiple clouds. Watch out: Do not assume public internet access is acceptable when the scenario calls out private connectivity, compliance, or predictable performance. |
Common PCA Confusion Points
Confusion point | How to think about it |
|---|---|
Shared VPC vs VPC Peering | Shared VPC centralizes network ownership while service projects deploy workloads. VPC Peering privately connects separate VPCs but does not provide centralized network administration. |
VPC Peering vs Private Service Connect | Peering connects networks. PSC connects consumers privately to services/endpoints without exposing or coupling entire networks. |
Private Google Access vs Cloud NAT | Private Google Access is for private access from VMs to Google APIs/services. Cloud NAT is for outbound internet access from private resources. |
Cloud VPN vs Cloud Interconnect | VPN is encrypted over the public internet and good for lower-volume or quick setup. Interconnect is private, higher-bandwidth, lower-latency enterprise connectivity. |
HA VPN vs Classic VPN | HA VPN is the modern production answer with redundancy and BGP. Classic VPN is legacy/lower priority. |
Cloud Router vs Cloud NAT | Cloud Router exchanges routes with BGP. Cloud NAT provides outbound address translation. They solve different problems. |
External vs Internal Load Balancer | External load balancers face internet clients. Internal load balancers provide private service frontends inside VPCs or connected networks. |
Cloud CDN vs Media CDN | Cloud CDN is for normal web/static/cacheable content. Media CDN is for large-scale video, streaming, and high-throughput media delivery. |
Cloud Armor vs Firewall Rules | Cloud Armor protects at the edge and can filter Layer 7 web traffic. Firewall rules control packet access to resources in the VPC. |
Connectivity Tests vs Firewall Insights | Connectivity Tests validate a path from source to destination. Firewall Insights analyzes firewall rule usage, risk, and cleanup opportunities. |
Cram Summary
- Google Cloud VPCs are global; subnets are regional.
- Routing, firewall rules, and DNS are separate. Fixing one does not automatically fix the others.
- Shared VPC is the enterprise answer for centralized network control with app teams in separate projects.
- VPC Peering is private network-to-network connectivity, but it is not transitive.
- PSC is the service-oriented private endpoint answer, not a general network merge.
- Private Google Access is for private instances accessing Google APIs. Cloud NAT is outbound internet for private instances.
- Cloud Router exchanges BGP routes; it does not carry data traffic.
- Use HA VPN for resilient VPN. Use Interconnect for private high-bandwidth/low-latency enterprise links.
- Use external Application Load Balancer for global web/API traffic, Cloud Armor, CDN, TLS, and L7 routing.
- Use internal load balancers for private app-to-app or tier-to-tier traffic.
- Cloud DNS solves name resolution, not packet reachability.
- Cloud Armor is the WAF/DDoS edge answer. Firewall rules are the VPC packet-control answer.
- For troubleshooting, think Connectivity Tests first, then fix routes/firewalls/DNS based on evidence.
Sources used: Google Cloud Professional Cloud Architect certification page; Google Cloud networking docs for VPC, Shared VPC, VPC Network Peering, Private Service Connect, Cloud Router, Cloud VPN, Cloud Interconnect, Network Connectivity Center, Cloud Load Balancing, Cloud Armor, and related networking products.