How to resolve Cloud Composer 2 worker pod evictions and task failures?
Short answer
C Increase the maximum number of workers and reduce worker concurrency.
Question
Key Takeaways
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.
Common mistake: 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.
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
- https://cloud.google.com/composer/docs/composer-2/optimize-environments
- https://cloud.google.com/composer/docs/composer-2/troubleshooting-dags#task-fails-without-logs
These links open the official vendor documentation in a new tab.
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.
Community Votes
44% of anonymous learners picked answer C. Votes are pick records left by other test-takers — they are not the verified answer.
Discussion 12 contributions
Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.
From public community threads 12
-
ML6 👍 7 Answered DIf 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
-
GCP001 👍 4 Answered CC and D Check ref for memory optimization - https://cloud.google.com/composer/docs/composer-2/optimize-environments
-
raaad 👍 3 Answered BB&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.
-
ML6 👍 2 Answered DIf 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
-
taka5094 👍 1 Answered CCD 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.
Show 7 more comments
-
Anudeep58 👍 1 Answered DAnswer 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.
-
qq589539483084gfrgrgfr 👍 1 Answered BB&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
-
virat_kohli 👍 1 Answered DC. Increase the maximum number of workers and reduce worker concurrency. Most Voted D. Increase the memory available to the Airflow workers.
-
qq589539483084gfrgrgfr 👍 3 Answered CCD It is clear
-
Matt_108 👍 2 Answered CC & D to me
-
Jordan18 👍 2 Answered CC and D
-
desertlotus1211 👍 1Answer is B,D
Reader comments & corrections
No reader corrections yet — spotted an error or have a note? Share it below.