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…

Question

Options

• A
  1. TEAM_ONE uses cross-project binding and creates Cloud DNS private zones and DNS
• B
  1. TEAM_ONE uses cross-project binding and creates Cloud DNS private zones and DNS
• C
  1. TEAM_ONE creates a new VPC (SP_ONE_VPC) in the Shared VPC service projects
• D
  1. TEAM_ONE creates a new VPC (SP_ONE_VPC) in the Shared VPC service projects

• A
  9% (2)
• B
  68% (15)
• C
  5% (1)
• D
  18% (4)

Explanation

In this scenario, using cross-project binding is the simplest and most efficient way to allow each team to create and manage their own DNS private zones while ensuring that workloads across both service projects can resolve DNS records across the Shared VPC. Cross-project binding: This feature allows private DNS zones created in the service projects (SP_ONE_PRJ and SP_TWO_PRJ) to be associated with the Shared VPC (SH_VPC) in the host project (SH_HOST_PRJ). It enables DNS queries for those zones to be resolved by workloads attached to the Shared VPC. Centralized connectivity: Since all workloads in both service projects (SP_ONE_PRJ and SP_TWO_PRJ) use the Shared VPC (SH_VPC), no additional VPCs or VPC peering setups are required, minimizing setup effort. Team independence: Each team manages their DNS private zones and records independently within their respective service projects, fulfilling the requirement for decentralization. This design achieves the desired DNS resolution while requiring the least amount of setup effort compared to solutions involving new VPCs, DNS peering, or VPC Network Peering.

No community discussion yet for this question.