Practice Test #1

Incorrect. Creating VLAN attachments in service projects decentralizes hybrid connectivity administration. Even if attachments connect to the Shared VPC network, ownership and lifecycle management are spread across product teams, conflicting with the requirement that a centralized Network Engineering team administer all WAN links and routing. It also increases the risk of inconsistent BGP/route advertisement settings and complicates troubleshooting and governance.

Incorrect. Standalone projects with VLAN attachments per project require each project to manage its own hybrid connectivity constructs and routing, which violates the centralized administration requirement. It is also less cost-efficient at scale because each project may need its own Cloud Router sessions and attachment configuration, increasing operational overhead and making consistent routing policy enforcement harder.

Incorrect. Deploying both Interconnects and VLAN attachments in every project is the least cost-efficient and most operationally complex design. It duplicates expensive connectivity resources, increases port and attachment counts, and makes centralized routing control nearly impossible. Project-level isolation should be achieved through Shared VPC governance, IAM, and network segmentation rather than replicating physical Interconnect infrastructure.

Firewall rules logging records allow/deny decisions and some connection metadata in Cloud Logging, but it does not capture full packets or payloads. Forwarding logs to an IDS would not provide the raw traffic needed for deep packet inspection and signature-based detection. It also introduces log processing latency and does not meet the explicit “packet payloads” requirement.

VPC Flow Logs capture network flow metadata (e.g., src/dst IP, ports, protocol, bytes, packets, start/end time) and are useful for visibility and troubleshooting, not payload inspection. Even with a Logging sink and filtering for egress, you still cannot reconstruct packet contents. This fails the IDS requirement for mirrored packets with payloads.

An internal HTTP(S) load balancer is a proxy-based Layer 7 service and is not used as a Packet Mirroring collector. Packet Mirroring collectors require an internal passthrough Network Load Balancer (TCP/UDP) so the mirrored packets are delivered without L7 termination or protocol constraints. Additionally, “HTTP(S)” would not cover arbitrary egress traffic (non-HTTP) from the subnets.

Incorrect. You cannot create Cloud Router “in the VPC networks of all projects” to solve Shared VPC hybrid routing. Cloud Router is tied to a specific VPC network, and in Shared VPC the VPC network exists in the host project. Service projects don’t have separate VPC networks for the shared subnets; they attach to the host’s VPC. Multiple routers in multiple projects would not provide shared VPC route exchange.

Incorrect. Creating the Cloud Router in the Finance service project would not attach it to the Shared VPC host project’s VPC network. Service projects typically do not own the shared VPC network; they only use subnets from the host. As a result, the VLAN attachments/BGP sessions for the Dedicated Interconnect would not be correctly associated with the central VPC used by all departments.

Incorrect. R&D, HR, and Finance are service projects and do not each have their own VPC network for the shared subnets; they attach to the host project’s VPC. Creating separate Cloud Routers in each service project would not connect those routers to the shared VPC, and would not correctly terminate the VLAN attachments for the Dedicated Interconnect that must be associated with the host VPC.

A global external HTTP(S) load balancer provides an external anycast VIP and L7 routing, not a way to make VMs natively own addresses from an internal RFC1918 range like 192.168.70.0/24. It also introduces a new front end (a managed gateway) and is protocol-specific (HTTP/S). This violates the requirement to avoid new gateways and doesn’t satisfy “instances have addresses in both ranges.”

DNS records can direct clients to different IPs, but DNS does not assign IP addresses to VM interfaces. If the VM does not actually have 192.168.70.0/24 addresses configured, it cannot receive traffic destined to those IPs (unless another device/load balancer owns them). DNS is a naming solution, not an IP addressing mechanism, so it cannot meet the requirement.

VPC peering connects two separate VPC networks and exchanges routes, but it does not make a single VM interface hold IPs from two unrelated ranges. You would still need the 192.168.70.0/24 range to exist as a subnet/secondary range somewhere and a way to assign those IPs to the VM. Peering also adds architectural complexity and doesn’t meet the “same instances have addresses in both ranges” requirement.

Incorrect. Reserving a static external IP and using an external HTTP(S) load balancer creates an internet-reachable frontend by design. Even if backends are private, the forwarding rule is public and violates the requirement that the service be internal-only and not exposed. It also adds unnecessary cost and complexity compared to built-in internal DNS for VM discovery.

