Cloud Digital Leader Fundamental Cloud Concepts 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.

• ✗

  Preemptible VMs

  Why it's wrong here

  Preemptible VMs are transient instances that Google Cloud can terminate at any time, typically within 24 hours, to reclaim capacity for other customers. For a one-time complex data transformation that is not designed to be checkpointed and resumed, an unexpected termination would require restarting the entire job from scratch, potentially losing hours of processing work. While they are significantly cheaper, the cost savings do not justify the high risk of failure for a critical, non-recoverable workload. If the job cannot tolerate interruptions, preemptible VMs should be avoided.

• ✗

  Committed use discount VMs for 1 year

  Why it's wrong here

  Committed use discounts entail a contractual obligation to pay for a fixed number of VMs for a 1-year or 3-year term, which is fundamentally mismatched to a single, one-time transformation that runs for only a short duration. You would be paying for the entire commitment period even though the job completes in hours, making this the most expensive option by far. Moreover, commit types are tied to specific machine families and regions, limiting flexibility if the job's requirements change. For a one-off workload, the discount offered never offsets the cost of idle, dedicated capacity.

• ✗

  Dataflow with preemptible workers

  Why it's wrong here

  Dataflow with preemptible workers attempts to reduce cost by using spot-like workers, but those workers can be terminated at any time, forcing Dataflow to recompute any lost intermediate state. While Dataflow provides automatic restart and checkpointing, the job's wall-clock time and total cost can increase significantly due to repeated recomputation, especially for a complex transformation with many stages. Additionally, Dataflow's managed service overhead and per-job charges often make it more expensive than a simple VM for a one-time batch task that doesn't need streaming or autoscaling. The risk of delays and cost overruns makes this a poor fit for a single, deadline-sensitive job.

• ✓

  Standard VMs (on-demand) and delete them after the job

  Why this is correct

  Standard on-demand VMs provide guaranteed availability for as long as you need them, with no upfront commitment or termination risk. You can select an instance size matching your transformation's requirements, run the job, and then delete the VM immediately afterward, paying only for the precise compute time consumed. This approach offers direct control over the environment, simplifies debugging, and is cost-effective for a one-time workload because there are no hidden service fees or prolonged obligations. For a job that must complete reliably once, a standard VM that is deleted after use is the most straightforward and dependable choice.

Go deeper

Related to this question