An enterprise cloud infrastructure team is provisioning a Virtual Private Cloud (VPC) network to host internal database workloads across two regions (`us-east1` and `us-west1`). The database instances are deployed on Compute Engine virtual machines (VMs) that do not have external IP addresses assigned. The architecture requires that these private instances securely download software patches from public internet repositories and send automated backups to Google Cloud Storage endpoints, while remaining completely inaccessible to inbound traffic from the public internet. Which TWO configuration steps should the cloud architect implement to meet these requirements?
- Enable Private Google Access on the subnets where the Compute Engine instances reside.Answer
- Configure Cloud Routers and Cloud NAT gateways in both us-east1 and us-west1 regions.Answer
- CEstablish a VPC Network Peering connection to an intermediate VPC network with an internet gateway, relying on peer route transit.
- DDeploy HA VPN gateways in both regions and configure static 0.0.0.0/0 routes pointing to Cloud Storage endpoints.
- EConfigure VPC Service Controls perimeter rules to dynamically assign temporary public IP addresses for egress repository access.
Answer
The correct configurations are to enable Private Google Access on the subnets housing the private VM instances and to deploy Cloud Routers with Cloud NAT gateways in both regions.
To allow private Compute Engine VMs without public IP addresses to securely communicate with Google APIs (such as Cloud Storage), Private Google Access must be enabled at the subnet level. To allow these same private VMs to initiate outbound connectivity to external internet repositories for software updates without allowing inbound public connections, Cloud NAT must be deployed alongside Cloud Router in each region.
Step-by-Step Solution
Key Concept
Subnet-level Private Google Access and Cloud NAT configuration for private VPC topology egress
Estimated Time:1m 30s