Incorrect. This option explicitly creates a public DNS A record and uses an external HTTP(S) load balancer with a static external IP. That contradicts the requirement to avoid public DNS records and to not expose the service. Even if access is restricted at the firewall, the endpoint is still publicly addressed and increases attack surface and operational overhead.

Incorrect. A short alias like https://metrics/v1/ is not something Compute Engine automatically provides. Default search domains are not guaranteed to resolve arbitrary hostnames unless you configure custom DNS (for example, a private Cloud DNS zone with an A record for “metrics”). Without that configuration, clients will fail to resolve the name, so it is not a reliable built-in solution.

Incorrect. Private Google Access is not enabled at the VPC level; it is configured per subnet. The exam often tests this scope detail. While organization policies and DNS can be centralized, the PGA on/off switch is a subnet attribute. Therefore, this option is not a valid configuration action in Google Cloud.

Incorrect. Private Services Access is used to access managed services privately over VPC peering (for example, Cloud SQL private IP) and is unrelated to accessing Google APIs like Cloud Storage JSON API or Cloud Logging API. It would not help bypass the firewall for Google APIs, nor does it address the routing requirement described.

Incorrect. Google APIs are not reached via internal RFC1918 addresses in your VPC; they are accessed via well-known VIP ranges (e.g., 199.36.153.4/30 and 199.36.153.8/30) when using private/restricted Google access. Routing to “internal IP addresses of Google APIs” via the default internet gateway is not a valid or meaningful configuration and would not achieve the goal.

Incorrect. Three standalone VPCs plus full-mesh HA VPN adds significant operational overhead (multiple gateways, tunnels, routing, monitoring) and cost. It also does not provide centralized control of subnets and firewall rules across projects; each VPC remains independently administered. VPN is better suited for hybrid connectivity or when encryption over the public internet is required, not for routine intra-org east-west connectivity.

Incorrect. Using three separate Shared VPC host projects would still split the environment into three distinct VPC networks, each with its own routing domain, firewall rules, and subnet administration. While a central team could manually coordinate IP allocations across those hosts, this design does not provide the single authoritative network control plane or the simplest east-west connectivity model requested. Inter-squad communication would still require additional constructs such as VPC Network Peering or VPN, which increases operational overhead compared with placing all squads in one Shared VPC.

Incorrect. VPC Network Peering reduces some overhead versus VPN, but still creates separate routing/security domains with decentralized firewall and route management in each VPC—contrary to the requirement for centralized control. Peering also introduces design constraints (no transitive peering; careful route exchange planning) and does not inherently prevent overlapping subnets unless you enforce IPAM externally. Shared VPC is the cleaner governance model here.

Incorrect. Adding static routes contradicts the requirement to learn future subnets automatically. Static routes would require manual changes whenever new VPC subnets are created or on-prem prefixes change. While Cloud Router can exist alongside static routes, static routing is not “dynamic routing” and is not the intended solution for BGP-based HA VPN connectivity.

Incorrect. A second HA VPN gateway is unnecessary because HA VPN already includes two interfaces designed for redundancy with two tunnels. Also, you generally do not create VPC firewall rules to allow BGP (tcp/179) to Cloud Router because Cloud Router is a managed control-plane service, not a VM endpoint in your VPC that receives BGP packets directly.

Incorrect. Enabling global dynamic routing may be useful if you need routes learned in asia-northeast1 to be available in other regions, but it does not replace the required Cloud Router + BGP configuration. Creating a second HA VPN gateway is also unnecessary. The missing core step is establishing BGP sessions via Cloud Router on the existing HA VPN gateway tunnels.

Opening a Cloud Support case is not the standard or required method to obtain an LOA-CFA. In normal Dedicated Interconnect provisioning, the LOA-CFA is available through self-service mechanisms (Console download and email to the NOC contact). Support may help only if there is an abnormal situation (e.g., LOA-CFA not generated, access issues, or incorrect contact details), but it’s not one of the primary actions expected on the exam.

Incorrect. The gcloud compute interconnects describe command returns resource metadata (state, location, link type, etc.) but does not directly download a LOA-CFA PDF as part of the standard CLI output. While APIs/console can expose LOA-CFA retrieval, the described command is not the typical or documented method to download the LOA-CFA document itself for cross-connect ordering.

Incorrect. Google does not generally send the LOA-CFA directly to the colocation provider as a fully hands-off process. The customer typically must provide the LOA-CFA to the provider to authorize and instruct the cross-connect. Telling the provider no action is needed risks missing the 5-business-day window and delaying circuit turn-up, impacting project timelines and redundancy goals.