Granular Outbound FQDN Control with Hierarchical Firewalls
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?
Community Votes
100% of anonymous learners picked answer B. Votes are pick records left by other test-takers — they are not the verified answer.
Community Insight
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.
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.
Community Discussion (4 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
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
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.