Block Egress Domains by SNI With Cloud NGFW

Egress URL Filtering With Cloud NGFW Endpoints

A security engineer is designing an egress perimeter control architecture for Google Cloud workloads located in a VPC across multiple zones. The organization requires Layer 7 traffic inspection to filter outbound HTTP and HTTPS connections based on domain matcher strings and TLS Server Name Indication (SNI), applying custom block or allow actions.

Which combination of components and configuration steps should the engineer implement to meet these requirements?

Deploy an external Application Load Balancer with a global forwarding rule, apply target network tags to VM instances, and attach Cloud Armor security policies containing custom WAF rules.

Create a zonal firewall endpoint in each target zone, configure a URL filtering security profile containing domain matcher strings, add the profile to a security profile group, and create a firewall policy rule that uses the apply_security_profile_group action.

Configure a regional internal proxy Network Load Balancer, create a ProjectNetworkPolicy to intercept outbound traffic, and apply VPC firewall rules with destination ranges set to 0.0.0.0/0.

Create an internal passthrough Network Load Balancer in each zone, attach standard VPC firewall rules filtering by service account, and associate a proxy-only subnet with the REGIONAL_MANAGED_PROXY purpose.

Explanations

Deploy an external Application Load Balancer with a global forwarding rule, apply target network tags to VM instances, and attach Cloud Armor security policies containing custom WAF rules.

What This Option Is and Does

An external Application Load Balancer with Cloud Armor provides ingress protection, DDoS mitigation, and Web Application Firewall (WAF) filtering for incoming internet traffic directed toward Google Cloud-hosted web applications.

Why It Doesn't Meet the Requirement

Ingress vs. Egress: Cloud Armor and external Application Load Balancers inspect inbound traffic originating from external clients. They do not intercept or inspect outbound egress connections initiated by internal VMs heading to internet destinations.
Wrong traffic direction: WAF rules protect frontend services from web vulnerabilities (such as SQLi and XSS), but they do not act as an outbound URL filter or egress perimeter for VM internet access.
Network tag limitation: Network tags allow arbitrary IAM tag edits and do not establish the Layer 7 inspection pipeline required for Cloud NGFW URL filtering.

Key Characteristics and Limitations

Inbound edge proxy: External load balancers route ingress traffic from external clients to internal backends.
Cloud Armor scope: Evaluates request headers, GeoIP, and OWASP rule sets for inbound HTTP/HTTPS requests.
No outbound SNI filtering: Cannot act as a boundary gateway for egressing VM connections.

This Answer Would Be Correct If

The organization needed to protect an internally hosted public web service against incoming web-based attacks, bots, and Layer 7 distributed denial-of-service (DDoS) attempts.

Additional Context

For egress inspection, Google Cloud uses Cloud NGFW Enterprise URL filtering or Secure Web Proxy rather than Cloud Armor.

View source documentation

Create a zonal firewall endpoint in each target zone, configure a URL filtering security profile containing domain matcher strings, add the profile to a security profile group, and create a firewall policy rule that uses the apply_security_profile_group action.

What Cloud NGFW URL Filtering Is

Cloud Next Generation Firewall (NGFW) Enterprise URL filtering provides native Layer 7 egress inspection for HTTP and HTTPS traffic without requiring third-party proxy appliances or sidecar agents. It inspects Host headers and TLS Server Name Indication (SNI) fields during session negotiation to enforce granular domain-level access policies.

How It Meets the Requirements

Layer 7 domain and SNI matching: A URL filtering security profile defines matcher strings and regular expressions that Cloud NGFW matches against the request Host header or TLS SNI to determine whether traffic is permitted or blocked.
Zonal inspection points: A firewall endpoint is provisioned at the zonal level in the same zone and VPC as the source workloads to intercept and inspect Layer 7 traffic.
Security profile groups: The URL filtering profile is packaged inside a security profile group, which can aggregate multiple security capabilities (such as URL filtering and intrusion prevention).
Policy rule enforcement: A hierarchical or global network firewall policy rule selects traffic using Layer 3/Layer 4 criteria and applies the apply_security_profile_group action to route matching connections to the firewall endpoint for Layer 7 evaluation.

Key Advantages and Capabilities

Centralized policy governance: Enforces uniform outbound security across organizations, folders, or VPC networks using hierarchical firewall policies.
Seamless TLS inspection support: Reads the SNI during TLS handshakes without requiring client-side certificate installation for SNI-based filtering.
Scalable cloud-native architecture: Eliminates the operational overhead, bottlenecks, and routing complexity of managing self-hosted proxy VM fleets.
Integration with network tags: Can be combined with secure tags to apply granular URL policies based on workload identity and environment tiering.

