Associate Cloud Engineer

Cloud Storage Data Access audit logs record read (and write) operations performed on objects and buckets, including who performed them, whereas Admin Activity audit logs only record configuration and metadata changes and do not track data access events. Because Data Access audit logs (other than BigQuery) are disabled by default due to their volume, they must be explicitly enabled for the buckets that need to be audited. Once enabled, the resulting log entries can be viewed and filtered in the Logs Explorer (log viewer) by filtering on the Cloud Storage resource type, giving the auditor the ability to see who accessed the data in those buckets.

Organization Policy controls WHAT resources can be created (resource restrictions), while IAM controls WHO can take actions (identity-based access). Creating a folder to organize projects and applying an organization policy constraint to restrict resource locations to US fulfills the requirement. Organization policies cascade to child resources and projects within the folder.

Cloud Spanner provides the optimal solution for multiplayer gaming requiring consistent performance across global users. It offers strong ACID transactions, global distribution, automatic scaling, and high availability—all with minimal operational complexity. Bigtable excels at massive scale but is NoSQL; Cloud SQL cannot scale horizontally across regions.

Access Approval requires the roles/accessapproval.approver IAM role to grant users permission to approve or dismiss access requests from Google support/engineering staff. Google's IAM best practices recommend managing access through Google Groups rather than assigning roles directly to individual user accounts, because groups simplify access management, provide easier auditing, and reduce administrative overhead as team membership changes. Therefore, the correct approach is to add the SREs to a Google group and grant that group the roles/accessapproval.approver role. The roles/iam.roleAdmin role is unrelated to Access Approval—it only controls the ability to create and manage custom IAM roles—so it does not enable approval of support access requests.

Google's documented solution for this scenario is Private Google Access for on-premises hosts. It requires establishing private connectivity between the on-premises network and a Google Cloud VPC using Cloud VPN or Cloud Interconnect, then using Cloud Router to advertise a custom route for the restricted.googleapis.com virtual IP range (199.36.153.4/30) over that tunnel so on-premises traffic destined for Google APIs is routed privately rather than over the public internet. On the on-premises side, DNS must be configured so that requests to *.googleapis.com (including storage.googleapis.com) resolve via a CNAME to restricted.googleapis.com, which resolves to the 199.36.153.4/30 VIP range. Because this IP range is never announced publicly and is only reachable through the private VPN/Interconnect link, on-premises bare-metal servers can reach Cloud Storage without ever having a public IP address or open internet egress, while restricted.googleapis.com additionally limits access to only APIs/services supported by VPC Service Controls, reducing data-exfiltration risk. See Google Cloud's documentation, 'Private Google Access for on-premises hosts' and 'Configure Private Google Access for on-premises hosts.'