Google Professional Cloud Architect Sample Questions

Following a cyber incident at Rivertown Outfitters that left key production workloads down for almost three weeks, the newly hired CISO requires a control that prevents production Compute Engine virtual machines from obtaining external IP addresses unless an explicit exception is approved. You want a straightforward solution that aligns with Google recommendations and that you can enforce centrally across projects. What should you do?

• ❏ A. Use VPC Service Controls to place production projects in a service perimeter and block access to the public internet

• ❏ B. Replace default internet gateway routes with Cloud NAT so that all production subnets use private egress only

• ❏ C. Apply the Organization Policy constraint constraints/compute.vmExternalIpAccess at the organization or folder and allow only the explicitly approved VM resource names

• ❏ D. Build two custom VPC networks so that one hosts approved instances with a default route and the other hosts all remaining instances without a default route

Design a Google Cloud data warehouse for time series telemetry that minimizes scanned data and avoids server management. What should you implement?

• ❏ A. Query external files with BigQuery external tables

• ❏ B. Cloud Bigtable

• ❏ C. BigQuery with date partitioned telemetry

• ❏ D. AlloyDB for PostgreSQL

Your team runs a retail checkout application on Google Kubernetes Engine. Customers report that the checkout component is not responding. You observe that every pod in the checkout deployment crashes and restarts about every 3 seconds. The service writes its logs to standard output. You want to quickly examine the runtime errors that are causing the restarts without disrupting production. What should you do?

• ❏ A. Review the Cloud Logging entries for each Compute Engine VM that is acting as a GKE node

• ❏ B. Use Cloud Trace to inspect latency traces for the checkout service

• ❏ C. Inspect the affected GKE container logs in Cloud Logging using the workload and container filters

• ❏ D. Use kubectl to exec into one pod and tail the application logs from inside the container

Which GCP compute services provide automatic scaling and minimal operations for long term application hosting after an initial lift and shift to Compute Engine? (Choose 2)

• ❏ A. Managed instance groups

• ❏ B. Google Kubernetes Engine

• ❏ C. Google Dataproc

• ❏ D. Google App Engine Standard

BlueMonk Retail needs to move a 25 TB on premises database export into Cloud Storage and their link to Google Cloud averages 300 Mbps and the team wants to minimize total transfer time and overall cost while following Google recommended best practices for large dataset migration. What should you do?

• ❏ A. Use gcloud storage cp to copy the files from the data center to a Cloud Storage bucket

• ❏ B. Configure Storage Transfer Service with an on premises agent to move the export into Cloud Storage

• ❏ C. Order Transfer Appliance and ingest the export by shipping the device to Google

• ❏ D. Build a Cloud Dataflow job that reads directly from the source database and writes to Cloud Storage

In a Compute Engine managed instance group, how can you apply a new instance template only to future VMs and keep existing instances unchanged? (Choose 2)

• ❏ A. Set PROACTIVE rollout with RECREATE

• ❏ B. Use OPPORTUNISTIC updates and let autoscaling add instances

• ❏ C. Create a new managed instance group and shift traffic with a load balancer

• ❏ D. Use OPPORTUNISTIC updates and manually resize the group

You are the Cloud Security Administrator at Orion Pixel Labs where teams build games on Google Cloud. The development and quality assurance groups collaborate and need access to each other’s environments, yet you discover they can also access staging and production which raises the risk of accidental outages. One staging environment used for performance tests must copy a subset of production data every 36 hours. How should you restructure the environment to keep production isolated from all other environments while still allowing the required data transfer?

• ❏ A. Place development and test resources in a single VPC and place staging and production resources in a different VPC

• ❏ B. Create one project for development and test together and create separate projects for staging and production

• ❏ C. Keep all environments in one project and enforce a VPC Service Controls perimeter around production data

• ❏ D. Deploy development and test workloads to one subnet and deploy staging and production workloads to another subnet

Which GCP services provide low latency and durable session storage, durable object storage for user photos and exported VM images, and log archiving with lifecycle tiering after 90 days?

• ❏ A. Local SSD for sessions and Cloud Storage with lifecycle for logs, photos and exported VM images

• ❏ B. Memcache with Cloud Datastore for sessions and Cloud Storage with lifecycle for logs, photos and exported VM images

