Google ACE Practice Question: A company uses Cloud DNS for internal DNS…

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Use Cloud DNS inbound server policy to forward queries to the other VPC.

  Why it's wrong here

  Cloud DNS inbound server policy is designed for hybrid cloud scenarios where on-premises DNS resolvers need to send queries into private zones hosted in a VPC. It creates a forwarding endpoint that receives inbound queries, not a mechanism for one VPC to pull records from another VPC's private zone. Since the new VPC's workloads would still query their own default DNS, this policy does nothing to resolve the other project's private zone. Therefore, it's incorrect for VPC-to-VPC DNS discovery.

• ✗

  Export the private zone as a public zone and create a delegation.

  Why it's wrong here

  Exporting a private zone as a public zone and creating a delegation would publish internal hostnames and IP addresses to the public internet, which is both a security risk and a violation of the private zone's purpose. Even if you delegated, VMs in the new VPC would not automatically use the public zone for resolution; they would need to be configured to query a public DNS server, and public DNS cannot resolve private IP addresses consistently. The delegation also requires public NS records and changes the authoritative path, breaking the existing private resolution in the source VPC. This approach is neither safe nor functionally correct for internal name resolution.

• ✓

  Set up a DNS peering zone between the new VPC and the VPC that hosts the private zone.

  Why this is correct

  Cloud DNS peering is the intended solution: you configure a DNS peering zone in the new VPC that targets the source VPC's private zone, and the new VPC's resolver forwards queries for that zone to the source VPC's Cloud DNS. This creates a unidirectional resolution path, so if you need bidirectional resolution you must create a separate peering zone in the opposite direction. The peering works even without VPC peering because the query is handled by the Cloud DNS infrastructure, not by network routing. It preserves the private zone's visibility scope and requires only the appropriate DNS peering IAM permissions.

• ✗

  Create a Private DNS zone in the new project with forwarding to the on-premises DNS.

  Why it's wrong here

  Creating a new private DNS zone in the new project and forwarding to on-premises DNS is irrelevant because the records you need live in the other VPC's private zone, not on the on-premises DNS server. Outbound forwarding in Cloud DNS sends queries for specified domains to an external resolver (e.g., on-premises), but on-premises DNS has no authoritative data for the other project's private zone; it would likely return NXDOMAIN or cause infinite forwarding. This option also implicitly assumes you want to override the zone, but you would need to replicate all records manually, which is error-prone and defeats the purpose of using Cloud DNS. The correct inter-VPC path is DNS peering, not forwarding to a hybrid resolver.

Go deeper

Related to this question