Cloud Digital Leader Google Cloud Products and Services Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Use preemptible VMs for worker nodes

  Why this is correct

  Preemptible VMs (now called spot VMs in Google Cloud) provide a significantly discounted price (typically 60-80% off on-demand pricing) for worker nodes in a Dataflow batch pipeline. Because Dataflow is designed to handle worker loss through checkpointing and automatic restart of tasks, batch jobs are generally resilient to the occasional termination that preemptible VMs may undergo. This directly reduces the compute cost of the worker pool without changing the pipeline logic or delivery time, making it the most straightforward way to cut costs for a recurring batch job.

• ✗

  Shut down the Dataflow job between runs

  Why it's wrong here

  Shutting down the Dataflow job between runs is ineffective because Dataflow batch jobs are ephemeral by nature: each job spins up its own worker pool, processes the data, and automatically releases all resources upon completion. There is no persistent cluster or idle compute that continues to incur charges between scheduled runs, so the job ceases to exist cost-wise once it finishes. In fact, each scheduled run creates a brand-new job from scratch, so manually shutting down a job that is already terminated does nothing to lower the cost of the future runs.

• ✗

  Switch from batch to streaming mode

  Why it's wrong here

  Switching from batch mode to streaming mode would likely increase costs because streaming Dataflow jobs run continuously, holding a persistent set of workers that remain allocated even during periods of low or zero data ingress. These jobs also incur additional overhead for state management, windowing, and keeping the pipeline in a listening state, which leads to a higher overall resource consumption compared to a finite batch job. Since the workload is described as batch processing every hour, a streaming pipeline would process the same data but with a constant compute footprint, making it a more expensive option.

• ✓

  Set autoscaling to a lower maximum number of workers

  Why this is correct

  Setting autoscaling to a lower maximum number of workers reduces cost by capping the peak size of the worker pool that Dataflow can scale to in response to backlog. This prevents the job from spinning up an excessive number of workers during temporary spikes in input data, thereby limiting compute and memory costs; however, it may extend the total run time because fewer workers process the data concurrently. It is a valid cost control knob for batch workloads that are not time-sensitive, as the job will simply run longer but with a bounded resource ceiling.

• ✓

  Use flexible resource scheduling (batch mode)

  Why this is correct

  Flexible Resource Scheduling (or batch mode with flexible start time in Dataflow) is a job-level pricing option that enables Google Cloud to delay the start of a batch job until it finds available capacity, in exchange for a lower price than on-demand execution. This is designed for workloads that have no strict SLA on when they complete, making it a good fit for a scheduled every-hour batch job where some delay is acceptable. While it does not directly affect per-worker pricing like preemptible VMs, it lowers the overall job cost by using discounted, often idle, capacity in the region.

Go deeper

Related to this question