Why This Is Optimal

This architecture directly leverages Google Cloud's native NGFW Enterprise constructs, fulfilling all Layer 7 domain filtering, SNI matching, and automated enforcement requirements while maintaining high throughput and low latency.

View source documentation

Configure a regional internal proxy Network Load Balancer, create a ProjectNetworkPolicy to intercept outbound traffic, and apply VPC firewall rules with destination ranges set to 0.0.0.0/0.

What This Option Is and Does

A regional internal proxy Network Load Balancer terminates client TCP connections and forwards them to internal backends, while ProjectNetworkPolicy is a policy construct used in Google Distributed Cloud Hosted (GDCH) environments to control data transfer policies for container workloads.

Why It Doesn't Meet the Requirement

Lack of URL filtering engine: An internal proxy Network Load Balancer terminates TCP connections at Layer 4 and lacks the built-in URL filtering security profile engine needed to match domain names and SNI.
Irrelevant policy framework: ProjectNetworkPolicy applies specifically to Google Distributed Cloud Hosted container workloads and does not provide Cloud NGFW Layer 7 URL filtering in Google Cloud VPCs.
Standard VPC firewall limitations: VPC firewall rules targeting 0.0.0.0/0 operate at Layer 3/Layer 4 and cannot inspect or filter by domain name or SNI.

Key Characteristics and Limitations

Internal reverse proxy: Internal proxy Network Load Balancers are designed for internal service-to-service communication, not outbound internet URL inspection.
No domain matcher evaluation: Cannot process security profile groups or execute Layer 7 matcher rules.
Missing endpoint association: Fails to create the required zonal firewall endpoints to receive intercepted packets.

This Answer Would Be Correct If

You were deploying an internal microservices architecture in a private environment requiring Layer 4 reverse proxying with dedicated VIP frontends.

Additional Context

To filter outbound traffic by domain name in standard VPC networks, administrators must use Cloud NGFW Enterprise security profiles or Google Cloud Secure Web Proxy.

View source documentation

Create an internal passthrough Network Load Balancer in each zone, attach standard VPC firewall rules filtering by service account, and associate a proxy-only subnet with the REGIONAL_MANAGED_PROXY purpose.

What This Option Is and Does

An internal passthrough Network Load Balancer (NLB) distributes Layer 4 TCP/UDP traffic to backend virtual machines at wire speed, while proxy-only subnets are dedicated subnets used by Envoy-based proxy load balancers and Secure Web Proxy instances. Standard VPC firewall rules filter packets at Layer 3 and Layer 4 based on IP ranges, protocols, ports, and service accounts.

Why It Doesn't Meet the Requirement

No Layer 7 domain or SNI filtering: Standard VPC firewall rules only evaluate IP addresses, protocols, ports, and service account metadata; they cannot parse Layer 7 Host headers or TLS SNI values.
Passthrough load balancer limitations: An internal passthrough NLB does not terminate TLS sessions or inspect Layer 7 payloads; it merely forwards raw packets to backend targets.
Mismatched architecture: Configuring an internal NLB with standard VPC firewall rules does not instantiate the Cloud NGFW Layer 7 inspection engine or firewall endpoint constructs.

Key Characteristics and Limitations

Layer 4 only: Cannot make routing or security decisions based on URLs, URIs, or domain names.
No security profile integration: Standard VPC firewall rules cannot reference security profile groups or execute apply_security_profile_group actions.
Proxy-only subnet scope: Proxy-only subnets reserve IP addresses for Envoy proxies, not for standard VPC firewall packet evaluation.

This Answer Would Be Correct If

The goal were to build a custom, self-managed fleet of third-party proxy virtual machines behind an internal load balancer to process regional TCP traffic.

Additional Context

Cloud NGFW Enterprise replaces the need for custom passthrough load balancer architectures by integrating inspection endpoints directly into Google Cloud's virtual network fabric.

View source documentation

Last updated August 28, 2026Validated August 28, 2026

Egress URL Filtering With Cloud NGFW Endpoints

Which combination of components and configuration steps should the engineer implement to meet these requirements?

Deploy an external Application Load Balancer with a global forwarding rule, apply target network tags to VM instances, and attach Cloud Armor security policies containing custom WAF rules.

Configure a regional internal proxy Network Load Balancer, create a ProjectNetworkPolicy to intercept outbound traffic, and apply VPC firewall rules with destination ranges set to 0.0.0.0/0.

Explanations

Deploy an external Application Load Balancer with a global forwarding rule, apply target network tags to VM instances, and attach Cloud Armor security policies containing custom WAF rules.

What This Option Is and Does

