GCP Professional Cloud Architect Practice Question

An enterprise runs nightly Spark-based extract-transform-load (ETL) jobs on a regional managed instance group (MIG) of standard Compute Engine VMs. Each run processes 7 TB of data stored in Cloud Storage and writes checkpoints back to the same bucket every 10 minutes, allowing the job to resume after a failure. Management wants to reduce compute cost while preserving the current four-hour completion window and keeping operational effort low. Additional constraints are:

Instances must not have public IP addresses.
Engineers want to keep using gcsfuse to mount the Cloud Storage bucket.
Any interruptions should be handled automatically so that jobs finish within the window without manual intervention.

Which deployment approach best meets all requirements?

Create a GKE Autopilot cluster and deploy the ETL code as Kubernetes CronJobs; Autopilot will automatically place the pods on Google-managed nodes and restart them after preemption events.
Provision a GKE Standard cluster with a node pool consisting of Spot VMs that have no public IPs and are behind Cloud NAT; run the Spark workload as Kubernetes CronJobs that use gcsfuse mounts and let Kubernetes reschedule pods when nodes are preempted.
Replace the MIG with a regional MIG that uses Spot VMs without external IP addresses; configure instance startup scripts to relaunch the Spark job after each preemption.
Deploy the ETL pipeline as a Cloud Run job that mounts the Cloud Storage bucket with gcsfuse and relies on Cloud Scheduler to trigger nightly executions.

Report Issue

Answer Description

Running the workload as Kubernetes CronJobs on a GKE Standard cluster whose sole node pool uses Compute Engine Spot VMs delivers the largest discount while still satisfying operational and technical constraints:

− GKE Standard supports creating node pools backed entirely by Spot VMs, which are up to 91% cheaper than regular on-demand VMs. When a Spot VM is preempted, the node pool's autoscaler automatically provisions a replacement, and the Kubernetes control plane reschedules the interrupted pods. Because the Spark job checkpoints to Cloud Storage every 10 minutes, the job can restart and still meet the four-hour SLA. − Nodes in the pool can be created without external IP addresses and reach the internet (if needed) through Cloud NAT, satisfying the no-public-IP requirement. − The Cloud Storage FUSE CSI driver (or gcsfuse in a container image) lets pods mount the bucket exactly as on the current VMs, so no code changes are required.

The other options fail to meet one or more constraints:

A GKE Autopilot cluster does not allow you to specify Spot or preemptible capacity; although Google may run Autopilot on discounted infrastructure, pods are not exposed to preemption and the pricing discount is smaller, so cost-saving potential is lower.
Migrating to Cloud Run jobs removes the ability to use gcsfuse mounts and may exceed CPU-second quotas, risking the four-hour SLA.
Converting the existing MIG to Spot VMs keeps costs down, but you must build custom logic for instance replacement, health checks, and job restarts, increasing operational overhead compared with Kubernetes' built-in rescheduling.

Ask Bash

Bash is our AI bot, trained to help you pass your exam. AI Generated Content may display inaccurate information, always double-check anything important.