Google PCNE: Network Automation, Governance and Cost Operations — 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

Network automation, governance, and cost operations on Google Cloud are inseparable disciplines that determine how reliably, securely, and economically your networks run at scale. Effective practice blends a well-structured resource hierarchy and least-privilege IAM with infrastructure as code and event-driven workflows, all underpinned by clear budgets, quotas, and auditability. The end state is predictable provisioning, minimal manual change, defensible compliance evidence, and transparent unit economics for networking.

Governance and Access Control

• Resource hierarchy

  • Organization → Folders → Projects is the control plane for permission inheritance and policy guardrails. Place production and non-production in separate folders to isolate policies and quotas. Use labels on VPCs, subnets, routers, forwarding rules, and instances for cost allocation and resource targeting.
  • Shared VPC consolidates routing and connectivity in a host project while delegating compute to service projects. Share only the subnets each service project needs to follow the principle of exposing networks explicitly and to reduce unintended route exposure.

• IAM and least privilege

  • Separate network administration from security administration. Compute Network Admin grants full control over networking constructs and read-only access to firewall rules, while Security Admin manages firewall rules and SSL certificates. This separation avoids over-entitled operators and aligns with change control.
  • Grant targeted roles:
    • To modify firewall rules, use Security Admin on the Shared VPC.
    • To manage VLAN attachments and other core network resources, Compute Network Admin is appropriate.
    • For automation against specific resources, grant resource-level permissions rather than project-wide roles when feasible, or create a custom role limited to required permissions.
  • Prefer service account impersonation and short-lived tokens over persistent keys. Disallow service account key creation via organization policy where possible. Use Workload Identity Federation to remove keys entirely for on-prem or multi-cloud automation.
  • Follow least-privilege access for data plane tasks. For example, a job reading Cloud Storage only needs storage object viewer on the target bucket, not broad editor on the project.

• Organization policies

  • Enforce “no external IP” for VMs by default; use Private Google Access and Cloud NAT to reach Google APIs without public addresses.
  • Constrain peering and external sharing to approved patterns (for example, restrict VPC peering configurations to avoid sprawl).
  • Restrict service account key creation and service account use to limit credential sprawl.
  • Failure modes and trade-offs:
    • Overly broad inherited roles at the folder can silently grant write access to many projects. Review role bindings with effective permission analysis.
    • Blocking VMs from having external IPs without planning for Private Google Access and NAT leads to outages when calling Google services.
    • Converting a VPC from auto mode to custom mode without refactoring templates that assumed auto subnets breaks deployments; explicitly reference custom subnets thereafter.

Automation, IaC, and Event-Driven Operations

• Infrastructure as Code with Terraform

  • Use a modular design: one module per primitive (VPC, subnet, firewall, Cloud Router, Cloud NAT, interconnect attachment), then compose environment stacks. Version modules and pin versions in consuming stacks to control rollouts.
  • Store state remotely with locking (for example, Cloud Storage with Dynamo-style locking via a back-end pattern) to prevent concurrent changes. Encrypt and back up state; treat state as sensitive.
  • Drift management:
    • Enforce change via pull requests and terraform plan in CI to reveal intended vs actual. Run scheduled drift detection (plan -detailed-exitcode) and emit alerts when drift appears.
    • Avoid ad-hoc gcloud changes in production; if emergency fixes are necessary, record them and reconcile in code immediately.
  • Idempotence and guardrails: Always plan, review, and apply. Use targeted applies to minimize blast radius. Use variable validation and policy-as-code (for example, Sentinel or OPA) to block anti-patterns like overlapping CIDRs or open firewalls.

• gcloud, APIs, and workflows

  • Use gcloud and REST for low-latency operational tasks, but wrap them in repeatable scripts. Handle eventual consistency and API rate limits with retries and exponential backoff.
  • Event-driven operations:
    • Use Cloud Scheduler + Pub/Sub + Cloud Run/Cloud Functions to automate routine tasks such as quota checks, NAT utilization audits, or firewall logging sampling.
    • Stream Admin Activity and Data Access logs to Pub/Sub to trigger guardrail workflows (for example, auto-revert an unauthorized firewall rule change).
  • Example snippets
    • Grant a role:
      • gcloud projects add-iam-policy-binding PROJECT –member=user:alice@example.com –role=roles/compute.networkAdmin
    • Create a route for Google APIs to bypass a default route to an NGFW:
      • gcloud compute routes create google-apis-egress –network=NET –destination-range=199.36.153.8/30 –next-hop-gateway=default-internet-gateway –priority=800