Why It Doesn't Meet the Requirement

Ingress vs. Egress: Cloud Armor and external Application Load Balancers inspect inbound traffic originating from external clients. They do not intercept or inspect outbound egress connections initiated by internal VMs heading to internet destinations.
Wrong traffic direction: WAF rules protect frontend services from web vulnerabilities (such as SQLi and XSS), but they do not act as an outbound URL filter or egress perimeter for VM internet access.
Network tag limitation: Network tags allow arbitrary IAM tag edits and do not establish the Layer 7 inspection pipeline required for Cloud NGFW URL filtering.

Key Characteristics and Limitations

Inbound edge proxy: External load balancers route ingress traffic from external clients to internal backends.
Cloud Armor scope: Evaluates request headers, GeoIP, and OWASP rule sets for inbound HTTP/HTTPS requests.
No outbound SNI filtering: Cannot act as a boundary gateway for egressing VM connections.

This Answer Would Be Correct If

The organization needed to protect an internally hosted public web service against incoming web-based attacks, bots, and Layer 7 distributed denial-of-service (DDoS) attempts.

Additional Context

For egress inspection, Google Cloud uses Cloud NGFW Enterprise URL filtering or Secure Web Proxy rather than Cloud Armor.

View source documentation

Create a zonal firewall endpoint in each target zone, configure a URL filtering security profile containing domain matcher strings, add the profile to a security profile group, and create a firewall policy rule that uses the apply_security_profile_group action.

What Cloud NGFW URL Filtering Is

How It Meets the Requirements

Layer 7 domain and SNI matching: A URL filtering security profile defines matcher strings and regular expressions that Cloud NGFW matches against the request Host header or TLS SNI to determine whether traffic is permitted or blocked.
Zonal inspection points: A firewall endpoint is provisioned at the zonal level in the same zone and VPC as the source workloads to intercept and inspect Layer 7 traffic.
Security profile groups: The URL filtering profile is packaged inside a security profile group, which can aggregate multiple security capabilities (such as URL filtering and intrusion prevention).
Policy rule enforcement: A hierarchical or global network firewall policy rule selects traffic using Layer 3/Layer 4 criteria and applies the apply_security_profile_group action to route matching connections to the firewall endpoint for Layer 7 evaluation.

Key Advantages and Capabilities

Centralized policy governance: Enforces uniform outbound security across organizations, folders, or VPC networks using hierarchical firewall policies.
Seamless TLS inspection support: Reads the SNI during TLS handshakes without requiring client-side certificate installation for SNI-based filtering.
Scalable cloud-native architecture: Eliminates the operational overhead, bottlenecks, and routing complexity of managing self-hosted proxy VM fleets.
Integration with network tags: Can be combined with secure tags to apply granular URL policies based on workload identity and environment tiering.

Why This Is Optimal

View source documentation

Configure a regional internal proxy Network Load Balancer, create a ProjectNetworkPolicy to intercept outbound traffic, and apply VPC firewall rules with destination ranges set to 0.0.0.0/0.

What This Option Is and Does

Why It Doesn't Meet the Requirement

Lack of URL filtering engine: An internal proxy Network Load Balancer terminates TCP connections at Layer 4 and lacks the built-in URL filtering security profile engine needed to match domain names and SNI.
Irrelevant policy framework: ProjectNetworkPolicy applies specifically to Google Distributed Cloud Hosted container workloads and does not provide Cloud NGFW Layer 7 URL filtering in Google Cloud VPCs.
Standard VPC firewall limitations: VPC firewall rules targeting 0.0.0.0/0 operate at Layer 3/Layer 4 and cannot inspect or filter by domain name or SNI.

Key Characteristics and Limitations

Internal reverse proxy: Internal proxy Network Load Balancers are designed for internal service-to-service communication, not outbound internet URL inspection.
No domain matcher evaluation: Cannot process security profile groups or execute Layer 7 matcher rules.
Missing endpoint association: Fails to create the required zonal firewall endpoints to receive intercepted packets.

This Answer Would Be Correct If

You were deploying an internal microservices architecture in a private environment requiring Layer 4 reverse proxying with dedicated VIP frontends.

Additional Context

To filter outbound traffic by domain name in standard VPC networks, administrators must use Cloud NGFW Enterprise security profiles or Google Cloud Secure Web Proxy.

View source documentation

Create an internal passthrough Network Load Balancer in each zone, attach standard VPC firewall rules filtering by service account, and associate a proxy-only subnet with the REGIONAL_MANAGED_PROXY purpose.

What This Option Is and Does

Why It Doesn't Meet the Requirement

