Google ACE Practice Question: Your company runs a data processing pipeline on…

Your company runs a data processing pipeline on Cloud Dataproc. The pipeline reads data from Cloud Storage, processes it with Spark, and writes results to BigQuery. Recently, the pipeline has been failing with errors indicating insufficient disk space on the worker nodes. The cluster is configured with standard worker nodes with 100 GB of standard persistent disk. The data size being processed has grown from 50 GB to 150 GB. What is the most cost-effective way to resolve the disk space issue?

⚠ Common exam trap

Google Cloud often tests the misconception that adding more nodes (scaling out) is the default solution for storage issues, but the trap here is that the problem is disk space per node, not cluster capacity, making automatic disk resizing the most cost-effective and operationally efficient fix.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Enable automatic disk resizing for the cluster.

Cloud Dataproc's automatic disk resizing feature dynamically increases the size of persistent disks on worker nodes when disk usage exceeds a threshold (default 90%). This resolves the insufficient disk space issue without manual intervention or additional cost for unused capacity, making it the most cost-effective solution for handling the increased data volume from 50 GB to 150 GB.

Answer analysis

Option-by-option breakdown

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

✗
Increase the size of the persistent disks on the worker nodes to 200 GB.
Why it's wrong here
Manually increasing the persistent disk size on every worker node to 200 GB is a static, one-time change that only helps if the workload's growth is predictable. It does not react to actual disk usage, so you may still run out later, and you pay for the full 200 GB even when only a fraction is used. In contrast, automatic disk resizing grows the disk only when needed, avoiding the up-front over-provisioning cost.
✗
Use local SSDs instead of persistent disks for temporary storage.
Why it's wrong here
Local SSDs are attached to the worker node as ephemeral storage and are designed for low-latency, high-throughput workloads, not for expanding total capacity. They offer high IOPS but a limited per-node capacity, and any data written to them is lost if the node is deleted or recreated. Because the pipeline is running out of disk space, the bottleneck is capacity, not I/O performance, so switching from persistent disks to local SSDs would not solve the problem.
✓
Enable automatic disk resizing for the cluster.
Why this is correct
Enabling automatic disk resizing on the node pool lets GKE monitor persistent-disk usage and grow the disk capacity in real time when utilization crosses a threshold, up to a configurable maximum. This keeps worker nodes operational during data spikes without human intervention, and because the disk only grows when needed, you avoid paying for unused space. It is the correct balance of resilience and cost management for a pipeline with variable data volume.
✗
Increase the number of worker nodes in the cluster.
Why it's wrong here
Adding more worker nodes distributes the pipeline across a larger fleet, but each node still has its original disk size, so a single node that fills its boot disk can still fail. While cluster autoscaling can help with overall CPU/memory pressure, it increases cluster cost and does not increase the capacity of any individual node. The disk-full condition is a per-node storage limit, which automatic disk resizing directly addresses.

Visual reference

Go deeper

Google ACE Practice Question: Your company runs a data processing pipeline on…

Why each option matters

Option-by-option breakdown

Related to this question