• ❏ C. Memorystore for Redis for sessions and Persistent Disk SSD for exported VM images and Cloud Storage for logs and photos

• ❏ D. Memorystore for Memcached for sessions and Cloud Storage with lifecycle for logs, photos and exported VM images

FinchPay, a financial technology company, sees sporadic slowdowns when confirming card charges and the payment path crosses multiple microservices on Google Cloud. The engineers believe interservice latency is the cause and they want to isolate exactly which backend services add the extra time during a request. What should they do to identify the services responsible for the delays?

• ❏ A. Enable Cloud Logging for every backend service and search the logs for error patterns

• ❏ B. Turn on Cloud Profiler across the services to analyze CPU and memory usage

• ❏ C. Instrument the application with Cloud Trace and view distributed traces to see end to end latency across calls

• ❏ D. Place an external HTTP(S) Load Balancer in front of the services to distribute requests evenly

Which Google Cloud resource hierarchy enables a central team to enforce organization wide IAM guardrails while each department manages access to its own projects?

• ❏ A. Single Organization with one shared Folder and central IAM

• ❏ B. Multiple Organizations per department

• ❏ C. Single Organization with per-department Folders and delegated IAM

All GCP questions come from my Google Cloud Architect Udemy course and certificationexams.pro

You are the architect for LumaBooks, an online publisher, and you operate a production service on Cloud Run for Anthos in a GKE cluster. A new release is ready and you want to direct about 20% of real user traffic to it so that you can validate performance and errors before promoting it fully. How should you test the new build with a limited portion of production traffic?

• ❏ A. Create a parallel Cloud Run service for the new build and place an external HTTPS load balancer in front to weight traffic across both services

• ❏ B. Configure Traffic Director with a new service entry that targets the new version and set a small weighting to route a fraction of requests

• ❏ C. Deploy the new version as a revision within the existing Cloud Run service and use traffic splitting to route a small percentage to that revision

• ❏ D. Set up a Cloud Build trigger on a feature branch and pass a substitution variable named TRAFFIC_PERCENT to control how much traffic goes to the new version

Which Google Cloud design provides private low latency hybrid connectivity and prevents overlapping IP ranges with on premises while supporting growth for the next five years?

• ❏ A. Default VPC with HA VPN

• ❏ B. Auto mode VPC with Cloud Interconnect

• ❏ C. Custom VPC with unique CIDRs and Dedicated Interconnect

Riverton Analytics plans to automate the rollout of a Compute Engine managed instance group for a latency sensitive service. Each VM requires numerous OS packages and during peak events the group scales from 8 to 160 instances and must make new VMs ready to serve quickly. What should you implement to automate the deployment while keeping instance startup time to a minimum?

• ❏ A. Use Google Cloud OS Config guest policies to install the required packages on instances in the managed instance group after they start

• ❏ B. Build a custom Compute Engine image that includes all required OS packages and use Deployment Manager to create the managed instance group with this image

• ❏ C. Provision the managed instance group with Terraform and use a startup script to download and install the OS packages during initialization

• ❏ D. Use Puppet to configure the instances after the managed instance group is created so that manifests install the necessary OS packages

Which approach minimizes cost for interruptible batch workloads on Google Cloud while ensuring only HIPAA eligible services are used?

• ❏ A. Multi year committed use discounts for Compute Engine

• ❏ B. Spot VMs for interruptible batches and remove non HIPAA services

• ❏ C. Standard VMs with VPC Service Controls

Your team at a fintech startup is deploying a single second generation Cloud SQL for MySQL instance that stores mission critical payment records. Leadership wants the design to minimize data loss if a regional outage or other catastrophic event occurs. Which features should you enable to reduce potential data loss to the lowest practical level? (Choose 2)

• ❏ A. Semisynchronous replication

• ❏ B. Automated backups

• ❏ C. Sharding

• ❏ D. Binary logging

• ❏ E. Read replicas

Which Compute Engine architecture provides autoscaling, global low latency, and multi-zone high availability for a REST API with spikes around 120 thousand requests per second?

• ❏ A. Zonal managed instance group per region with external HTTPS load balancing

• ❏ B. Regional managed instance groups behind an external TCP proxy

• ❏ C. Regional autoscaled MIGs per region with a global external HTTPS load balancer

