Google PCNE: Firewall Policy, Cloud Armor and Network Security — Study Guide

By Laurynas Brazys · 22 August 2026 · #google #PCNE #certification #exam-prep #study-guide

Part of the Google Professional Cloud Network Engineer — Study Guide. Practice with verified answers in the Google exam hub, or take timed practice tests on ExamRoll.io.

Overview

Firewall policy, Cloud Armor, and network security on Google Cloud together provide layered controls for segmentation, attack surface reduction, DDoS resilience, and observability. Effective designs combine identity-aware targeting, hierarchical enforcement, least-privilege ingress and egress, and edge protections tied to Google’s global load balancers. Operational success depends on understanding rule evaluation, implied behaviors, logging scope, and where traffic actually originates for different load-balancing modes.

VPC firewall rules and identity-aware targeting

VPC firewall rules are stateful and evaluated per network, direction, and priority.

• Direction and implied rules:
  • Ingress is evaluated against traffic entering a VM NIC; egress against traffic leaving it.
  • Two implied rules exist in every VPC: an implied deny-all ingress and an implied allow-all egress. These cannot be modified and do not produce logs. The default network also creates several permissive rules; custom VPCs do not.
• Priority and evaluation:
  • Priorities range 0–65535 where lower is evaluated first. The first matching rule fully determines the action.
  • If multiple rules with the same priority match, the most specific IP range wins; if equal specificity and conflicting actions, deny wins. Avoid same-priority overlaps.
• Targets and sources:
  • Targets define which VMs the rule applies to: network tags, VM service accounts, or secure tags. Sources/destinations are IP CIDRs; for ingress you can also specify source service accounts or tags for same‑VPC sources.
  • Network tags are VM metadata settable by project users; they are simple but less controlled. Service accounts provide identity-aware targeting tied to workload identity and IAM, harder to misuse. Secure tags (organization-level resource manager tags bound via IAM) let security teams control which VMs a rule can target without allowing developers to self-assign protection-bypassing tags; use them for stronger governance.
• Logging:
  • Enable firewall rule logging per rule to capture allowed or denied connections matched by that rule. Implied denies are not logged; if you need deny logs, add an explicit high-priority deny rule with logging enabled.
  • Logs include rule reference, action, 5‑tuple, bytes, and can be exported for forensics.

Design and operations:

• Least-privilege ingress: Prefer deny-by-default using explicit high-priority denies, then add scoped allows by service account or secure tag. For instance groups behind a load balancer, allow only from the load balancer or health check ranges that actually source the traffic.
• Least-privilege egress: Replace the implied allow with an explicit high-priority deny-all egress plus targeted allows (for NAT ranges, partner IPs, or Google APIs via Private Google Access). Be careful not to break return flows; statefulness permits responses to allowed connections without extra rules.
• Identity-aware targeting:
  • Use service accounts for “who can talk” policy, independent of IP mobility.
  • Use secure tags to prevent developers from self-applying permissive network tags.
• Common pitfalls and failure modes:
  • Load balancer source identity: For external HTTP(S) load balancers, backends see connections from Google Front End proxies, not from client IPs. Use Cloud Armor for client IP allow/deny; use VPC firewall to allow GFE egress and health check ranges. For TCP/UDP Network Load Balancers, backends see the client IP; firewall allowlists of client IPs apply directly.
  • Missing deny logs: Denies from implied rules aren’t logged. Add an explicit deny with logging enabled to observe blocked traffic.
  • NAT bypass: If a VM has an external IP, it will use it for egress and bypass Cloud NAT. Remove the external IP to force NAT use.
  • Rule mismatch diagnosis: Confirm direction, target identity (tag/service account/secure tag), priority, and source filters. If logs show no match, the traffic isn’t hitting the rule you expect.

Short example, identity-aware ingress allow with logging:

• Target: service account sa: web-backend@project.iam.gserviceaccount.com
• Source ranges: GFE proxy ranges + Google health checks
• Priority: 100
• Action: allow tcp:80,443
• Logging: on

Hierarchical firewall policy, segmentation, and service perimeters

Hierarchical firewall policies enforce organization- or folder-wide rules before any VPC-level rules. Use them to guarantee guardrails (for example, “deny all ingress from the internet to non‑load‑balanced VMs” or “deny RDP/SSH from 0.0.0.0/0”). Lower-level VPC rules cannot override an org/folder deny that already matched.

Segmentation strategy:

• Ingress segmentation:
  • Organization/folder policy: high-priority denies for risky ports and a default deny except for sanctioned entry points. Permit Google health check ranges where required.
  • VPC rules: workload-specific allows targeted by service account or secure tag. For internal services, use Private Service Connect or internal load balancing for east-west access with constrained rules.
