Cross-Project Cloud DNS Zone Binding in a Shared VPC

PCNE By islever Editorial Last updated

Configuring Cloud DNS. Configuring VPCs.

Short answer

B Have each team create private zones in its own service project and cross-project bind them to SH_VPC in SH_HOST_PRJ so both teams' workloads resolve each other's zones.

Question

Your organization's current architecture has one Shared VPC host project (SH_HOST_PRJ) that contains a single VPC (SH_VPC) and two Shared VPC service projects (SP_ONE_PRJ and SP_TWO_PRJ) that do not contain any VPCs. Each Shared VPC service project belongs to a different team: TEAM_ONE manages SP_ONE_PRJ and TEAM_TWO manages SP_TWO_PRJ.
You must design a solution that allows each team to create their own DNS private zones and DNS records only in their respective Shared VPC service projects. Workloads in SP_ONE_PRJ must be able to resolve all the DNS private zones defined in SP_TWO_PRJ and conversely. Your design must have the least amount of set up effort. What should you do?
    1. TEAM_ONE uses cross-project binding and creates Cloud DNS private zones and DNS records in SP_ONE_PRJ, and binds the zones to the Shared VPC host project (SH_HOST_PRJ). 2. TEAM_TWO creates Cloud DNS private zones and DNS records in SP_TWO_PRJ, and uses cross-project binding to connect the zones to the Shared VPC host project (SH_HOST_PRJ).
    1. TEAM_ONE uses cross-project binding and creates Cloud DNS private zones and DNS records in SP_ONE_PRJ, and binds the zones to the VPC (SH_VPC) in the Shared VPC host project (SH_HOST_PRJ). 2. TEAM_TWO creates DNS private zones and DNS records in SP_TWO_PRJ and uses cross-project binding to connect the zones to the VPC (SH_VPC) in the Shared VPC host project (SH_HOST_PRJ).
    Correct Answer
    1. TEAM_ONE creates a new VPC (SP_ONE_VPC) in the Shared VPC service projects (SP_ONE_PRJ). TEAM_ONE creates Cloud DNS private zones and DNS records in SP_ONE_PRJ, and binds the zones to the new VPC (SP_ONE_VPC). TEAM_ONE creates a Cloud DNS peering relationship between SP_ONE_VPC and the VPC (SH_VPC) in the Shared VPC host project (SH_HOST_PRJ). 2. TEAM_TWO completes the same actions for the SP_TWO_PRJ project.
    1. TEAM_ONE creates a new VPC (SP_ONE_VPC) in the Shared VPC service projects (SP_ONE_PRJ). TEAM_ONE creates Cloud DNS private zones and DNS records in SP_ONE_PRJ, and binds the zones to the new VPC (SP_ONE_VPC). TEAM_ONE creates a VPC Network Peering relationship between SP_ONE_VPC and the VPC (SH_VPC) in the Shared VPC host project (SH_HOST_PRJ). 2. TEAM_TWO completes the same actions for the SP_TWO_PRJ project.

Key Takeaways

It tests that a Cloud DNS private zone attaches to a VPC network — via cross-project binding — not to a project, and that one shared VPC gives mutual resolution without new VPCs or peering.

This PCNE question tests Cloud DNS cross-project binding in a Shared VPC design. The answer is option B: create each team's private zones in its own service project and bind them to SH_VPC in the host project.

Common mistake: Option A is the tempting near-miss: it describes the same cross-project approach but says to bind the zones to the host project SH_HOST_PRJ, which is not how private zone attachment works; zones bind to SH_VPC.

Expert Analysis

The governing rule A Cloud DNS private zone is attached to one or more VPC networks, never to a Google Cloud project by itself. That is why option A, which says to bind the zones to the host project SH_HOST_PRJ, is not a valid configuration: there is no "bind to project" operation for private zones. Option B describes the actual mechanism — cross-project binding — where a private zone created in SP_ONE_PRJ or SP_TWO_PRJ is attached to the VPC network living in another project, here SH_VPC inside SH_HOST_PRJ.

Mapping the scenario Both service projects contain no VPC of their own; their workloads run in SH_VPC through Shared VPC. If TEAM_ONE's zone is cross-project bound to SH_VPC, every VM in SH_VPC — and therefore every workload in SP_ONE_PRJ and SP_TWO_PRJ — resolves it, and the same holds for TEAM_TWO's zones. Mutual resolution falls out of the fact that all workloads share one network, so no additional DNS infrastructure is required.

Least setup effort Options C and D each require provisioning two brand-new VPCs, then adding either Cloud DNS peering or VPC Network Peering plus zone configuration. That is far more work, and VPC peering (D) does not by itself make private zones resolvable across networks — DNS peering in C would, but only after the extra VPCs exist. Neither is needed here because a single VPC already spans both teams.

Why B over A Option A's substance is nearly identical, as one comment observes, but its wording binds zones to a project rather than to SH_VPC, which is the technically correct target. Option B is therefore the correct choice, matching the comment that notes you bind zones to VPCs, not projects. The decisive answer is B.

Official Reference

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

Exam Strategy

When a DNS question mentions Shared VPC, first identify which network the workloads actually live in — here only SH_VPC — because private zones attach to VPC networks, not projects or service projects. Then rank options by effort: any choice that creates extra VPCs or peering is usually avoidable when one network already spans the teams, so prefer the single cross-project binding option. Be precise about wording: an option naming the correct target network beats one describing the same idea against the wrong resource.

Frequently Asked Questions

Why can't a private zone be bound directly to the host project?

Private zone attachment targets VPC networks, not Google Cloud projects, so there is no project-level binding. The correct target is SH_VPC in SH_HOST_PRJ, attached via cross-project binding.

Do both service projects need their own VPCs for cross-team DNS resolution?

No. Because SP_ONE_PRJ and SP_TWO_PRJ workloads run in the Shared VPC's SH_VPC, binding each team's zones to SH_VPC makes them resolvable everywhere without new VPCs or peering.

What does Cloud DNS cross-project binding actually do?

It lets you create a private zone in one project (the service project) while attaching it to a VPC network in another project (the host project), keeping zone administration with the owning team.

More PCNE FAQ →

Community Votes

B
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

  1. n2183712847 👍 2 Answered B
    Option B correctly leverages Cloud DNS's cross-project binding feature to allow each team to manage their own DNS zones in their respective service projects while ensuring that DNS records are resolvable by workloads in both service projects through the shared VPC, with minimal setup effort.
  2. 1f01b87 👍 2 Answered B
    B is correct
  3. Positron75 👍 1
    The difference is that A talks specifically about binding the zones to the host project, while B mentions binding them to the VPC in the host project. Since you bind zones to VPCs rather than projects directly, B is correct.
  4. kirrim 👍 1
    Am I crazy? I think A and B are saying the same thing, and are both correct?

Reader comments & corrections

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

Log in to comment, report an error, or add a note about this question.

Configuring Policy-Based VPN for Non-BGP On-Premises Networks

S-grade

Deploying Packet Mirroring Policies in GCP Regions

S-grade

Troubleshooting Asymmetric Traffic on Google Cloud Interconnect

S-grade

Hub-and-Spoke Centralized Egress with VPC Peering

S-grade

Practice All PCNE Questions

Access 80 questions with complete answers and detailed explanations.

View Full PCNE Practice Test →

← Back to PCNE Study Guide