Your company recently migrated to Google Cloud. You configured separate Virtual Private Cloud (VPC) networks for Department A and Department B. You need to configure both VPC networks to have access…

Question

Options

• ACustomize the operating system DNS configuration files to target the on-premises DNS servers.
• BKeep the different VPC networks from both departments isolated with different on-premises links,
• CPeer Department A's and Department B's VPC networks to have all on-premises connectivity via
• DConfigure a Cloud DNS Peering zone in Department A's VPC network pointing to Department B's

• A
  6% (2)
• B
  3% (1)
• C
  12% (4)
• D
  79% (27)

Explanation

Option D is correct because Cloud DNS Peering zones let Department A's VPC delegate DNS resolution to Department B's VPC - where a Cloud DNS forwarding zone is configured to send conditional queries to on-premises DNS servers - without requiring full VPC peering. This means both departments reach on-premises DNS through a managed, low-overhead Cloud DNS configuration, while their data plane traffic stays fully isolated via their separate VPN/Interconnect links.

A is wrong because manually editing OS-level DNS config files (e.g., /etc/resolv.conf) is high operational overhead - it must be maintained per VM and doesn't scale or benefit from Cloud DNS's managed service features.

B is wrong because while keeping separate on-premises links satisfies the isolation requirement, it doesn't address how conditional DNS forwarding is implemented - it leaves the DNS problem unsolved without a managed solution.

C is wrong because VPC peering between Department A and B would violate the "full isolation between VPC networks" requirement; VPC peers share route tables and can route traffic to each other.

Memory tip: Think "DNS Peering != VPC Peering." Cloud DNS Peering shares only DNS resolution, not network routes - so you get on-premises DNS access in both VPCs without punching a hole in your network isolation.

No community discussion yet for this question.