• Operational pitfalls

  • Race conditions when multiple pipelines manage shared resources (for example, firewalls in a common VPC) cause flapping. Use ownership conventions and folder-scoped pipelines.
  • API flakiness under high parallelism triggers quota errors; throttle and batch operations by region and resource type.

Cost, Quotas, and Capacity Management

• Quotas and API limits

  • Track per-project and per-region quotas (addresses, forwarding rules, firewall rules, interconnect attachments, routers). Automate quota monitoring, and request increases before new environments land. Bake preflight quota checks into CI to fail fast.
  • Provision at scale with:
    • Regional sharding (create resources per region to avoid regional quota contention).
    • Preallocation (reserve addresses and set up routers ahead of peak events).
    • Staged rollouts (create, validate, then attach backends).

• Egress and topology economics

  • Intra-VPC cross-region traffic incurs inter-region egress costs. Place communicating workloads in the same region or replicate data regionally when latency and cost matter.
  • For users near us-east1 and europe-west1, a single VPC with regional subnets enables private RFC1918 communication, minimizing NAT and peering overhead while allowing simple policy and routing.
  • Use VPC Network Peering for low-overhead connectivity between projects or departments with no NAT and no transitive routing; keep non-overlapping CIDRs. Use separate VPCs to isolate departments that must not communicate.
  • Cloud CDN reduces egress and improves latency for HTTP(S) traffic; a global HTTP(S) load balancer is the control plane for CDN. A network load balancer will not improve global latency for web apps because it lacks edge distribution and caching.
  • Choose interconnect wisely: Dedicated Interconnect with VLAN attachments in a host project centralizes administration and reduces per-project cost for large, shared on-prem connectivity. Cloud VPN with Cloud Router is suitable for quick, encrypted connectivity between organizations, evolving to interconnect later.

• Cost allocation, budgets, and forecasting

  • Tag all network resources with labels for department, environment, and cost center. Export billing data to BigQuery and derive unit costs (for example, $/GB egress per service).
  • Create budgets at project, folder, or label granularity. Send alerts to Pub/Sub and wire to ChatOps or Cloud Run responders. Automate actions on overrun (for example, reduce logging sampling or scale down non-critical test environments).
  • Optimize egress:
    • Prefer Private Google Access and Cloud NAT instead of external IPs to control egress paths and centralize billing.
    • For forced-tunnel topologies, add custom routes for Google APIs to the default internet gateway or configure Private Google Access for on-prem to avoid hairpinning through third-party firewalls.
    • Forecast capacity by analyzing VPC Flow Logs and load balancer logs; correlate with seasonality. Right-size NAT gateways and interconnect capacity in advance of peak.

Auditability and Operational Excellence

• Logging and evidence

  • Cloud Audit Logs:
    • Admin Activity logs capture control plane changes to VPCs, routes, firewalls, routers, and load balancers; they are always on. Retain centrally and route to a security project with CMEK if required.
    • Data Access logs for networking APIs can be high volume; enable selectively and apply sampling or sinks.
  • VPC Flow Logs and Firewall Rules Logging provide data-plane evidence for incident response and compliance. Store for the required retention horizon and index with BigQuery for investigations.
  • Change records: Require every network change to originate from IaC with an immutable plan artifact and a ticket reference. For exceptional manual changes, capture gcloud command, operator, timestamp, and justification in a central registry.

• Secure credentials and automation risk control

  • Eliminate long-lived service account keys. Use IAM Conditions to scope automation by resource, time, or IP. Guard high-risk permissions (for example, compute.firewalls.update, compute.routers.updateBgpPeer) with approval workflows.
  • Apply least privilege to CI/CD, use per-environment service accounts, and rotate tokens frequently. Use VPC Service Controls for service perimeter protection where data exfiltration risks exist.

