4 of the 8 questions we have for this objective, shown with the answer and the reasoning.
Designing a cloud solution infrastructure that meets technical requirements
Brisbay Outdoor sells camping gear from a site hosted in us-central1. Product images and videos are stored in a Cloud Storage bucket and make up 85 percent of the bytes served. Customers in Australia and Europe report slow page loads, and the company wants to cut latency for these users with the least change to the application.
What should you do?
- AMove the bucket to a dual-region location in the United StatesA dual-region bucket improves availability within the United States but does not bring content closer to users in Australia or Europe.
- BIncrease the machine type of the web servers in us-central1Larger web servers do not reduce the network distance to far-away users, and most of the bytes come from the bucket rather than the servers.
- CChange the bucket storage class from Standard to NearlineNearline is a lower-cost class for infrequently accessed data and adds retrieval charges; it does not improve latency.
- DServe the bucket through a backend bucket on a global external Application Load Balancer and enable Cloud CDNCloud CDN caches the static images and videos at Google edge locations near users, which cuts latency for distant customers without changing the application.
Why: Latency for distant users is mostly a distance problem, so the fix is to put content closer to them. For static objects, Cloud CDN in front of a Cloud Storage backend bucket caches content at Google edge locations worldwide. Bucket location type and storage class change availability and price, not proximity to users. Scaling compute is a common distractor when most of the slow content is static.
Designing a cloud solution infrastructure that meets technical requirements
Northgate Credit Union runs core workloads on Compute Engine VMs and Cloud SQL. After a ransomware incident at a peer institution, the board requires that backups be kept for at least 90 days and that no one, including project owners and administrators whose accounts are compromised, can delete or shorten the retention of a backup before that period ends. Backup management should be central across 15 projects.
Which solution should you recommend?
- APersistent disk snapshot schedules with a 90-day retention in each projectSnapshot schedules automate backups, but a user with sufficient IAM permissions in the project can delete snapshots, so they are not protected from compromised administrators.
- BBackup and DR Service with backup vaults that use an enforced minimum retention of 90 daysBackup vaults store backups in an isolated, immutable store, and an enforced minimum retention prevents anyone from deleting backups or reducing retention before the period ends, managed centrally across projects.
- CCloud SQL automated backups with retention set to 90 daysCloud SQL backups cover only the databases, and their retention settings can be changed by an administrator of the instance.
- DA nightly script that copies disk images to a Cloud Storage bucket with Object Versioning enabledVersioning keeps old object versions, but anyone with delete rights can still remove them, and a custom script adds maintenance with no central management.
Why: Ransomware-resistant backup design needs isolation and immutability, not only a schedule. Backup and DR Service stores backups in backup vaults, which are separate from the source projects and can enforce a minimum retention that even privileged users cannot override. It also gives one place to manage policies for VMs and Cloud SQL across many projects. Project-level snapshots and native backups are useful, but they share the fate of the project's administrators.
Designing a cloud solution infrastructure that meets technical requirements
Calder Insurance has a Cloud Run service that started returning HTTP 500 errors after a recent deployment. The on-call engineer is new to Google Cloud and wants an assistant inside the Google Cloud console that can look at the service's logs, errors, and configuration in the context of the project, explain what it finds in natural language, and suggest likely causes and next steps. The team will not build or train any tooling for this.
What should the engineer use?
- AGemini Cloud Assist in the Google Cloud console, asking it about the failing Cloud Run serviceGemini Cloud Assist is built into the console, uses the project's resources, logs, and errors as context, and gives troubleshooting guidance and next steps in natural language without any tooling to build.
- BA custom model trained on the project's logs with Gemini Enterprise Agent PlatformTraining a model is a large data science effort and is not needed, because Gemini Cloud Assist already provides troubleshooting help for Google Cloud resources.
- CRecommender cost recommendations for the Cloud Run serviceRecommender suggests cost, performance, and security improvements but does not analyze a live error to find its cause.
- DCloud Asset Inventory exports to BigQueryAsset Inventory shows resource metadata and history, but the engineer would still need to write queries and correlate errors manually.
Why: Gemini Cloud Assist is the AI assistant built into the Google Cloud console for operators and architects. It answers questions about the project's resources, helps design, deploy, and optimize workloads, and helps troubleshoot by exploring logs, metrics, and errors with natural language in project context. The scenario's constraints, a new engineer working in the console and no tooling to build, point to the built-in assistant. Building a custom model or exporting data to BigQuery are possible, but they require far more effort and still leave the analysis to the engineer.
Designing a cloud solution infrastructure that meets technical requirements
Wrenfield Imaging processes medical scans with workers on a Compute Engine managed instance group. Uploads publish a message to a Pub/Sub subscription, and each worker pulls messages and takes about 30 seconds per scan. Upload volume is growing 20 percent per quarter and is very uneven during the day. CPU usage on the workers stays near 60 percent whether the backlog is empty or has 50,000 messages, so the current CPU-based autoscaling does not react to the backlog.
How should you configure autoscaling?
- ALower the CPU utilization target of the autoscaler to 30 percentBecause CPU stays flat regardless of backlog, a lower CPU target only adds a fixed amount of idle capacity and still does not respond to the queue.
- BSet the managed instance group to a fixed size based on the peak backlogA fixed size sized for peaks wastes money most of the day and will fall behind again as volume grows 20 percent per quarter.
- CAutoscale the managed instance group on the Pub/Sub subscription's undelivered message count as a per-group Cloud Monitoring metric with a target number of messages per instanceScaling on backlog per instance adds workers when messages pile up and removes them when the queue drains, which matches the real demand signal for queue-based workers.
- DAutoscale on the HTTP load balancing serving capacity of the instance groupThe workers pull from Pub/Sub and are not behind a load balancer, so there is no request rate for this signal to measure.
Why: Scale on the metric that represents demand. For pull-based workers, demand is the queue, not CPU, so the managed instance group autoscaler should use the Pub/Sub undelivered messages metric with a target per instance. This lets capacity follow both the daily pattern and long-term growth without manual resizing. CPU and load balancer signals are correct for request-serving tiers, which is why they appear as distractors here.