Managing and provisioning a solution infrastructure · Topic 2 of 6
VPC Design, Load Balancing and Network Security
Configuring VPC layouts, Shared VPC, Cloud NAT, load balancers, Cloud Armor, Cloud NGFW, Cloud IDS and secure tags to protect access to and from the cloud.
- 4 min
- Shared VPC for central control; plan non-overlapping ranges.
- Cloud NAT for outbound with fixed IPs; Private Google Access for Google APIs.
- Global external Application Load Balancer for internet HTTP(S) with Cloud Armor and CDN.
What it is
Inside Google Cloud, the network must let users reach applications, let applications reach each other and Google services, and block everything else. The exam tests VPC layout, load balancer choice and the layers of network protection: firewalls, Cloud Armor, intrusion detection and private access.
How it works
VPC layout
| Pattern | Use it when |
|---|---|
| Shared VPC with host projects per environment | A central network team, many service projects, consistent firewall and routing |
| Separate VPCs connected by PSC or NCC | Strong isolation between business units or tenants |
| Hub and spoke | A central network with shared services (DNS, inspection, hybrid links) and spokes per team |
Plan non-overlapping IP ranges across all VPCs and on-premises sites, including secondary ranges for GKE Pods and Services.
Access to the internet, Google APIs and cloud-adjacent services
| Need | Configuration |
|---|---|
| Private VMs call the internet with fixed source addresses | Cloud NAT with reserved static external IPs |
| Private VMs call Google APIs | Private Google Access on the subnet |
| Consume a managed or partner service privately | Private Service Connect endpoint |
| Managed services that live in a Google-owned network (Cloud SQL private IP, for example) | Private services access or Private Service Connect, depending on the service |
| Cloud Run reaching VPC resources | Direct VPC egress or a Serverless VPC Access connector |
Load balancing
| Requirement | Load balancer |
|---|---|
| Global HTTP(S) users, CDN, WAF, single anycast IP | Global external Application Load Balancer |
| HTTP(S) within one region (for example for residency) | Regional external Application Load Balancer |
| Private HTTP(S) between internal services | Internal Application Load Balancer |
| TCP/UDP, keep the client IP | Passthrough Network Load Balancer |
| Several GKE clusters behind one entry point | Multi-cluster Gateway |
Backend service settings matter: timeouts, session affinity, connection draining and health checks. Backends behind an external Application Load Balancer should keep idle connections open longer than the load balancer's own keepalive (600 seconds), or clients see sporadic 502 errors.
Layers of network protection
| Layer | Product | Protects against |
|---|---|---|
| Edge, HTTP(S) | Cloud Armor | DDoS, OWASP-style attacks, bots, rate-based bans per client |
| Network | Cloud Next Generation Firewall (firewall policies) | Unwanted traffic between workloads; hierarchical, global and regional policies |
| Intrusion detection | Cloud IDS | Detects threats in mirrored traffic; alerts, does not block |
| Intrusion prevention | Cloud NGFW Enterprise | Inspects and can block threats inline |
| Identity-aware access | Identity-Aware Proxy | Users reach apps based on identity and context, no VPN |
Secure tags (IAM-governed tags) work in network and hierarchical firewall policies, so a rule such as "sandbox VMs may not reach training VMs" can apply across many projects. Classic network tags work only in VPC firewall rules.
Cloud IDS detects; it does not stop traffic. If the requirement is to block, choose firewall rules, Cloud Armor or Cloud NGFW Enterprise.
Access control on the network path
- Least-privilege firewall rules with explicit deny rules at the organization or folder level.
- VPC Service Controls for data exfiltration through Google APIs (covered in the security chapter).
- IAP TCP forwarding for administrator SSH or RDP without public IPs.
A worked scenario
A GKE cluster has no external IPs by policy, yet must call a supplier's public API that allowlists source addresses. Attaching IPs to nodes breaks the policy; NAT VMs need patching. Cloud NAT with reserved static external addresses gives a fixed, managed egress path.
How the exam asks about this
- "Bots from a few hundred addresses flood the login API." Cloud Armor rate-based ban rule.
- "Block sandbox to training traffic across 30 projects without per-VM rules." Secure tags in an organization firewall policy.
- "Admins must SSH without public IPs or VPN." IAP TCP forwarding.
What to remember for the exam
- Shared VPC for central control; plan non-overlapping ranges.
- Cloud NAT for outbound with fixed IPs; Private Google Access for Google APIs.
- Global external Application Load Balancer for internet HTTP(S) with Cloud Armor and CDN.
- Cloud Armor at the edge, firewall policies in the network, Cloud IDS for detection.
- Secure tags work in hierarchical firewall policies; network tags do not.
Opening a service to the internet and filtering by IP is a weak substitute for private connectivity or IAP when users work from changing locations.
Common mistakes
Assuming Cloud IDS blocks attacks. It only detects.
Giving private nodes external IPs to reach an allowlisted API.
Short backend keepalive timeouts behind an external Application Load Balancer.
Check yourself
How do private GKE nodes call an external API that allowlists fixed IPs?
Cloud NAT with reserved static external IP addresses.
Which product applies rate-based bans to abusive clients at the edge?
Cloud Armor.
Can Cloud IDS block malicious traffic?
No, it detects and alerts; blocking needs firewall policies, Cloud Armor or Cloud NGFW Enterprise.
Topic 2 of 6 in Managing and provisioning a solution infrastructure
Test yourself on Managing and provisioning a solution infrastructure
The full Google Cloud Professional Cloud Architect question bank has 877 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by Google Cloud. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.