An enterprise is designing a scalable egress architecture in Google Cloud for workloads residing in private subnets without external IP addresses. The security architecture team has established the following operational and security requirements: Enforce granular Layer 7 security policies on outbound HTTP/HTTPS web traffic based on source identities (such as Secure Tags and Service Accounts), request methods, and destination URL lists. Provide an explicit proxy architecture where client applications configure standard proxy variables (HTTP_PROXY and HTTPS_PROXY). Eliminate the administrative overhead of deploying, patching, and maintaining custom virtual machine (VM) proxy clusters. Provide automatic scaling of proxy infrastructure to accommodate fluctuating egress traffic demands with high availability. Integrate alongside existing VPC Service Controls perimeters without disrupting private data boundaries. Which architectural solution should the organization implement?

Deploy Google Cloud Secure Web Proxy (SWP) within the region, allocate a proxy-only subnet for its managed Envoy instances, define modular egress policies using Secure Tags and URL lists, and configure client workloads to direct egress traffic to the proxy's IP endpoint.: ### What Google Cloud Secure Web Proxy Is **Google Cloud Secure Web Proxy (SWP)** is a cloud-native, fully managed Layer 7 service designed to inspect, secure, and govern outbound web (HTTP/HTTPS) traffic from Google Cloud workloads. It eliminates the operational complexity of designing, scaling, and maintaining self-managed third-party proxy virtual machines. ### How It Meets the Enterprise Requirements - **Granular Layer 7 Policy Enforcement:** Secure Web Proxy allows administrators to author modular egress policies that match traffic based on **source identities** (such as **Secure Tags**, **IAM Service Accounts**, or IP ranges) and destination criteria (including **hostnames**, **URL paths**, **wildcards**, and **HTTP request methods**). - **Explicit Proxy Architecture:** Workloads send web requests explicitly to the proxy's internal IP address and port via standard environment variables (`HTTP_PROXY`, `HTTPS_PROXY`) or application proxy settings, using HTTP/S `CONNECT` tunnels for end-to-end TLS security. - **No VM Management Overhead:** As a fully managed service, Google Cloud handles all underlying infrastructure provisioning, security updates, and software maintenance automatically. - **Elastic Autoscaling & High Availability:** Secure Web Proxy utilizes managed **Envoy proxy pools** that scale up and down dynamically in response to bandwidth demands, utilizing a reserved **proxy-only subnet** within the region. - **VPC Service Controls Integration:** Secure Web Proxy complements **VPC Service Controls**; while VPC Service Controls establishes security perimeters around Google APIs (like Cloud Storage and BigQuery) to prevent data exfiltration, Secure Web Proxy controls and logs general outbound web traffic to external SaaS and internet endpoints. ### Key Advantages - **Zero Infrastructure Maintenance:** Operates out of the box without requiring custom VM clusters or manual OS patching. - **Identity-Aware Filtering:** Enforces fine-grained egress policies bound directly to Google Cloud resource metadata (Secure Tags) rather than brittle network-level IP addresses. - **Default-Deny Security Model:** Ensures that all outbound connections are blocked unless explicitly permitted by an authorized egress rule. - **Full Observability:** Logs all permitted and denied requests natively to **Cloud Logging** and integrates with **Cloud Audit Logs**. ### Why This Is Optimal Secure Web Proxy provides native Layer 7 inspection and identity-aware egress filtering while completely eliminating the operational complexity and failure domains associated with self-managed proxy VM fleets.

Architect Secure Web Proxy Egress Scalability | Professional Cloud Security Engineer

Architect Secure Web Proxy Egress Scalability

Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.

An enterprise is designing a scalable egress architecture in Google Cloud for workloads residing in private subnets without external IP addresses. The security architecture team has established the following operational and security requirements:

Enforce granular Layer 7 security policies on outbound HTTP/HTTPS web traffic based on source identities (such as Secure Tags and Service Accounts), request methods, and destination URL lists.
Provide an explicit proxy architecture where client applications configure standard proxy variables (HTTP_PROXY and HTTPS_PROXY).
Eliminate the administrative overhead of deploying, patching, and maintaining custom virtual machine (VM) proxy clusters.
Provide automatic scaling of proxy infrastructure to accommodate fluctuating egress traffic demands with high availability.
Integrate alongside existing VPC Service Controls perimeters without disrupting private data boundaries.

Which architectural solution should the organization implement?

Deploy a Regional External Application Load Balancer with Hybrid Network Endpoint Groups (NEGs) pointing to an on-premises web proxy cluster over Cloud Interconnect.

Configure Cloud NAT on the VPC network with Cloud Router, define URL-based firewall rules to filter outbound web domains, and attach VPC Service Controls perimeters directly to the Cloud NAT gateway.

Deploy a Cross-Region Internal Proxy Network Load Balancer with Managed Instance Groups (MIGs) running open-source proxy software, configured with Cloud NAT for outbound internet connectivity.

Deploy Google Cloud Secure Web Proxy (SWP) within the region, allocate a proxy-only subnet for its managed Envoy instances, define modular egress policies using Secure Tags and URL lists, and configure client workloads to direct egress traffic to the proxy's IP endpoint.

Professional Cloud Security Engineer

Architect Secure Web Proxy Egress Scalability

Related questions