Nimbus Outfitters uses BigQuery as its enterprise data warehouse and the datasets are spread across nine Google Cloud projects. Finance requires that every query charge is billed to one central analytics project and that no costs accrue in the projects that store the data. Analysts must be able to read and run queries but must not change or create datasets. How should you assign IAM roles to meet these requirements?

• ❏ A. Add the analysts to a group, then grant the group BigQuery Data Viewer on the billing project and BigQuery Job User on the projects that host the datasets

• ❏ B. Add the analysts to a group, then grant the group BigQuery Data Owner on the billing project and BigQuery Metadata Viewer on the projects with the datasets

• ❏ C. Place all analysts in a group and assign BigQuery Job User on the dedicated billing project and BigQuery Data Viewer on every project that stores the datasets

• ❏ D. Add the analysts to a group, then grant the group BigQuery User on the billing project and BigQuery Data Viewer on the projects that host the datasets

Which configuration lets App Engine standard reach an on-prem MySQL over private IP through an existing Cloud VPN?

• ❏ A. Private Service Connect

• ❏ B. Serverless VPC Access connector

• ❏ C. Private Google access

• ❏ D. Private services access

StellarPlay Studios has replatformed parts of its mobile game backend into independent microservices that expose HTTP REST APIs over HTTPS. The company needs to achieve near continuous availability because outages cause user churn and it must keep latency low for a global player base while scaling quickly during traffic spikes. Considering these goals and the nature of the APIs, how should you design the backend on Google Cloud platform?

• ❏ A. Use a Layer 4 TCP Load Balancer with Compute Engine VMs in a managed instance group limited to one zone in several regions

• ❏ B. Use a Layer 7 HTTPS Load Balancer with Compute Engine VMs in a managed instance group limited to one zone in several regions

• ❏ C. Use a Layer 7 HTTPS Load Balancer with Compute Engine VMs in managed instance groups distributed across multiple zones in multiple regions

• ❏ D. Use a Layer 4 TCP Load Balancer with Compute Engine VMs in managed instance groups spread across multiple zones in multiple regions

How should you centralize raw logs from all Google Cloud projects and retain them for 10 years in a simple and cost effective way for auditor access?

• ❏ A. Export logs from all projects to BigQuery

• ❏ B. Use aggregated sinks to export all logs to Cloud Storage

• ❏ C. Stream all logs to Pub/Sub

• ❏ D. Centralize logs in a Cloud Logging bucket with custom retention

The correct option is Apply the Organization Policy constraint constraints/compute.vmExternalIpAccess at the organization or folder and allow only the explicitly approved VM resource names.

This control provides a centrally enforced guardrail that denies external IP assignment by default across all targeted projects. It supports a narrow allowlist so you can approve only specific instances when there is a justified exception. It aligns with recommended practices because it is simple to roll out at the organization or folder level and is auditable and reversible.

Use VPC Service Controls to place production projects in a service perimeter and block access to the public internet is incorrect because VPC Service Controls protect access to Google managed APIs and services rather than controlling generic internet egress or the ability for VM interfaces to obtain external IP addresses.

Replace default internet gateway routes with Cloud NAT so that all production subnets use private egress only is incorrect because Cloud NAT enables outbound connectivity for instances without external IPs and does not stop users from assigning external IPs to instances. It also does not replace the default internet gateway route and therefore does not meet the requirement to prevent external IP allocation.

Build two custom VPC networks so that one hosts approved instances with a default route and the other hosts all remaining instances without a default route is incorrect because this design is operationally complex and easy to bypass and it does not centrally prevent the assignment of external IPs. It lacks a policy based approval mechanism and does not scale well across projects.

The correct choice is BigQuery with date partitioned telemetry. It meets the requirement to minimize scanned data for time series analytics and it removes server management through a fully managed serverless warehouse.

With BigQuery you can partition tables by ingestion time or by a timestamp column so queries automatically prune partitions and scan only the relevant dates. Partition filters and optional clustering on device or metric fields further reduce bytes processed and improve performance while you pay only for the data scanned. The service is serverless so capacity provisioning and maintenance are handled by Google.

Query external files with BigQuery external tables does not minimize scanned data for analytical workloads because queries read data from external storage and often cannot benefit from native partition pruning and columnar storage. Performance and cost control are better with native partitioned tables for this use case.