No Layer 7 domain or SNI filtering: Standard VPC firewall rules only evaluate IP addresses, protocols, ports, and service account metadata; they cannot parse Layer 7 Host headers or TLS SNI values.
Passthrough load balancer limitations: An internal passthrough NLB does not terminate TLS sessions or inspect Layer 7 payloads; it merely forwards raw packets to backend targets.
Mismatched architecture: Configuring an internal NLB with standard VPC firewall rules does not instantiate the Cloud NGFW Layer 7 inspection engine or firewall endpoint constructs.

Key Characteristics and Limitations

Layer 4 only: Cannot make routing or security decisions based on URLs, URIs, or domain names.
No security profile integration: Standard VPC firewall rules cannot reference security profile groups or execute apply_security_profile_group actions.
Proxy-only subnet scope: Proxy-only subnets reserve IP addresses for Envoy proxies, not for standard VPC firewall packet evaluation.

This Answer Would Be Correct If

The goal were to build a custom, self-managed fleet of third-party proxy virtual machines behind an internal load balancer to process regional TCP traffic.

Additional Context

Cloud NGFW Enterprise replaces the need for custom passthrough load balancer architectures by integrating inspection endpoints directly into Google Cloud's virtual network fabric.

View source documentation

Last updated August 28, 2026Validated August 28, 2026

Egress URL Filtering With Cloud NGFW Endpoints

Explanations

Deploy an external Application Load Balancer with a global forwarding rule, apply target network tags to VM instances, and attach Cloud Armor security policies containing custom WAF rules.

What This Option Is and Does

Why It Doesn't Meet the Requirement

Key Characteristics and Limitations

This Answer Would Be Correct If

Additional Context

Create a zonal firewall endpoint in each target zone, configure a URL filtering security profile containing domain matcher strings, add the profile to a security profile group, and create a firewall policy rule that uses the apply_security_profile_group action.

What Cloud NGFW URL Filtering Is

How It Meets the Requirements

Key Advantages and Capabilities

Why This Is Optimal

Configure a regional internal proxy Network Load Balancer, create a ProjectNetworkPolicy to intercept outbound traffic, and apply VPC firewall rules with destination ranges set to 0.0.0.0/0.

What This Option Is and Does

Why It Doesn't Meet the Requirement

Key Characteristics and Limitations

This Answer Would Be Correct If

Additional Context

Create an internal passthrough Network Load Balancer in each zone, attach standard VPC firewall rules filtering by service account, and associate a proxy-only subnet with the REGIONAL_MANAGED_PROXY purpose.

What This Option Is and Does

Why It Doesn't Meet the Requirement

Key Characteristics and Limitations

This Answer Would Be Correct If

Additional Context

Try 10 interactive questions like this one, free

Related questions

Cloud Logging Sinks to Chronicle UDM

Cloud Secure Web Proxy

SAML SSO with JIT Provisioning

IAM Allow Policy Inheritance Additive

Workforce Identity Federation Attribute Mapping and Conditions

BigQuery ML Linear Regression

Egress URL Filtering With Cloud NGFW Endpoints

Explanations

Deploy an external Application Load Balancer with a global forwarding rule, apply target network tags to VM instances, and attach Cloud Armor security policies containing custom WAF rules.

What This Option Is and Does

Why It Doesn't Meet the Requirement

Key Characteristics and Limitations

This Answer Would Be Correct If

Additional Context

Create a zonal firewall endpoint in each target zone, configure a URL filtering security profile containing domain matcher strings, add the profile to a security profile group, and create a firewall policy rule that uses the apply_security_profile_group action.

What Cloud NGFW URL Filtering Is

How It Meets the Requirements

Key Advantages and Capabilities

Why This Is Optimal

Configure a regional internal proxy Network Load Balancer, create a ProjectNetworkPolicy to intercept outbound traffic, and apply VPC firewall rules with destination ranges set to 0.0.0.0/0.

What This Option Is and Does

Why It Doesn't Meet the Requirement

Key Characteristics and Limitations

This Answer Would Be Correct If

Additional Context

Create an internal passthrough Network Load Balancer in each zone, attach standard VPC firewall rules filtering by service account, and associate a proxy-only subnet with the REGIONAL_MANAGED_PROXY purpose.

What This Option Is and Does

Why It Doesn't Meet the Requirement

Key Characteristics and Limitations

This Answer Would Be Correct If

Additional Context

Try 10 interactive questions like this one, free

Related questions

Cloud Logging Sinks to Chronicle UDM

Cloud Secure Web Proxy

SAML SSO with JIT Provisioning

IAM Allow Policy Inheritance Additive

Workforce Identity Federation Attribute Mapping and Conditions

BigQuery ML Linear Regression