Cloud Digital Leader Google Cloud Products and Services Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Assign external IPs to the VMs and use firewall rules.

  Why it's wrong here

  Assigning external IPs directly violates the requirement that the VMs have no public IP addresses, unnecessarily exposing them to the internet and expanding the attack surface. Firewall rules govern network traffic to and from VM instances, but they do not control access to Cloud Storage buckets, which is enforced by IAM and VPC Service Controls. Therefore, even with restrictive firewall rules, the bucket would remain reachable by other external IPs and the architecture would not satisfy the stated constraint.

• ✗

  Create a bucket with uniform bucket-level access and grant the `storage.objectViewer` role to `allUsers`.

  Why it's wrong here

  Uniform bucket-level access is an IAM setting for consistency, but granting storage.objectViewer to allUsers turns the bucket into a public-read resource, allowing anyone with the bucket URL to list and download objects. This is the opposite of restricting access to a specific set of VMs; it ignores network context entirely. Moreover, the VMs would still need a way to reach the bucket via Private Google Access, and public IAM does not provide any access restriction based on VPC membership.

• ✗

  Use a Cloud VPN to connect the VMs to the bucket.

  Why it's wrong here

  Cloud VPN creates an encrypted IPsec tunnel between an on-premises network and Google Cloud VPC, and it is not used for communication between VMs inside the same VPC and Google-managed services. Since the VMs and the bucket are both in Google Cloud, the VPN does not provide a data path or additional security boundary for accessing Cloud Storage. The correct path for VM-to-Google API traffic without public IPs is Private Google Access, so this solution is unnecessary and technically misguided.

• ✓

  Enable Private Google Access on the subnet and use VPC Service Controls to limit bucket access to the VPC.

  Why this is correct

  Enabling Private Google Access on the VM's subnet allows instances with only internal IPs to reach Google APIs and services, including Cloud Storage, through the VPC's internal routing and the default gateway. VPC Service Controls add a security perimeter that explicitly restricts bucket access to the VPC network, preventing access from the public internet or other networks within the organization. Together they enforce the requirement: the VMs remain without public IPs, and the bucket's access is limited to the VPC, not just any Google-authenticated identity.

Go deeper

Related to this question