• Egress segmentation:
  • Replace the implied allow-all egress with a high-priority deny-all egress at org/folder or VPC scope, then open only what is needed:
    • Internet egress via Cloud NAT or approved egress firewalls.
    • Google APIs via Private Google Access and private.googleapis.com or restricted.googleapis.com endpoints. The restricted endpoint pairs with VPC Service Controls to prevent data exfiltration to unauthorized identities or projects.
    • For designs that steer 0.0.0.0/0 through a third-party firewall but still require direct access to Google APIs without hairpinning, add static routes for the Google APIs VIP blocks to the default internet gateway and enable Private Google Access on the subnets. This preserves security controls while reducing latency and dependency on the third-party device for first‑party services.

Service perimeter interactions:

• VPC Service Controls define perimeters around projects and supported Google APIs to mitigate data exfiltration. When perimeters are enabled:
  • Prefer restricted.googleapis.com so API calls must remain within the perimeter context.
  • Ensure DNS points the relevant domains to the restricted or private endpoints and that routes do not backhaul to untrusted egress devices.
  • Combine perimeter policy with egress firewall allowlists to avoid accidental leaks to non‑perimeter endpoints.

Trade-offs:

• Org-level denies simplify risk management but can block legitimate experiments if change control is slow; delegate exceptions using secure tags and documented request workflows.
• Aggressive egress denies reduce blast radius but require robust service discovery and change control to prevent outages.

Cloud Armor, WAF, and global edge protections

Cloud Armor binds security policies to external HTTP(S) and external TCP/SSL Proxy load balancers to protect at the edge.

• WAF rules:
  • Use preconfigured rules for OWASP Top 10 and common CVEs, and custom rules using an expression language to match on headers, IPs, countries, URIs, and more.
  • Attach per backend service and order rules by priority. Actions include allow, deny with specific responses, or redirect for HTTP(S).
• Rate limiting:
  • Enforce per-key quotas (for example, by client IP, header, or cookie) with sliding windows and burst controls. Rate-based bans automatically add temporary denies for abusive sources.
• Adaptive Protection:
  • ML-driven anomaly detection learns normal request patterns and surfaces L7 DDoS or abuse. It can suggest or auto-generate candidate rules; deploy them in preview first.
• Preview mode:
  • Evaluate new rules without impacting traffic. Preview results are logged, enabling low-risk tuning. Move to enforced mode after verification.

DDoS defense and global load balancer controls:

• Google’s global anycast edge absorbs volumetric L3/L4 attacks; SYN/ACK validation, malformed packet handling, and autoscaling edge capacity are built into the platform for external HTTP(S) and TCP/SSL Proxy.
• Combine with Cloud Armor to mitigate L7 floods, credential stuffing, and application abuse.
• Enforce TLS policies, modern ciphers, and, where needed, client mTLS at the load balancer. For IPv6 requirements, use a global external HTTP(S) or TCP/SSL Proxy load balancer with IPv6 VIPs.
• For allowlisting specific client IPs to a load-balanced app:
  • If using HTTP(S), prefer Cloud Armor allowlists keyed by client IP and keep backend firewall rules limited to GFE and health check sources.
  • If using a TCP/UDP Network Load Balancer, backends see the real client IP; apply VPC firewall allowlists directly to the targeted instances (by secure tag or service account) and include Google health check IPs.

Operational cautions:

• Rules are evaluated at the edge; incorrect allowlists can cause global outages instantly. Use preview and staged rollouts, and monitor Cloud Armor logs and load balancer metrics.
• Session affinity needs vary: For mixed protocols (for example, HTTP and TFTP from the same client to the same backend pool), client IP affinity on the load balancer preserves stickiness across ports.

Visibility, inspection, and incident response

Observability:

• VPC Flow Logs provide sampled 5‑tuple flow records per subnet with configurable sampling, metadata enrichment, and aggregation intervals. Use them for performance baselining and anomaly detection.
• Firewall rule logging captures per-connection allows and denies for the specific rules with logging enabled; create explicit deny rules to log blocks that would otherwise hit implied denies.
• Cloud Armor request logs and preview results show rule matches, action decisions, and rate-limiting outcomes at the edge.

Inspection and detection:

• Packet Mirroring copies traffic to a collector in the same region for deep packet inspection or IDS. Scope mirroring by subnet, tag, or service account to limit overhead. Packet mirroring is out-of-band and does not block; use it with Cloud IDS or third-party sensors.
• Inline L7 inspection requires a 2‑NIC appliance pattern and routing through it. Engineer for symmetric routing and HA; consider regional fault domains and potential throughput bottlenecks. Inline devices increase blast radius if they fail; deploy managed instance groups and health-checked route failover patterns where applicable.

