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.

• ✗

  Use committed use discounts for 1 year on GPU instances

  Why it's wrong here

  Committed use discounts (CUDs) require a 1- or 3-year commitment and are designed for steady-state, always-on workloads. For a finite batch analysis job that will finish and shut down, you would continue paying for reserved GPU capacity even after the workload completes, and you forfeit the 60-80% savings offered by preemptible VMs. Since the workload is transient, the long-term commitment makes CUDs economically suboptimal here.

• ✗

  Use regular VMs with both CPU and GPU on the same instance

  Why it's wrong here

  Using a single regular VM with both CPU and GPU forces you to provision a fixed-size instance that must accommodate both phases, but during CPU-heavy preprocessing the GPU remains idle and during GPU-heavy alignment the CPU is underutilized. These instances are billed per second at on-demand rates, which can be several times higher than preemptible pricing. A design that separates preprocessing and alignment into distinct autoscaling VM pools lets each resource scale independently and eliminates paying for idle components.

• ✓

  Use preemptible VMs with CPU for preprocessing and preemptible VMs with GPU for alignment, with checkpointing

  Why this is correct

  Preemptible VMs cost up to 70-80% less than standard VMs and are killed by Google Compute Engine within 24 hours, making them ideal for fault-tolerant batch tasks. By splitting the pipeline into CPU-based preprocessing and GPU-based alignment on separate preemptible VM groups, you avoid mixing resource types and can automatically restart interrupted tasks from checkpointed state. This minimizes compute spend while still completing the analysis, and is the most cost-effective approach for a finite workload.

• ✗

  Use sole-tenant nodes for data isolation

  Why it's wrong here

  Sole-tenant nodes lock a physical server to your project and are typically used to satisfy licensing or regulatory isolation requirements, not to reduce costs. You pay for the entire node, regardless of how many of its vCPUs or GPUs you actually use, and they do not support preemptible pricing or per-second billing at reduced rates. For a data analysis job that simply needs cheap, interruptible compute, sole-tenant nodes would be significantly more expensive without providing any processing benefit.

Go deeper

Related to this question