Cloud Bigtable is a NoSQL key value database for low latency operational access rather than a SQL analytics warehouse for telemetry. It also requires instance sizing and node management which does not satisfy the requirement to avoid server management.

AlloyDB for PostgreSQL targets transactional and mixed workloads on managed PostgreSQL and it is not a columnar analytics warehouse. You must manage instances and storage settings and large scans are not minimized the way they are with partitioned analytical storage.

Inspect the affected GKE container logs in Cloud Logging using the workload and container filters is correct.

This option is best because the application writes to standard output and GKE automatically collects container stdout and stderr to the centralized logging backend. You can scope by workload and container in the logs interface to focus on the checkout deployment and view the exact error messages that occur before each crash. This approach requires no interaction with running pods and it continues to capture messages even as the pods restart every few seconds.

Review the Cloud Logging entries for each Compute Engine VM that is acting as a GKE node is incorrect because node level logs are noisy and focus on system and kubelet activity. Application stdout from containers is organized under Kubernetes resources, so looking at VM entries is slower and makes it easy to miss the container errors you need.

Use Cloud Trace to inspect latency traces for the checkout service is incorrect because Trace is for distributed request latency and requires instrumentation. It does not surface crash stack traces or the stderr and stdout messages that explain why the pods are restarting.

Use kubectl to exec into one pod and tail the application logs from inside the container is incorrect because the pods are restarting every few seconds which makes an interactive session unreliable. It also touches production containers and provides no aggregated history across restarts, so it is slower and less reliable than using centralized logs.

The correct options are Google Kubernetes Engine and Google App Engine Standard.

Google Kubernetes Engine offers a managed Kubernetes control plane with automatic scaling for nodes and pods and it can run in Autopilot mode where Google manages the cluster infrastructure. This reduces day to day operations while still providing robust scaling and reliability for long term application hosting after an initial lift and shift to Compute Engine.

Google App Engine Standard is a fully managed application platform where you deploy code and the platform handles provisioning, autoscaling, patching and health. It requires minimal operations and is well suited for stable long running services once the workload has been migrated.

Managed instance groups can autoscale virtual machine instances and integrate with load balancing, yet you still manage operating systems, images, startup logic and many lifecycle tasks. This makes them more operationally heavy than managed application platforms for long term hosting.

Google Dataproc is designed for data processing with Spark and Hadoop and its autoscaling focuses on batch or ephemeral clusters. It is not intended for always on application hosting.

The correct option is Order Transfer Appliance and ingest the export by shipping the device to Google.

At 300 Mbps, moving 25 TB over the network would take roughly a week or more when you include protocol overhead and potential retries. Transfer Appliance is built for large one time migrations over limited bandwidth since you copy locally and ship the device to Google which shortens wall clock time and improves reliability. It can also reduce operational disruption because the corporate link is not saturated for days.

Use gcloud storage cp to copy the files from the data center to a Cloud Storage bucket depends entirely on the 300 Mbps link so the transfer would take many days and would require you to manage retries and throughput tuning. This does not minimize time for a 25 TB migration.

Configure Storage Transfer Service with an on premises agent to move the export into Cloud Storage gives managed scheduling and checksumming, yet it still uses the same constrained link so total duration would be similar. This service is better when you have recurring transfers over sufficient bandwidth rather than a one time bulk move at this size and speed.

Build a Cloud Dataflow job that reads directly from the source database and writes to Cloud Storage is not appropriate here because you already have an export and this approach adds development and run cost without solving the bandwidth bottleneck.

The correct options are Use OPPORTUNISTIC updates and let autoscaling add instances and Use OPPORTUNISTIC updates and manually resize the group.

With OPPORTUNISTIC updates, the managed instance group accepts the new instance template but does not proactively restart or recreate existing virtual machines. If you let autoscaling add instances, each newly created instance uses the new template while existing instances remain unchanged, which achieves the goal without disruption.

You can achieve the same outcome by combining OPPORTUNISTIC updates with manually resize the group. Increasing the target size creates new instances from the updated template while leaving the current instances intact. You can later scale in to retire older instances on your own schedule.

Set PROACTIVE rollout with RECREATE is incorrect because a proactive rollout triggers replacement of existing instances so the new template is applied to current machines, which changes them.

