Practice Test #1

Multiple standalone VMs with a CPU alert threshold still requires manual action to add capacity (or scripting not mentioned). Standalone instances also lack managed autohealing and consistent rollout via instance templates. It doesn’t address the requirement for Google-recommended automatic scaling practices, and it doesn’t explicitly ensure multi-zone high availability across at least two zones in us-central1.

Replacing VMs with high-CPU instances is a vertical scaling approach that is slower and potentially disruptive (instance replacement/restart). It still relies on manual intervention and doesn’t inherently provide multi-zone resilience or managed autohealing. Vertical scaling also won’t handle a 10x spike as effectively as horizontal scaling with autoscaling instance counts.

Using an instance group is closer, but the option says you increase instances “whenever you see high CPU utilization,” which is manual and violates the requirement for automatic scaling without intervention. It also doesn’t specify spanning two zones; a zonal instance group would not meet the SLO requirement for availability across at least two zones in us-central1.

Incorrect. `gcloud config configurations activate prod-us` changes the active configuration, which the question explicitly forbids. Although `gcloud config list` would then show that configuration’s properties, this approach violates the requirement and uses more commands than necessary. On the exam, any option that changes state when the prompt requires read-only inspection should be ruled out.

Incorrect. `kubectl config get-contexts` reads Kubernetes contexts from kubeconfig, not gcloud named configurations. The question asks about the inactive gcloud configuration prod-us, so kubeconfig is the wrong source of truth for this task. Even though this command is read-only, it does not directly tell you what properties are set in prod-us.

Incorrect. `kubectl config use-context` changes the current Kubernetes context, which modifies kubeconfig state and violates the requirement. In addition, kubectl contexts are separate from gcloud named configurations, so switching contexts does not reveal what is stored in prod-us. This option both changes state and consults the wrong configuration system.

Incorrect. A TCP Proxy Load Balancer is a proxy-based external load balancer. It terminates the client TCP session at Google’s edge and then opens a separate connection to the backend. As a result, the backend typically sees a Google proxy source IP rather than the real client IP, which breaks per-client IP rate limiting based on source address at the VM.

Incorrect. An SSL Proxy Load Balancer is also proxy-based and is intended for SSL/TLS termination and proxying at L4. Like TCP Proxy, it does not preserve the original client source IP at the network layer because the proxy establishes a new connection to the backend. It’s useful for offloading TLS, but not for source-IP-based rate limiting on the VM.

Incorrect. An internal TCP Network Load Balancer is not internet-facing; it provides load balancing for private RFC1918 traffic within a VPC (and connected networks). The question explicitly requires the service to be publicly accessible on the internet, so an internal load balancer cannot meet the accessibility requirement even though it is L4.

Nearline Storage is intended for data accessed less than once per month. While it supports infrequent access, it is typically more expensive to store than Coldline. Given the stated access pattern (quarterly) and long retention (24 months), Nearline usually results in higher total storage cost without providing a meaningful benefit, unless reads were closer to monthly or operational constraints required lower retrieval costs.

Regional Storage refers to Standard storage in a single region (not an infrequent-access class). It is designed for frequently accessed data with low latency in that region. For 24-month retention with only occasional reads, Regional/Standard storage would be unnecessarily expensive compared to Coldline because you pay higher per-GB storage rates even though the data is rarely accessed.

Multi-Regional Storage is Standard storage replicated across multiple regions (legacy concept; commonly replaced by multi-region/dual-region location choices). It targets high availability and low latency for globally accessed, active content. For long-term retention with quarterly reads, it is the most expensive option among those listed due to higher storage costs, and it does not reduce retrieval charges enough to justify the premium.

Incorrect. This uses public internet egress and depends on resolving and allowlisting public IPs for storage.googleapis.com, which can change and are not intended for static firewall rules. It violates the constraints: no outbound internet access, no reliance on hard-coded public IPs, and the requirement that Google API traffic stay on private paths restricted to Google-controlled ranges.

Incorrect. A proxy VM in Google Cloud does not automatically make traffic private to Google APIs; the proxy still needs a path to reach Cloud Storage endpoints. Without additional configuration, it typically uses public internet/NAT or external IPs, which is disallowed. It also adds operational overhead and becomes a bottleneck/failure domain, and it’s not the recommended pattern versus Restricted Google APIs.

