Simulado Google Cloud Professional Cloud Network Engineer

Instances with only internal IPs reach Google APIs and services when Private Google Access is enabled on their subnet, and they reach the general internet for updates through Cloud NAT, which provides managed source NAT without giving the VMs public IPs. Assigning ephemeral external IPs is wrong because it directly violates the no-external-IP mandate; a public IP is not required for outbound updates when Cloud NAT is present. Treating an alias IP range as an external NAT address is wrong because alias IPs are internal RFC 1918 addresses from the subnet's primary or secondary range, not public NAT addresses. Peering to a 'Google-owned VPC' for external connectivity is wrong because that is not how Private Google Access or internet egress works, and Private Google Access is a per-subnet setting available in both custom and auto mode VPCs, not auto mode only.

Using an ingress allow for TCP 22 from the IAP range 35.235.240.0/20 with a network tag or service-account target is correct: firewall rule targets can be specified by network tag or by service account, both of which follow the VM regardless of its IP, so autoscaled instances are automatically covered as long as they carry the tag/SA — and 35.235.240.0/20 is the published source range that IAP TCP forwarding uses. Scoping the rule to the subnet primary ranges is wrong because a firewall rule's *target* is what selects which VMs the rule applies to; subnet ranges are source/destination CIDRs, not targets, so this would apply broadly to every VM in those subnets rather than only the 'bastion-managed' ones. Allowing TCP 22 from 0.0.0.0/0 and relying on IAP IAM is wrong because opening 22 to the entire internet violates least privilege and secure-by-default — and IAP's protection only applies if traffic actually goes through IAP; an open rule lets non-IAP sources reach SSH directly. Maintaining a named IP range updated by an autoscaling hook is wrong because firewall targets cannot be arbitrary IP lists, and hand-syncing IPs is exactly the fragile, race-prone approach the requirement says to avoid; tags/service accounts solve this natively.

Connectivity Tests evaluates the configuration along the path and can surface DNS-related problems such as a private zone not being visible to the source network, and pairing it with a live query against the internal metadata resolver from the workload directly proves whether the name resolves from that exact endpoint — addressing the zone-association and forwarding hypotheses without making changes. VPC Flow Logs would only show that UDP 53 flows did or did not occur; absence of flows does not distinguish a zone-visibility/forwarding misconfiguration from many other causes, so it is an indirect guess. Packet mirroring would capture DNS packets, but Cloud DNS private resolution is handled by the internal metadata server and an NXDOMAIN at the wire level still wouldn't tell you that the root cause is a missing zone association — it diagnoses symptoms, not the config. Firewall Rules Logging only confirms allow/deny of DNS traffic to the resolver, which is a narrower question than whether the private zone is actually associated with the network and able to resolve the record.