Your organization maintains a central Cloud DNS private zone named `corp.internal` that was initially associated with a Virtual Private Cloud (VPC) network named `mgmt-vpc`. You have created a new application network named `prod-vpc` within the same Google Cloud project. Virtual machines in `prod-vpc` need to resolve private domain names defined in `corp.internal` without exposing the DNS zone publicly or deploying dedicated proxy virtual machines. Which TWO actions must you perform to allow VMs in `prod-vpc` to resolve private hostnames in `corp.internal`? (Select TWO.)
- Edit the `corp.internal` Cloud DNS private zone configuration to add `prod-vpc` to the list of authorized VPC networks.Cevap
- Ensure that instance operating systems in `prod-vpc` send internal DNS queries to the default Google Cloud internal metadata DNS server address (`169.254.169.254`).Cevap
- CEnable the Cloud DNS API inside the individual `prod-vpc` subnet properties rather than enabling it at the Google Cloud project level.
- DAttach an IAM deny rule at the `prod-vpc` subnet resource level to prevent subnet-level resolution rules from overriding project-level Cloud DNS settings.
Cevap
The correct actions are to add the new VPC network to the authorized networks list of the existing Cloud DNS private zone, and to ensure that VMs in the network route internal DNS queries to the internal metadata DNS server address at 169.254.169.254.
To allow virtual machines in a new VPC to resolve records hosted in an existing Cloud DNS private zone, you must add the new VPC network to the zone's list of authorized networks. Additionally, workloads must use the standard Google Cloud metadata DNS resolver at 169.254.169.254, which handles lookup requests for all private zones authorized for that network.
Adım Adım Çözüm
Anahtar Kavram
Cloud DNS Private Zone Multi-VPC Authorization