Create a new managed instance group and shift traffic with a load balancer is unnecessary for this scenario and changes the architecture rather than using the update policy to apply the template only to future instances within the same group.

The correct option is Create one project for development and test together and create separate projects for staging and production. This keeps production isolated with its own project boundary while allowing development and test to collaborate in a shared project. You can still enable a controlled cross project data flow from production to staging on the required 36 hour schedule.

Projects are the primary isolation boundary for IAM, policy, quotas, and network scope in Google Cloud. By putting staging and production in their own projects you prevent broad access overlap and you reduce the risk of accidental outages in production. Grant a dedicated service account in staging narrowly scoped read access to only the specific datasets or buckets in production that need to be copied. Schedule the transfer every 36 hours using Cloud Scheduler to trigger a job such as Storage Transfer Service or a Dataflow pipeline so the movement is one way and least privilege.

Place development and test resources in a single VPC and place staging and production resources in a different VPC is incorrect because VPCs are network boundaries and do not enforce administrative or IAM isolation. It also groups staging with production which violates the requirement to keep production isolated from all other environments.

Keep all environments in one project and enforce a VPC Service Controls perimeter around production data is incorrect because VPC Service Controls focuses on reducing data exfiltration for supported services and does not replace project level isolation or protect compute resources. Keeping everything in one project keeps IAM and quotas coupled and increases the chance of accidental access to production.

Deploy development and test workloads to one subnet and deploy staging and production workloads to another subnet is incorrect because subnets are not security or administrative boundaries for IAM. It also places staging with production which does not meet the isolation requirement.

The correct option is Memcache with Cloud Datastore for sessions and Cloud Storage with lifecycle for logs, photos and exported VM images.

This combination satisfies all requirements. Memcache provides very low latency access for session data while Cloud Datastore supplies durable storage so sessions can be recovered and shared across instances. For user photos, exported VM images and log archiving, Cloud Storage is the right durable object store and it supports lifecycle management so objects can automatically transition to a colder tier after 90 days. Note that Cloud Datastore is now Firestore in Datastore mode and App Engine Memcache is a legacy feature, so newer answers may reference Memorystore plus Firestore to describe a similar pattern for low latency with durable backing.

Local SSD for sessions and Cloud Storage with lifecycle for logs, photos and exported VM images is incorrect because Local SSD is ephemeral and attached to a single VM which means data can be lost on VM stop or host events and it is not a shared or durable session store.

Memorystore for Redis for sessions and Persistent Disk SSD for exported VM images and Cloud Storage for logs and photos is incorrect because Persistent Disk is block storage and does not provide object storage features or lifecycle policies for exported images, which are typically stored in Cloud Storage. In addition, Memorystore for Redis does not provide durable persistence for session data.

Memorystore for Memcached for sessions and Cloud Storage with lifecycle for logs, photos and exported VM images is incorrect because Memcached is an in memory cache without durability, so it cannot meet the requirement for durable session storage by itself.

The correct option is Instrument the application with Cloud Trace and view distributed traces to see end to end latency across calls.

This approach gives you distributed tracing that stitches together spans across all microservice hops on a single request. By propagating context across service boundaries, each hop is timed and visualized on a timeline so you can see exactly where latency accumulates. You can drill into spans for RPCs and HTTP calls to find the slow backend or dependency and quantify its contribution to total request time.

Enable Cloud Logging for every backend service and search the logs for error patterns is not sufficient for pinpointing cross service latency. Logs are valuable for diagnostics and errors, yet they do not automatically correlate an entire request path across services or provide precise per hop timing without full tracing instrumentation.

Turn on Cloud Profiler across the services to analyze CPU and memory usage focuses on code level resource usage inside a process. Profiler helps find hot methods and memory issues, but it does not show network or interservice latency along a distributed call path.

Place an external HTTP(S) Load Balancer in front of the services to distribute requests evenly does not address latency within a multi hop service chain. Load balancing can improve availability and distribution but it does not provide visibility into which downstream service adds delay.

The correct option is Single Organization with per-department Folders and delegated IAM.

This structure lets a central team apply organization wide guardrails using Organization level IAM and Organization Policy while delegating day to day access control to department administrators at the Folder level. IAM policies inherit from Organization to Folder to Project which allows the central team to set baseline constraints and audit requirements while each department manages access to its own projects within its folder.

