How to resolve Cloud Composer 2 worker pod evictions and task failures?

You recently deployed several data processing jobs into your Cloud Composer 2 environment. You notice that some tasks are failing in Apache Airflow. On the monitoring dashboard, you see an increase in the total workers memory usage, and there were worker pod evictions. You need to resolve these errors. What should you do? (Choose two.)

Increase the directed acyclic graph (DAG) file parsing interval.
Increase the Cloud Composer 2 environment size from medium to large.
Increase the maximum number of workers and reduce worker concurrency. Source Reference Answer
Increase the memory available to the Airflow workers.
Increase the memory available to the Airflow triggerer.

Community Votes

44%

41%

15%

44% of anonymous learners picked answer C. Votes are pick records left by other test-takers — they are not the verified answer.

Community Insight

The exam tests whether you know that worker pod evictions are resolved by addressing per-worker memory pressure (C and D), not by broadly increasing environment size or changing DAG parsing.

Worker pod evictions in Cloud Composer 2 are usually caused by out-of-memory conditions in Airflow workers. The community consensus is to reduce worker concurrency and increase worker memory, rather than simply scaling the environment size.

Choosing B (increase environment size) is a common mistake, because scaling the whole environment may seem like a straightforward fix, but it doesn’t target the per-worker OOM issue and is not the recommended solution for worker pod evictions.

Community Discussion (12 comments)

ML6 👍 7 Selected: D

If an Airflow worker pod is evicted, all task instances running on that pod are interrupted, and later marked as failed by Airflow. The majority of issues with worker pod evictions happen because of out-of-memory situations in workers. You might want to: - (D) Increase the memory available to workers. - (C) Reduce worker concurrency. In this way, a single worker handles fewer tasks at once. This provides more memory or storage to each individual task. If you change worker concurrency, you might also want to increase the maximum number of workers. In this way, the number of tasks that your environment can handle at once stays the same. For example, if you reduce worker Concurrency from 12 to 6, you might want to double the maximum number of workers. Source: https://cloud.google.com/composer/docs/composer-2/optimize-environments

taka5094 👍 1 Selected: C

CD On the Monitoring dashboard, in the Workers section, observe the Worker Pods evictions graphs for your environment. The Total workers memory usage graph shows a total perspective of the environment. A single worker can still exceed the memory limit, even if the memory utilization is healthy at the environment level. According to your observations, you might want to: - Increase the memory available to workers. - Reduce worker concurrency. In this way, a single worker handles fewer tasks at once. This provides more memory or storage to each individual task. If you change worker concurrency, you might also want to increase the maximum number of workers. In this way, the number of tasks that your environment can handle at once stays the same. For example, if you reduce worker Concurrency from 12 to 6, you might want to double the maximum number of workers.

desertlotus1211 👍 1

Answer is B,D

Anudeep58 👍 1 Selected: D

Answer C,D According to your observations, you might want to: Increase the memory available to workers. Reduce worker concurrency. In this way, a single worker handles fewer tasks at once. This provides more memory or storage to each individual task. If you change worker concurrency, you might also want to increase the maximum number of workers. In this way, the number of tasks that your environment can handle at once stays the same. For example, if you reduce worker Concurrency from 12 to 6, you might want to double the maximum number of workers.

virat_kohli 👍 1 Selected: D

C. Increase the maximum number of workers and reduce worker concurrency. Most Voted D. Increase the memory available to the Airflow workers.

ML6 👍 2 Selected: D

If an Airflow worker pod is evicted, all task instances running on that pod are interrupted, and later marked as failed by Airflow. The majority of issues with worker pod evictions happen because of out-of-memory situations in workers. You might want to: - Increase the memory available to workers. - Reduce worker concurrency. In this way, a single worker handles fewer tasks at once. This provides more memory or storage to each individual task. If you change worker concurrency, you might also want to increase the maximum number of workers. In this way, the number of tasks that your environment can handle at once stays the same. For example, if you reduce worker Concurrency from 12 to 6, you might want to double the maximum number of workers. Source: https://cloud.google.com/composer/docs/composer-2/optimize-environments

qq589539483084gfrgrgfr 👍 3 Selected: C

CD It is clear

Matt_108 👍 2 Selected: C

C & D to me

GCP001 👍 4 Selected: C

C and D Check ref for memory optimization - https://cloud.google.com/composer/docs/composer-2/optimize-environments

qq589539483084gfrgrgfr 👍 1 Selected: B

B&D See this- https://cloud.google.com/composer/docs/composer-2/troubleshooting-dags#task-fails-without-logs go through the suggested fixes for If there are airflow-worker pods that show Evicted

Jordan18 👍 2 Selected: C

C and D

raaad 👍 3 Selected: B

B&D: B : - Scaling up the environment size can provide more resources, including memory, to the Airflow workers. If worker pod evictions are occurring due to insufficient memory, increasing the environment size to allocate more resources could alleviate the problem and improve the stability of your data processing jobs. D: - Increase the memory available to the Airflow workers. - Directly increasing the memory allocation for Airflow workers can address the issue of high memory usage and worker pod evictions. More memory per worker means that each worker can handle more demanding tasks or a higher volume of tasks without running out of memory.

Comments & Corrections

No comments yet — spotted an error or have a note? Share it below.

Expert Analysis

Why the Answer Is Correct

C and D are correct. During evictions, a worker's memory limit is exceeded, causing the pod to be evicted and tasks to fail. Increasing worker memory (D) directly gives each task more headroom. Reducing worker concurrency (C) means each worker handles fewer tasks simultaneously, lowering peak memory per pod. As comment [1] notes, if you lower concurrency you may also increase max workers to maintain throughput; option C captures both. This is exactly the guidance in the official memory optimization documentation.

Why the Other Options Are Wrong

A (DAG parsing interval) affects scheduler CPU/parsing, not the memory of running worker pods. B (increase environment size) may add resources to the environment, but it is a broad scaling action and doesn't fix the per-worker memory limit that triggers evictions; comment [3] incorrectly suggests B as a solution but official guidance focuses on worker memory and concurrency. E (triggerer memory) is relevant only to triggerer/sensor workloads, not standard worker task execution, so it is irrelevant here.

Community Comment Notes

Several comments (e.g., [1], [5], [6]) cite the official 'optimize-environments' page and explicitly recommend increasing worker memory and reducing worker concurrency. Comment [2] also points to the same reference. A few users chose B&D ([3], [8]), but the described mechanism of evictions—per-worker OOM—points to C and D as the intended pair.

Official Reference

Exam Strategy

When a Cloud Composer question describes worker pod evictions, immediately think 'worker memory' and 'worker concurrency'—not environment size or DAG parsing. Write down that the pair of actions is C and D, and remember that reducing concurrency may require increasing max workers to maintain throughput.

Related Analysis

← Back to PDE Study Guide