An enterprise organization operates a hub-and-spoke topology across multiple Google Cloud projects. The hub project hosts private managed DNS zones for centralized internal microservices. The security team has defined the following requirements for all spoke VPC networks: Spoke VPCs must be able to query and resolve internal DNS records hosted in the hub project's private managed zones without replicating zone files across projects. The organization must mitigate data exfiltration and block malicious domains by overriding resolution for threat indicators to point to an internal sinkhole IP address, while allowing specific trusted subdomains to bypass these overrides. Service identities managing spoke infrastructure must follow the principle of least privilege, possessing only the permissions required to target the hub network for DNS resolution without administrative access to DNS records. Which combination of Cloud DNS security and architecture controls should the security engineer deploy?

Create Cloud DNS Peering Zones in the spoke VPC networks targeting the hub VPC network as the DNS producer network; configure Cloud DNS Response Policies associated with the spoke VPC networks that define local data sinkhole records and bypassResponsePolicy behavior rules; and grant the roles/dns.peer role to the spoke service identities on the hub project.: ### What Cloud DNS Peering, Response Policies, and DNS IAM roles are **Cloud DNS Peering Zones**, **DNS Response Policies (RPZ)**, and the **DNS Peer role (`roles/dns.peer`)** provide a secure, scalable framework for centralized name resolution, granular traffic redirection, and least-privilege administrative access across multi-project Google Cloud environments. ### How it meets the cross-VPC resolution requirement A **Cloud DNS peering zone** is a private zone configured in a consumer network (the spoke VPC) that forwards DNS queries for a given namespace to a producer network (the hub VPC). This allows instances in spoke VPCs to query private records hosted centrally in the hub network without needing VPC network peering at the data plane or duplicating zone records across spoke projects. ### How it meets the security and exfiltration mitigation requirement **Cloud DNS Response Policies** act as a response policy zone (RPZ) mechanism applied directly to VPC networks. They evaluate DNS queries before standard resolution paths: - **Threat mitigation / Sinkholing**: By adding response policy rules with `localData`, queries matching malicious or unauthorized domains are intercepted and resolved to an internal sinkhole IP address (or NXDOMAIN). - **Bypass exceptions**: By configuring specific subdomain rules with the `--behavior=bypassResponsePolicy` attribute, trusted domain lookups bypass policy matching and resolve normally through authoritative zones or upstream resolvers. ### How it meets the least-privilege IAM requirement The predefined **`roles/dns.peer`** (DNS Peer) role allows an identity to establish a DNS peering link pointing to a VPC network in the target project without granting permissions to view, alter, or delete individual resource record sets or private managed zones in that target project. ### Key advantages and capabilities - **Centralized zone governance**: Eliminates record synchronization drift across disparate VPC networks. - **Zero-trust DNS perimeter enforcement**: Enforces response policy rules at the Google Cloud SDN resolver layer without requiring on-premises appliances or dedicated DNS forwarder VMs. - **Strict privilege separation**: Keeps record creation (`roles/dns.admin`) segregated from network peering binding (`roles/dns.peer`).

Cloud Dns Peering Response Policies Sinkhole | Professional Cloud Security Engineer

Cloud Dns Peering Response Policies Sinkhole

Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.

An enterprise organization operates a hub-and-spoke topology across multiple Google Cloud projects. The hub project hosts private managed DNS zones for centralized internal microservices. The security team has defined the following requirements for all spoke VPC networks:

Spoke VPCs must be able to query and resolve internal DNS records hosted in the hub project's private managed zones without replicating zone files across projects.
The organization must mitigate data exfiltration and block malicious domains by overriding resolution for threat indicators to point to an internal sinkhole IP address, while allowing specific trusted subdomains to bypass these overrides.
Service identities managing spoke infrastructure must follow the principle of least privilege, possessing only the permissions required to target the hub network for DNS resolution without administrative access to DNS records.

Which combination of Cloud DNS security and architecture controls should the security engineer deploy?

Deploy Cloud DNS Forwarding Zones in each spoke VPC targeting the Cloud DNS metadata address 169.254.169.254; attach Cloud Armor security policies to intercept malicious DNS domain queries; and grant the roles/compute.networkAdmin role to the spoke service identities.

Configure VPC Network Peering with custom route export between all spoke VPCs and the hub VPC; deploy Cloud DNS Outbound Server Policies with Type 2 alternative name servers to filter malicious queries; and grant the roles/dns.admin role to the spoke service identities on the hub project.

Create duplicate private managed zones in each spoke VPC containing identical A and CNAME records; create VPC firewall egress rules matching malicious domain names; and grant the roles/dns.reader role to the spoke service identities on the hub project.

Create Cloud DNS Peering Zones in the spoke VPC networks targeting the hub VPC network as the DNS producer network; configure Cloud DNS Response Policies associated with the spoke VPC networks that define local data sinkhole records and bypassResponsePolicy behavior rules; and grant the roles/dns.peer role to the spoke service identities on the hub project.

Professional Cloud Security Engineer

Cloud Dns Peering Response Policies Sinkhole

Related questions