This approach balances centralized governance with decentralized ownership. It supports clear separation of duties and simplifies compliance because guardrails are enforced at the highest level while local teams retain autonomy for their resources.

Single Organization with one shared Folder and central IAM is incorrect because it concentrates all control in a single folder and central team which prevents departments from independently managing access to their projects. It does not provide the delegated administration the question requires.

Multiple Organizations per department is incorrect because creating separate organizations fragments governance and prevents consistent organization wide policies and IAM guardrails. Centralized auditing and policy enforcement become difficult and cross organization controls are limited.

The correct option is Deploy the new version as a revision within the existing Cloud Run service and use traffic splitting to route a small percentage to that revision.

This approach uses Cloud Run revisions and weighted traffic routing so you can send about twenty percent of production requests to the new revision while keeping the remainder on the stable one. You can adjust the percentages up or down and then quickly roll forward or roll back based on results, which is the intended canary pattern for Cloud Run and works the same on Cloud Run for Anthos.

Create a parallel Cloud Run service for the new build and place an external HTTPS load balancer in front to weight traffic across both services is unnecessary and adds complexity because Cloud Run already provides built in weighted routing between revisions within a single service. Managing two separate services behind a load balancer complicates deployment and rollback without providing benefits for this scenario.

Configure Traffic Director with a new service entry that targets the new version and set a small weighting to route a fraction of requests is not the recommended method for Cloud Run canary releases. Cloud Run handles revision level traffic splitting natively, and introducing Traffic Director for this purpose adds control plane overhead and does not align with the simple per revision routing model built into the platform.

Set up a Cloud Build trigger on a feature branch and pass a substitution variable named TRAFFIC_PERCENT to control how much traffic goes to the new version is incorrect because Cloud Build manages builds and automation rather than live traffic routing. There is no built in traffic control through such a substitution and traffic allocation must be configured on the Cloud Run service itself.

The correct option is Custom VPC with unique CIDRs and Dedicated Interconnect. This design gives private low latency hybrid connectivity and avoids overlapping IP ranges with on premises while allowing ample room to scale for the next five years.

A custom VPC lets you select your own RFC 1918 ranges so you can align with enterprise IP address management and ensure that Google Cloud subnets do not overlap with existing on premises networks. Choosing unique CIDRs up front supports clean growth as you add projects, regions, and services over time.

Dedicated Interconnect delivers private physical connectivity that bypasses the public internet, which provides consistent low latency and high throughput with an SLA. You can scale capacity and reach by adding circuits and VLAN attachments, which supports sustained growth without redesigning the network.

Default VPC with HA VPN is not a good fit because the default network is auto mode with many precreated subnets that use fixed ranges that can conflict with your on premises space. HA VPN rides over the public internet, so latency and jitter are less predictable than a private interconnect.

Auto mode VPC with Cloud Interconnect does provide private connectivity, but auto mode preallocates regional subnets from a predefined block, which can lead to overlap or inefficient address use. Meeting the requirement to prevent overlap and plan multi year growth calls for custom subnet design rather than auto mode.

The correct option is Build a custom Compute Engine image that includes all required OS packages and use Deployment Manager to create the managed instance group with this image.

Prebaking all required packages into a custom image removes time consuming installation steps from instance boot. A managed instance group that uses an instance template pointing to this image can scale rapidly because new VMs begin from an image that already has everything needed to serve traffic. This keeps initialization short and supports fast scale out from 8 to 160 instances during peak events.

Deployment Manager can provision the managed instance group and instance template consistently. The key success factor is the custom image that minimizes startup time. Deployment Manager is currently in maintenance mode and newer guidance often prefers Terraform, yet the principle of using a prebaked image remains the fastest path to readiness.

Use Google Cloud OS Config guest policies to install the required packages on instances in the managed instance group after they start is slower because packages are installed post boot. That increases the time before an instance becomes ready and can delay serving during sudden scale out.

Provision the managed instance group with Terraform and use a startup script to download and install the OS packages during initialization still incurs package installation at boot. Even with efficient scripting, downloading and installing many packages increases startup time and undermines rapid readiness.

Use Puppet to configure the instances after the managed instance group is created so that manifests install the necessary OS packages introduces agent installation and convergence time. This is reliable for configuration drift control but is too slow for latency sensitive scale out because instances must complete configuration runs before they are ready.