Incident response practices:

• Centralize logs to a security project, build detections for sudden deny spikes, new high-priority rule creations, or Cloud Armor rate limit triggers. Use BigQuery or SIEM integrations for investigation.
• Ensure least-privilege IAM: Network Admin is insufficient to modify firewall policies in Shared VPC where Security Admin is required; segregate duties between network and security teams.
• When you need SSH break-glass access and keys are not pre-provisioned, use gcloud compute ssh from Cloud Shell to push an ephemeral key via instance metadata if permitted by IAM and instance metadata settings.
• For troubleshooting “no logs” scenarios: verify the rule and direction, remember that implied denies don’t log, and check hierarchical policies that might have matched earlier.

Practical Problem Scenario

Contoso Retail runs a multi-tier web platform on Google Cloud. Frontend traffic is served by a global external HTTP(S) load balancer; application VMs run in multiple regions without external IPs. Egress must hairpin through a third-party NGFW except for Google APIs (BigQuery and Pub/Sub). The security team wants org-wide guardrails, client IP allowlists for a partner pilot, and minimal risk when testing a suspected malicious client.

Approach:

1. Establish hierarchical guardrails

   • Create an organization-level hierarchical firewall policy that denies all ingress from 0.0.0.0/0 to VM targets lacking the secure tag env=public-entry, and denies administrative ports (SSH, RDP) from the internet.
   • Rationale: Stops unsafe exposure globally; developers cannot self-assign the secure tag due to IAM on tags.

2. Identity-aware workload targeting

   • Assign distinct service accounts to frontend, application, and database tiers. Reference these service accounts in VPC-level firewall rules to permit only required east-west flows (for example, frontend→app tcp:443, app→db tcp:5432).
   • Rationale: Ties policy to workload identity and resists accidental tag misuse.

3. Ingress allows for load-balanced backends

   • On the app VMs, create a high-priority ingress allow rule targeted by the app service account, with source ranges equal to Google Front End proxies and Google health check ranges; enable logging.
   • Rationale: For HTTP(S) L7, backends should only accept connections from GFE and health check IPs; client IP allowlists are enforced at the edge.

4. Cloud Armor edge policy

   • Attach a Cloud Armor policy to the external HTTP(S) load balancer backend service:
     • Add a partner client IP allowlist rule.
     • Enable preconfigured WAF rules for OWASP Top 10.
     • Configure a rate limit keyed by client IP with conservative thresholds.
   • Rationale: Enforces client source restrictions and application-layer protections where the client IP is visible and before traffic reaches the VPC.

5. Adaptive protection and safe testing

   • Enable Adaptive Protection and create a deny rule for the suspected client IP in preview mode.
   • Rationale: Preview allows behavior verification without impacting real users; logs confirm whether the client is malicious before enforcing.

6. Egress segmentation with Private Google Access

   • Keep a 0.0.0.0/0 route to the third‑party NGFW. Add custom static routes for Google APIs VIPs to the default internet gateway and enable Private Google Access on subnets. Add an explicit high-priority egress deny-all rule, then specific allows for NGFW next-hop and Google APIs; enable logging.
   • Rationale: Forces general internet egress through the NGFW while allowing BigQuery and Pub/Sub to be reached privately without unnecessary hairpinning.

7. NAT and external IP controls

   • Use Cloud NAT for instances that need internet egress but have no external IPs. Audit and remove any external IPs on compute instances that must use NAT.
   • Rationale: Prevents NAT bypass and preserves a single egress posture.

8. Inspection and monitoring

   • Enable Packet Mirroring in each region for the app tier, targeting the app service account, and send mirrored traffic to a regional IDS collector. Enable VPC Flow Logs and firewall rule logging for key rules; export Cloud Armor and VPC logs to a central security project and BigQuery.
   • Rationale: Provides deep visibility for threat hunting and performance baselines without in-path latency.

9. Incident-ready operations

   • Build alerting on spikes in Cloud Armor denies, firewall deny logs, or changes to hierarchical policies. Document a break-glass SSH procedure using Cloud Shell gcloud compute ssh for controlled emergency access.
   • Rationale: Detects active abuse rapidly and preserves a secure operational path for remediation.

10. Change safety and rollback

• Stage Cloud Armor changes in preview, then enforce. For firewall changes, use lower-risk priorities and canary projects before propagating to org-level policy.
• Rationale: Minimizes the chance of global outages from policy mistakes while maintaining strong posture.

← VPC Architecture · All domains · Hybrid Connectivity →

Practice these questions → · Timed practice on ExamRoll.io →

Browse Google →