Granular Outbound FQDN Control with Hierarchical Firewalls

PCSE By islever Editorial Last updated Sep 9, 2026

Short answer

B Create a folder-level deny-all rule within a hierarchical firewall policy and override it with VPC-scoped FQDN allowlists while configuring Cloud NAT for the designated networks.

Question

Your organization utilizes Cloud Run services within multiple projects underneath the non-production folder which requires primarily internal communication. Some services need external access to approved fully qualified domain names (FQDN) while other external traffic must be blocked. Internal applications must not be exposed. You must achieve this granular control with allowlists overriding broader restrictions only for designated VPCs. What should you do?

Implement a global-level allowlist rule for the necessary FQDNs within a hierarchical firewall policy. Apply this policy across all VPCs in the organization and configure Cloud NAT without any additional filtering.
Create a folder-level deny-all rule for outbound traffic within a hierarchical firewall policy. Define FQDN allowlist rules in separate policies and associate them with the necessary VPCs. Configure Cloud NAT for these VPCs. Correct Answer
Create a project-level deny-all rule within a hierarchical structure and apply it broadly. Override this rule with separate FQDN allowlists defined in VPC-level firewall policies associated with the relevant VPCs.
Configure Cloud NAT with IP-based filtering to permit outbound traffic only to the allowlist d FQDNs' IP ranges. Apply Cloud NAT uniformly to all VPCs within the organization's folder structure.

Key Takeaways

Tests hierarchical firewall policy scoping and FQDN allowlisting, with the common trap of misapplying global baselines or relying on Cloud NAT for domain-based filtering.

This question tests implementing granular outbound traffic controls using Google Cloud Hierarchical Firewall Policies and Cloud NAT. It establishes that a folder-level deny-all baseline combined with VPC-scoped FQDN allowlists provides the required security posture for non-production environments.

Common mistake: Choosing option D because candidates mistakenly assume Cloud NAT natively filters by FQDN, ignoring that GCP firewalls require explicit hierarchical policy configuration for domain-based egress rules.

Expert Analysis

Why the Answer Is Correct

Option B correctly implements a defense-in-depth strategy by establishing a folder-level deny-all rule as the default baseline for the non-production environment. By placing FQDN allowlist rules in separate VPC-level hierarchical firewall policies, you ensure that only designated virtual networks can reach approved external domains, directly satisfying the requirement for granular control. Cloud NAT is appropriately configured on those specific VPCs to translate private IPs for outbound traffic.

Why the Other Options Are Wrong

Option A applies a global allowlist without a deny-all baseline, leaving unauthorized outbound traffic unblocked. Option C scopes the baseline to the project level, which contradicts the folder-wide architectural boundary described and adds unnecessary management overhead. Option D incorrectly assumes Cloud NAT supports native FQDN filtering, when it only handles IP/port translation, and applying it uniformly violates the requirement to restrict access to designated VPCs only.

Community Comment Notes

As noted by user KLei, the consensus correctly highlights that Cloud NAT fully supports Cloud Run workloads, validating the infrastructure choice. Learners widely recognized that the folder-level deny-all paired with targeted VPC policies is the only architecture that satisfies both the security baseline and the granular exception requirements. One commenter emphasized that this approach ensures "no outbound traffic is allowed by default" while maintaining precise domain exceptions.

Official Reference

These links open the official vendor documentation in a new tab.

Exam Strategy

Always establish a deny-all baseline at the highest logical scope matching your organizational boundary before layering exceptions. When questions specify FQDN filtering, remember that native GCP firewalls and Cloud NAT require explicit policy configuration rather than automatic domain resolution.

Frequently Asked Questions

Why can't Cloud NAT handle FQDN filtering natively?

Cloud NAT only performs IP/port translation and does not inspect DNS queries or resolve domains. FQDN filtering requires hierarchical firewall policies or a third-party proxy.

Should the deny-all rule be at the organization or folder level?

Use the folder level since the question specifies a non-production folder boundary. Scoping it higher would affect unrelated production environments unnecessarily.

More PCSE FAQ →

Community Votes

100%

100% of anonymous learners picked answer B. Votes are pick records left by other test-takers — they are not the verified answer.

Discussion 4 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 4

Pime13 👍 1 Answered B

This approach allows you to: Enforce a deny-all rule at the folder level, ensuring that no outbound traffic is allowed by default. Create specific allowlist rules for the approved FQDNs and apply these rules to the necessary VPCs, providing the required external access. Configure Cloud NAT to handle the outbound traffic for these VPCs, ensuring that the traffic is routed correctly while adhering to the allowlist rules.
KLei 👍 1 Answered B

Cloud Public NAT support not only the VM instances but also Cloud Run https://cloud.google.com/nat/docs/overview#supported-resources
MoAk 👍 1 Answered B

Only answer that makes sense to me.
yokoyan 👍 1 Answered B

I think it's B.

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

← Back to PCSE Study Guide