The correct option is Spot VMs for interruptible batches and remove non HIPAA services.

This choice minimizes compute cost by using discounted interruptible capacity that fits batch processing which can tolerate reclamation. Resilient batch jobs can checkpoint and retry so they complete even if an instance is reclaimed while the deep discount keeps spending low.

Compliance is preserved by using only services that are listed as HIPAA eligible under the Business Associate Addendum and by excluding any products that are not covered. This keeps protected health information within covered services while still taking advantage of the savings offered by interruptible capacity.

Multi year committed use discounts for Compute Engine is not the best fit because commitments reduce cost for steady and predictable usage rather than interruptible batch jobs that are sporadic. It also does not ensure that only HIPAA eligible services are used.

Standard VMs with VPC Service Controls does not minimize compute cost for batch work since standard instances are priced at on demand rates. VPC Service Controls help reduce data exfiltration risk, yet they do not change which services are HIPAA eligible or provide the large cost savings needed for this use case.

The correct options are Automated backups and Binary logging.

Automated backups create consistent base backups of your instance so you always have a recent restore point. When combined with Binary logging, Cloud SQL can perform point in time recovery by restoring the last backup and then replaying the binary logs to a precise timestamp. This combination minimizes potential data loss to the smallest practical window because you can recover up to just before the outage or incident.

Binary logging records every change after the last backup and is required for point in time recovery. Without Binary logging you would only be able to restore to the time of the last backup. Without Automated backups there is no base image to which the logs can be applied. Enabling both features together is the standard approach in Cloud SQL to achieve a low recovery point objective.

Semisynchronous replication is not a Cloud SQL managed feature for MySQL and Cloud SQL replicas use asynchronous replication. It does not apply to a single instance design and it would not guarantee minimal data loss in this managed service.

Sharding is a scalability pattern that partitions data across multiple instances. It does not provide a recovery mechanism and it does not reduce potential data loss for a single instance workload.

Read replicas are designed for read scaling and are replicated asynchronously. An Read replicas setup can lag behind the primary and can lose recent transactions during a failover or promotion, so it is not the best way to minimize data loss. Read replicas do not replace Automated backups and Binary logging for point in time recovery.

The correct option is Regional autoscaled MIGs per region with a global external HTTPS load balancer.

This design gives you autoscaling that reacts to sudden traffic spikes because managed instance groups can scale out based on load metrics. It also delivers global low latency because the global external HTTPS load balancer uses anycast to route users to the nearest healthy backend. High availability is achieved because regional managed instance groups distribute instances across multiple zones within each region which provides zone level redundancy and faster recovery from failures.

The global HTTPS load balancer terminates TLS and provides application aware features that are essential for a REST API. It supports advanced health checks and connection draining which helps keep latency stable during failover and scale events. Placing regional managed instance groups behind it lets each region scale independently while the global control plane spreads requests across regions when needed.

Zonal managed instance group per region with external HTTPS load balancing is less resilient because a zonal group runs in only one zone in each region which creates a single zone failure risk and reduces availability compared to a regional group that spans multiple zones.

Regional managed instance groups behind an external TCP proxy does not fit a REST API requirement because the TCP proxy is a layer four load balancer and does not provide HTTP and HTTPS application layer features such as URL routing and HTTP health checks and Cloud CDN integration that a REST service typically needs.

The correct option is Place all analysts in a group and assign BigQuery Job User on the dedicated billing project and BigQuery Data Viewer on every project that stores the datasets.

This assignment ensures that queries are billed only to the central analytics project because query jobs are charged to the project where the job runs. Granting Job User on the billing project lets analysts create and run jobs there so costs do not accrue in the projects that host the data. Granting Data Viewer on the dataset projects provides read access to tables and views while preventing changes to schemas or data and it also prevents creating new datasets.

With this combination analysts can reference datasets across projects while their jobs execute in the billing project. They cannot create or modify datasets because they do not have BigQuery User or Data Owner on any project.

Add the analysts to a group, then grant the group BigQuery Data Viewer on the billing project and BigQuery Job User on the projects that host the datasets is incorrect because it would cause analysts to run queries in the dataset projects which would bill charges to those projects. Data Viewer on the billing project does not help with centralized billing.