• Runbooks, lifecycle, and continuous improvement

  • Maintain runbooks for routine operations: onboarding a project to Shared VPC, creating VPC peering, establishing Cloud VPN with IKEv2, promoting Cloud Armor rules in preview to enforce.
  • Define lifecycle policies:
    • Sandbox → Staging → Production promotion with identical Terraform modules and regionally specific variables.
    • Decommission playbooks to remove peering, NAT, and routes safely.
  • Continuous improvement:
    • Post-incident reviews should feed back into modules (for example, adding default deny egress with explicit allowlists, or NAT logging by default).
    • Regularly review org policies, labels, and budgets for drift from intended posture.

Practical Problem Scenario

Contoso Retail operates in North America and Europe. Users and services run mainly in us-east1 and europe-west1. Security requires a default route to a third-party NGFW, no external IPs on VMs, and centralized on-prem connectivity. The company also needs clear cost allocation by department and automated guardrails.

1. Establish governance and topology

• Create a Shared VPC host project with a single VPC and two regional subnets in us-east1 and europe-west1. Rationale: One VPC with regional subnets allows direct RFC1918 communication between regions with simple routing and policy, minimizing per-project overhead.
• Share only the necessary subnets to three service projects (Marketing, Supply, Finance). Rationale: Subnet-level sharing limits route and firewall exposure while preserving centralized control.
• Create a separate VPC for a legacy Finance system that must be isolated; peer only Marketing and Supply where needed. Rationale: VPC peering provides low-latency private connectivity for the two departments while preserving isolation from Finance.

2. Configure secure access to Google services without public IPs

• Enable Private Google Access on all shared subnets. Rationale: Instances without external IPs can reach Google APIs privately.
• Because the default route goes to an NGFW, add a custom static route for 199.36.153.8/30 to the default internet gateway. Rationale: Ensures calls to Google APIs do not hairpin through the firewall, reducing latency and avoiding a single choke point.

3. Centralize on-prem connectivity

• Deploy Dedicated Interconnect and VLAN attachments in the Shared VPC host project, attaching to a Cloud Router per region. Rationale: Centralized interconnect reduces cost and operational duplication; Cloud Router provides dynamic routing for growth.
• Grant Compute Network Admin to network operators, and Security Admin to the security team. Rationale: Enforces least privilege and separation of duties; network admins cannot change firewalls without security approval.

4. Automate provisioning and guardrails

• Implement Terraform modules for VPC, subnets, routers, NAT, peering, and firewall policies. Store state remotely with locking; enforce pull-request reviews with terraform plan in CI. Rationale: Repeatable, versioned changes with drift control minimize outages.
• Add an OPA policy to block overlapping CIDRs and open 0.0.0.0/0 ingress to internal subnets. Rationale: Prevents common misconfigurations at review time.
• Use Cloud Scheduler to publish daily quota checks to Pub/Sub; a Cloud Run service calls the Service Usage API to verify headroom for addresses, forwarding rules, and interconnect attachments. Rationale: Avoids deployment failures due to quota exhaustion.

5. Optimize cost and allocate accurately

• Apply labels env, dept, and service to all network resources via Terraform. Export billing to BigQuery and define budgets per department with alerts to Pub/Sub. Rationale: Transparent cost allocation and early warnings on spikes enable proactive action.
• Front the public web properties with a global HTTP(S) load balancer and enable Cloud CDN. Rationale: Improves latency for global users and reduces egress by serving cached content at the edge.

6. Strengthen auditability and incident response

• Route Admin Activity and Firewall Rules Logging to a central logging project with CMEK. Rationale: Tamper-evident change records and data-plane evidence satisfy compliance.
• For suspected abusive clients, deploy a Cloud Armor rule in preview mode on the HTTP(S) load balancer and review logs before enforcing. Rationale: Minimizes user disruption while validating the mitigation.

7. Document and iterate

• Publish runbooks for onboarding a project to Shared VPC, creating VPC peering between Marketing and Supply, and building a policy-based Cloud VPN for partners that lack BGP. Rationale: Standardized execution reduces MTTR and variance.
• After each change window, capture metrics (deployment time, errors, egress $/GB, cache hit ratio) and feed improvements back into modules and policies. Rationale: Continuous improvement embeds reliability and cost control into daily operations.

← Network Observability · All domains

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

Browse Google →