How Do You Resolve an Internal Domain for VPC and On-Premises Clients?
Short answer
B Create a Cloud DNS managed private zone authorized for the VPC network, add an A record for the load balancer, and let the inbound server policy serve on-premises resolvers over Cloud VPN.
Question
You are deploying a new internal web application behind an internal Application Load Balancer. The application must be accessible from both the VPC network and on-premises network using the domain name internal.altostrat.com. This name must not be resolvable from the public internet. Your on-premises network is connected to the VPC network by using Cloud VPN, and you have configured an inbound server policy. You need to resolve the domain name with the least administrative overhead. What should you do?
Key Takeaways
The question tests whether you pair a Cloud DNS private zone with the inbound server policy that lets on-premises resolvers query it — the trap is assuming a private zone alone is visible to the on-premises network.
Deploying an internal application behind an internal Application Load Balancer requires a DNS name that resolves for both VPC and on-premises clients while staying invisible to the public internet. This page establishes that a Cloud DNS managed private zone, paired with the already-configured inbound server policy, is the correct low-overhead answer.
Common mistake: Choosing option C, a public managed zone, because it is the simplest way to make a name resolve from everywhere — but it publishes internal.altostrat.com to the public internet, which the requirement explicitly forbids.
Expert Analysis
Why the Answer Is Correct
A Cloud DNS managed private zone is the only option that keeps internal.altostrat.com off the public internet while still giving the VPC network an authoritative answer for the load balancer's IP address. Authorizing the VPC network attaches the zone to the network where the internal Application Load Balancer lives, so VPC workloads resolve the A record normally. The on-premises side is handled by the inbound server policy you already configured: on-premises resolvers forward queries for altostrat.com to the Cloud DNS inbound endpoint reachable over Cloud VPN, so no per-client configuration is needed. That combination satisfies both reachability requirements with a single centrally managed record, which is precisely the least-administrative-overhead constraint.Why the Other Options Are Wrong
Option A puts the record only on the on-premises DNS server, so instances inside the VPC network would have no authoritative source for internal.altostrat.com and would need their own duplicate records — two places to maintain, and the VPC half of the requirement is unmet. Option C creates a public zone, which makes the name globally resolvable and directly violates the requirement that it must not be resolvable from the public internet. Option D edits HOSTS files on every employee workstation, which is the definition of high administrative overhead: records go stale, IP changes break silently, and it scales poorly. None of A, C, or D leverages the inbound server policy that was supplied as a hint about how on-premises resolution is meant to work.Community Comment Notes
Mr_MIXER007 reached the same conclusion, quoting the two governing constraints — "must not be resolvable from the public internet" and "you have configured an inbound server policy" — and mapping them to "Cloud DNS Private Zone + Inbound DNS Policy." That pairing is the key insight the question is fishing for: the private zone serves the VPC, and the inbound policy serves the on-premises side over Cloud VPN. Commenters who stop at "private zone" alone miss that on-premises clients cannot resolve an authorized private zone without the inbound forwarding path. The vote record is thin, but the reasoning aligns with Cloud DNS documented behavior for private zones and inbound server policies.Official Reference
Exam Strategy
When a scenario says a name must be resolvable internally but not publicly, eliminate any answer containing a public zone or host-file edits immediately. Then check whether the answer serves both client populations — VPC and on-premises — using the Cloud VPN and inbound server policy details the question deliberately supplies.
Frequently Asked Questions
Why doesn't the private zone alone let on-premises hosts resolve internal.altostrat.com?
A private zone is only visible to the VPC networks it is authorized for. On-premises resolvers need the inbound server policy forwarding path over Cloud VPN to reach Cloud DNS.
Why is a Cloud DNS public zone wrong for internal.altostrat.com?
A public zone publishes the record to global resolvers, so the name becomes resolvable from the public internet — exactly what the requirement forbids.
Discussion 1 contributions
Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded.
From public community threads 1
-
Mr_MIXER007 👍 1 Answered BB (Create a Cloud DNS managed private zone, authorize the VPC network to use it, and add an A record that points to the load balancer's IP address.) «must not be resolvable from the public internet» «you have configured an inbound server policy» Cloud DNS Private Zone + Inbound DNS Policy.
Reader comments & corrections
No reader corrections yet — spotted an error or have a note? Share it below.
Related Analysis
Practice All ACE Questions
Access 84 questions with complete answers and detailed explanations.
View Full ACE Practice Test →