Add the analysts to a group, then grant the group BigQuery Data Owner on the billing project and BigQuery Metadata Viewer on the projects with the datasets is incorrect because Data Owner allows creating and modifying datasets which violates the requirement to prevent changes. Metadata Viewer only permits viewing metadata and does not allow reading table data so analysts could not query the data.

Add the analysts to a group, then grant the group BigQuery User on the billing project and BigQuery Data Viewer on the projects that host the datasets is incorrect because BigQuery User includes the ability to create datasets which the requirement explicitly forbids.

The correct configuration is Serverless VPC Access connector.

Serverless VPC Access connector allows App Engine standard to send traffic into your VPC network, which can then traverse your existing Cloud VPN to reach the on premises MySQL instance over private IP. App Engine standard instances do not natively sit in your VPC, so the connector provides the needed egress path for private RFC 1918 destinations. With proper routes and firewall rules, the connector enables the application to reach the database privately across the VPN.

Private Service Connect is used to privately publish or consume services within Google Cloud, typically for producer and consumer service endpoints. It does not provide a path for App Engine standard to reach an on premises database through Cloud VPN.

Private Google access lets resources without external IPs reach Google APIs and services using private connectivity. It does not enable connectivity to on premises networks or arbitrary private IP addresses, so it does not satisfy the requirement.

Private services access establishes private IP connectivity to certain Google managed services such as Cloud SQL using private IP in your VPC. It is not used to connect to self hosted databases in an on premises environment over Cloud VPN.

The correct option is Use a Layer 7 HTTPS Load Balancer with Compute Engine VMs in managed instance groups distributed across multiple zones in multiple regions. This approach matches HTTPS REST APIs, delivers global load balancing for low latency, and provides resilience and rapid scaling for near continuous availability.

An external HTTPS load balancer is global and uses anycast so players connect to the nearest edge and are routed to healthy backends in the closest region. Managed instance groups spread across multiple zones remove zonal single points of failure and support health checks and autoscaling to handle sudden traffic spikes. Having backends in more than one region reduces user latency worldwide and allows fast failover if a region becomes impaired. Terminating TLS at the edge improves connection performance for mobile users while HTTP aware health checks and routing ensure only healthy services receive traffic.

Use a Layer 4 TCP Load Balancer with Compute Engine VMs in a managed instance group limited to one zone in several regions is not suitable because a TCP load balancer is not HTTP aware and typically does not provide the global HTTPS features needed for REST APIs, and restricting each region to one zone creates a single point of failure that undermines availability.

Use a Layer 7 HTTPS Load Balancer with Compute Engine VMs in a managed instance group limited to one zone in several regions uses the right load balancer type but still limits each region to one zone, which means a zonal outage would take the service in that region offline and this does not meet near continuous availability.

Use a Layer 4 TCP Load Balancer with Compute Engine VMs in managed instance groups spread across multiple zones in multiple regions distributes capacity well but it is the wrong load balancer type for HTTPS APIs since it lacks HTTP level routing and health checks, and it does not provide the global HTTP specific capabilities that best serve a worldwide player base.

The correct option is Use aggregated sinks to export all logs to Cloud Storage.

An aggregated sink at the organization or folder level captures logs from all descendant projects and routes them to a single Cloud Storage bucket. Cloud Storage is well suited for long term retention because you can apply a bucket retention policy for ten years and optionally use retention lock for immutability. You can place the data in Coldline or Archive storage classes to minimize cost while keeping access simple for auditors through straightforward IAM permissions and object browsing.

Export logs from all projects to BigQuery is not the simplest or most cost effective choice for decade long retention. BigQuery is optimized for analytics and querying rather than low cost archival, so you would pay for storage and incur query costs, and auditors typically need straightforward file access rather than SQL queries.

Stream all logs to Pub/Sub is incorrect because Pub/Sub is a messaging service and not a long term storage solution. Its message retention is limited and it is intended to fan out streams to downstream systems rather than keep raw logs for many years.

Centralize logs in a Cloud Logging bucket with custom retention is less appropriate for a ten year retention target and auditor access. While Logging buckets can increase retention, keeping data inside Logging is generally more expensive over long durations and does not provide the simple object based access and bucket level retention controls that Cloud Storage offers.