FQDN-Filtered Egress Across a Shared VPC with PCI Segmentation
Contoso Retail runs a Shared VPC with a host project in us-central1 and europe-west1, 12 service projects, and 800 VMs that have no external IP addresses. On-premises connects through Dedicated Interconnect to a single VPC. All internet egress goes through Cloud NAT in the host project. Security discovered a service-project VM resolved and uploaded 4 GB to an unknown domain over HTTPS; VPC Flow Logs showed the NAT IP but not the destination FQDN. The company must allow only an approved list of about 40 external SaaS FQDNs, block all other egress, and keep Google API traffic private. A new requirement says payment-card systems must not share an egress path with marketing workloads. The network team resists forward proxies because of latency and operational overhead.
1. Design an egress control architecture that enforces the 40-FQDN allowlist without relying solely on Cloud NAT. Explain why each layer is needed and what it cannot do.
Read the worked answer
Cloud NAT alone cannot enforce an FQDN allowlist because it operates on IP and port, and SaaS endpoints resolve to changing IPs. Add a centralized egress layer in the host project: a set of egress proxy VMs or a managed Secure Web Proxy deployment in an egress VPC, with firewall rules that allow only proxy egress to the internet. Service projects route 0.0.0.0/0 through policy-based routes or a network appliance next hop to the proxy. The proxy performs TLS inspection or SNI-based filtering against the approved FQDN list. If TLS interception is not acceptable, SNI filtering plus a deny-by-default policy is the minimum; it will not catch domains hidden behind encrypted SNI or IP-only connections.
Use Cloud DNS response policies or a DNS filtering layer to block resolution of non-approved domains as a defense-in-depth control, but do not treat DNS filtering as sufficient because applications can use hard-coded IPs or external DNS. Combine it with firewall egress rules that deny direct internet access from service-project subnets, so a VM cannot bypass the proxy by using its own route.
Google API traffic should not traverse the internet proxy. Enable Private Google Access on subnets and, where possible, use Private Service Connect endpoints for Google APIs. That keeps googleapis.com traffic on Google's network and reduces proxy load.
What this cannot do: it cannot inspect traffic that never reaches the proxy, so route enforcement and firewall rules must be tested from each service project. It also cannot reliably identify destination FQDNs when clients use IP literals, so alert on direct IP egress attempts.
2. The PCI requirement says cardholder-data workloads must not share an egress path with marketing. How would you segment egress while keeping the architecture manageable for 12 service projects?
Read the worked answer
Create two egress paths in the host project: a PCI egress VPC and a general egress VPC. Put PCI workloads in dedicated service projects or dedicated subnets with a distinct network tag. Use policy-based routes or separate VPCs to send PCI subnet traffic to the PCI proxy/NAT path and marketing traffic to the general path. The PCI path should have a smaller allowlist, stricter logging, and no route to the marketing proxy. The general path should not be able to route into the PCI path.
Manageability comes from standardizing on a few network tags and Terraform modules rather than per-project bespoke routes. Each service project gets a module that creates its subnets, attaches the correct tag, and references the shared egress attachment. PCI projects get an additional org policy constraint or IAM control that prevents them from adding a default route to the internet. Use VPC Service Controls around the PCI projects to reduce data exfiltration paths, but note that VPC Service Controls do not replace network egress filtering.
The main failure mode is shared NAT IPs: if PCI and marketing use the same Cloud NAT, external parties see the same source IP and the paths are not isolated. Separate NAT gateways and proxies fix that. Also ensure logging is separated: PCI proxy logs go to a restricted bucket with longer retention, while marketing logs can use standard retention. Review routes quarterly because a single misconfigured route can collapse the segmentation.
3. VPC Flow Logs showed only the NAT IP, not the FQDN. What logging and detection changes would let you investigate a similar exfiltration attempt faster?
Read the worked answer
VPC Flow Logs record 5-tuples, bytes, and timestamps, but not DNS names or HTTP host headers. To answer 'what domain did this VM contact,' add DNS logging through Cloud DNS logging on the egress VPC, and proxy logs that record SNI or HTTP Host. If traffic goes through Cloud NAT, enable NAT logging to map NAT IP and port to the internal VM, then join that to proxy and DNS logs by timestamp and 5-tuple. Without NAT logging, multiple VMs behind one NAT IP are indistinguishable.
For detection, create log-based metrics and alerts for: a VM resolving a domain not on the allowlist, a proxy deny event above a threshold, a large outbound byte count to a single destination, and direct egress attempts that bypass the proxy. A 4 GB upload should trigger a volume anomaly alert if you baseline normal egress per VM or per service account. Export proxy and DNS logs to the SIEM with the internal VM identity as a required field.
Prioritize the detection that closes the visibility gap: proxy deny logs with the requested FQDN. That tells you both that a control worked and which workload tried to violate it. Flow logs remain useful for volumetric evidence and for proving that blocked traffic did not leave. Also retain logs long enough to investigate; the default 30 days may be too short for an incident discovered weeks later.