Incorrect. Migrating servers to Compute Engine is unnecessary and does not address the core requirement for on-prem access. An internal load balancer cannot use storage.googleapis.com as a backend in this way; Cloud Storage is not a backend service you can attach to an internal TCP/HTTP(S) load balancer. This option reflects a misunderstanding of load balancing and Cloud Storage access patterns.

Sharing charts from individual dashboards is not the intended mechanism for centralized, ongoing observability. It can create a fragmented experience and typically still relies on per-project dashboards and maintenance. It also doesn’t provide a true unified metrics exploration layer across projects (e.g., filtering/grouping by project in one place). This may look like “single pane of glass,” but it’s not the standard, scalable Cloud Monitoring approach.

Granting Monitoring Viewer on all three projects is necessary for access control, but it does not solve the “single pane of glass” requirement by itself. The SREs would still need to switch project context in the Cloud Console (or run separate queries per project) because there is no aggregated metrics scope. IAM answers “who can view,” not “where the unified view lives.”

Using default dashboards sequentially is explicitly not acceptable because it requires switching contexts (project-by-project). It also doesn’t provide cross-project charts, aggregated alerting, or a unified metrics explorer experience. While it is quick, it fails the core requirement of a single pane of glass across north-1, south-1, and west-1.

Incorrect. The prompt explicitly says you cannot change the billing model, and arranging a slot commitment/capacity pricing is a billing model change. Also, slot commitments are not typically “temporary” in the sense of a one-off query without administrative overhead and minimum commitment considerations. Even if possible, it’s not the required method to estimate on-demand query cost.

Incorrect. BigQuery on-demand analysis pricing is not based on bytes returned to the client; it is based on bytes processed by the query. While returning 50 million rows may have practical implications (time, client memory, export costs), it does not drive the core on-demand query charge in the way bytes processed does.

Incorrect. Row counts do not map directly to bytes processed because BigQuery charges by bytes read/processed, which depends on column sizes, selected columns, partition pruning, clustering, and query execution plan. Also, running SELECT COUNT(*) itself can scan large amounts of data and incur costs, defeating the purpose of a safe pre-estimate.

Vertical Pod Autoscaler only adjusts CPU and memory requests for pods; it does not create GPU-capable nodes or manage cluster infrastructure for specialized accelerators. It also may evict and recreate pods to apply updated recommendations, which is dangerous for long-running rendering jobs that cannot resume from checkpoints. Even if VPA improved resource sizing, it would not ensure that NVIDIA GPU capacity appears when work arrives. Therefore it does not address the core scheduling and cost problem in this scenario.

Preemptible VMs are explicitly the wrong choice for non-restartable jobs because they can be terminated by Google Cloud before the render completes. A 10–16 hour rendering task with no checkpointing would lose all progress if the node were reclaimed. Although this option reduces cost, it violates the requirement that jobs must not be interrupted. Cost savings cannot come at the expense of guaranteed completion for these workloads.

A dedicated GPU node pool with autoscaling is workable, but setting a minimum size of 1 means at least one GPU node runs continuously even when there is no work for most of the month. That directly conflicts with the requirement to minimize cost for a workload that appears only a few days each month. Autoscaling from a baseline of 1 also provides less savings than provisioning GPU nodes only when pending jobs exist. Because a more cost-efficient automatic scaling option exists, this is not the best answer.

Incorrect. gcloud container clusters update staging-ops modifies the cluster resource itself (e.g., node pool settings, add-ons, release channel, maintenance windows), not the local CLI defaults. It does not change what cluster future commands target by default. This option can look plausible because it includes the word “update,” but it updates the cluster configuration, not your gcloud environment.

Incorrect. Cloud SDK does not use a user-created file like ~/.gcloud/gke.default to set default cluster targeting. gcloud stores configuration properties via gcloud config in its managed configuration directories/files, and you should not invent custom files expecting gcloud to read them. This reflects a common misconception from other tools that use dotfiles for defaults.

Incorrect. There is no supported ~/.gcloud/defaults.json mechanism for setting gcloud defaults. While gcloud does maintain internal configuration state, it is managed through gcloud config set and named configurations, not by manually creating JSON files. On the exam, any answer involving creating arbitrary files for gcloud defaults is typically a red flag.